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:

# <span class="createlink">AuthLDAPEnabled</span> On
<span class="createlink">AuthBasicProvider</span> ldap
<span class="createlink">AuthzLDAPAuthoritative</span> 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

Posted Wed 27 Jan 2010 11:55:55 PM CET Tags: pam