| 1 | [[TOC(heading=Índice)]] |
| 2 | = Acta videoconferencia 13 de Julio 2011 = |
| 3 | Asisten: Málaga, Huelva, Barcelona y Sevilla |
| 4 | |
| 5 | Próxima reunión: Miércoles 21 septiembre 10:30 |
| 6 | |
| 7 | == Versión 1.0.2 == |
| 8 | |
| 9 | Se decide estabilizar la versión con los cambios necesarios para poder tener opengnsys en marcha el próximo curso. Fecha de aproximada de liberación final de julio. |
| 10 | |
| 11 | Cambios que se están realizando: |
| 12 | |
| 13 | === Estructura de servidores descentralizada === |
| 14 | |
| 15 | Se tiene un servidor de administración central y varios repositorios. |
| 16 | |
| 17 | Ha habido que realizar modificaciones en distintos sitios: |
| 18 | * /opt/opengnsys/client/etc/preinit/mountrepo.sh -> variable rootserver no cogia ip del repo sino del server |
| 19 | * /opt/opengnsys/www/gestores/gestor_pxe_*-php -> no tomaba la variable repo |
| 20 | * librería que incluye: ogGetIpRepo |
| 21 | |
| 22 | === Wake on lan entre dos subredes === |
| 23 | |
| 24 | Se tiene el servidor de arranque remoto en distinta subred que los clientes. Tenemos dos soluciones según podamos configurar o no nuestra red: |
| 25 | |
| 26 | * Los router dejen pasar estos paquetes. |
| 27 | * El server se conecta por ssh al repo y les manda las mac de los equipos que hay que arrancar, el repo manda la orden wake on lan. |
| 28 | |
| 29 | === Menú cliente con validación ldap === |
| 30 | |
| 31 | Se ha optado por una solución que modifique lo mínimo posible. En la página del menú se define una variables de si existe validador y y si es así hace un include al código del validador.php. Da la posibilidad de que los administradores personalicen el validador. |
| 32 | |
| 33 | Se propone que se defina la variable "tipo de validador", para que se puedan tener varios validadores simultaneamente según el cliente que iniciemos. |
| 34 | |
| 35 | === Separación de servicios y recursos === |
| 36 | |
| 37 | Se podrá configurar Opengnsys para que los distintos recursos (samba, pxe, log,...) se puedan situar en distintas ubicaciones. |
| 38 | |
| 39 | === Instalador === |
| 40 | |
| 41 | Casi listo para poder instalar en Fedora. |
| 42 | |
| 43 | Se está preparando para que se pueda instalar individualmente el repo o el server. Este cambio necesita que se defina exactamente que servicio está por defecto en uno u otro servidor. Posiblemente se dejará para la siguiente versión. |
| 44 | |
| 45 | |
| 46 | === Postconfiguración de windows === |
| 47 | |
| 48 | La configuración de los clientes tras la restauración de la imagen de windows está muy avanzada. |
| 49 | |
| 50 | === Postconfiguración por grupos de clientes === |
| 51 | |
| 52 | Para modificar lo mínimo posible, se tomará como grupo del cliente el aula en que está definido y en este ámbito se podrán realizar configuraciones específicas tras la restauración de la imagen. |
| 53 | |
| 54 | === Subiendo el código al subversión === |
| 55 | |
| 56 | Es conveniente que para cada cambio se cree un ticket que lo describa y una rama dentro del branches/version1.0-tickets que contenga el código. |
| 57 | |
| 58 | |
| 59 | == Versión 2.0 == |
| 60 | |
| 61 | A la vuelta del verano nos centraremos en la versión 2.0 |
| 62 | |
| 63 | Comenzar a especificarla desde cero: Revisar los ticket pendientes y las necesidades/deseos traídas de redIris |
| 64 | |
| 65 | Debe existir un script de migración de la 1.0.x a la 2.0 |
| 66 | |
| 67 | == Formación == |
| 68 | |
| 69 | En septiembre se organizará la formación de opengnsys para las universidades. |
| 70 | |
| 71 | Se está creando una plataforma virtual de formación. |
| 72 | |
| 73 | == Configuración de arranque == |
| 74 | |
| 75 | Los parámetros de la configuración de arranque se cambian en distinto sitio según el gestor que usemos: |
| 76 | * pxelinux: en base de datos en la tabla itemboot, mirar también menuboot, menuboot_itemboot |
| 77 | * grub4dos: modificar las plantillas en /opt/opengnsys/tftpboot/menu.lst/templates |
| 78 | |
| 79 | |