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.
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!