Diario de mi Proyecto : PFC sobre Moodle

  Archivos
Jul 07 [2]
Jun 07 [12]
Mayo 07 [13]
Mar 07 [3]
Nov 06 [6]
Oct 06 [5]


Sindicación
Artículos
Comentarios


Enlaces
eGrupos
ZoomBlog

 
Inicio | Mi Perfil | Suscríbete al blog
 

Ingeniero Informático!

Enlace permanente 14 de Julio, 2007, 18:20

Hola!

Ayer realicé la presentación del proyecto y todo fue muy bien! Me pusieron una nota excelente y la verdad es que estoy bastante contento! Ya soy ingeniero!!

Aquí finalizo el desarrollo de este blog. Espero que sirva de ayuda a los desarrolladores de Moodle!!

Quiero agradecerte Alberto toda tu ayuda y la forma de dirigir el proyecto. Me pareces una excelente persona y un magnífico profesor!

Byeeeeeeee
Comentarios 92 ~ Comentar | Referencias (0)


 

Memoria finalizada!

Enlace permanente 6 de Julio, 2007, 18:38

Hola!

Hoy mismo, después de varios días de agobios y muchísimo trabajo, he acabado la memoria del proyecto y he finalizado, a falta de una revisión de la documentación interna, el módulo Remote Running.

Con respecto a la memoria, poco más que decir, he finalizado los puntos que me faltaban por realizar. Han sido revisados por Alberto y por mí minuciosamente y ahora mismo está en la copistería a la espera de encuadernar!

En cuanto al módulo Remote Running, hay novedades:

  • He conseguido una ejecución remota. Más adelante explico esto.
  • He añadido la opción de compilar y ejecutar en las vistas del profesor. Cuando éste vaya a calificar a sus alumnos, le aparecerá una interfaz parecida a los alumnos, solo con los botones de compilación y ejecución.
  • He corregido la documentación interna y he eliminado código innecesario.
Ejecución remota

Cuando los alumnos necesiten ejecutar sus programas, se conectarán al servidor de forma remota, mediante el protocolo ssh. He integrado un cliente ssh en el módulo, denominado Mindterm. Esto ha sido posible porque este cliente ssh da la posibilidad de ejecutarse como un Applet de Java.

El único requisito es que el servidor donde esté alojado Moodle, cuente con un servidor ssh para aceptar las conexiones de los clientes. Es tarea del administrador de Moodle, localizar un servidor ssh robusto, con métodos de seguridad avanzados.

Esto está casi acabado... este fin de semana terminaré con la presentación y el viernes 13....... EL GRAN DÍA!!!!

Bye!

Referencias: Mindterm, http://www.appgate.com/products/80_MindTerm/
Comentarios 22 ~ Comentar | Referencias (0)


 

Applet de Java y memoria del pfc

Enlace permanente 30 de Junio, 2007, 16:01

Hola gente!

Pues ayer conseguí incluir la posibilidad de crear y ejecutar Applet de Java en el módulo. A punto he estado de tirar la toalla y no conseguirlo, pero con tiempo y paciencia, ha salido todo bien. El único problema es que le he dedicado demasiadas horas y estoy a tope de trabajo...

El módulo ofrece la posibilidad de crear Applets de Java, compilándose y ejecutándose en un pop-up del navegador donde se esté ejecutando el módulo. La única diferencia con respectos a los otros lenguajes, es que hay que pulsar el botón compilar antes de ejecutar el Applet desarrollado. Esto es así, porque para ejecutar el applet, redirecciono a un fichero applet.php que se encarga de crear el link que, una vez pulsado, lanzará el pop-up con el Applet.

Voy a comentar algo que tardé más de lo normal encontrar en Internet. Gcj compila exactamente igual, un applet de java que un programa en java. Para el caso de los applet la sentencia es:

gcj -C applet.java

Gcj creará el .class que será el que habrá que insertar en el fichero .html.

Y como hay bastante prisa, no comento nada más. Solo decir que me quedan dos días bastante duros terminando la documentación del pfc. También tengo que seguir investigando el tema de la ejecución remota, por ahora no tengo nada interesante.

En estos instantes estoy completando el apartado Análisis del sistema de la memoria del pfc.

Bye
Comentarios 39 ~ Comentar | Referencias (0)


 

Última entrega! (11º)

Enlace permanente 29 de Junio, 2007, 9:37

Ya llevo un par de días trabajando en la que será la última entrega de este proyecto.

Esta entrega se compone de muchísimos objetivos. El más importante y general es pulir y acabar de programar el módulo. Ahora mismo he realizado el siguiente trabajo:

  • Función compilar: he mejorado esta función, consiguiendo que se ejecuten los comandos necesarios de gcc para cada lenguaje. Ada ha sido eliminado debido a los errores con GNAT.
  • Opción enunciado: he creado una opción denominada Mostrar enunciado, para que el profesor decida si mostrar el enuncidado de una prueba desde en el momento que comience el examen o tenerlo visible siempre. Se ha incluido un botón de ayuda explicando la utilidad de esta opción.
  • Ficheros de ayuda en inglés: he creado todos los ficheros de ayuda en inglés.
  • Fichero idioma inglés: he traducido el fichero de idioma del módulo al inglés.
  • Cambio de nombre de actividad offline por actividad y examen por prueba.
  • Inserción del botón código: he insertado un botón llamado código. Este botón insertará un lenguaje predefinido (Hola mundo) en el lenguaje de programación del módulo.
  • Función reserve_words: esta función ha sido mejorada y cambiada de nombre a prohibited_words.
  • Ejecutables y fuentes en espacio de usuario: he mejorado la creación de fuentes y ejecutables. En este momentos los archivos se crean en el espacio de usuario del alumno que utilice el módulo.
  • Memoria del proyecto: he terminado los 4 primeros capítulos de la memoria, junto con el resumen y se los he enviado a Alberto para su posterior revisión.
Me queda por realizar:
  • Finalizar la memoria del proyecto: restantes capítulos, análisis, diseño, manual de usuario, programador, etc.
  • Documentación interna: revisar la documentación interna ya realizada.
  • Incluir lenguaje Applet Java: se va a dar la posibilidad de crear Applet de Java y ejecutarlos.
  • Funcionamiento en Linux: instalaré Linux en mi equipo para probar el funcionamiento de este sistema operativo.
  • Investigación: seguir con la investigación de la ejecución remota.
También he necesitado mejorar los botones de descarga de ficheros ejecutable y fuente, debido al cambio de almacenamiento de los mismos.  Esto me ha dado algún que otro problema ya que antes estaban en la misma ruta que la web, y con un simple formulario "action = nombre_ejecutable" funcionaba bien. Como esto me ha llevado mucho tiempo y ha sido complicado de descubrir, voy a poner el código exacto, para el caso del ejecutable, por si alguien lo necesita:

$dir = $CFG->dataroot.'/'.$course->id.'/'.$CFG->moddata.'/remoterunning/'.$remoterunning->id.'/'.$USER->id.'/'.'program.exe';
              if (file_exists($dir)) {
                      $filearea = $remoterunninginstance->file_area_name($USER->id);
                      $file = 'program.exe';
                      if ($CFG->slasharguments) {
                         $ffurl = "$CFG->wwwroot/file.php/$filearea/$file";
                      }  
                      else {
                         $ffurl = "$CFG->wwwroot/file.php?file=/$filearea/$file";
                       }
                       echo '  <td>';
                       echo '      <form enctype="multipart/form-data" method="post" '."action=\"$ffurl\">";
                       echo '      <input type="submit" name="download"  value="'.get_string("program","remoterunning").'">';
              echo '      </form>';
              }


No voy a entrar más en detalles del trabajo que he realizado en los primeros puntos, ya que necesito acabar toda la documentación para el martes y estoy bastante agobiado. Si alguien necesita ayuda, que me deje comentarios y le contestaré encantado.

Bye.

Comentarios 29 ~ Comentar | Referencias (0)


 

Entrada de datos desde fichero

Enlace permanente 26 de Junio, 2007, 2:52

Hace unos días probé la entrada de datos a un programa desde un fichero.

Realicé un sencillo programa en C (program.exe), con una instrucción scanf y otra printf, mostrando el dato pedido. Luego creé un archivo con un único número (datos.txt), y al poner la instrucción:

program < datos.txt

Se mostraba el dato por pantalla. Realicé varias pruebas con varias instrucciones scanf, con enteros y caracteres, con string, etc., siempre poniendo en cada línea de un fichero el dato adecuado. Todas las pruebas que realicé fueron satisfactorias, e incluso redireccionando la salida a la vez también funcionaba, es decir, la instrucción:

program < datos.txt > salida.txt

Si los datos del fichero son incorrectos, no correspondiéndose con el tipo de datos esperado por el programa, los fallos que se producen son del mismo tipo que si se introdujeran por teclado erróneamente.

Me falta por invetigar la integración de la consola en el navegador.

Bye
Comentarios 27 ~ Comentar | Referencias (0)


 

SSH

Enlace permanente 25 de Junio, 2007, 23:22

Mal asunto para utilizar ssh a la hora de ejecutar remotamente un ejecutable en mi módulo.

Por lo que he estado viendo en los enlaces que pongo en referencias, ssh sirve para ejecutar programas remotamente, pero para ello es el cliente quien tiene que iniciar la sesión, no siendo posible abrir una sesión desde el servidor, pues uno de los requisitos es contar con un "daemon ssh" en el ordenador que se quiere conectar.

Tendré que ver si se puede integrar la consola con el navegador. Mañana comentaré sobre la redirección datos de entrada desde un fichero.

Referencias:

Sesión gráfica remota: http://www.riveonline.com/index.php/blog/show/Sesin_grfica_remota_UbuntuMandrake_con_ssh.html

SSh tricks:
http://en.jakilinux.org/apps/ssh-tricks/
Comentarios 22 ~ Comentar | Referencias (0)


 

Fortran y ADA

Enlace permanente 25 de Junio, 2007, 14:12

Acabo de perder más de 3 horas configurando el módulo para que funcione con FORTRAN...
Al principio pensaba que la causa era los dintintos tipos de FORTRAN que existen, 77, 90, 95, etc. He elegido 90 porque es actual. He probado con varios programitas típicos y aún así no funcionaba...

Después de analizar soluciones como tirar el ordenador por la ventana o a la piscina, he probado con instalar el paquete gfortran en otro ordenador y ha funcionado perfectamente.

No sé la causa de que no funcione en mi ordenador, pero bueno, eso no es problema. He configurado el módulo para que funcione bien y llame al compilador correctamente.

Y ya que estoy escribiendo, la sintaxis correcta de gfortran es:

  • Para compilar: gfortran -c code.f90
  • Para compilar y crear un ejecutable: gfortran code.f90 -o program
Si se quiere programar en una versión distinta, solo hay que cambiar la extensión del archivo asegurándose de que el código es el correcto para la versión que se necesite.

Esta tarde me pondré con el último lenguaje, ADA y actualizaré el artículo con los resultados.

Bye


ACTUALIZACIÓN

Está claro que hoy no es mi día... Otras tantas horas perdidas con gnat... Y lo peor de todo es que no funciona, nada de nada. Por ahora, ADA queda en suspenso. Hablaré con Alberto sobre este tema y tomaré una decisión.

¿Y cuál es el problema? Pues que si a gnat le paso el path de un fichero, no funciona. Así de simple y así de extraño. Y el módulo funciona con los path de los ficheros, no es posible trabajar solo con el nombre del fichero :-(

Comentarios 30 ~ Comentar | Referencias (0)


 

Botones de ayuda y compilación con gcj

Enlace permanente 25 de Junio, 2007, 9:53

He insertado botones de ayuda en la interfaz del módulo. Estos botones son fáciles de crear, simplemente hay que utilizar la función helpbutton() y crear el fichero de ayuda correspondiente. Los ficheros de ayuda se crean en la carpeta lang/carpeta_idioma/help/nombre_módulo. En el caso de remote running sería lang/es_es_utf8/help/remoterunning. Aquí se crean los ficheros html correspondientes.

Con el lenguaje Java he tendido el siguiente problema. La forma de compilar y crear un ejecutable con gcj es la siguiente:


gcj -o Foo --main=Foo Foo.java
Siendo el código el siguiente:

public class Foo
{
public static void main(String args[])
{
System.out.println("Hello.");
}
}

Es decir, el nombre del archivo tiene que ser el nombre de la clase principal y hay que pasarle el nombre de la
clase donde se encuentre el main. Para realizar esto correctamente he creado dos áreas de texto en la interfaz,
que se activarán cuando el lenguaje utilizado sea Java. En estas áreas, el usuario tendrá que indicar al sistema el
nombre que tendrá el fichero y el nombre de la clase main.

He tenido que modificar las funciones de llamada a la compilación y ejecución, añadiendo parámetros para recoger
el nombre del fichero y de la clase main.

Captura de pantalla con botones de ayuda y áreas de texto para el lenguaje Java:





Comentarios 25 ~ Comentar | Referencias (0)


 

Permisos en el módulo

Enlace permanente 23 de Junio, 2007, 2:23

Este artículo lo escribo para comentar un asunto muy importante de Moodle y de los módulos.

Recientemente he descubierto los permisos para aplicar a los módulos. No voy a entrar mucho en detalles, pues todo está más o menos bien explicado en la web de Moodle (a veces un poco cutre porque son traducciones literales del inglés...).

Los permisos en un módulo se crean para dar derechos a los usuarios del módulo. Estos usuarios son conocidos como roles en la plataforma. Un rol puede ser: administrador, profesor, estudiante, creador de un curso, etc. Más sobre roles pinchando en este enlace.

Mediante los permisos puedo establecer que sea solo el profesor el que tenga la capacidad de calificar a un alumno, que sea el administrador quien pueda eliminar o crear el curso, o que sea el profesor, etc., es decir, aplico derechos a los distintos roles de la plataforma. Los permisos también pueden diferenciar cada vista particular de un rol sobre el módulo, es decir, un profesor tendrá un vista distinta a un alumno en una tarea cuando, por ejemplo, haya que subir un archivo. El alumno verá el formulario de subida de archivos, pero el profesor no. Todo esto se consigue con la creación de permisos o capacidades en la actividad a desarrollar.

¿Cómo se definen estas capacidades? Hay que crear un archivo, denominado access.php, en la carpeta db del módulo. El nombre de la variable de los permisos, junto con los permisos, tienen que ser exactamente igual que el nombre del módulo. Por ejemplo, si quiero crear un permiso para que solo el profesor pueda calificar a los alumnos, el código será el siguiente:



<?php

$mod_remoterunning_capabilities = array(

    'mod/remoterunning:grade' => array(

        'captype' => 'write',
        'contextlevel' => CONTEXT_MODULE,
        'legacy' => array(
            'teacher' => CAP_ALLOW,
            'editingteacher' => CAP_ALLOW,
            'admin' => CAP_ALLOW
        )
    )
);

?>


Como se puede comprobar, el nombre de la variable y de los permisos es igual que el nombre del módulo (remoterunning). Más sobre permisos, capacidades y roles en este
enlace.

Estos permisos se generan en la plataforma cuando se instala el módulo. Para comprobar que un usuario particular posee los permisos que hemos desarrollado hay que entar en Moodle como administrador e ir a
Administración del Sitio>>Usuarios>>Permisos>>Definir roles. Posteriormente habrá que pinchar en el rol a comprobar.

Bye
Comentarios 29 ~ Comentar | Referencias (0)


 

10º Entrega

Enlace permanente 21 de Junio, 2007, 11:34

Hola,
pues en esta entrega tengo que comentar bastantes asuntos. Primero comenzaré con la programación del módulo, he realizado cambios en el módulo y he añadido clases para diferenciar los distintos tipos de actividad. He realizado cambios en la interfaz del módulo, documentación interna, he continuado trabajando en la memoria del pfc y he comenzado a investigar soluciones a la ejecución remota.

Programación del módulo

Para realizar una correcta programación de la actividad y conseguir una integración adecuada en Moodle, he decidido trabajar con clases y objetos. El módulo tendrá tres clases, una será la clase base, denominada remoterunning_base y las otras clases serán extendidas, es decir, clases que heredan de remoterunning_base y se denominan remoterunning_offline y remoterunning_uploadsingle

He tomado esta decisión porque el módulo está orientado de dos formas distintas. Una es para que los alumnos puedan compilar y ejecutar sus programas desde la plataforma. Será una tarea en la que el profesor no intervendrá, los alumnos la utilizaran en el momento que esté disponible.

La otra forma de utilizar el módulo será como un examen, los profesores podrán evaluar los conocimientos de programación a sus alumnos, el módulo da la posibilidad de subir el fichero fuente con los resultados, el profesor podrá calificar, recibirá un mail de aviso cuando los alumnos envíen sus ficheros, etc. Es muy parecida a la opción "subir un único fichero" de la actividad tarea.

En cuanto a la documentación del código fuente, he comenzado a realizarla. En cada fichero he introducido una pequeña cabecera, como la siguiente:

/**
 * Fichero para una vista particular de una instancia del módulo.
 * Contiene el código para escribir problemas y compilarlos o ejecutarlos.
 *
 *
 * @author Francisco Javier Rodríguez Martín
 * @version $Id: view.php,v 1.0 2007/06/14 16:41:20 mark-nielsen Exp $
 * @package remoterunning
 **/

Y cada función de la librería lib.php y de las clases creadas está comentada. Indico lo que hace cada función y para qué sirven los parámetros. Por ejemplo, para la función remoterunning_compiler($language,&$compiler,$route):

/**
 * Esta función devuelve el comando a ejecutar según el lenguaje
 * que se haya configurado el módulo
 *
 * @param $language El lenguaje de programación del módulo
 * @param &$compiler El comando final de ejecución
 * @param $route La ruta del fichero a ejecutar o compilar
 **/

Interfaz de la actividad

He realizado cambios en la interfaz del módulo, ahora aparecen la consola de código fuente al comienzo, los botones en medio y la consola con los mensajes al final. Cuando se inicia la actividad, solo aparecen los botones de compilar y ejecutar. Una vez que el usuario compila o ejecuta su código, al crearse los ficheros fuente y ejecutable, el sistema lo detecta y aparecen los botones de download pertinentes. He añadido también un botón de ayuda que explicará al usuario, para qué sirve cada botón de la actividad. Una captura de pantalla:




































Memoria del proyecto


He continuado estos días con el documento de memoria del proyecto. He realizado el apartado Planificación, en la que hablo sobre la metodología de programación y las fases de desarrollo del proyecto. Los siguientes apartados que realizaré son el análisis y el diseño de la actividad.

Investigación para la ejecución remota

Como último trabajo del módulo, tengo que investigar si es posible una ejecución remota de los programas escritos por los usuarios del módulo.

Si no existieran instrucciones de entrada, sería posible redireccionar a un fichero y mostrar la salida. Como se quiere controlar estas intrucciones, voy a  investigar varias cuestiones:
  • Intentar integrar la consola del SO en el navegador.
  • Investigar código de Eclipse para ver como redireccionan la consola.
  • Crear applet de Java con terminal de SO.
  • Redirección de entrada desde fichero.

A currar!

Bye
Comentarios 26 ~ Comentar | Referencias (0)


 

Módulo integrado!

Enlace permanente 17 de Junio, 2007, 12:44

Hola!
Pues después de tres días programando como un loco, he conseguido la integración absoluta en la plataforma!! Todas las funcionalidades básicas de Moodle se ejecutan adecuadamente, es decir, la calificación, subida de ficheros, envío de mail al profesor, apertura y cierre de la actividad, etc.

He conseguido la integración en la plataforma! Esto es muy importante porque era un objetivo esencial del proyecto!

Y como estoy a punto de tirar el portátil por la ventana, descanso y mañana continuo actualizando el blog. Comentaré aspectos de la programación del módulo. También voy a continuar con la memoria del proyecto y la documentación interna del módulo.

Bye
Comentarios 25 ~ Comentar | Referencias (0)


 

Reorganización del módulo

Enlace permanente 15 de Junio, 2007, 9:30

Hola!
Hace un par de días, me di cuenta que para conseguir ciertas características en Remote Running, tenía que comenzar a programarlo de nuevo, sirviéndome lo que llevo realizado hasta ahora. Las características que necesito controlar son la subida de archivos por parte de un alumno y la calificación de una entrega por parte del profesor.

Estas dos opciones requieren controlar muchos aspectos internos del módulo, por ejemplo, cada vez que un alumno suba un fichero, éste tiene que llegar al profesor pudiendo calificarlo. Cuando el profesor acceda al módulo se le mostrará una lista con los alumnos y sus respectivos archivos subidos, si están calificados o no, etc. Lo que realmente se califica es el problema que mande el profesor, no el archivo en sí, es decir, un profesor realizará un examen de programación, el alumno enviará un fichero como resultado del examen. Por lo tanto, el profesor, basándose en el fichero resultado, calificará el problema.

Con todo lo anterior quiero dejar claro que todas las opciones que forman un módulo suelen estar relacionadas entre sí, lo que requiere una programación estructurada, utilizando si es posible clases para diferenciar las distintas funcionalidades de un módulo. Por lo tanto, he comenzado a programar el módulo de nuevo. A partir de ahora el módulo tendrá dos posibles finalidades:

  • Offline: será un módulo que los alumnos utilicen para compilar y ejecutar sus problemas de programación. No requiere la intervención del profesor. Estará siempre disponible para los alumnos, dentro de las fechas de apertura y cierre que indique el profesor.
  • Examen: el módulo estará orientando a una actividad que se podrá calificar. Los alumnos deberán subir sus archivos fuente como resultado final. Este trabajo será calificado por el profesor.
Centrándome en temas de programación: he utilizado POO para desarrollar el módulo, tengo una clase remoterunning_base y una clase remoterunning_uploadsingle para diferenciar la funcionalidad Offline y Examen. La clase remoterunning_uploadsingle hereda de la primera. Además he reformado la tabla inicial, he añadido permisos con el archivo access.php, etc.

En próximos días comentaré más detenidamente los métodos de programación, ahora a seguir trabajando. La opción Offline funciona perfectamente, voy a seguir programando la segunda funcionalidad, muchísimo más complicada.

Saludos
Comentarios 9 ~ Comentar | Referencias (0)


 

Realizando funciones

Enlace permanente 11 de Junio, 2007, 19:06

Hola!
Durante estos días he seguido con la programación del módulo. He añadido más objetivos a esta entrega, como los siguientes:

  • Función source_route para los ficheros fuente: esta función devolverá en un parámetro las diferentes rutas de los ficheros fuente, según el lenguaje configurado en el módulo.
  • Función source_file: esta función creará el fichero fuente con la extensión adecuada al lenguaje utilizado en el módulo.
  • Actualizar el código de funciones predeterminadas del módulo: funciones como update_instance o delete_instance aparecen vacías y he de programarlas adecuadamente.
  • Botón upload: si he permitido la opción de subir un fichero, o el módulo está enfocado como examen, he de incluir un botón que suba archivos de los usuarios y los reciba el profesor adecuadamente.
  • Email al profesor: he de configurar esta opción correctamente.
También he estado trabajando con los objetivos del anterior artículo:

Ya he eliminado las rutas del estilo D:\appservmoodle... por sus equivalentes $CFG->dirroot."moodle...". También he creado la función source_route que devuelve las rutas de los ficheros fuente, según el lenguaje utilizado en el módulo, ya que tendrán distinta extensión:

function REMOTERUNNING_source_route($language,&$route) {
    global $CFG;
           
    switch ($language) {
          case 0: $route = $CFG->dirroot."modRemoteRunning\file.c";
                  break;
          case 1: $route = $CFG->dirroot."mod\RemoteRunning\file.cpp";
                          break;
          case 2: $route = $CFG->dirroot."mod\RemoteRunning\file.java";
                  break;
          case 3: $route = $CFG->dirroot."mod\RemoteRunning\file.ada";
                  break;
          case 4: $route = $CFG->dirroot."mod\RemoteRunning\file.f";
                  break;                                     
          case 5: $route = $CFG->dirroot."mod\RemoteRunning\file.c";
                  break;
              }
    }

En cuanto a las variables del formulario, ya se recogen todas correctamente para su posterior tratamiento. He tenido que modificar la tabla del módulo, quedando de la siguiente manera:

CREATE TABLE `prefix_REMOTERUNNING` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `course` int(10) unsigned NOT NULL default '0',
  `name` varchar(255) NOT NULL default '',
  `description` text NOT NULL default '',
  `timedue` int(10) unsigned NOT NULL default '0',
  `timeavailable` int(10) unsigned NOT NULL default '0',
  `language` tinyint(1) unsigned NOT NULL default '0',
  `exam` tinyint(1) unsigned NOT NULL default '0',
  `grade` int(10) NOT NULL default '0',
  `timelimit` int(10) NOT NULL default '0',
  `upload` tinyint(2) unsigned NOT NULL default '0',
  `resubmit` tinyint(2) unsigned NOT NULL default '0',
  `emailteachers` tinyint(2) unsigned NOT NULL default '0',
  `maxbytes` int(10) unsigned NOT NULL default '100000',
  `timemodified` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`)
) COMMENT='Define REMOTERUNNING';

He creado la función reserve_words, que devolverá un mensaje de error en el caso de que se intente utilizar funciones del estilo exec(), system(), etc. Esta función revisará el código y suspenderá la compilación y ejecución, si se encuentran funciones potencialmente dañinas para el sistema. Esta función no está terminada, y que tengo que investigar el cógigo ADA, FORTRAN y JAVA para averiguar funciones de ejecución de programas:

function REMOTERUNNING_reserve_words($language,&$read,$text) {
       
    switch ($language) {
       
        case 0: $list = array    ("shell_exec","exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;
        case 1: $list = array    ("shell_exec","exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                        break;
        case 2: $list = array    ("exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;
        case 3: $list = array    ("exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;
        case 4: $list = array    ("exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;                                     
        case 5: $list = array    ("shell_exec","exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;
              }
        return 1;
            }

Mensajes de error. Ahora mismo estoy trabajando en este aspecto. La idea es que si se pulsa el botón de download del ejecutable o fichero fuente, y estos ficheros no existen, mostrar un error y volver a la vista del módulo. Por ahora consigo lanzar el error, pero al volver a la vista del módulo, se produce un error de seguridad que tengo que corregir.

Mañana más.

Bye
Comentarios 6 ~ Comentar | Referencias (0)


 

9º entrega

Enlace permanente 8 de Junio, 2007, 10:47

Después de 1 semana estudiando uno de los dos exámenes que me quedan para finalizar las asignaturas, continuo con el proyecto.

Se ha producido un fallo importante en la realización del proyecto, ya que la forma de ejecución de los programas desarrollados por el usuario en el módulo no es correcta. Si se ejecuta los programas desde una consola del SO, solo se visualizará en el servidor y no en el cliente, por lo tanto esta solución no es válida y tengo que pensar en otra forma de hacerlo.

He modificado la interfaz del módulo, para así tener más espacio para escribir el código. He añadido dos botones más, uno llamado compilar y otro llamado fuente. El primero realizará solo la compilación del código escrito por el usuario y el segundo permite descargar el código en un fichero.

También realizaré lo siguiente:

  • Mensajes de error: controlaré ciertos fallos que se puedan producir en el módulo, lanzando mensajes de error. Puede pasar que un usuario pinche el botón de descarga del programa y no haya ningún ejecutable creado.
  • Eliminar directorios: programaré adecuadamente las rutas de los ficheros con variables del tipo $dirroot y $wwwroot, eliminando la forma actual (D:\appserv\moodle...)
  • Recoger variables del formulario: modificaré la tabla del módulo para que recoja las variables de configuración.
  • Función palabras reservadas: mediante esta función se revisará el código para detectar palabras reservadas que se puedan utilizar para un uso fraudulento de la aplicación. Por ahora, este será el método para controlar el código malicioso.

Comentarios 4 ~ Comentar | Referencias (0)


 

8º entrega finalizada

Enlace permanente 30 de Mayo, 2007, 10:35

Acabo de finalizar el documento de la 8º entrega. El proyecto va fenomenal y creo que ha entrado en la recta final.

A partir de esta entrega me voy a centrar en el formulario de opciones, es decir, que las opciones que se configuran funcionen perfectamente. Voy a ir programando también las distintas instrucciones de compilación para los distintos tipos de lenguaje, modificaré la interfaz para que recoja la descripción del módulo, o enunciado del problema, y el botón de subida de archivos lo programaré para que aparezca cuando se indique en las opciones.

Mañana tengo reunión con Alberto y probablemente acordemos más trabajo. Aunque esta semana reduciré el tiempo al proyecto ya que el 7 de junio tengo el último examen difícil de la carrera (me quedan dos) y le dedicaré casi todo el día.

Bye
Comentarios 25 ~ Comentar | Referencias (0)


 

Tercer problema solucionado!!

Enlace permanente 28 de Mayo, 2007, 0:12

Genial!
Gracias al foro de desarrolladores de Moodle me han informado que la función stripslashes() devuelve el texto original sin las medidas de seguridad que aplica la plataforma. Con la utilización de la misma, he solucionado este problema y la compilación y ejecución de código se realiza con total normalidad.

A seguir programando! Byeee


Comentarios 15 ~ Comentar | Referencias (0)


 

Problema de Moodle al recoger texto

Enlace permanente 27 de Mayo, 2007, 21:22

Vaya tardecita que llevo... Casi tres horas con el mismo problema... Creo que está solucionado, aunque tendré que hacer más pruebas.

Resulta que esta tarde he estado programando la forma en que voy a capturar el texto introducido desde una de las consolas por un usuario y pasarlo a un archivo para así compilarlo y ejecutarlo. Pero antes de esto, he tendio otros dos problemas que he tardado en solucionar.

Primer problema

El botón ejecutar. Necesitaba que el botón fuera de acción y no de formulario, es decir, pulsar y que se lance el proceso de compilación y ejecución. Pues resulta que en PHP no existen los botones interactivos, tenía que hacerlo en JavaScript con lo que no podía utilizar las funciones ya desarrolladas en PHP.
Investigando un poco encontré el siguiente código para "engañar" a PHP y que se produzca la acción deseada:

<?php
if( $_POST['ActBack']  == "1" && isset($_POST['ActBack'])){
              REMOTERUNNING_running($result,$text);
            }
?>

El código anterior se declara al comienzo de la página, y dentro del formulario:

<input type="hidden" name="ActBack" value="0">   
      <input type="submit" name="btnBack "value="Ejecutar" onClick = "eval('ActBack.value=1')">

Con lo anterior, el botón funciona perfectamente y al pulsarlo se ejecuta la función REMOTERUNNING_running();

Segundo problema

La ejecución de los programas los realizaré mediante la consola del sistema, pero los mensajes de error y warnings del compilador he preferido mostrarlos en la interfaz del módulo. Para representar un cuadro donde mostrar los mensajes utilicé la función print_textarea() para mostrar texto, pero al pasarle una variable con la información, aparecía todo seguido, sin retornos de carro.

Para solucionar esto, creé un pequeño FRAME dentro de la misma página, pero no conseguía pasarle el texto de ninguna forma así que he optado por crear una tabla con "Scroll" y css, es decir, que si los errores sobrepasan el tamaño de la ventana, se visualizará un scroll para navegar y ver toda la información.

Esto lo he conseguido con el siguiente código:

<style type="text/css">
            td.scroll
            {
                width: 420px;
                height: 260px;
                font-family: verdana;
                font-size: 11px;
                color: #ccddee;
                background-color: #203b59;
                scrollbar-base-color: #203b59;
                scrollbar-3d-light-color: #a0bbd9;
                scrollbar-arrow-color: #a0bbd9;
                scrollbar-darkshadow-color: #203b59;
                scrollbar-face-color: #203b59;
                scrollbar-highlight-color: #809bb9;
                scrollbar-shadow-color: #809bb9;
                scrollbar-track-color: #203b59;
                }
        </style>
...

<td><table width="420" height="260"><tr><td class="scroll"><div style="width: 100%; height: 100%; overflow: auto;"><p aling="left"><?php echo $result; ?></p></div></td></tr></table></td>


















Tercer problema

La propia captura del texto... Esto me ha dado muchísimos problemas. La solución ha sido sencilla, aunque estoy investigando alguna más.

Resulta que a la hora de capturar texto del usuario, Moodle posee un sistema de seguridad para no ejecutar código sql malicioso. Resulta que si se añade dobles comillas (" ") a un texto en un formulario, Moodle introduce barras invertidas para desactivar posibles instrucciones sql. Si introducimos texto como printf("Hola mundo"), Moodle lo convierte en printf(\"Hola mundo\") con lo cual se producen errores de compilación.

Por ahora no es posible desactivar esta medida de seguridad, pero lo que he realizado es tratar la cadena como un todo y sustituir esas \" por " o "\ por " de la siguiente manera:

$text= str_replace(' \" ',' " ',$text);
$text= str_replace(' "\ ',' " ',$text);


Con la solución de los problemas anteriores ya tengo el módulo muy avanzado con la funcionalidad que se marcó en los objetivos del proyecto. A partir de este momento, me centraré en la programación de las opciones, de los distintos lenguajes y puliré el código adaptándolo a las normas de estilo de Moodle.

Bye


Comentarios 20 ~ Comentar | Referencias (0)


 

Consola controlada

Enlace permanente 26 de Mayo, 2007, 10:37

Hola!

Ya tengo el problema de lanzar la consola del SO controlada. E incluso he descubierto varias instrucciones muy interesantes. Resulta que era problema de mi ordenador. Cuando se inicia, está ejecutándose ya el servidor httpd de Apache. Solo tengo que pararlo y volver a iniciarlo manualmente.

Por lo tanto instrucciones como exec(cmd.exe /K start program.exe) funcionan perfectamente, lanzándose la consola y visualizando los resultados. El usuario será el encargado de cerrar esta consola.

Ahora mismo estoy trabajando en el proceso de compilación y ejecución de un fichero con PHP. Cuando termine actualizaré este artículo y expondré los resultados.

Bye

ACTUALIZACIÓN

Proceso de compilación y ejecución de programas finalizado y funcionando perfectamente. Código utilizado:

$so = getenv("HTTP_USER_AGENT");
system('gcc d:\misdoc~1\g.c 2>compilar.txt',$valorgcc); //Con esto recojo el valor devuelto por gcc
if(!$valorgcc) {  
       if (preg_match("/win/i",$so)) {
       shell_exec('start D:\AppServ\www\moodle\mod\RemoteRunning\a.exe');
       }
      else {
      shell_ex a.exe');
 unset($result);

      $result = 'ENHORABUENA'.'<BR>'.'Su programa ha sido ejecutado satisfactoriamente.';
}

 else {
     REMOTERUNNING_read_compilation($result);
}


Como el módulo tiene que funcionar tanto en Windows como en Unix, en la variable $so almaceno el SO en el que me encuentro. Lanzo la compilación del fichero con gcc y devuelvo el valor en $valorgcc. Si el proceso finaliza correctamente ($valorgcc = 0) ejecuto el fichero a.exe desde una consola. Si en la compilación hay errores ejecutaré la función REMOTERUNNING_read_compilation(), creada en lib.php, que se encargará de leer las líneas del fichero compilar.txt con los errores de compilación, para posteriormente mostrarlos en una consola del módulo.

El código de la función REMOTERUNNING_read_compilation(&$read) es el siguiente:

function REMOTERUNNING_read_compilation(&$read) {
   
    $chain = array();
    $i = 0;
    $fp=fopen(FILE_COMPILATION,'r');
    while(!feof($fp)) {
        $chain[$i] = fgets($fp);
        $i++;
        $chain[$i] = "<BR>";
        $i++;
    }
    $read=implode("",$chain);
    fclose($fp);
}  

El código de ejecución de unix contiene errores que corregiré más adelante, para lanzar el programa creado desde unix no será con 'bash a.exe'. Todavía tengo que investigar esto. Cuando finalice el proyecto para Windows lo modificaré para que funcione perfectamente para Unix.

Bye
Comentarios 2 ~ Comentar | Referencias (0)


 

Comenzando una nueva entrega

Enlace permanente 25 de Mayo, 2007, 18:44

Hola!

Ya estoy trabajando en una nueva entrega. Ésta va a estar centrada sólo y exclusivamente en programar el módulo Remote Running. Después de una reunión con Alberto, hemos decidido cambios importantes:

  • Seguridad código malicioso: se puede detectar código malicioso en el programa del usuario revisando el código para buscar instrucciones tipo exec o system.
  • El ejecutable será lanzado por consola sin redireccionar la salida a un fichero para no perder interactividad con el usuario. Esto ocasiona un problema en PHP, ya que éste no ofrece múltiples hilos de ejecución. Si lanzo un programa sin redireccionar la salida a un fichero, PHP esperará a finalizar la ejecución con lo que no se podrá controlar el tiempo de ejecución. Por lo tanto, esta opción será descartada por el momento. Investigaré la web Multi-threading strategies in PHP » Implicit Evaluation with PHP, en la que proponen un pseudo multi-hilo para PHP.
  • Varias opciones nuevas:
    • Permitir reenvío.
    • Email al profesor.
    • Tamaño máximo de fichero subidos al servidor.
    • El tiempo máximo de examen será renombrado a límite de tiempo.
A trabajar!
Comentarios 22 ~ Comentar | Referencias (0)


 

7º entrega finalizada

Enlace permanente 23 de Mayo, 2007, 17:27

Hola!
Acabo de terminar la 7º entrega de este proyecto. He finalizado la entrega con la ejecución controlada en tiempo de los programas que se ejecutarán en Remote Running. Voy a controlar este tiempo para abortar la ejecución de aquéllos que lo sobrepasen.

En cuanto a la ejecución segura de código malicioso, no tengo muy claras las cosas. He visto que www.codeide.com no reconoce funciones como system() o exec(). Esto seria interesante para asegurarse que el usuario no puede ejecutar comandos dentro del servidor como del, rm, etc. El único problema es que tengo que averiguar como lo han conseguido... Retomaré este problema si al finalizar la programación del módulo me sobra tiempo para poder implementar algo interesante.

Otro problema me está surgiendo a la hora de lanzar la consola (cmd.exe, en el caso de Windows) desde el módulo. Estoy comprobando que la ejecución se produce en segundo plano, es decir, cmd.exe se ejecuta pero el SO no muestra el terminal. Esto no es un problema a la hora de compilar, pero necesito mostrar la consola al usuario para que interactúe con los programas ejecutados.

Ahora mismo estoy probando con instrucciones como las siguientes:

exec("cmd.exe /C start gcc d:\misdoc~1\g.c");
exec('cmd.exe /C start D:\AppServ\www\moodle\mod\RemoteRunning\a.exe');

El argumento start debería lanzar la consola, pero esto no se produce. En la primera instrucción no es necesario mostrar la consola, pero sí al ejecgram.exe ya que si el programa necesita interactuar con el usuario, es necesario mostrar algún tipo de terminal.

Seguiré investigando este tema.

Byeee

Comentarios 26 ~ Comentar | Referencias (0)



Blog alojado en ZoomBlog.com

 

 

<<   Octubre 2020    
LMMiJVSD
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Categorías
General [41] Sindicar categoría