Hoy llegué a la oficina con la idea de que algunos tracs aún no andaban. Resultó que la auth contra LDAP no estaba lista. Encontré que esta configuración si andaba:

    AuthLDAPURL ldap://ldap.except.com.ar/ou=People,dc=except,dc=com,dc=ar
    Require valid-user

Mientras que esta otra no:

    AuthLDAPURL ldap://ldap.except.com.ar/ou=People,dc=except,dc=com,dc=ar
    AuthLDAPGroupAttribute memberUid
    AuthLDAPGroupAttributeIsDN off
    Require group cn=except,ou=Group,dc=except,dc=com,dc=ar

Resulta que ahora tenés que avisarle que el grupo lo tiene que buscar en el LDAP:

    Require ldap-group cn=except,ou=Group,dc=except,dc=com,dc=ar

sysadmin apache ldap

Hoy me tocó hacer una negrada marca cañón. Resulta que tenemos un Xarope andando. En la arquitectura de Xarope tenemos un Apache que nos hace de frontend a todos los sitios Zope que corren en los DomU's.

El tema es que estaba poniendo a andar en uno de los DomU's un repo Mercurial, el cual corre detrás de un lighty. Ponerlo a andar no fue muy duro, salvo que no sabía mucho ni de uno ni del otro. Cuestión que llegué al punto en que podía hacer un hg clone para bajarme una copia del repo, mas no hacer un push. Acá es donde se ponía peluda la cosa.

El problema es el siguiente: para que las passwds no anden volando en cueros tenía que poder acceder al repo por https. Ahora, repiensen el esquema: tengo un Apache al que le llegan los pedidos https, el que a través de un Rewrite forwardea el pedido al Lighttpd corriendo en otra máquina (virtual, pero no viene al caso). Por razones casi obvias forwardear de un 443 a un 443 no anda. ¡Pero resulta que si el forward es al 80 si!

Es decir, el Apache recibe https, y cuando forwardea el pedido, lo hace en http plano. Esto responde a mi pregunta "¿Comocatzo vamos a hacer cuando los usuarios de Zope pidan acceso por https?". La única contra que le veo a este setup es que el sitio final (sea un Zope o un repo Mercurial) no sabe si el acceso viene con SSL o no.

sysadmin lighttpd apache ssl mercurial xarope

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

Heme aquí otra vez, tratando de dar el último paso en darle hosting a humitos, que vendría a ser, dar acceso a subversion por https. Actualmente tenemos acceso anónimo y acceso por ssh, pero el primero no tiene autenticación, por lo que no permite commits, y para acceder al segundo requiere un user en mi server. Éste no deja de ser mi server privado y no me gusta la idea de abrir cuentas a troche y moche.

Prender https fue faćil, aunque lo puse en el puerto 4433, porque en el 443 tengo el ssh. El motivo es medio largo de explicar. Cabía la posibilidad de poner algún programa que me permita tener los dos servicios en el mismo puerto, pero el más maduro que ví decía ser una implementación muy chapucera.

Poner dav y dav-svn a andar es una pavada. Todo está explicado en el libro de subversion. El problema saltó cuando ví los repos de humitos. Este chango tiene bastantes proyectitos chicos puestos en disco de una forma que justo queda incómodo de usar con esto.

Resulta que los paths son de la pinta /home/humitos/proyectos/<proy>/svn. Las directivas que tengo que poner en la configuración de apache son de la pinta:

<Location /~humitos/svn/<proy>>
  DAV svn
  SVNPath /home/humitos/proyectos/<proy>/svn
</Location>

Al día de hoy cuento 15 proyectos. Se me ocurrió que tal vez s podría hacer con un LocationMatch, as in:

<LocationMatch ^/(~|%2f|%2F)humitos/svn/([^/]*)/(.*)$>
DAV         svn
    SVNPath     /home/humitos/projects/$2/svn/$3
</LocationMatch>

El primer match es porque en distintas circunstancias el ~ es enviado en alguna de esas tres formas por los navegadores, y no se desescapan antes de ser procesados por Apache. Lamentablemente no hay nada en la documentación de Apache que diga que se puedan usar el $2 y el $3 de esa forma, cosa que me confirmaron en el canar #apache en freenode. También existe la directiva SVNParentPath, pero serviría sólo si los path fueran de la pinta /home/humitos/proyectos/<proy>/svn.

Así que al fin y al cabo, no me quedó otra más que poner todo en un mismo archivo, darle permiso a humitos para escribir en él, y darle sudo pare reiniciar el Apache.

sysadmin apache subversion

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

anoche puse a andar un trac para kreissy. una de las cosas que dejé colgando fue que el trac quedó abierto como... bueno, apelen a su imaginación para terminar esa frase. esa misma noche humitos dejó su impronta, cosa que no me molesta, pero marca que esto no puede quedar así. so, a poner auth.

trac delega todo el sistema de autenticación en apache, así que es lo mismo que poner a andar tal cosa. apache tiene muy buena doc9n[1] al respecto. el desafío es hacerlo andar desde un .htpasswd.

pero, no se puede poner un bloque en un .htpasswd, lo cual imposibilita la empresa. y esto, ahora recuerdo, es lo que lo hizo imposible antes. así que no queda otra que recurrir a la configuración global de apache y dejarnos de joder.

al final el archivo /etc/apache2/sites-available/trac-kreissy quedó:

<Location /~mdione/projects/kreissy>
    SetHandler mod_python
    PythonHandler trac.web.modpython_frontend
PythonOption TracEnv /home/mdione/src/projects/kreissy/trac
    PythonOption TracUriRoot /~mdione/projects/kreissy
</Location>

# auth
<Location /~mdione/projects/kreissy/login>
AuthType Basic
    AuthName "kReiSSy-trac"
AuthUserFile /home/mdione/src/projects/kreissy/trac/htpasswd
    Require valid-user
</Location>

luego agregamos el sitio como enabled y reiniciamos apache:

$ sudo a2ensite trac-kreissy
Site trac-kreissy installed; run /etc/init.d/apache2 reload to enable.
$ sudo /etc/init.d/apache2 reload

c'est tout! luego configuro el trac con trac-admin y listo.

sysadmin trac apache

[1] documentación.