Hosting artesano

Al principio fue un tutorial de Bulma

Mi primer sistema de correo con dominios virtuales lo monté siguiendo un tutorial de http://bulma.net (gran sitio) usando mysql, postfix, sasl y courier. En el tutorial (que ahora no encuentro: no funciona el buscador de bulma) había además una sencilla aplicación php para gestionar la creación de dominios y cuentas de correo en la base de datos.

Cuando todo funcionaba instalé Horde (Application Framework) y sus aplicaciones IMP (webmail), Ingo(reglas de filtrado de correo), Turba(libreta de direcciones), Kronolith (calendarios), Mnemo (notas postit).

Tiempo después el spam empezó a ganar popularidad. El servidor se petaba a cada rato. Los clientes pedían la posibilidad de activar un mensaje de respuesta automática en periodos vacacionales, y nosotros queríamos poner quotas a las cuentas de correo porque algunxs se estaban saliendo de la taza.
Estuve peleándome con estas movidas y acabé encontrándome con amavis, spamassasin, las listas negras, las listas grises, gnarwl para las vacaciones y un parche de postfix para la quota de los buzones de correo.

...y llegó ldap

Seguí leyendo artículos sobre sistemas de correo y una palabra que no sé porqué hasta entonces para mí (y diría que para otros tantos aún en la actualidad) había sido tabú, aparecía en todas partes: ldap.

Ldap, como SCSI, eran palabras que de vez en cuando se escuchaban en la facultad. Estaban asociadas a cosas super difíciles para expertos. No era para tanto. Siguiendo un par de tutoriales puede uno ponerse al día con ldap. De SCSI no voy a decir nada porque todavía no sé distinguir el raid0 del raid1. (NOTA para entendidos: en la facultad alguien ponía siempre a principios de diciembre un folio en todos los tablones que decía: "YA SCSI NAVIDAD"... tardamos un par de años en coger el chiste (SUBNOTA para no entendidos: SCSI se pronuncia "escasi")).

Ldap en palabras para entendernos es una base de datos jerárquica, en forma de árbol, donde cada nodo del árbol tiene un padre y varios hijos (menos el nodo raíz del árbol, que lógicamente no tiene padre). Además, para ldap los schemas definen objectClasses, que están compuestos por attributes. Haciendo una analogía con drupal una objectClass es un content-type y un attribute un field. Las dos grandes diferencias conceptuales en la comparativa con drupal son:

  1. ya existe una serie de objectclasses disponibles de las que elegimos con cuales queremos trabajar, según las características de cada objectclass y nuestras necesidades. Muchas de estas objectclasses vienen definidas en RFCs y otras son estándares de facto por ser parte de proyectos con cierta solidez (ej: Courier proporciona CourierMailAccount y alguna otra objectclass). Podemos definir las nuestras propias pero creo que no es una práctica habitual, yo al menos procuro buscar soluciones con las objectclasses existentes. Una objectclass como hemos dicho se compone de atributos, unos requeridos (MUST), otros optativos (MAY).
  2. cada nodo del árbol ldap independientemente de las características de su nodo padre o sus hijos está definido por una o más objectclasses y por lo tanto tienen la sumatoria de atributos de todas sus objectclasses (obligatorios y optativos).
Hay más cosas que contar de ldap pero no es el objeto de este post, lo dejaré para otro día.

Siguiendo un tutorial de cuya fuenta no me acuerdo monté un sistema de mail con OpenLdap usando PhpLdapAdmin y posteriormente un script propio para crear los dominios y las cuentas de correo.

...y llegó phamm

Buscando alguna aplicación que me facilite la tarea de gestionar las cuentas de correo me he encontrado con phamm (actualmente la versión 0.4.10), una aplicación php para gestionar servicios usando ldap como backend.

En el mundo del software libre no hay ISP Control Panels alternativos a los conocidos paquetes privativos CPanel o Plesk. Hay bastantes intentos que han acabado siendo proyectos abandonados. Otros, con desarrollo más o menos continuado en el presente, no me gustan porque o bien te fuerzan a usar un paquete software determinado (léase exim o qmail en vez de postfix, ezmlm en vez de mailman o un webmail en concreto) o bien tienes que dejarles tomar el control del sistema para que lo gestionen a su manera, perdiendo en la práctica la capacidad de bajar a la línea de comandos para hacer alguna cosa a mano, a riesgo de romper algo.

Estos paneles de control son cajas negras que proporcionan una funcionalidad con mayor o menor eficacia. Personalmente prefiero configurar los servicios a mano, conocer los detalles de su configuración, y que el panel de control sirva para gestiones a alto nivel (crear cuentas de correo, etc), que puedan ser delegadas a los clientes.

Phamm es un modesto proyecto de software libre que no alcanza la categoría de "panel de control para ISP". Es una aplicación sencilla de usar, con mucha potencia y muy práctica. Me ha venido como anillo al dedo pues se encarga de manejar en ldap las cuentas de correo (con aliases, forward, amavis, quota y vacaciones) incorpora plugins para usuarixs ftp, para entradas dns (contra powerdns) y para radius (que no uso).

Con phamm gestiono las cosas en ldap. Los servicios los monto a mi manera contra la estructura de phamm en ldap. Phamm proporciona unos schemas propios para el sistema de correo, más cómpletas que las de Courier. Para el dns se usan objectclasses estándares y para el ftp usa las objectclasses de pureftp. La flexibilidad del sistema es máxima:

  1. Como servidor smtp uso posftix y no pienso cambiarlo :)
  2. Como servidor pop/imap uso courier (con los schemas de phamm); el cambio a dovecot es trivial.
  3. Como servidor ftp uso proftp en vez de pureftp. He hecho unos pequeños cambios para que phamm trabaje con schemas estándares (posixAccount) en vez de con los de pureftp (aunque también podría haber usado los schemas de pureftp con proftpd --que no proporciona schemas propios).
  4. Como servidor dns uso powerdns con dnsDomain como schema (estándar). Se puede usar bind con el backend ldap sin tocar nada en ldap/phamm.
  5. Las listas de correo con sympa en vez de mailman ya que trae soporte multidominio sin necesidad de parchear. La información de listas de correo y suscritos se guarda en mysql (aunque hay unas opciones ldap que no he explorado aún).
  6. El servidor web: apache: a mano. He visto que existe dos o tres módulos de apache para almacenar los virtualhosts en ldap.