lunes, 30 de agosto de 2010

Leer una base de datos Berkeley DB

Muchísimas aplicaciones utilizan bases de datos BerkeleyDB, y no hay (que yo sepa) ninguna aplicación específicamente diseñada para ver el contenido de éstas. Así que busqué un lenguaje de programación que me permitiera trabajar rápidamente con ellas y encontré que la papeleta me la resolvió PHP:

error_reporting(E_ALL);
$id = dba_open("file", "r", "db4");
var_dump($id);
$key = dba_firstkey($id);

while ($key != false) {
if (true) {
$handle_later[] = $key;
}
$key = dba_nextkey($id);
}
echo("\n");
foreach ($handle_later as $val) {
$string=dba_fetch($val,$id);
echo("$val||$string\n");
}

miércoles, 25 de agosto de 2010

Sobre la posible responsabilidad de la Administración Pública en un programa desarrollado mediante un modelo libre (aspectos técnicos)

El modelo de trabajo en dos fases, con repositorio a cargo de la comunidad de desarrolladores y versiones oficiales a cargo de la A. P. es fácilmente implementable en los sistemas de «forja» de código actuales, y con poca dificultad en cualquier otro que se desee. Por ejemplo, el sistema ya existe en la forja de OSOR.eu. A tal fin se distingue entre tres formas de obtener el código:

  • A través de los medios propios del repositorio o a través de su interfaz web

  • En forma de bola 'tar' o archivo comprimido generado automáticamente por la forja

  • En forma de bola 'tar', archivo comprimido o paquete (fuente o binario) creado por los desarrolladores propios de la A. P.


En los dos primeros casos el usuario obtiene una versión del código que se considera, a todos los efectos, como inestable o de desarrollo. En el tercero, el código obtenido se considera, a todos los efectos, código publicado por la A. P.

A modo de ejemplo, véase el proyecto SEXTANTE de la Junta de Andalucía alojado en OSOR.eu que nos proporciona los tres modos:



Los casos a) y b) quedan claramente al alcance de cualquiera, pero sin embargo quien obtiene el código por dichas vías es plenamente consciente de que obtiene código no necesariamente comprobado, mientras que el caso c) es el resultado del esfuerzo consciente por parte de ciertos desarrolladores en empaquetar una versión determinada del código.

De esta manera, el flujo de trabajo comienza con desarrolladores que realizan cambios en el código y añaden tales cambios al repositorio. Según la confianza que se tenga en dichos desarrolladores, podrán añadirlos directamente a la rama «tronco» del repositorio o no, pero en cualquier caso dichos cambios son parte de la base de código desde ese mismo momento. Nótese que la responsabilidad es puramente personal del desarrollador que realiza el cambio, y que no se trata necesariamente de personas responsables ante la A. P.

El flujo continúa con la evaluación de dichos cambios por parte de dos grupos, los usuarios que decidan obtener esa versión del código y probarla, y con ello informar de posibles fallos o regresiones de código, y los restantes desarrolladores que decidan hacer una «revisión por iguales» del cambio y, en su caso, portarlo a otras ramas del repositorio.

El siguiente paso es que uno de los desarrolladores que sí tienen la responsabilidad ante la A. P. de seleccionar el código aceptable para su publicación haga una revisión de una serie de cambios al «tronco» del repositorio y publique una nueva versión oficial del programa. Es en este punto, y solamente en éste, donde aparece la responsabilidad de la A. P. ante los usuarios.

Queda el caso puntual de las versiones inestables oficiales, entendiendo por tales las versiones «candidatas para la liberación» que se publican por muchos proyectos, tanto libres como privativos. Dichas versiones son necesarias, casi imprescindibles, para probar el código antes de liberarlo, pero suelen publicarse de la misma manera que las versiones oficiales. Suelen contener una indicación clara de su estado no definitivo, como las letras 'rc' (Release Candidate) o el indicativo 'beta'. Sin embargo, el publicarlas de la misma manera que las versiones oficiales definitivas puede tomarse, con un poco de mala fe o de ineptitud, como indicativo de que se encuentras endosadas por la A. P.

El caso con estas versiones es que efectivamente se trata de versiones publicadas oficialmente, ya que es código que ha sido comprobado por los desarrolladores de confianza. En ese sentido la A. P. es responsable de la publicación de una versión inestable, pero es el usuario el responsable de haber elegido esa versión para su descarga estando disponible una versión estable oficial aunque sea más antigua: ningún usuario puede aducir que descargó una versión 'rc', 'beta' o '0.x' sin saber que se trata de versiones de prueba. Para reforzar este punto, versiones tales no deben presentarse en la página principal del proyecto, pero sí en la página de versiones liberadas de la forja. No es un problema que aparezcan en la zona de noticias de la página principal del proyecto si se presentan como versiones de prueba.

La diferencia presentada entre código en el repositorio y código publicado oficialmente hace posible el modelo de comunidad en el que la única normativa para ser considerado como desarrollador es haber contribuido con código válido.

martes, 24 de agosto de 2010

warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory

Configurando la autenticación de mi servidor de correo Postfix con Cyrus SASL2 me encontré con que no funcionaba: el fichero /etc/sasldb2 estaba en su sitio y con los permisos correctos, pero no había manera.

Esta página de Matthew Chapman me dio la pista de lo que pasaba (y, consecuentemente, la solución): la biblioteca Cyrus SASL2 se mete en una jaula chroot en /var/spool/postfix antes de comprobar si /etc/sasldb2 existe, y por ello aunque exista correctamente, no lo encuentra.

La solución creando un enlace simbólico no funciona, ojo, porque desde dentro de la jaula chroot resulta que /etc/sasldb2 se apuntaría a si mismo. Por lo tanto, hay que copiar el fichero, o crear un enlace duro si quieres olvidarte de actualizar la copia en la jaula cada vez que cambies el original:

ln /etc/sasldb2 /var/spool/postfix/etc

viernes, 20 de agosto de 2010

Mover descargas entre instalaciones de aMule

Tenía, en un disco duro que ya no uso para eso, un .aMule con su configuración y todo lo demás, incluido su Temp, que contiene los ficheros de las descargas parciales.

Hoy probé a mover esas descargas parciales (los ficheros *.part, *.part.met, *.part.met.bak y *.part.met.seeds, que contienen, respectivamente, los datos descargados, la información de la descarga, una copia de seguridad de ésta, y una lista de fuentes cuando son escasas.

He comprobado que simplemente moviendo estos ficheros al .aMule/Temp que uso ahora, renombrando aquellos cuyo número de serie coincidía con un grupo ya existente, la cosa funciona perfectamente.

Ojo, eso sí, hay que usar la misma numeración para los que tenían la misma numeración. Así, si tienes que mover 001.part, 001.part.met y 001.part.met.bak, y ya existen esos nombres en el Temp de destino, los puedes llamar 901.part, 901.part.met y 901.part.met.bak pero no 901.part, 902.part.met y 903.part.met.bak.

martes, 17 de agosto de 2010

Sobre la posible responsabilidad de la Administración Pública en un programa desarrollado mediante un modelo libre

Si una Administración Pública distribuye un programa libre, tiene cierta responsabilidad con los usuarios del mismo incluso en el caso de que la propia Licencia del programa indique lo contrario, ya que, al contrario que un distribuidor cualquiera, una A. P. sí tiene una obligación legal real de velar por los receptores del programa, que son sus ciudadanos. Dicha responsabilidad puede ser mayor aún en el caso de que el usuario del programa sea la propia A. P. de modo tal que un problema en el programa suponga para aquélla la pérdida de datos de los ciudadanos o cualquier otro resultado que les perjudique.

Al mismo tiempo, crear un programa al modo de los proyectos libres implica que varias personas (los desarrolladores en quienes se tiene confianza suficiente como para permitirles acceso de escritura al repositorio), algunas de las cuales no tendrán ningún tipo de relación contractual directa ni indirecta con la A. P. que promocione el programa, podrán realizar cambios al mismo, algunos de los cuales pueden ser perjudiciales, bona fide o maliciosamente.

Parece entonces que llegamos al dilema cruel de que una A. P. debe renunciar a liberar un programa y desarrollarlo a través de una comunidad o aceptar la responsabilidad de un programa que no se encuentra bajo su control.

Sin embargo, se trata de un falso dilema, ya que hay un paso intermedio entre el desarrollo y la publicación, que es el punto en el que la A. P. puede intervenir a fin de controlar el proceso conforme a su responsabilidad sin correr el riesgo de molestar a la comunidad de desarrolladores con injerencias. Dicho punto es la liberación de versiones oficiales del programa.

El flujo de trabajo correcto para bordear adecuadamente el problema es:

  1. que los desarrolladores trabajen libremente, hasta el punto en que tal cosa sea posible para que el programa no se aleje de las especificaciones, en el repositorio de código

  2. que un grupo seleccionado de desarrolladores, responsables ante la A. P. (funcionarios, contratados por la A. P. o contratados por una empresa contratada a tal fin por la A. P.), seleccione regularmente el código de la rama «tronco» del repositorio, lo empaquete (a modo de paquete fuente o de paquetes fuente y binario) y lo publique


De este modo, los usuarios que lo deseen pueden obtener las versiones de desarrollo del código, lo cual es imprescindible para la detección de fallos en el mismo y su mejora, sin responsabilidad para la A. P., y ésta puede proporcionar versiones oficiales que hayan pasado el filtro de los desarrolladores contratados, con plena responsabilidad.

Es conveniente, pero no necesario, que la distinción entre estas dos maneras de proporcionar el código sea patente en la interfaz web del repositorio de código, con una mención del tipo «[La A. P.] no se hace responsable de los posibles fallos de estas versiones de desarrollo y niega toda responsabilidad sobre el mismo. Si no es usted un usuario avanzado, por favor utilice las versiones oficiales que puede encontrar en [sitio web].».

Ante un problema real que se produzca como consecuencia del uso del código, la estrategia de defensa de la A. P. debe variar en función de que dicho fallo se produzca en un código obtenido del repositorio o en un programa de la distribución oficial.

En el primer caso, la A. P. debe negar toda responsabilidad, indicando que el usuario sabía lo que hacía al descargar una versión de desarrollo, e indicando que el usuario asumió toda la responsabilidad al usar la interfaz web del repositorio de desarrollo del código (si lo hizo así) o indicando que el usuario era plenamente consciente del peligro de utilizar una versión de desarrollo, ya que es inconcebible que un usuario lo suficientemente avanzado como para utilizar el repositorio sin usar su interfaz web no lo sea.

En el segundo caso, la A. P. debe aceptar la plena responsabilidad por el perjuicio causado, ya que es, al menos, responsable civil subsidiario, pero al mismo tiempo debe averiguar qué desarrollador aceptó el cambio en el código que causó el problema e iniciar las acciones penales y, en su caso, disciplinarias adecuadas, ya que sin duda se trata de uno de los «desarrolladores de confianza» plenamente identificados por ser funcionarios, contratados por la A. P. o contratados por una empresa contratada a tal fin por la A. P.

viernes, 13 de agosto de 2010

Usuario que reparte el correo

Me ha costado un buen rato ver qué pasaba, pero lo he conseguido.

Tengo una máquina que recibe mi correo electrónico, y estaba tratando de configurar el servicio en una máquina nueva. Utilizo Postfix, y tiene la sana costumbre de que el usuario que reparte el correo, es decir, el usuario que el proceso local utiliza para escribir en los buzones, es el usuario nobody.

Pero yo necesitaba que fuera el usuario mail, ya que utilizo directorios Maildir, por fiabilidad. Me ha costado averiguar cómo hacerlo (estoy desentrenado), pero finalmente lo he conseguido: basta con añadir la línea

default_privs = mail


al fichero /etc/postfix/main.cf.