AZLinux

Recientemente nos pidieron desde el MOOC de Miríada X la realización de un pequeño video sobre nuestro equipo de trabajo ... y allá que fuimos.

En este pequeño documental describimos brevemente nuestro trabajo de implantación de Software Libre en los escritorios del Ayuntamiento de Zaragoza y sobre todo plasmamos las opiniones personales de los miembros del equipo AZLinux.

Espero que os guste.

Por @jact_abcweb.

Esta es la historia de un grupo de pioneros. Aún hoy, todavía quedan tierras por conquistar y paraísos por descubrir. Y alguien tiene que hacerlo. Sólo los espíritus indomables son capaces de hacer frente a las adversidades del camino y continuar su periplo día tras día.

Este 2012 que acaba, termina para nosotros mucho mejor de lo que empezó. A finales del año anterior y a principios de este, habíamos padecido graves problemas de integración de nuestro NCL con documentos ofimáticos y eso había conllevado casi un parón total en las migraciones de equipos a Linux.

Pero, como dice el dicho, a grandes males, grandes remedios. Ni cortos ni perezosos, no esperamos a que nadie viniera a solucionarnos el tema y, por nuestra cuenta (como hacen los auténticos pioneros), dimos un rodeo al problema y convertimos el contratiempo en una nueva oportunidad. Aunque perdíamos alguna funcionalidad, utilizamos el protocolo NCP (más arcaico que la evolución que presentaba el NCL) para conectarnos a nuestros servidores de ficheros.

Esto resolvió la encrucijada y, además de permitirnos retomar las migraciones, también nos dio la ocasión de no anclarnos sólo a sistemas basados en SuSE para desarrollar AZLinux. El paquete ncpfs también se encuentra disponible para otras distribuciones y pensamos que era el momento perfecto para pensar en otras posibilidades.

Finalmente nos decantamos por Ubuntu y, durante gran parte del presente año, hemos trabajado en adaptarlo a nuestras necesidades. En octubre ya teníamos una plataforma bastante estable y desde entonces hemos estado haciendo pruebas con un grupo escogido de usuarios. El año que viene será ya nuestro buque insignia.

Pero no sólo nos hemos dedicado a pensar en el futuro, sino que también hemos gastado nuestros recursos en mejorar procesos internos. Sobre todo, han ido encaminados en dos frentes.

El primero, en unificar, mejorar y ampliar nuestros procesos automáticos de migraciones. Como resultado, publicamos un esquema que resume el amplio abanico de posibilidades que cubrimos hasta el momento.

El segundo, en conseguir que nuestra navaja suiza, migasfree, nos sirviera también para interactuar con equipos Microsoft Windows. A día de hoy, ya tenemos un cliente para esta plataforma que es capaz de inventariar el equipo en el servidor y recoger información sobre el hardware. Próximamente será capaz de instalar/desinstalar software empaquetado. También estamos dedicando esfuerzos en mejorar la usabilidad del servidor y en agilizar el sistema de instalación para que sea más fácil captar usuarios que puedan contribuir a enriquecer más esta aplicación.

Como he dicho al empezar, ha sido un gran año para nosotros y sólo nos queda un deseo para el que viene: que podamos continuar afrontando nuevos desafíos, porque ganas no nos faltan ;).

Por @jact_abcweb.

Con motivo del Zentyal Summit de este año, Ricardo Cavero (@caveroarceiz), ha dado una charla sobre la evolución del proyecto de migración a software libre que estamos llevando a cabo desde hace unos años en nuestro Ayuntamiento. Desde hace unos meses estamos trabajando en una versión de AZLinux basada en Ubuntu y esta no podía ser mejor ocasión para presentarla en sociedad.

Aún no es una versión en producción aunque ya está en fase beta. Nos faltan algunos ajustes finales y, para resolver varios de ellos, vamos a contar con la ayuda de Zentyal. Ante todo, debemos centrarnos en conseguir la mejor experiencia de usuario posible para que nos ayude en nuestra gestión del cambio diaria. Y tener tan cerca de nosotros a una empresa como Zentyal nos da las garantías necesarias para emprender este nuevo reto.

El cambio a Ubuntu nos da más independencia tecnológica de la que teníamos pero, sin embargo, nos ha cambiado el paradigma de escritorio que hasta entonces conocíamos con Gnome 2. La elección del nuevo entorno de escritorio no ha estado exenta de dudas e incertidumbres y esperamos no habernos equivocado demasiado en nuestra opción final: Gnome Classic.

Otro aspecto importante que debíamos tener en cuenta antes de sacar a producción la nueva versión de AZLinux era preparar las herramientas necesarias para la actualización de los equipos existentes (tanto de Windows a AZLinux 12, como de AZLinux 2 a la versión 12). Este es el motivo que ha hecho ralentizar el proceso de culminación de esta versión. Pero ahora que este trabajo está terminado, estamos en condiciones de seguir con las pruebas en algunos usuarios reales (especialmente seleccionados para la ocasión).

Durante la charla en el Zentyal Summit, ha habido una pregunta que me ha llamado especialmente la atención. Alguien ha preguntado sobre si teníamos alguna medida sobre el estado de satisfacción de nuestros usuarios con el cambio de sistema operativo. La realidad es que no la tenemos como tal, aunque la comunicación y el feedback es constante con ellos. De hecho, la experiencia de estos años, nos hace sacar estas conclusiones al respecto:

• En nuestra organización, ha sido más problemático el cambio de la herramienta ofimática que el del sistema operativo. Mientras que tenemos a dos personas en exclusiva para resolver dudas sobre OpenOffice/LibreOffice, tan apenas hay incidencias sobre el uso del sistema operativo (una vez que los usuarios han pasado por un curso de formación que nosotros mismos hemos diseñado).
• Las soluciones de las incidencias de los equipos con Linux son más fáciles de desplegar que en los equipos con Windows que poseemos. Además, un determinado problema suele propagarse menos porque, una vez detectado en un equipo, la solución se aplica a todos los demás en un período de tiempo razonablemente corto (gracias al hecho de que paquetizamos los cambios en la configuración software, a nuestra herramienta de distribución migasfree y a que los equipos con Linux son mucho más homogéneos y menos degradables).
• Aunque la gestión del cambio ha sido constante durante todo este tiempo, últimamente hemos observado una variación en la tendencia. Si antes los usuarios eran reticentes a los cambios, ahora los hay que nos piden directamente que les actualicemos a Linux porque han observado que va más rápido (la edad media de nuestros equipos es de 5/6 años) y da menos problemas.

Presentación del Proyecto AZLinux en Zentyal Summit 2012

Etiquetas: ubuntu, zentyal

Por @jact_abcweb.

Con el cambio de distribución base (de openSUSE a Ubuntu), tocaba, de nuevo, salvar el importante escollo de hacer funcionar los certificados digitales en la nueva plataforma. El reto consistía (otra vez) en tener disponibles simultáneamente ambos tipos de certificados: Ceres y DNIe. Todo volvía a depender de encontrar una versión de OpenSC que hiciera esto posible.

OpenDNIe está a punto de integrarse dentro de OpenSC, y en la forja de Cenatic hay versiones previas a esta inminente integración, que permiten instalarlo sin problemas en varias distribuciones Linux actuales.

Sin embargo, Ceres se ha quedado en el limbo. La comunidad dispone de una versión liberada del proyecto de la FNMT, pero nadie da el paso para integrarla dentro de OpenSC. El resultado es que cada vez es más complicado hacer convivir ambos módulos en las distribuciones modernas de Linux.

¿Cómo lo hemos conseguido esta vez?

El escollo más claro lo constituye el hecho de que a partir de OpenSC-0.12, ya no es posible cargar módulos de certificados digitales. Había que encontrar una versión que funcionara en Ubuntu Precise y que permitiera la carga de módulos.

De nuevo, hemos recurrido a la forja de Cenatic para partir de una versión de OpenSC-0.11.13 que integra, además, el DNIe.

La mala noticia es que ha costado compilar dicha versión en Ubuntu 12.04. Cambios en la forma de enlazar librerías en el sistema, nos han mantenido entretenidos durante algunas semanas. Aún así, no hemos sido capaces de compilarla con todos los módulos activos, y hemos tenido que prescindir de la librería opensc-signer.so.

El siguiente reto ha consistido en paquetizar el resultado de la compilación. Para ello, hemos partido del paquete para Ubuntu Natty (el último de la versión 0.11).

Se han tenido que quitar algunos patches, modificar algún otro y adecuar la compilación para que no se genere el paquete mozilla-opensc (la librería opensc-signer.so). Aparte de eso, el paquete es funcional en Ubuntu 12.04.

Después, se ha compilado el módulo de Ceres, modificando, naturalmente, la versión referida a OpenSC.

Conclusiones

El sistema funciona pero si cada vez que cambiemos de versión de Ubuntu hay que hacer todo esto (mientras se pueda hacer...), vamos a tener un problema importante en la migración a Linux de nuestra administración.

Tras varios años de trabajar con entornos Linux y los certificados digitales españoles, me vuelven a surgir algunos interrogantes a los que todavía no hemos encontrado respuesta: ¿Cuándo tendremos disponible Ceres dentro de OpenSC? Si se ha conseguido con el DNIe, ¿qué inconvenientes hay para que no se pueda integrar el código de Ceres?

El DNIe es potencialmente usable por gran parte de la población española.

Ceres es usado a diario por la administración pública española para sus gestiones con certificados digitales.

Artículos relacionados

• Certificados digitales en AZLinux 3.
• Conclusiones del OpenDNIe hackfest.
• OpenDNIe en AZLinux.

Etiquetas: dnie, ceres, cenatic

Miguel Jaque finaliza su etapa en CENATIC.

Durante la andadura de AZLinux tanto Miguel Jaque como otros compañeros de Cenatic nos han acompañado en nuestras alegrias y penas. Recuerdo especialmente tu charla sobre Presente y Futuro del Software Libre en Zaragoza Milla Digital en la que tuve el honor de compartir mesa contigo.

Reconocemos y agradecemos tu labor en CENATIC como defensor del Software Libre con argumentos éticos y técnicos, y especialmente tu apoyo para que la AAPP avance hacia modelos mas abiertos y sostenibles.

El Software Libre es abierto y sostenible, y estoy convencido que esto, a no tardar mucho, va a ser una exigencia de nuestro clientes, los ciudadanos y ciudadanas a los que debemos máxima eficacia y eficiencia.

Miguel, esperamos contar contigo en tu nueva andadura para la que te deseamos toda la suerte del mundo.

Eduardo Romero. Equipo AZLinux

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

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

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