AZLinux

Han pasado más de 5 años desde la última entrada en esta bitácora. Cinco años que han dado para mucho. Cinco años en los que hemos dado la vuelta a la tortilla, ya que actualmente, el 70% de los ordenadores del Ayuntamiento de Zaragoza tienen un sistema operativo Linux. Cinco años en los que el proyecto Vitalinux Edu de la DGA, heredero del germen que supuso Vitalinux, ha nacido y se ha expandido en casi 80 centros educativos de Aragón.

La palabra frugalidad parece que está últimamente de moda. Puede tener connotaciones negativas como austeridad o pasividad, pero en nuestro contexto, tiene connotaciones muy positivas, ya que están relacionadas con la optimización y la eficiencia. A lo largo de este tiempo, se han visto mermados nuestros recursos humanos para afrontar la migración a software libre dentro del Ayuntamiento, pero cada día teníamos que dar soporte a más ordenadores y realizábamos más proyectos en paralelo. Nuestra receta ha sido sencilla: aplicar los procedimientos adecuados y llevar a cabo la mejora continua siempre que nos ha sido posible.

Sólo así se entiende como un equipo reducido de personas lleven el desarrollo y la gestión de más de 3000 ordenadores en el Ayuntamiento. Personas que, si por algo destacan, es por intentar aplicar el sentido común en cada una de sus acciones: no reinventar la rueda, apoyarse en hombros de gigantes y hacerlo todo lo más sencillo posible para que sea mantenible en el tiempo. Este planteamiento es el que nos ha conducido a la receta: paquetería linux + migasfree + integración continua.

Partimos de la integridad y auditoría que otorgan los paquetes Linux al sistema operativo. Después, desarrollamos migasfree para agilizar y controlar las tareas de mantenimiento de los ordenadores. Finalmente, hemos montado un sistema de integración continua basándonos en GitLab, cerrando así el flujo de trabajo.

Este método de trabajo es el que también explica cómo hemos respondido a los desafíos que nos ha traído esta pandemia. En un tiempo récord teníamos que satisfacer la demanda del teletrabajo para los empleados municipales. En 3 días ya tuvimos un sistema operativo Linux preparado para trabajar a través de una VPN municipal. Gracias a migasfree, hemos podido evolucionar este proyecto para mejorar la experiencia de usuario y la seguridad de las conexiones. En 3 meses hemos dado servicio a casi 800 nuevas estaciones de teletrabajo, entre ordenadores dedicados y máquinas virtuales.

AZLinux no es una distro generalista. Está pensada para un entorno muy concreto: el Ayuntamiento de Zaragoza. Pero lo que sí podemos transmitir es nuestro modelo y las herramientas que usamos. Esperamos que nuestras experiencias puedan ser seguidas por otros organismos, ya sean públicos o privados. Hemos demostrado que con determinación, motivación y constancia es posible cambiar las cosas desde dentro y ser cada día más eficientes y eficaces.

Etiquetas: evolución

Por @jact_abcweb

Este blog ha sido testigo de algunos artículos relacionados con el desarrollo de AZLinux 3. Esta versión era la sucesora de la que ahora mismo está en producción y estaba basada en openSUSE 11.4. Y lo digo en pasado porque ya nunca verá la luz. Diversos motivos nos han llevado a cambiar de distribución base.

Uno ha sido la política de actualizaciones de openSUSE, que nos ha dejado sin paquetes para la versión 11.2 (nuestro actual AZLinux 2) y que dentro de poco hará lo propio con la versión 11.4. Otro, el más importante, ha sido que hemos descubierto un método alternativo de conexión a nuestra infraestructura de ficheros Netware. Este método, aunque más lento y de peor rendimiento que el que teníamos, nos ha posibilitado independizarnos de una distribución única de Linux y así hemos podido escoger entre un amplio abanico de posibilidades.

Meses atrás os pedíamos opinión sobre este asunto. Os agradecemos los comentarios y vuestros consejos. Al final nos hemos decantado por Ubuntu 12.04 LTS, con Gnome Classic como escritorio.

Con el cambio de distribución, hemos decidido cambiar también la numeración. Por eso, y porque aunque AZLinux 3 no haya llegado a ser, sí que nos ha servido como campo de pruebas para evolucionar nuestra distribución (y no queríamos que su recuerdo se perdiera si manteníamos el número 3 para la nueva versión).

AZLinux 12 está creciendo rápidamente para convertirse en nuestro próximo sistema Linux en producción, pero todavía nos faltan algunas cosas por montar y algunos errores por solucionar.

Para celebrar este nuevo hito, me gustaría presentaros una retrospectiva gráfica de las distintas versiones de nuestra distribución.

Hacia finales de 2008, nace AZLinux 1. Hubo 14 prototipos previos a esta primera versión. Está basada en SLED 10 SP2 y, a día de hoy, todavía sigue en producción en unos 100 equipos, pero está previsto sustituir todos ellos por AZLinux 2 en breve.

En febrero de 2010, AZLinux 2 sale de la fábrica para empezar su vida productiva. Basada en openSUSE 11.2, ha ido evolucionando notablemente en todo este tiempo, añadiendo parches (muchas veces externos a openSUSE) aquí y allá. Aunque sus comienzos fueron titubeantes, ahora mismo es nuestro buque insignia, ya que se encuentra en más del 80% de los equipos con Linux del Ayuntamiento.

En verano de 2011, empezamos a trabajar sobre lo que iba a ser AZLinux 3. Ya no teníamos tanta urgencia como con la anterior versión, pero sabíamos que era imprescindible estar lo más al día posible para dar el mejor servicio posible a nuestros usuarios. A nivel de distribución base era bastante continuista en relación a openSUSE 11.2, ya que no había cambios muy drásticos. Sin embargo, en cuanto al código desarrollado por nosotros, sí que hubo cambios significativos. Lástima que se quedara sólo en un prototipo, pero es que se nos quedó pequeño antes de hora.

Un mes antes de que saliera la versión oficial, en marzo de este año, ya estábamos estudiando y haciendo pruebas con la nueva versión de Ubuntu. Es la siguiente versión LTS y hay una gran comunidad detrás (tal vez la mayor en estos momentos). Todavía tiene bugs importantes que resolver (es normal llevando tan poco tiempo de vida), pero estamos seguros e ilusionados en que AZLinux 12 es un gran salto, por muchos motivos, en nuestro proyecto de migración a software libre.

Sin cambio, el progreso es imposible; y los que no son capaces de cambiar de mentalidad no son capaces de cambiar nada.

George Bernard Shaw

El actual escritorio AZlinux 2 para los empleados públicos dentro del Ayuntamiento de Zaragoza está basado en OpenSUSE 11.2 y Gnome 2.28. Superadas algunas limitaciones que nos conducían hacia openSUSE vamos a iniciar una nueva fase de desarrollo AZLinux 3 sin restricciones a la hora de elegir distro y escritorio Linux.

La oferta es amplia, por eso nos gustaría dar pasos firmes pero sobre seguro ya que nuestra instalación cuenta con mas de 3.000 ordenadores personales donde más de la mitad cuentan con 5 y 6 años de vida. Nuestros usuarios viene del mundo XP y queremos que sea una transición suave y sin sobresaltos (o los justos).

Hemos estudiado varias opciones pero nos gustaría contar con vuestra opinión (a ser posible razonada) fundamentalmente en dos aspectos que debemos elegir:

¿Qué distribución y entorno de escritorio elegimos?

Distribución: openSUSE, Ubuntu, Debian, Linux Mint, Fedora, Red Hat, ...

Escritorio: Unity, Gnome Shell, Gnome Classic, MATE, LXDE, XFCE, OpenBox, ...

Nuestras preferencias actuales se centran en Ubuntu/Mint y Gnome Shell/MATE pero estamos abiertos a recibir vuestras recomendaciones.

Gracias.

Equipo AZLinux Ayuntamiento de Zaragoza

Por @jact_abcweb

Llamamos núcleo, o core, al mínimo conjunto de paquetes que constituyen la distribución AZLinux. El resto de paquetes que forman parte de la distro no es que sean menos importantes, ya que cada uno de ellos ha sido creado por una determinada necesidad o funcionalidad, pero los paquetes del núcleo son los que dotan a nuestra distribución de un sello de identidad propio. Veamos por qué, estudiando cada uno de ellos.

azl-setup

También podría llamarse azl-bootstrap, ya que su misión es convertir a una distribución Linux base (para AZLinux 3, es openSUSE 11.4) en AZLinux.

Descarga e instala el resto de paquetes de la distribución. También contiene algunos ficheros clave para el arranque de la máquina y que utiliza nuestro sistema de clonación personalizado (basado en Clonezilla) para terminar el clonado de cada ordenador.

Además, incluye los paquetes del NCL y se encarga de instalarlo.

azl-utils

Únicamente contiene una serie de scripts que facilitan la programación del resto de paquetes de la distribución. Esta es la lista:

• azl-backup-file: sirve para hacer una copia de seguridad de un archivo (frecuentemente de un fichero que pertenece a otro paquete, durante el proceso de instalación de un paquete).
• azl-change-file: reemplaza un fichero por otro con una determinada extensión (al igual que el otro, se usa durante la instalación de paquetes, para cambiar archivos de configuración de otros paquetes por los nuestros adaptados).
• azl-delete-line: borra una determinada línea de un fichero (para automatizar cambios de ficheros de otros paquetes)
• azl-gconf: sirve de interfaz para realizar cambios en GConf a nivel de sistema.
• azl-get-line-number: devuelve el número de la línea del texto buscado en un fichero.
• azl-get-user-graphic: devuelve el usuario que tiene lanzada la sesión gráfica en el equipo.
• azl-get-value: sirve para obtener el valor de una clave de un fichero de configuración.
• azl-insert-line: añade una línea en un fichero (útil para automatizar cambios de ficheros de otros paquetes).
• azl-line-comment: comenta o descomenta líneas en ficheros de configuración.
• azl-restore-file: restaura ficheros de configuración originales de otros paquetes (se usa durante la desinstalación de paquetes de AZLinux).
• azl-set-value: establece un valor para una clave de un archivo de configuración.
• azl-update-apps: hace las veces de macro en la instalación/desinstalación de paquetes para invocar al comando update-desktop-database.
• azl-update-icons: mismo cometido que el script anterior, pero para el comando gtk-update-icon-cache.

Una parte de ellos están hechos en Python, para aprovechar la librería argparse y parsear la lista de argumentos fácilmente. El resto, debido a su simplicidad, están hechos en Bash.

Como se puede observar, tanto los nombres de los paquetes como los nombres de los scripts comienzan por el prefijo azl con el fin de diferenciarlos del resto y encontrarlos fácilmente a través de la consola de comandos.

azl-system-config

Realiza cambios en ficheros de configuración que tienen que ver con el arranque de la máquina (sistema sysconfig).

azl-lan

Se encarga de configurar los servicios de red de la máquina:

• xinetd
• Proxy del sistema
• Firewall
• NTP

azl-pms

Debe su denominación a que configura el Package System Manager del sistema. En nuestro caso, Zypper. Además, incorpora un script que sirve de interfaz para instalar y desinstalar paquetes manualmente.

También contiene un script para facilitar la operación de subir ficheros al servidor de migasfree.

azl-nds

Configura el cliente LDAP de la máquina con los parámetros de nuestro servidor y contiene 2 scripts para realizar operaciones contra el árbol NDS de nuestra organización:

• azl-nds-info: obtiene determinados valores del árbol NDS para un determinado usuario.
• azl-nds-server: sirve para iniciar o cerrar sesión en el servidor Novell.

azl-auth

Se encarga de:

• Configurar el NCL.
• Configurar los módulos de autenticación PAM para integrar el login en el servidor de ficheros de Novell con el login en el equipo.
• Configurar el servicio OpenSSH para las conexiones remotas.
• Configurar el servicio SLP (necesario para la conexión con el servidor Novell de nuestra organización).
• Añadir determinados grupos a los usuarios de la máquina (necesarios para que la conexión con el servidor Novell funcione).

También contiene scripts que sirven para crear y gestionar usuarios adecuados en la máquina.

azl-skel-base

Contiene los ficheros básicos para el perfil de los usuarios (los que residen en /etc/skel/). Se diferencia de un perfil habitual en que añade un lanzador para la conexión con el sistema de ficheros de Novell que utilizamos y porque configura Nautilus con un marcador a dicha localización de red.

Etiquetas: system, core, azlinux

Por @jact_abcweb

En este artículo hablaremos de cómo hemos hecho funcionar los certificados digitales Ceres y DNIe en AZLinux 3.

La distribución base de esta nueva versión de nuestra distribución es openSUSE 11.4. La versión mínima de OpenSC para esta versión de openSUSE es la 0.12.0, la cual es incompatible con los paquetes opensc-ceres y opensc-dnie existentes, ya que no permite la carga dinámica de módulos criptográficos.

Primer intento

La primera tentativa consistió en instalar los paquetes que ya teníamos funcionando en nuestra distribución anterior (AZLinux 2, con openSUSE 11.2 como sistema base): opensc-0.11.7, opensc-ceres-2.1.1 y opensc-dnie-1.4.6.

Conseguimos instalar el pack sin problemas, pero, al ejecutar los comandos de OpenSC, observamos que no era posible acceder a los certificados de las tarjetas.

Segundo intento

Hacer funcionar el DNIe en openSUSE 11.4, gracias al proyecto OpenDNIe, no tiene ya mayor dificultad, pero para nosotros, en nuestro quehacer diario, sigue siendo prioritario trabajar con los certificados Ceres, aunque eso signifique perder la funcionalidad del DNIe. Por esa razón, la siguientes pruebas fueron encaminadas a hacer funcionar ese módulo criptográfico, a cualquier precio. Esto fue lo que hicimos.

Lo primero fue hacer un downgrade de OpenSC en la distribución base (openSUSE 11.4), para permitir la carga de módulos. Conseguimos hacer funcionar la versión 0.11.13 perteneciente a openSUSE 11.3, pero instalando las dependencias de openSUSE 11.4 (todas las que se podían).

Después, tuvimos que compilar el fuente de opensc-ceres, modificando la constante MODULE_VERSION referente a la versión de OpenSC, en el fichero src/libcard/base_card.h.

El invento es totalmente funcional y se consigue operar tanto con los comandos de OpenSC como con el módulo a través del navegador web Firefox.

A la tercera, va a la vencida

Ya teníamos soporte para Ceres y teníamos resuelta la papeleta de los certificados digitales en nuestra versión en desarrollo. Sin embargo, nos resistíamos a dejar fuera de juego al DNIe, pues cada vez se pueden hacer más gestiones con él y, pensando en el futuro cercano, nos podía venir bien para actualizar el sistema operativo en nuestros equipos de atención al público (a los que llamamos Zaragoza Accesible).

Para aprovechar el trabajo ya hecho, podríamos haber compilado el fuente del paquete opensc-dnie y utilizar el mismo truco de la constante de la versión de OpenSC. Pero hicimos otra cosa: empezamos de cero con otra perspectiva. Partimos de un OpenDNIe funcional para nuestra plataforma y volvimos a compilar opensc-ceres.

Optamos por esta opción por 2 razones: porque existía una versión de OpenSC que nos permitía la carga de módulos adicionales y porque así podíamos tener las ventajas de un código de OpenDNIe más actualizado. En el proyecto OpenDNIe, existe una primera versión de OpenSC que tiene ya integrado OpenDNIe. Esta versión corresponde a los inicios del proyecto y nos permitía probar nuestra teoría.

Compilamos el paquete y las pruebas de funcionamiento fueron positivas con la página de verificación de la DGP. Después, volvimos a compilar opensc-ceres y, modificando el fichero /etc/opensc.conf, conseguimos soporte para ambos módulos criptográficos.

Como último paso, paquetizamos los ficheros objeto de OpenSC y Ceres, automatizando el proceso de instalación de los certficados raíz y configuración de OpenSC. Un reto menos en nuestro camino hacia AZLinux 3.

Etiquetas: opensc, ceres, dnie, azlinux

En algunos entornos es útil poder realizar acciones en varias máquinas simultáneamente.

pssh permite conectarse mediante ssh a varias máquinas y realizar una acción única en todas ellas simultáneamente.

Para nuestra aula de formación esta funcionalidad es muy interesante. Por ejemplo, deseamos borrar el perfil del usuario curso (home incluido) cada vez que acaba un curso en cada una de las máquinas del aula.

pssh -h /opt/aytozgz/pssh/hosts userdel -r curso
     -h fichero > fichero con las maquinas a las que se acceder 

Ademas pssh incluye, como podéis ver en el enlace, otro conjunto interesante de comandos muy útiles como pscp, prsync, pnuke y pslurt

Cómo añadir o quitar aplicaciones para que arranquen en el inicio del escritorio (equivalente al "Programas > Inicio" de Windows)

Procedimiento

• Acceder al Centro de Control del Usuario
• Acceder a Sesiones > Programas al Inicio 
• Añadir, quitar aplicaciones
• También pueden desactivarse por si es necesario activarlas mas tarde.

 En nuestro caso para evitar este tedioso procedimiento utilizamos un paquete rpm para que añade el lanzador (fichero.desktop) correspondiente en /etc/xdg/autostart.

Más Aplicaciones

Entorno XDG >

XDG_CONFIG_DIRS=/etc/xdg
XDG_DATA_DIRS=/usr/share

¿Como se genera?

Partimos de XDG_CONFIG_DIRSl/menus/applications.menu como fichero base

• Resumen
  • Crea Menus y submenus cuya definicion esta en ficheros .directory
    • XDG_DATA_DIRS/desktop-directories
  • Cada aplicacion esta definida por un fichero .desktop
    • XDG_DATA_DIRS/applications
  • Dentro de cada menu se incluyen categorias para ser mostradas
    • Las aplicaciones son mostradas en funcion de las categorias definidas en su .desktop
  • XDG_CONFIG_DIRS/menus/applications.menu pertenece al paquete desktop-data
    • por lo tanto es deseable no tocarlo
  • Para añadir cambios usar la posibilidad de mergear .menu
    • metemos nuevos .menu en XDG_CONFIG_DIRS/menus/applications-merged/ (mergeo automatico)
    • De esta menera podemos añadir menus o quitar entradas que no interesan

Enlaces

XDG Base Directory Specification

Desktop Menu Specification > ejemplo clarificador al final del documento

Desktop Entry Specification

Entendiendo XDG Base Directory Specification

XDG > Parte del estandar freedesktop.org

Define uno o más directorios base donde los ficheros deben ser buscado.

Orden de búsqueda:

1. $XDG_DATA_HOME > en su defecto ~/.local/share

2. $XDG_DATA_DIRS > en su defecto /usr/local/share ; /usr/share

Mimetype

Los ficheros tienen asociado un Mimetype que indica qué tipo de fichero es.

Se clasifican mediante el esquema media/subtipo: text/plain o image/jpg

Directorios

• XDG/mime/packages > plantillas
• XDG/mime/packages/MEDIA/subtype.xml > definicion de cada tipo
• XDG/mime/globs > relacion extensión Mimetype
• XDG/mime/magic > relacion patrón Mimetype
• XDG/mime/aliases > alias de Mimetype
• Otros

Como se determina el Mimetype

• En este orden:
  1. XDG/mime/globs > relacion extensión Mimetype
  2. XDG/mime/magic > relacion patrón Mimetype

Asociar MIMETYPE con aplicación por defecto

XDG/applications/defaults.list

ejemplo: application/excel=calc.desktop

Truco

gnomevfs-info muestra el mimetype de un fichero.