Sábado 4 de Agosto de 2007

Cuando las cosas se tuercen

Hace muy poco, tras una actualización del sistema (Debian sid), el paquete gnokii falló en su instalación y, para variar, no hice demasiado caso a lo que me decía el sistema de paquetes e insistí en desinstalarlo puesto que no lo estaba utilizando. Ahí empezó el gran problema, el sistema de paquetes se atascó de mala manera y no decía más que:

 El paquete está en un estado muy malo e inconsistente - debe reinstalarlo
  antes de intentar desinstalarlo.

Resultando la desinstalación prácticamente imposible dado que los scripts postrm fallaban de mala manera, y estaba en un punto muerto.

Buscando en la red encontré esta entrada, de similares características, y donde daban una solución parcial para, al menos, configurar los paquetes pendientes:

# dpkg --pending --configure

Más tarde comprendí que la mejor forma de salir del atasco, dado que ninguno de los mecanismos normales funcionaban, era parchear dichos scripts para que al menos no diesen fallos al instalador. Los encontré en el directorio /var/lib/dpkg/info y cambié con un editor los párrafos que fallaban, que originalmente eran en el archivo gnokii.postrm:

# Old versions added a gnokii user too
if getent user gnokii; then
    if [ $1 = "purge" ]; then
        /usr/sbin/userdel --remove gnokii
    else
        /usr/sbin/userdel gnokii
    fi
fi

Me decidí por la supresión directa, probé la desinstalación normal con dpkg -r gnokii y todo funcionó a la perfección.

Nota: El problema está en que el paquete quiere eliminar un antiguo usuario que crean versiones anteriores, pero consulta erróneamente la base de datos user, cuando debería ser passwd.

Aplicaciones web y Debian

Justo lo que buscaba hace mucho tiempo, una guía, una normativa Debian para usar con las aplicaciones web.

Un proyecto de Alioth llamado webapps-common incluye varios manuales:

• Manual de normas para aplicaciones web.
• Documentación para el desarrollador.
• Normas para aplicaciones PHP

Todos están aún clasificados como bocetos (drafts), pero contienen un montón de cosas útiles, con las que se puede estar de acuerdo ó no, pero es un punto de partida al que puedes agarrarte, y no presenta una curva de aprendizaje muy compleja.

Una parte interesante es la que habla de dónde situar los archivos que componen la aplicación:

• Contenido estático ó dinámicamente interpretado: /usr/share/PACKAGE/www.
• Contenido ejecutado dinámicamente:
  • Si es dependiente de la arquitectura puede ir en /usr/lib/cgi-bin/PACKAGE ó en /usr/lib/PACKAGE.
  • Si es independiente debe ir en /usr/share/PACKAGE.
• Archivos de aplicación incluídos específicamente irán en un subdirectorio único de /usr/share/PACKAGE.
• Otros archivos de datos estáticos y programas auxiliares fuera de las rutas estándar de los usuarios (PATHS y demás) deberán ir también en un subdirectorio único de /usr/share/PACKAGE.
• Los datos persistentes, de caché y similares deben seguir las indicaciones de la normativa de aplicaciones con bases de datos.
• La configuración de la aplicación irá en un directorio llamado /etc/PACKAGE, y aquellos contenidos modificables ó contrarrestables lo harán en un subdirectorio del anterior.
• Las bibliotecas PHP irán en /usr/share/PHP y los módulos Perl seguirán la normativa Debian sobre Perl.

Hay muchas más cosas, pero creo que profundizaré en ellas cuando tenga que empaquetar estas aplicaciones, y no antes.

Ah, se me olvidaba mencionar que esta información está en consonancia con el FileSystem Hierarchy Standard, también conocido como FHS.

Paquetes Debian y bases de datos

Ya mencionado en la anterior sección, pero quiero dejar constancia aquí de la guía de uso de dbconfig-common escrita por Sean Finney, ya que la considero un recurso fundamental para implementar este sistema; y es que empiezo a estar harto de que al buscar el término dbconfig-common en la red me aparezcan en los primeros puestos páginas irrelevantes sobre el tema.

Más sobre Bacula

Ahora que tengo que crear una instalación nueva de Bacula sobre una máquina Debian no está de más el leer otras experiencias de instalación y puesta en marcha. Además, esta vez voy a usar una base de datos relacional, lo que puede hacerlo mucho más divertido (y enloquecedor).

Graham Smith cuenta cómo le fue a él, y que pasos siguió para conseguirlo; creo que es útil tenerlo aquí.

Desarrollando con Catalyst

He encontrado un hilo en PerlMonks que da ideas para analizar el rendimiento de una aplicación Catalyst.

Entre ellos se menciona el módulo Devel::DProf que tendré que estudiar más.