tags/etch

sarge-etch-1

2009-01-22T04:24:04Z

Después de la debacle de la semana pasada (de la que aún quedan algunas secuelas que ya comentaré) y teniendo ya planeada una upgradeada del desrver de Sarge a Etch (cosa que venía haciendo en un Xen hasta que me fui de vacaciones), decidimos hacerlo de una.

Empezamos en otra máquina instalando un Etch prístino. Esto implicó (re)instalar todo el soft que ya estaba corriendo en el servidor (que aún seguía corriendo). Lo único que no instalamos de nuevo aún es el zope/plone; tal vez lo hagamos directamente con lo que llaman un buildout.

Una desición personal, sobre todo basada en que en este entorno casi todos somos root, fue instalar algo que mantuviera en un rcs el contenido de /etc. Hace un par de años me senté a intentar un wrapper para svn que guardara la metadata como properties de los archivos llamado sylvan. El sistema era mas o menos usable, pero por suerte el genio de Joey Hess le ocurrió el mismo problema y salió con etckeeper. ectkeeper no está en Etch, por lo que instalé ese paquete y metastore bajándolos del repo de Sid y mercurial del repo de backports. Como no estoy seguro que el nnotito de aptitude sepa manejar este tipo de repos [para el caso creo que dselect tampoco] no puse backports entre los deblines.

El siguiente paso fue mergear la configuración actual del server con lo que me dejó esta instalación. Claramente no era cuestión de tirar el /etc viejo encima del otro y que se hagan agua los helados. Para ello usé xxdiff (o también podría haber usado meld o diff3 para emacs), pudiendo seleccionar qué pedazos quería específicamente. Un poco de edición y estábamos casi listos.

El penúltimo paso fue popular el nuevo LDAP. pare ello alcanzó un slapcat -l en el server; borrar los registros que ya están en el server nuevo (el root del directorio y el admin); luego un slapadd -l en el nuevo; y luego probar con un par de ldapsearchs. Tambien copiar los certificados y cambiarles el owner a openldap.

Luego tocó hacer andar PAM y nss contra dicho LDAP. La configuración estaba "as is", incluyendo los certificados. Luego de algo así como una hora encontré que la parte de TLS no estaba andando, así que hube de desactivarla, para lo cual śolo hubo que comentar el ssl start_tls y ya. Mas adelante veré cómo reactivarla.

Ya listos (cerca de las 12 de la noche) apagué el server, instalé el disco y a bootear. Y acá es cuando comienza el verdadero baile.

Por suerte el mail no me trajo verdaderos problemas. Sólo tuve que ser muy cuidadoso, pues nosotros bajamos losmails de nuestra verdadero servidor por fetchmail. Por algún motivo se me escapó en el merge de la configuración del postfix la parte que dice que use MailDir en el home del usuario, por lo que estuve renegando otro tanto. ssh también fallaba, pero era porque se me había escapado un PasswordAuthentication no.

El último paso de la noche era (re)configurar el Apache para que anduvieran los repos svn vía DAV que autenticaban contra el LDAP. Al día siguiente vendría la parte de reactivar otros servicios del Apache. No hubo que renegar mucho, sólo cambiaron la forma en que le decía que autentique contra LDAP y agregarle una z a AuthzLDAPAuthoritative:

# AuthLDAPEnabled On
AuthBasicProvider ldap
AuthzLDAPAuthoritative on

13 horas después de iniciar mi día laboral (3 de la matina) me retiré tambaleando a mi casa.

sysadmin ldap debian sarge etch pam apache svn

sarge-etch-2

2009-01-22T04:24:04Z

El segundo día me amaneció a las 13. Hoy tocaba terminar con el Apache, que incuía apenas los tracs y el dotproject. Ambos implicaban upgrades.

Los trac no me hicieron renegar mucho, pues está muy bien documentado y hasta fue scripteable. Básicamente era un salto de sqlite2 a sqlite3, un trac-admin ... upgrade seguido de un trac-admin ... resync.

Con lo único con lo que renegué fue que a pesar del upgrade fue exitoso no podía entrar. En los logs encontraba esto:

(9)Bad file descriptor: Could not open password file: (null)

Google al rescate me dijo que había que apagar esa directiva que había tenido que modificar el día anterior:

AuthzLDAPAuthoritative off

También me salió esto:

Failed to load the AuthzSVNAccessFile: The character 'o' in rule '@except' is not allowed in authz rules

Eso era porque en un archivo de configuración del repo (conf.svnaccess) tenía los permisos de sólo lectura como ro en vez de r.

El dotproject me enfrentó a un viejo archienemigo: mysql. La verdad que no se a queinacarajos se le ocurre que es una excelente idea poner la configuración de acceso y permisos de una base de datos dentro de la base misma. Por un lado eso termina siendo un archivo binario no versionable y por otro obliga al sysadmin a aprender SQL (cosa que sé, pero no manejo fluidamente ni me interesa saberlo; otro de los motivos por los que amo los ORM's). Y además esta configuración termina en /var y no en etc. postgresql, en cambio, es mucho más inteligente. Y viva el SQL independiente del motor. Lástima nadie lo usa...

Bien, sólo tuve que hacer un dump del mysql anterior (chroot mediante), crear la base en el nuevo y hacer un load. Fantástico. Luego una lucha trabado con el sistema de permisos antesmencionado. Luego apuntar un browser a https://server/dotproject/install. En ese minisitio tuve primero que configurarlo (como DP no es un paquete en Debian, lo instalé de fuentes; la configuración queda en un archivo en include/config.php; ojo que las otras opciones es nukear las bases), luego volver a entrar a dicha URL, momento en el cual detecta las bases viejas y da la opción de upgradearlas. Anduvo sin problemas y ahora disfrutamos de un DP más nuevo. Yeepee!

sysadmin debian sarge etch apache trac svn mysql dotproject