AZLinux

por Raul Huerta @rauerta

Publicamos en breve macro que permite convertir varios ficheros odf situados en una carpeta a pdf

Lanzador:

/usr/bin/oowriter -invisible "macro:///biblioteca.(nombre_modulo).(nombre_macro)"

Codigo:

sub Conversor_PDF

	dim sArchivo as String
	dim sRuta as String
	dim sDirectorio as String
	dim bConvertir as Boolean


	’Seleccionamos la carpeta que contiene los archivos a exportar
	msgbox("Selecciona la carpeta que contenga los ficheros a convertir")
	sDirectorio = PickFolder

	’Tomamos el primer archivo de dicho directorio
	sArchivo = Dir(sDirectorio & Barra & "*.od*", vbNormal)
	bConvertir = False
	Do While sArchivo <> ""
		if right(sArchivo,4) = ".odt" or right(sArchivo,4) = ".ods" or right(sArchivo,4) = ".odp" then
			Convertir(sDirectorio,sArchivo)
			bConvertir = True
		end if
		sArchivo = Dir
	Loop

	if bConvertir = False then
		msgbox ("No hay ningún documento de OpenOffice para convertir en esta carpeta")
	else
		msgbox("Los ficheros han sido convertidos y se encuentran en la misma carpeta")
	end if
end sub


Function PickFolder as String

   dim oFolderPickerDlg as Object
   dim cPickedFolder as String

   oFolderPickerDlg = createUnoService( "com.sun.star.ui.dialogs.FolderPicker" )
   oFolderPickerDlg.execute()
   cPickedFolder = oFolderPickerDlg.getDirectory()
   PickFolder = ConvertFromURL( cPickedFolder )

End Function

Sub Convertir(sDirectorio as String, sArchivo as String)

	dim sURL as string
	dim oDocumento as Object

	GlobalScope.BasicLibraries.LoadLibrary("Tools")

	oDocumento = StarDesktop.loadComponentFromURL(ConvertToUrl(sDirectorio & Barra & sArchivo), "_blank", 0, Array(MakePropertyValue("Hidden", True), ))
	sURL = GetFileNameWithoutExtension( oDocumento.url ) & ".pdf"
	oDocumento.storeToURL(sURL, Array(MakePropertyValue("FilterName", "writer_pdf_Export"), ))
	oDocumento.close(True)

End Sub


Function Barra as String

	Barra = ""
	if environ("OSTYPE") = "linux" then Barra = "/"

End Function


Function MakePropertyValue( Optional cName As String, Optional uValue ) As com.sun.star.beans.PropertyValue

	Dim oPropertyValue As New com.sun.star.beans.PropertyValue

	If Not IsMissing( cName ) Then oPropertyValue.Name = cName
	If Not IsMissing( uValue ) Then oPropertyValue.Value = uValue
	MakePropertyValue() = oPropertyValue

End Function

por Raul Huerta @rauerta

Publicamos en breve macro que permite convertir varios ficheros odf situados en una carpeta a pdf

Lanzador:

/usr/bin/oowriter -invisible "macro:///biblioteca.(nombre_modulo).(nombre_macro)"

Codigo:

sub Conversor_PDF

	dim sArchivo as String
	dim sRuta as String
	dim sDirectorio as String
	dim bConvertir as Boolean


	’Seleccionamos la carpeta que contiene los archivos a exportar
	msgbox("Selecciona la carpeta que contenga los ficheros a convertir")
	sDirectorio = PickFolder

	’Tomamos el primer archivo de dicho directorio
	sArchivo = Dir(sDirectorio & Barra & "*.od*", vbNormal)
	bConvertir = False
	Do While sArchivo <> ""
		if right(sArchivo,4) = ".odt" or right(sArchivo,4) = ".ods" or right(sArchivo,4) = ".odp" then
			Convertir(sDirectorio,sArchivo)
			bConvertir = True
		end if
		sArchivo = Dir
	Loop

	if bConvertir = False then
		msgbox ("No hay ningún documento de OpenOffice para convertir en esta carpeta")
	else
		msgbox("Los ficheros han sido convertidos y se encuentran en la misma carpeta")
	end if
end sub


Function PickFolder as String

   dim oFolderPickerDlg as Object
   dim cPickedFolder as String

   oFolderPickerDlg = createUnoService( "com.sun.star.ui.dialogs.FolderPicker" )
   oFolderPickerDlg.execute()
   cPickedFolder = oFolderPickerDlg.getDirectory()
   PickFolder = ConvertFromURL( cPickedFolder )

End Function

Sub Convertir(sDirectorio as String, sArchivo as String)

	dim sURL as string
	dim oDocumento as Object

	GlobalScope.BasicLibraries.LoadLibrary("Tools")

	oDocumento = StarDesktop.loadComponentFromURL(ConvertToUrl(sDirectorio & Barra & sArchivo), "_blank", 0, Array(MakePropertyValue("Hidden", True), ))
	sURL = GetFileNameWithoutExtension( oDocumento.url ) & ".pdf"
	oDocumento.storeToURL(sURL, Array(MakePropertyValue("FilterName", "writer_pdf_Export"), ))
	oDocumento.close(True)

End Sub


Function Barra as String

	Barra = ""
	if environ("OSTYPE") = "linux" then Barra = "/"

End Function


Function MakePropertyValue( Optional cName As String, Optional uValue ) As com.sun.star.beans.PropertyValue

	Dim oPropertyValue As New com.sun.star.beans.PropertyValue

	If Not IsMissing( cName ) Then oPropertyValue.Name = cName
	If Not IsMissing( uValue ) Then oPropertyValue.Value = uValue
	MakePropertyValue() = oPropertyValue

End Function

El actual escritorio AZlinux2 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 AZLinux3 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

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

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

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

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

El pasado 15 de junio, en el Digital Water Pavilion, tuvimos el gran honor de hablar de migasfree en la primera jornada oficial de Software y Barra Libre.

Alberto Gacías, creador de este gestor de repositorios que usamos a diario para mantener nuestro parque de ordenadores con Linux, introdujo a los asistentes en la filosofía del proyecto. Aunque migasfree es una herramienta de gestión sencilla, explicar los conceptos que llevan a la consecución del proyecto no es tarea tan simple.

Contó también cómo nació la idea de migasfree dentro del proyecto de migración a software libre del Ayuntamiento de Zaragoza.

Otras ideas clave de la charla de Alberto, fueron:

• Configurar un equipo requiere mucho más tiempo que instalar los programas.
• Aparte de la configuración a nivel de usuario y de máquina, hace falta otro nivel más: el de la organización.
• En el Ayuntamiento, este nuevo nivel de configuración es el que se paquetiza (en nuestro caso, en formato RPM).
• Las actualizaciones masivas en horas clave pueden llegar a colapsar la conexión a Internet de una organización. Es necesario una distribución escalonada.
• migasfree surge de la necesidad de solucionar estos problemas organizativos:
  • Repositorios dinámicos para una distribución de software gradual.
  • Es una herramienta simple: sólo hay que paquetizar (ahí radica la complejidad y el verdadero esfuerzo).
  • Es adaptable y escalable: es programable para adecuarse a las necesidades de cada organización.
  • Gestión inicial de datos de equipos cero: se alimenta de la información que van proporcionándole los clientes.

migasfree es un proyecto de software libre. Como tal, cualquiera puede colaborar en él o adaptarlo a sus necesidades. Actualmente, los desarrolladores principales son Alberto Gacías (parte del servidor) y Jose Antonio Chavarría (parte del cliente). Para finales del verano está previsto liberar una actualización que incluirá como nueva prestación una capa de seguridad en las comunicaciones entre el servidor y el cliente basada en criptografía asimétrica.

Actualización 2011-06-20

Presentación de Alberto sobre migasfree.

Etiquetas: migasfree

Por lo que a nosotros respecta, el hackfest de Cádiz ha sido muy positivo. Allí planteamos nuestra problemática con las tarjetas Ceres, y nuestro deseo de que ese proyecto sea el siguiente en solucionarse de la misma forma que se ha hecho con el DNIe. Pudimos hablar de primera mano con gente de la FNMT y se mostraron receptivos con nuestra proposición.

Debemos dar las gracias de nuevo a CENATIC por la organización del evento y por haber servido de mediador en el caso de éxito que representa ya OpenDNIe.

Compartir 2 días con personas de la talla de Martin Paljak, Juan Antonio Martínez, Malcolm Bain, Enrique Hérnandez Bello, los amigos de Emergya y CENATIC, Tomás García-Merás, Santiago Suárez y más gente de la que no recuerdo el nombre (que nos perdonen la omisión), ha sido increible a nivel técnico y humano. Sólo lamento no haber tenido más tiempo para hablar con todos y cada uno de ellos.

En Cádiz hemos asistido a un momento histórico y lo hemos presenciado en primera fila. El tiempo record en el que se ha constituido el proyecto OpenDNIe, es indicativo de que cuando se quiere y se proveen los medios necesarios, cualquier empresa se puede emprender y conseguir resultados que benefician a todos.

Pero no nos debemos dormir en los laureles:

• dentro de OpenDNIe el trabajo está muy bien encaminado pero aún no se ha acabado,
• abrir el debate de qué se quiere hacer con el DNIe (en las jornadas hubo un interesante debate acerca de posibles usos que demandan los usuarios),
• es necesario aprovechar la inercia creada para que lo conseguido con OpenDNIe sólo sea el primer hito de muchos otros.

Referencias

• OpenDNIe y Ceres en AZLinux (presentación del Ayuntamiento de Zaragoza en el OpenDNIe hackfest)
• OpenDNIe: Reflexiones a la vuelta de la Playa de Cádiz
• Agradecimiento de CENATIC

Etiquetas: dnie, ceres, cenatic

Los próximos días 26 y 27 de mayo, se celebrará el primer hackfest sobre el OpenDNIe, en la Universidad de Cádiz.

Este evento, como dice Manuel Velardo, tiene un doble objetivo: Celebrar este HackFest potenciará la incorporación de nuevos desarrolladores a la Comunidad OpenDNIe, pero al tiempo, hemos invitado a expertos de primer nivel para que nos ayuden a anticipar el futuro de las identidades digitales en Europa

Desde el equipo de AZLinux, les deseamos un gran éxito en la convocatoria y que este modelo de desarrollo colaborativo entre comunidad e instituciones públicas se pueda extender a otros proyectos.

Actualización: 2011-05-20

Finalmente, estaremos presentes en el hackfest dando una charla sobre las peripecias que hemos tenido que hacer en AZLinux para hacer funcionar el DNIe y las tarjetas Ceres.