AZLinux

Como os comentamos en Razones para hacer una distribución propia, uno de los retos a los que nos enfrentamos en AZLinux, es mantener nuestros escritorios actualizados.

Si bien con migasfree conseguimos actualizar y configurar los equipos con AZLinux a voluntad, llega un momento en que instalar software más reciente nos resulta imposible, debido a que la Distribución GNU/Linux de la que partimos no lo permite. Es este un buen momento para plantearnos comenzar a desarrollar una nueva versión de nuestro escritorio libre.

Actualmente en el Ayuntamiento de Zaragoza trabajamos con cinco sistemas de escritorios diferentes:

• Microsoft Windows XP SP2
• Zaragoza Accesible (basado en SLED 10 SP2)
• AZLinux-1 (basado en SLED 10 SP2)
• AZLinux-2 (basado en OpenSUSE 11.2)
• AZLinux-3 (en desarrollo, basado en OpenSUSE 11.4)

Nuestro proceso principal de migración es el de migrar los XP a la última versión en producción de AZLinux, pero tambien estamos migrando los AZLinux-1 a AZLinux-2 en determinados casos.

Es obvio que mantener diferentes escritorios en producción conlleva una complejidad y esfuerzo considerable, no sólo para los técnicos encargados de mantenerlos sino también para los técnicos que dan soporte a los usuarios. Por este motivo no queremos tener más de dos versiones AZLinux en producción, con lo que el proceso de migración entre sistemas AZLinux empieza ahora a tomar cierta importancia.

Dado que nuestros recursos son muy limitados, hemos automatizado la migración entre distintos AZLinux ya que este proceso nos resta recursos de la migración de XP a AZLinux, nuestro principal objetivo. Es de esto, de lo que os vamos a hablar a continuación.

Requisitos

• Si algo sale mal (fallo de red, disco duro, corriente eléctrica, etc.) el sistema debe volver a su estado inicial.
• El proceso debe ser totalmente desatendido (será programado para su ejecución en horario no laboral).
• Posibilidad de realizar el proceso en dos pasos: salvado de AZLinux-1 por un lado y restauración en AZLinux-2 por otro lado ( p.e. cuando se requiera renovar el equipo físico, salvaremos en el PC antiguo y restauraremos en el PC nuevo)
• Debe copiarse todos los datos de todos los usuarios (documentos, correo electrónico, configuraciones, etc.)
• Debe copiarse todas las impresoras automáticamente.
• El mismo software que se haya instalado en la versión AZLinux antigua debe también ser instalado en la nueva (o en su defecto un software alternativo).
• El sistema debe ir registrando lo que va realizando para que en caso de error se pueda relanzar el proceso y pueda continuar desde donde se produjo el error.

Solución adoptada

El sistema automatizado de migración de AZLinux-1 a AZLinux-2 instala un Clonezilla personalizado en la partición swap de AZLinux. Una vez reiniciado el sistema en esta partición, desde Clonezilla se monta una carpeta de red (cifs) y se ejecuta un script que esquemáticamente realiza:

1. Un salvado y verificado posterior de las particiones del disco (menos la partición swap que ahora contiene Clonezilla).
2. Un salvado de datos de los usuarios y de datos del sistema en ficheros tar.gz en la carpeta de red.
3. Una restauración de las particiones de la imagen de AZLinux-2.
4. Una restauración de los datos de los usuarios y del sistema salvados anteriormente (tar.gz).
5. Volver a dejar la partición que ahora contiene Clonezilla como swap.

Nuestro "truco" consiste en usar la partición swap para arrancar un Clonezilla personalizado.

Otra forma de arrancar Clonezilla es haciendo uso de PXE, pero se nos plantea el inconveniente de que ninguno de nuestros equipos tiene activado PXE en la BIOS, lo cual requiere que un técnico se desplace para activarla, además de tener que instalar y mantener un servidor de arranque PXE. No descartamos esta opción a medio plazo.

Cómo lanzamos el proceso

Cuando queremos migrar un AZLinux-1 a AZLinux-2 lo que hacemos es:

1. Informar al usuario de que va a migrarse su AZLinux.
2. En migasfree asignamos el equipo al repositorio que contiene nuestro paquete mig.rpm (contiene todo lo necesario para instalar el Clonezilla personalizado en la particion swap) y actualizamos el equipo para que se instale dicho paquete.
3. Programamos el lanzamiento de la migración en horario no laboral p.e.: # mig-at 20:30 (el usuario no debe apagar el equipo o bien hacemos uso de Wake On LAN para que el equipo este encendido y pueda lanzarse el proceso)
4. Al dia siguiente el usuario nos informa del resultado. Si algo ha salido mal comprobamos los logs del proceso y actuamos en consecuencia.

Incovenientes detectados

1. Dado que el proceso requiere de un reinicio y algunos equipos (afortunadamente pocos en nuestro caso) tienen contraseñas BIOS antes de iniciar el proceso tenemos que eliminarlas si se programa la ejecución del proceso en horario no laboral, o bien lanzar el proceso con el usuario delante de su equipo para que éste introduzca la pasword de BIOS.
2. Si se produce un fallo de corriente eléctrica cuando se está restaurando la imagen de AZLinux-2, no siempre el sistema consigue volver a arrancar ya que Clonezilla ha copiado el Master Boot Record de grub y la restauración no ha sido completada. En este caso es preciso la intervención in situ de un técnico para copiar el Master Boot Record de syslinux y poder iniciar de nuevo Clonezilla para relanzar el proceso.
3. Algunos iconos de los lanzadores añadidos por los usuarios se pierden y hay que reasignarlos, ya que entre las diferentes Distribuciones empleadas dichos iconos han cambiado de nombre o de ruta.

Ventajas

1. Sistema de migración desatendido.
2. No interrumpimos el trabajo del usuario.
3. No generamos tráfico de red en horario laboral.
4. Simple de ejecutar.

AZLinux. Nos gusta el Software Libre.

Etiquetas: migración

Por @jact_abcweb

Cuando hace unos años nos planteamos la idea de adoptar software libre en el Ayuntamiento, sabíamos que no iba a ser una tarea fácil ni a corto plazo. Hicimos un planteamiento de migración progresiva, en varias fases, para ir familiarizándonos con las herramientas y, sobre todo, para evitar cambios abruptos en la experiencia de los usuarios y en el día a día de la institución. Esta ha sido (y es) la clave más importante en nuestro proyecto de migración y el reto, tecnológicamente hablando, era imponente.

Nuestro ecosistema, como cualquier otro, tiene sus particularidades. Además, es un ecosistema muy variado y bastante considerable en tamaño y recursos. Cuando llegó la fase de realizar un escritorio completo en software libre, debíamos enfrentarnos a los siguientes retos.

Teníamos que dar con la fórmula adecuada para hacer encajar todas esas piezas. La que más nos ha condicionado ha sido la integración con nuestro entorno de servidores Novell. Hace ya muchos años que están presentes en nuestro día a día. Poco a poco se han ido migrando servicios a plataformas libres, pero el núcleo duro (autenticación, correo, almacenamiento compartido), sigue perteneciendo a Novell. Esta empresa tiene una línea de negocio muy importante relacionada con Linux, por lo que nuestra elección de la distribución base para el escritorio fue sencilla. En un primer momento apostamos por SLED por el soporte que nos daba Novell en lo que eran nuestros primeros escarceos con sistemas operativos libres. Después, hemos ido cambiando a la versión de comunidad, openSUSE, ya que tenía versiones más recientes de los programas que íbamos necesitando.

Un aspecto esencial que me gustaría recalcar en esta parte de la historia es la filosofía general que hay en la corrección de errores en programas de software libre: no suele haber parches para versiones en producción, sino lo que se hace (generalmente, digo), es sacar una nueva versión de dicho programa. Si este comportamiento lo extrapolamos a un sistema operativo, el resultado de actualizar un determinado programa que soluciona un error importante, puede dar como resultado que tengas que actualizar gran parte (o toda) la distribución. La estrategia de SLED ha sido tener unos ciclos de desarrollo y mantenimiento excesivamente largos, por lo que no siempre se adaptaba a nuestras cambiantes necesidades.

La siguiente pieza del puzzle son los certificados digitales. Si fueran software, el anclaje de dicha pieza no sería particularmente complicado. La cuestión es que esos certificados, en nuestro caso, van en tarjetas criptográficas, y además, de 2 tipos diferentes. Del tipo Ceres son nuestras tarjetas de identificación como empleados municipales, y luego está el DNI electrónico, que es necesario para algunos trámites que realiza el ciudadano con el Ayuntamiento. Este tema siempre nos ha condicionado algunos aspectos importantes de la distribución base, ya que programas como OpenSSH tienen una relevancia esencial en el funcionamiento del sistema operativo.

La ofimática, en un entorno de gestión administrativa como el nuestro, es la columna vertebral de su funcionamiento diario. Por un lado, es prioritario acceder a toda la información generada con anterioridad en formatos propietarios y, por otro, es necesario trabajar con formatos abiertos, tal y como recomienda el Real Decreto 4/2010 a las administraciones públicas. Pese a la importancia de estos requisitos, seguramente ha sido la característica más fácil de ejecutar gracias a la existencia de OpenOffice.org. Ha habido escollos que salvar y problemillas con los que convivir, pero es ya una herramienta suficientemente madura para acometer estas necesidades.

Afortunadamente para nosotros, en los últimos años, la evolución de las distribuciones Linux para escritorio, ha sido vertiginosa, y cada vez hay más alternativas para programas y funcionalidades que antes sólo funcionaban en entornos propietarios. Sin embargo, hay todavía algunos nichos que no han sido cubiertos y hay aplicaciones hechas a medida, cuyos requerimientos hacen (a priori) imposible ejecutarlas en plataformas libres. En este sentido, sigue siendo esencial para nosotros dar soporte a este tipo de aplicaciones. Ahí entra el apartado de emulaciones. Hemos conseguido que algunas de ellas funcionen de forma integrada en el escritorio gracias a Wine, pero para el resto, hemos necesitado de máquinas virtuales para continuar con nuestro proyecto de migración. Pese a que estas máquinas virtuales ejecutan sistemas propietarios, no hemos tenido que hacer una inversión extra en licencias, ya que hemos utilizado las que poseíamos.

Estos eran, y son, los retos a los que nos enfrentamos. El resultado de todo este proceso ha dado a luz a nuestra distribución AZLinux. Una distribución específica para nuestro entorno de trabajo y que por eso no tiene sentido difundir (como distribución palpable) más allá de los entornos administrativos. Pero que sí que hay que difundir como conocimiento adquirido que se puede extrapolar a otros entornos específicos, ya sean otras administraciones públicas o incluso empresas de tamaño medio o grande. Las lecciones que hemos aprendido durante nuestro viaje bien pueden ayudar a que otros lo inicien.

Por si esto no fuera ya suficiente, aún queda otro reto, todavía mayor si cabe, al que nos enfrentamos cada día que pasa: la evolución de nuestra distribución. Los sistemas cambian, los programas cambian, las necesidades evolucionan y, una vez superados los retos iniciales, hay que seguir dándoles respuesta. Por ello seguimos en la brecha y estamos iniciando el proceso de AZLinux 3. En posteriores artículos iremos desgranando su desarrollo.

Etiquetas: azlinux, retos

Hemos llegado a 500 pcs con Linux.

Parecia imposible pero poco a poco vamos avanzando ya solo nos quedan ...... 2.300 , uffff!!

En la últimas semanas hemos realizado la actualización progresiva de la plataforma Ofimática. Actualizamos a OO3.1 desde OO2.3. No ha sido sencillo ya que los perfiles de usuario debían mantenerse intactos y no perder macros, diccionarios o autotextos. Creo que lo hemos conseguido.

Enhorabuena a los chicos del equipo escritorio SL del Ayuntamiento de Zaragoza.

Cuando buscamos software adecuado para nuestra distribución SLED 10 seguimos siempre la misma ruta:

1. Fuentes Novell

• DVD instalación
• DVD update
• Repositorios oficiales
• Pagina descargas de Novell

2. Software OpenSuse

• http://software.opensuse.org/search
• versión SLED/SLES

3. PackMan

• http://packman.links2linux.org/
• versión SLED o en su defecto OpenSuse 10.1 o 10.2

4. Linkat

• http://projectes.lafarga.cat/projects/linkat/downloads/files
• Proyecto departamento de Educación de la Generalitat de Cataluña.

5. Web oficial

• RPM para Suse
• Compilar código fuente