Acta videoconferencia del 1 de octubre

Asisten: Málaga, Valencia, Teruel y Sevilla.
Próxima reunión: 15 de octubre

Versión 1.1.1 (Espeto)

Consejo del día

Los consejos sólo se muestran al entrar o cuando se recarga la página.

Sólo hay 9. Se han cogido de las presentaciones de RedIris y de la documentación.

Por ahora se cogen de un array en el fichero de idioma. Más adelante se podría tomar desde otros orígenes, por ejemplo se podría poner en una zona de la web del proyecto.

Para incluir nuevos consejos:

• El texto se sitúa en /opt/opengnsys/www/idiomas/php/xxx/nada_xxx.php en el array $TipOfDay
• Para incluir una imagen asociada al consejo debe situarse en /opt/opengnsys/www/images, ser de formato png y llamarse "tipOfDay_$NUM.png", siendo NUM el índice del array que corresponde al consejo.

Script de migración y actualización

En está versión se ha cambiado el nombre del fichero de la plantilla PXE que arranca el disco duro de '01' a '10' por coherencia con las plantillas que arrancan particiones.

Por otro lado, por compatibilidad con los sistemas UEFI que no tienen sistema operativo en la primera partición, los nombres de las plantilla pasan de ser '1hd-1partition' a '1hd-1os'.

Se modifican los script de migración y actualización para que cambien los nombres de las plantilla antiguas, así como el valor de la plantilla asignada a un equipo en la base de datos cuando es '01'.

#926 bootOsCustom

Tiene ejemplos para que al arrancar una partición de Windows oculte las demás. Se modifica para que soporte varios discos y una partición de datos que no se oculta.

ogLiveAdapter.lib

Al probar el ogLive 5.0 se encontraron problemas en el comando 'read' que se utilizan en muchas funciones del motor de clonación.

Como esto puede pasar cada nuevo ogLive se pensó crear una librería para que las modificaciones especificas para cada ogLive se centralizarán en un punto y las funciones del motor de clonación fueran independientes de ellas.

Al seguir probando se vio que los cambios incluidos en está librería afectaban a muy pocas funciones, por lo que se ha suprimido incluyendo los cambios en los lugares concretos en que se necesitan.

La idea sí parece bien para otras versiones del ogLive.

#919 Browser

Se ha cambiado la creación del browser:

• Cambia la url de descarga de qt.
• Se añaden los ficheros de idioma y nuevas librerías.

Como nueva funcionalidad tenemos un nuevo enlace especial para llamar a un comando que muestre la salida en una ventana emergente.

Se incluye en los ejemplos de menú personalizado.

RemotePC

Se ha modificado la API REST para que la función que reserva los equipos realice el WOL desde el repositorio y el server.

Se incluye documentación de este tema en la parte de usuario, existía pero estaba situada junto a la de desarrollo

setclientmode

Sólo puede utilizar este script el usuario root y el que ejecuta la consola. El usuario de la consola lo toma del propietario del proceso del servicio web, de forma que se generaliza para distintas distribuciones de Linux.

#929 Autenticación de clave pública entre los ogLive

Los ogLive traen una pareja de claves ssl que permite comunicarse sin clave si son de la misma versión.

Para permitir que se puedan comunicar ogLive de distintas versiones se crea el script setsslkey que si existe toma las claves del ogLive por defecto y se la copia a los demás.

• Si no existe la pareja de claves o se utiliza el parámetro "NEW" se crea una nueva pareja de claves.

• Por defecto cambia las claves en todos los ogLive, pero si se le pasa como parámetro el nombre de la iso de un ogLive se cambiará sólo en este.

Las claves están situadas en el segundo sistema de ficheros del ogLive, que es de sólo lectura. La claves creadas por OpenGnsys se guardan dentro del initrd y en el momento del arranque se guardan en el sitio correcto (/root/.ssl)

Por motivos de seguridad no se guardan en un directorio del servidor.

Mejora la seguridad de los ogLive, ya que antes desde cualquiero LiveCd? de la distribución de la que se ha generado el ogLive se podría entrar en los ogLive de OpenGnsys. Ahora cada servidor tendrá su propia clave.

El script se llamará en el script de instalación del ogLive.

#925 APITOKEN servicios

Se crea el script settoken para generar un nuevo token de seguridad para la comunicación entre el repositorio, el server y la consola.

Se pueden generar de forma independiente la clave del repo, del server o de ambos (opción por defecto).

Se llamará en el instalador pero no en el script de actualización. Se hará en la próxima versión.

Error en el inventario de software

Después de enviar el comando desde la consola no se realiza la acción.

Pruebas málaga

Fallaba la bajarse el ogLive. Se debía a la configuración de red que no detectaba el proxy por https.

Al inicio del script de instalación se comprueba la red con el protocolo http, se deben comprobar también https

Al nombrar el tgz de la instalación hay que poner 'last' y no la revisión.

Próxima versión

Iniciar sesión tras restaurar

Como mejora para la próxima versión el comando restaurar de la consola permitirá iniciar la sesión del equipo después de terminar el despliegue.

Está implementado pero no se ha subido al proyecto.

Borra imágenes en repositorios externos

Este comando requiere permisos de root para la API REST. Por seguridad se cambia a la próxima versión.

Renombramos las ramas de git

Ahora tenemos la rama master con la versión estable y la rama de desarrrollo se denomina devel.

A partir de ahora la rama de desarrollo será la master. Se renombrará la rama master por legacy y la devel como master.

Cuando liberemos una versión estable se creará un tag de la misma. Se ha creado el tag de la 1.1.0a con el contenido actual de la rama master.

• El instalador bajará el código del tag correspondiente. Si el instalador está dentro de un archivo comprimido no se va a traer código, sino que usará en que hemos descomprimido.

• El actualizador mostrará un listado de los tag disponible para que quién instale decida a qué versión quiere actualizarse.

GitHub permite bajarse un archivo comprimido con los tag.

Hay de documentar en el wiki el nuevo proceso de actualización y en INSTAL.*.txt.

En github aparece el contenido del README.md. Se pondrá que la documentación de la instalación se puede consultar en installer/INSTALL.en.txt (o installer/INSTALL.es.txt)

Para no repetir la información en varios sitios en el githau

El grupo de desarrollo tendrá que bajarse de nuevo el repositorio, para que no haya conflicto entre la versión actual del master y la nueva. Otra opción es renombrar también las ramas en local y hacer luego un pull.

git branch -m master legacy
git branch -m devel master
git pull