oscarmlage oscarmlage

Dovecot, pequeñas peculiaridades

Desde hace algún tiempo -y después de haber lidiado con Cyrus y Courier- he optado por Dovecot como servidor POP3 e IMAP para máquinas en producción. Por varios motivos: la sencillez de configuración, sigue los estándares, soporta mbox y Maildir y algo muy importante, tiene un backend de autentificación SMTP compatible con Postfix (entre otros). Sin duda el servicio de correo electrónico es el menos agradecido y probablemente el más doloroso para el sysadmin pero el haber dado con esta combinación de elementos me ha ahorrado un montón de problemas. De todos modos en la última instalación que me ha tocado he encontrado un par de peculiaridades que me gustaría documentar por si alguien se encuentra en la misma situación.

Limitando usuarios ssh en Mercurial

Si algo bueno tiene Mercurial es que permite la autentificación de usuarios a través de SSH. Es muy sencillo agregar un nuevo usuario a un desarrollo/repositorio: adduser y con meterlo dentro del grupo correspondiente al desarrollo llegaría. Pero ¿qué ocurre si no queremos que ese usuario haga otra cosa que no sean comandos hg?. Conociendo la existencia de hg-ssh no ocurre demasiado, se trata de un script que hemos de referenciar en el authorized_keys del usuario que acabamos de crear de forma que todos los comandos entrantes pasen por este script. El script se encarga de parsear el comando que se pide en ejecución: si es de la familia de Mercurial lo ejecuta, en cualquier otro caso mostrará un error. Ejemplo de authorized_keys: command="~/hg-ssh /home/repo1 /home/repo2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAA... He optado por copiar el archivo hg-ssh en el directorio home del usuario, pero se podría referenciar directamente el que trae de ejemplo la instalación de Mercurial.

Mercurial sobre Apache

Mi predilección por Mercurial ha quedado patente en algún que otro post, así que una vez estamos conforme con nuestro servidor de versiones llega el momento de dar un paso más. Intentaremos configurar un interfaz web para mostrar el código a todo el mundo (una especie de Trac solo para código y adaptado a Mercurial). El proceso es tan sencillo como crear otro VirtualHost en tu Apache con unas características un poco especiales porque en vez de tirar de archivos dinámicos (.php, .asp…) vamos a tirar de un cgi en Python, así que la configuración sería algo así:

Mercurial: automatizando al máximo

Cuando trabajamos con servidores de versiones seguro que hay muchas razones de peso de por medio, una de ellas -la que veremos- puede ser la replicación de código en diversas máquinas. Supongamos un montón de máquinas que comparten el mismo código de repositorio, el orden de propagación de un cambio en todas esas máquinas es sencillo: Programamos dicho cambio en nuestro servidor de desarrollo (devel). Hacemos un commit local (en sistemas de versionado distribuido -como Mercurial- cada repositorio también es servidor). Lo siguiente es un push al servidor donde almacenamos el código (repo código). Ahora tocaría entrar en cada una de esas máquinas en las que queremos propagar el código y ejecutar un hg pull ; hg update.

El mejor firewall

Lo he visto en puntogeek a través del twitter de demogar y me ha parecido tan gracioso que he caido en el burdo copy-paste: Una célula humana contiene 75MB de información génetica. Un espermatozoide contiene la mitad; eso significa 37.5MB. Un ml de semen contiene 100 millones de espermatozoides. En promedio la eyaculación dura 5 segundos y contiene 2.24 ml de semen Esto significa que la producción del miembro de un hombre equivale 37.5MB x 100,000,000 x 2.25)/5 = 1,687,500,000,000,000 bytes/segundo = 1,6875 Terabytes/seg. Esto quiere decir que el óvulo femenino soporta este ataque DDoS a 1,5 terabytes por segundo, y solo permite que pase un solo paquete de información lo que la hace el mejor hardware firewall del mundo. La mala noticia de esto, es que ese paquete de información que deja pasar, cuelga el sistema por aproximadamente nueve meses.