PXE para instalaciones básicas de CentOS y Debian

jue, 20 oct 2011 by Foron

Otro mini-post que vuelve a salirse completamente de la idea general de este blog. Ya hay mucha documentación sobre PXE y sobre instalaciones automatizadas tanto de CentOS como de Debian, pero bueno, a ver si le es útil a alguien.

En este caso, vamos a montar un sencillo servidor PXE, que podremos usar para hacer instalaciones de CentOS y Debian. Bueno, en realidad, podemos instalar cualquier cosa, pero en mi caso no suelo necesitar nada más.

Todo esto se debe a que, para las pruebas que hago en mi laboratorio, el mínimo de máquinas virtuales que necesito no baja de... tres, y al final tiendo a perder mucho tiempo con las instalaciones, y poco con el trabajo "de verdad". Por eso, nada mejor que PXE, kickstart y debian-installer para agilizar el proceso.

Ojo, que todo esto, aunque perfectamente válido, no es lo que yo usaría, a priori, en un entorno real. Hay mucho software que automatiza lo que vamos a hacer aquí, con un interfaz web, scripts para actualizar repositorios, .... Por eso, creo que aplicaciones como Cobbler (por citar una) deben ser la primera opción.

Aún así, para los que queréis aprender cómo se montan estos "inventos", aquí van unas pinceladas.

El problema

Necesitamos una forma rápida de instalar servidores. En mi caso, máquinas virtuales. Aunque hoy en día la gente de VmWare, RedHat o Virsh+libvirt ofrecen alternativas para clonar instancias como churros, vamos a optar por una solución genérica y mucho más divertida.

Las distribuciones que vamos instalar con este sistema son CentOS y Debian. Para el caso de las basadas en kickstart, la cosa está muy clara, pero para Debian, muchos os preguntaréis ¿Por qué no FAI? Bien, la respuesta rápida, en mi caso, es que no quiero instalar un servidor NFS, y la última vez que miré era un requisito. Como decía, buscad la solución que más os guste.

Otro problema posterior es la configuración "fina" de las instancias. Eso no lo voy a documentar aquí, pero como pista: cfengine, puppet, ....

La solución

He dicho que iba a ir rápido, y ya me estoy enrollando.... Venga, lo primero que necesitamos, como no, es una BIOS que permita instalar los clientes vía PXE. Por supuesto, tanto Qemu/KVM como VmWare lo permiten, así que ni una palabra más al respecto.

En cuanto al software necesario para el servidor de instalaciones, necesitamos un DHCPD razonable (por ejemplo el del ISC), un TFTPD (por ejemplo atftpd) y un servidor web, que en mi caso va a ser apache. Situemos todo en contexto:

  1. La máquina virtual arranca y "habla" con DHCPD.
  2. Además de la información IP, se trasmite, vía DHCP+TFTP, pxelinux.0.
  3. En el caso de Debian, también se aprovecha para dar una pista sobre dónde encontrar el fichero para debian-installer.
  4. Cargamos el menú de arranque con TFTP.
  5. El sistema usa apache para obtener los ficheros ks, debian-installer y los rpm, deb y demás parafernalia.

Empezamos por lo fácil: El contenido web. Tan sencillo como copiar el contenido de los CDs de instalación de las distribuciones a una ruta del arbol web.

  # ls /var/www/instalaciones/centos/6.0-x86_64/
  CentOS_BuildTag  EULA  images    Packages                  repodata              RPM-GPG-KEY-CentOS-Debug-6     RPM-GPG-KEY-CentOS-Testing-6
  EFI              GPL   isolinux  RELEASE-NOTES-en-US.html  RPM-GPG-KEY-CentOS-6  RPM-GPG-KEY-CentOS-Security-6  TRANS.TBL

  # ls /var/www/instalaciones/debian/squeeze/
  autorun.inf  dists  firmware  g2ldr.mbr  install.amd  md5sum.txt  pool         README.mirrors.html  README.source  setup.exe  win32-loader.ini
  css          doc    g2ldr     install    isolinux     pics        README.html  README.mirrors.txt   README.txt     tools

Sigamos con la configuración para DHCP. Hemos dicho que, además de las obvias IPs, también van a ayudar a las Debian con la definición del fichero para debian-installer. Hay tres bloques de configuración que os quiero enseñar:

  # less /etc/dhcp/dhcpd.conf
  ...
  subnet 192.168.10.0 netmask 255.255.255.0 {
     option routers 192.168.10.1;
     option domain-name-servers 192.168.10.1;
     option domain-name "forondarena.net";
     option tftp-server-name "inst.forondarena.net";
     filename "/instalaciones/pxelinux.0";
  }
  host centos1 {
     hardware ethernet 52:54:00:30:38:c6;
     server-name "fn134.forondarena.net";
     fixed-address 192.168.10.134;
  }
  host debian1 {
     hardware ethernet 52:54:00:da:4a:92;
     server-name "fn135.forondarena.net";
     fixed-address 192.168.10.135;
     if substring (option vendor-class-identifier, 0, 3) = "d-i" {
       filename "http://inst.forondarena.net/instalaciones/squeeze_preseed_135.cfg";
          }
  }
  ...

Como veis, para CentOS no trasmitimos nada relacionado con el fichero kickstart, pero para Debian sí. ¿Por qué? Pues para enriquecer un poco el post con algo diferente, la verdad. Hay más de una forma de hacerlo.

Con esto ya tenemos la primera fase del arranque. Lo siguiente: El "boot menu". Y para esto necesitamos TFTP:

  /srv/tftp/instalaciones/
  ├── pxelinux.0
  ├── pxelinux.cfg
  │   ├── C0A80A86
  │   └── C0A80A87
  ├── squeeze-x86_64
  │   ├── initrd.gz
  │   └── vmlinuz
  ├── centos-6.0-x86_64
  │   ├── initrd.img
  │   └── vmlinuz
  ├── msgs
  │   ├── centos
  │   │   ├── boot.msg
  │   │   └── general.msg
  │   └── debian
  │       ├── f1.txt
  │       └── f2.txt

La mayoría de estos ficheros se pueden bajar casi desde cualquier sitio:

  http://ftp.cz.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/netboot/debian-installer/amd64/

Como el contenido de "msg" es obvio, vamos a los fichero importantes, C0A80A86 y C0A80A87. ¿Qué clase de nombres son estos? Pues son las IPs, en hexadecimal, de nuestras dos máquinas virtuales:

  $ IP_ADDR="192.168.10.134"; printf '%02X' ${IP_ADDR//./ }; echo
  C0A80A86
  $ IP_ADDR="192.168.10.135"; printf '%02X' ${IP_ADDR//./ }; echo
  C0A80A87

El contenido, para CentOS, en C0A80A86:

  timeout 100
  prompt 1
  display msgs/centos/boot.msg
  F1 msgs/centos/boot.msg
  F2 msgs/centos/general.msg

  default Centos6

  label Centos6
    menu label ^Centos 6 amd64
    kernel centos-6.0-x86_64/vmlinuz
    append initrd=centos-6.0-x86_64/initrd.img ramdisk_size=6878 ip=dhcp ks=http://192.168.10.40/instalaciones/ks_rh6_134.ks

Como veis, hemos especificado la ruta web para el fichero kickstart.

Para Debian, en C0A80A87:

  # less C0A80A87
  menu hshift 15
  menu width 49
  prompt 1
  display msgs/debian/f1.txt
  timeout 100
  f1 msgs/debian/f1.txt
  f2 msgs/debian/f2.txt
  menu title Installer boot menu
  menu color title    * #FFFFFFFF *
  ...
  menu tabmsgrow 18
  menu tabmsg Press ENTER to boot or TAB to edit a menu entry

  default install

  label install
      menu label ^Debian Squeeze Texto amd64
      menu default
      kernel squeeze-x86_64/vmlinuz
      append video=vesa:ywrap,mtrr vga=788 initrd=squeeze-x86_64/initrd.gz auto=true priority=critical locale=es_ES console-keymaps-at/keymap=es --

En este caso, no hemos dicho dónde encontrar el fichero para debian-installer. Ya lo sabemos.

Y ya casi por último, veamos los ficheros kickstart y debian-installer, a los que vamos a acceder desde apache:

  # ls -1  /var/www/instalaciones/
  ...
  ks_rh6_134.ks
  squeeze_preseed_135.cfg

Todos conocéis el formato de los .ks; son simples y fáciles de leer.

  #version=RHEL6
  install
  url --url=http://192.168.10.40/instalaciones/centos/6.0-x86_64/
  lang es_ES.UTF-8
  keyboard es
  network --device eth0 --onboot yes --bootproto static --ip 192.168.10.134 --netmask 255.255.255.0 --gateway 192.168.10.1 --nameserver 192.168.10.1 --hostname fn134.forondarena.net
  rootpw  --iscrypted contraseña
  firewall --service=ssh
  authconfig --enableshadow --passalgo=sha512 --enablefingerprint
  selinux --enforcing
  timezone --utc Europe/Madrid
  bootloader --location=mbr --driveorder=vda --append="crashkernel=auto rhgb quiet"
  clearpart --all --drives=vda
  part /boot --fstype=ext4 --size=200
  part pv.gjsqnW-TYE3-SDwW-646R-0SSI-hhDa-ZF6bXm --grow --size=200
  volgroup vg_primario --pesize=4096 pv.gjsqnW-TYE3-SDwW-646R-0SSI-hhDa-ZF6bXm
  logvol / --fstype=ext4 --name=lv_root --vgname=vg_primario --size=7400
  logvol swap --name=lv_swap --vgname=vg_primario --size=588
  ##repo --name="CentOS"  --baseurl=http://192.168.10.1/instalaciones/centos/6.0-x86_64/ --cost=100

  halt

  %packages
  @core
  @server-policy
  @spanish-support
  openssh*
  %end

Es un ejemplo autogenerado para una máquina virtual tipo KVM. No le hagáis mucho caso al contenido en sí. Lo dicho, tenéis un kilo de documentación, e incluso aplicaciones para hacer estos ficheros.

Otra cosa muy diferente es debian-installer. La verdad, no conozco a mucha gente que no se haya atascado con esto en algún momento. El concepto es sencillo, con una opción para cada una de las opciones de cada uno de los menús que pueden aparecer durante el proceso de instalación. El problema es que, esto tan fácil de decir, es un listado .... largo; y con algunos algoritmos, como el del cálculo de espacio para particiones, nada claros. Además, como suele ser demasiado frecuente, el que decidió los nombres de las opciones.... bueno, que no me parece demasiado intuitivo, aunque si estás familiarizado con Debian te haces enseguida.

No voy a escribir un ejemplo completo. Os vais a tener que conformar con una pequeña muestra:

  # cat /var/www/instalaciones/squeeze_preseed_135.cfg
  ...
  # Keyboard selection.
  d-i console-tools/archs select at
  d-i console-keymaps-at/keymap select es
  d-i keyboard-configuration/xkb-keymap select es
  ### Network configuration
  d-i netcfg/choose_interface select eth0
  d-i netcfg/disable_dhcp boolean true
  # Static network configuration.
  d-i netcfg/get_nameservers string 192.168.10.1
  d-i netcfg/get_ipaddress string 192.168.10.135
  d-i netcfg/get_netmask string 255.255.255.0
  d-i netcfg/get_gateway string 192.168.10.1
  d-i netcfg/confirm_static boolean true
  ...
  # Root password, encrypted using an MD5 hash.
  d-i passwd/root-password-crypted password contraseña
  ...
  ### Partitioning
  d-i partman-auto/disk string /dev/sda
  d-i partman-auto/method string lvm
  d-i partman-lvm/device_remove_lvm boolean true
  d-i partman-lvm/device_remove_lvm_span boolean true
  d-i partman-auto/purge_lvm_from_device boolean true
  d-i partman-auto-lvm/new_vg_name string vg_forondarenanet
  d-i partman-basicmethods/method_only boolean false
  d-i partman-auto/expert_recipe string boot-root :: \
  100 100 100 ext3 \
         $defaultignore{ } \
         $primary{ } \
         device{ /dev/sda } \
         $bootable{ } \
         method{ format } \
         format{ } \
         use_filesystem{ } \
         filesystem{ ext3 } \
         mountpoint{ /boot } \
         . \
  200 1000 -1 ext4 \
         $defaultignore{ } \
         $primary{ } \
         device{ /dev/sda } \
         method{ lvm } \
         vg_name{ vg_forondarenanet } \
         . \
  300 4000 -1 ext4 \
         $lvmok{ } \
         lv_name{ lvroot } \
         in_vg{ vg_forondarenanet } \
         method{ format } \
         format{ } \
         use_filesystem{ } \
         filesystem{ ext4 } \
         mountpoint{ / } \
         . \
  512 512 512 linux-swap \
         $lvmok{ } \
         in_vg{ vg_forondarenanet } \
         lv_name{ lvswap } \
         method{ swap } \
         format{ } \
         .
  d-i partman-auto/choose_recipe select boot-root

  d-i partman/confirm_write_new_label boolean true
  d-i partman/choose_partition select finish
  d-i partman/confirm boolean true
  d-i partman/confirm_nooverwrite boolean true
  d-i partman/confirm_nochanges boolean true
  d-i partman-lvm/confirm boolean true
  d-i partman-lvm/confirm_nooverwrite boolean true
  d-i partman-lvm/confirm_nochanges boolean true
  ...
  # Individual additional packages to install
  d-i pkgsel/include string openssh-server less
  d-i pkgsel/upgrade select safe-upgrade
  popularity-contest popularity-contest/participate boolean false
  d-i finish-install/reboot_in_progress note
  d-i debian-installer/exit/halt boolean true
  # This will power off the machine instead of just halting it.
  d-i debian-installer/exit/poweroff boolean true
  ...

Y así podría seguir...

En este caso es una máquina virtual para ESX. Me interesa que veáis la parte de particionado. Aunque no os lo creáis, he definido una partición primaria /boot de unos 100M, y el resto en LVM, con aproximadamente 512M de swap, y el resto de espacio disponible para raíz.

Y poco más hace falta. Ahora bien, en este post, las notas que suelo añadir al final son más importantes que nunca.

Notas

Nota 1: Los ficheros de instalación automática de los ejemplos hacen un halt una vez finalizada la instalación. ¿Por qué? Porque no tengo automatizado que la BIOS cambie por arte de magia de arranque por PXE a arranque desde disco.

Nota 2: Más que una nota, un consejo. No os volváis locos con la configuración de ficheros de sistema, usuarios y aplicaciones. Tenéis herramientas mucho mejores para la configuración "fina", así que plantearos añadir puppet, cfengine, chef, ... en los bloques "%packages" y "d-i pkgsel/include", y dejarles que hagan su trabajo al arrancar la máquina. Para CentOS (desde puppetlabs):

  %post
  ....
  /sbin/chkconfig --level 345 puppet on
  /bin/echo "$PUPPETIP puppet" >> /etc/hosts
  /bin/echo "nameserver $NAMESERVERIP" >> /etc/resolv.conf
  hostname $hostname
  # Write out the hostname to a file for reboot.
  /bin/echo -e "NETWORKING=yes\nHOSTNAME=$hostname" > /etc/sysconfig/network
  /usr/sbin/puppetd -tv

y, como mini-ejemplo, un poco diferente, para Debian:

  d-i preseed/late_command string in-target wget -P /tmp/ http://servidor_web/script.sh;
    in-target chmod +x /tmp/script.sh; in-target /tmp/script.sh

dejando que ese "script.sh" haga cosas como "sed -i 's/START=no/START=yes/'", siguiendo la estructura de Debian de ficheros en default y todas estas cosas.

Nota 3: Lo más importante. Este post no es suficiente para hacer que las instalaciones automáticas os funcionen. Necesita trabajo. Si os atascáis con algo, tweet o comentario, y lo intentaremos solucionar.

read more

Buzones compartidos con Dovecot

dom, 02 oct 2011 by Foron

Ahora que ando reestructurando mi laboratorio, voy a aprovechar para documentar un par de aplicaciones que estoy moviendo al nuevo hierro.

En realidad, esto se sale un poco del objetivo de este blog, sobre todo teniendo en cuenta que ya hay kilos de documentación sobre, en este caso, Dovecot; pero bueno, a mí me va a servir como referencia rápida, y quizá os sea de utilidad a alguno de los cuatro que pasáis por aquí.

Empezamos con los buzones compartidos en Dovecot. Como siempre, pretendo ser lo más práctico posible, así que lo mejor que se me ha ocurrido es describir exactamente la forma en la que yo mismo tengo montado "el invento".

El problema

Antes de nada, hablemos sobre las aplicaciones que debemos tener funcionando antes de empezar:

Necesitamos un servidor de correo propio (probablemente Postfix) en el que recibir los mensajes, ya sea porque el MX apunta a él o porque usamos software tipo Fetchmail, por ejemplo. Además, tenemos varios usuarios en nuestro sistema que acceden a su correo a través de Dovecot.

Entre el correo que reciben, además del privado para cada uno, es muy probable que los usuarios estén suscritos a varias listas: de seguridad, de usuarios, anuncios de nuevas versiones de x aplicación, .... Además, también hay cuentas tipo helpdesk y listas para un departamento o grupo que deben estar accesibles para varios usuarios simultaneamente.

Algo habitual en estos casos es, por un lado, que cada usuario gestione sus propias subscripciones a listas de correo, y por otro, para el caso de las cuentas tipo helpdesk de las que hemos hablado, el mandar una copia a cada uno de los n usuarios implicados. Obviamente, esto genera un montón de copias y mensajes repetidos que, aunque no tenga que suponer un enorme problema, sí que es más propenso a fallos, además de no dejar de ser "poco elegante".

La solución

Bien, aquí ya entramos en la forma en la que yo lo hago, que no tiene que ser ni mucho menos la mejor o la única.

Vamos a empezar por el caso más fácil, los buzones públicos:

Por usar un ejemplo concreto, al hablar de "buzón público" me voy a referir a listas de correo generales y accesibles para todo el mundo. El único control de acceso que se va a hacer sobre ellas es a nivel de sistema de ficheros, por lo que recomiendo que los usuarios del sistema pertenezcan a un grupo concreto (o varios) siempre que quieran acceder a una u otra lista.

Y digo usuarios del sistema porque cada lista va a ser un usuario de sistema (mapeada con una cuenta de correo), de tal manera que la suscripción será única. Si quisieramos hacer que todo el mundo tuviera acceso a la lista de usuarios de Postfix, crearíamos el usuario "postlista", por ejemplo, y nos suscribiríamos a la lista de Postfix con postlista _A_T_ forondarena.net (no existe ni existirá nunca, que conste, pero ahora ya tengo un spamtrap más :D ). Como podéis suponer, el correo que llegue a esta dirección se guardará físicamente en (esta parte de la configuración de Postfix/Dovecot os la dejo a vosotros):

  drwxrwx--- 5 postlista postlista 4096 oct  1 17:57   /home/postlista/Maildir

Volviendo a los permisos a nivel de sistema operativo, hay algo importante a tener en cuenta: Dovecot 2.x (y con ello su agente de entrega local que usamos en Postfix) crea los ficheros de correo con los mismos permisos que su directorio principal, y por lo tanto debemos hacer que Maildir tenga 770, por ejemplo (siempre que optemos por los permisos a nivel de sistema operativo para limitar el acceso).

Una vez hecho esto vamos a crear un directorio común que nos va a servir como referencia para que los distintos usuarios "sepan" donde están las listas. La estructura va a ser la siguiente:

  ls -lha /home/listas/Maildir
  lrwxrwxrwx 1 root  root    21 sep 22 22:03 .postlista -> /home/postlista/Maildir

En el directorio "/home/listas" (o cualquier otro, no es un usuario del sistema) vamos a crear un enlace simbólico para cada uno de los buzones públicos.

¿Pero cómo sabe un usuario que puede acceder a esa lista pública?

Para esto usaremos los namespaces de IMAP (El que quiera entrar en el detalle sobre lo que son, que busque el RFC).

Dovecot define los namespaces en un bloque similar al siguiente, a veces en un único dovecot.conf, a veces en otro fichero. Debian, por ejemplo, divide los diferentes apartados de configuración en ".conf" diferentes:

  namespace {
    type = public
    separator = /
    prefix = listas-public/
    location = maildir:/home/listas/Maildir:INDEX=~/Maildir/listas-public
    subscriptions = no
  }

Adaptad la configuración a vuestro gusto, pero lo importante es que cuando el usuario "pepe" se loguee vía IMAP, va a poder suscribirse a todo lo listado en el directorio "/home/listas/Maildir", que además va a aparecer en su Thunderbird en el subdirectorio listas-public. Además, queremos que cada usuario tenga los ficheros propios de control que usa Dovecot en su maildir privado.

Esta es la forma fácil de crear buzones públicos.

Sin embargo, IMAP define una extensión para ACLs (los interesados también tienen RFCs al respecto), con las que podemos definir un control de acceso mucho más detallado, y que nos permitirán hilar mucho más fino en lo que puede hacer el usuario x en el buzón del usuario z. Para que os hagáis una idea, y cogido directamente del wiki de Dovecot, las ACLs permiten establecer los siguientes permisos:

  • lookup: Mailbox is visible in mailbox list. Mailbox can be subscribed to
  • read: Mailbox can be opened for reading
  • write: Message flags and keywords can be changed, except \Seen and \Deleted
  • write-seen: \Seen flag can be changed
  • write-deleted: \Deleted flag can be changed
  • insert: Messages can be written or copied to the mailbox
  • post: Messages can be posted to the mailbox by LDA, e.g. from Sieve scripts
  • expunge: Messages can be expunged
  • create: Mailboxes can be created (or renamed) directly under this mailbox (but not necessarily under its children, see ACL Inheritance section above) (renaming also requires delete rights)
  • delete: Mailbox can be deleted
  • admin: Administration rights to the mailbox (currently: ability to change ACLs for mailbox)

En el wiki de Dovecot podéis ver que letra corresponde a cada permiso. Por ahora lo dejamos y pasamos a la creación de un buzón compartido. Por cierto, no sé si está claro que con "buzón" me puedo estar refiriendo también a carpetas como "Trash", "Sent", o cualquier otra que creemos a mano.

Vamos a suponer que tenemos un usuario "helpdesk" en el que recibimos todo el correo destinado a "helpdesk _A_T_ forondarena.net" (otro spamtrap).

  /home/helpdesk/Maildir

Helpdesk es otro usuario del sistema, y su Maildir tiene permisos 770, para limitar el acceso también a nivel de sistema operativo.

Ahora que ya tenemos el usuario del sistema y que estamos recibiendo correo, vamos a activar el soporte para ACLs en Dovecot. Es muy sencillo, sólo hay que añadir un par de plugins, ya sea en dovecot.conf, o en el fichero que defina vuestra distribución.

  ...
  mail_plugins = acl
  ...
  protocol imap {
    mail_plugins = $mail_plugins imap_acl
  }

Y una vez tenemos los plugins, añadimos la configuración básica:

  plugin {
     acl = vfile
  }

Recordemos que queremos que el usuario "pepe" pueda acceder a todo el buzón "helpdesk". Para conseguirlo, vamos a hacer login con el usuario helpdesk, y vamos a usar el propio protocolo IMAP para dar acceso a pepe:

  # openssl s_client -connect 192.168.10.20:993
  CONNECTED(00000003)
  ..... (información SSL) .....
  * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready.
  . login helpdesk password
  . OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS ACL RIGHTS=texk] Logged in
  . setacl INBOX pepe lrwstipekxacd
  . OK Setacl complete.

Dicho de otra forma, hemos permitido "lrwstipekxacd" (cada permiso de la tabla anterior es una de estas letras) en el INBOX de helpdesk al usuario pepe.

¿Pero cómo sabe pepe que puede acceder a helpdesk?

Pues con los namespaces, claro. Vamos a crear uno de tipo "shared":

  namespace {
    ...
    type = shared
    separator = /
    prefix = buzones-shared/%%u/
    location = maildir:%%h/Maildir:INDEX=~/Maildir/buzones-shared/%%u
    ...
  }

Igual que con los buzones públicos, cuando pepe acceda a su cuenta va a ver un directorio buzones-shared en el que aparecerá helpdesk. ¿Verdad?

Pues no, porque no hay forma (con un rendimiento razonable) de hacer que Dovecot se recorra todos los buzones configurados (todos esos %%h y %%u), y sepa a cuáles tiene acceso pepe. A fin de cuentas, pepe y helpdesk son usuarios completamente diferentes, y no hay un enlace en un directorio claramente identificado, como "/home/listas" en el caso de los buzones públicos.

¿Entonces qué?

Es aquí donde entran en juego lo que en Dovecot se llaman "directorios", y que vamos a usar para decir, en este caso a pepe, que puede acceder a helpdesk. La configuración es la siguiente:

  plugin {
    acl_shared_dict = file:/etc/dovecot/acls/shared-mailboxes
  }

Quien dice "file:" dice base de datos o fichero .db. En cualquier caso, para este ejemplo usaremos un fichero en texto plano, "/etc/dovecot/acls/shared-mailboxes". Tened en cuenta, una vez más, que pepe tiene que poder leer el contenido de este fichero, y que además le interesa poder crear un lock en el directorio mientras está trabajando con él (vigilad los permisos unix, usad el directorio que queráis).

El contenido de shared-mailboxes es el siguiente:

  shared/shared-boxes/user/pepe/helpdesk
  1

Es una sintaxis que me parece particularmente "retorcida", pero es lo que hay si no queréis usar base de datos.

Y con esto lo tenemos ya "casi todo" (ver notas al final del post). Cuando pepe abra su Thunderbird y liste las carpetas a las que puede suscribirse verá el inbox de helpdesk, en este caso a partir de la carpeta "buzones-shared".

Notas

Primera nota:

En Dovecot, una vez que definimos un namespace, también tenemos que definir explicitamente el namespace privado. Por lo tanto, la configuración completa, en lo que a namespaces se refiere, tiene que parecerse a esto:

  namespace {
    inbox = yes
    location =
    prefix =
    separator = /
    subscriptions = yes
    type = private
  }
  namespace {
    location = maildir:/home/listas/Maildir:INDEX=~/Maildir/listas-public
    prefix = listas-public/
    separator = /
    subscriptions = no
    type = public
  }
  namespace {
    location = maildir:%%h/Maildir:INDEX=~/Maildir/buzones-shared/%%u
    prefix = buzones-shared/%%u/
    separator = /
    subscriptions = no
    type = shared
  }

Una vez más, adaptad la configuración a vuestras preferencias. Por ejeplo, quizá os venga bien añadir un "list = children" en vuestros namespaces.

Segunda nota:

¿Si habéis hecho pruebas antes de llegar al final, os habéis dado cuenta de que, una vez configurados los buzones shared, las listas públicas han dejado de verse?

¡Claro!, hemos empezado a usar ACLs, así que hay que dar acceso a pepe a las listas. Muy fácil, nos logueamos con el usuario de la lista que queramos abrir, y damos acceso a pepe:

 ...
  * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready.
  . login postlista password
  . OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS ACL RIGHTS=texk] Logged in
  . setacl INBOX pepe lrwstipekxacd
  . OK Setacl complete.
  . logout

Tercera nota:

Los ficheros dovecot-acl tienen el siguiente contenido de ejemplo:

  user=pepe akxeilprwts

Pero no los editéis directamente. Usad setacl, getacl, myrights, ..., o mejor aún, alguna extensión de Thunderbird que lo haga por vosotros.

Y para terminar, tened en cuenta, una vez más, que este post no es una referencia para hacer copy/paste. Necesita trabajo (poco) si queréis hacerlo funcionar.

read more

Gestión de logs con Solandra III

lun, 15 ago 2011 by Foron

Pasamos a la tercera parte de la serie, en la que ya vamos a ver un ejemplo concreto de lo que puede ser un sencillo interfaz para la gestión de logs usando Solandra. Como siempre, todo el código y los ficheros de configuración más importantes están en Github.

Recordemos los objetivos que nos hemos marcado:

  • Ser capaces de gestionar un volumen muy importante de logs, con la máxima escalabilidad y disponibilidad.
  • Poder añadir los logs en el sistema de una forma sencilla.
  • Tener un interfaz web desde el que poder visualizar los datos.

Ya hemos hablado sobre la escalabilidad de Cassandra en los posts anteriores, así que no vamos a volver a entrar en este punto. Veamos los otros dos:

Inserción de datos en el sistema

Solandra es básicamente una adaptación de Solr, por lo que en realidad vamos a tratar conceptos propios de esta aplicación en lo que queda de post. Cuando veamos algo específico de Solandra, lo señalaré.

Uno de los elementos más importantes de la configuración del sistema es el schema; que viene a ser el lugar en el que se definen los atributos que forman cada "documento" (correo en este caso) que se quiere indexar. Como veremos más adelante, una vez creada esta estructura de datos, usaremos el comando curl para insertarla en el cluster a través de una url determinada. Además, Solandra permite trabajar con varios schemas diferentes de manera simultanea.

Simplicando un poco, el schema está compuesto por dos grandes bloques: La definición de los tipos de datos y la lista de atributos que forman cada documento.

Solr ofrece muchos tipos de datos ya creados de antemano: numéricos, texto, fechas, .... Por si esto fuera poco, la aplicación permite definir nuevos tipos siempre que se considere necesario. Para la gestión de logs de correo, por ejemplo, nos podría venir bien un tipo específico para las direcciones email:

  ...
  <fieldType name="email" class="solr.TextField" >
     <analyzer>
        <tokenizer class="solr.PatternTokenizerFactory" pattern="@" />
        <filter class="solr.LowerCaseFilterFactory" />
        <filter class="solr.TrimFilterFactory" />
     </analyzer>
  </fieldType>
  ...

Este tipo se basa en el TextField clásico, pero forma los tokens alrededor de la "@". De esta manera, facilitaremos las búsquedas tanto en base a la parte local de las direcciones como al dominio. Además, elimina los espacios y convierte las mayúsculas en minúsculas.

El siguiente paso es la definición de los atributos que componen cada documento, y que por supuesto van a ser de alguno de los tipos disponibles en el schema.

  <fields>
      <field name="id" type="uuid" indexed="true" stored="true" required="true" />
      <field name="in_from" type="email" indexed="true" stored="true" />
      <field name="in_size" type="tint" indexed="false" stored="true" />
      <field name="in_fentrada" type="tdate" indexed="true" stored="true" />
      <field name="in_to" type="email" indexed="true" stored="true" />
      <field name="in_to_adicional" type="email" indexed="true" stored="true" multiValued="true" />
      <field name="in_fsalida" type="tdate" indexed="true" stored="true" multiValued="true" />
      <field name="in_estado" type="string" indexed="false" stored="true" multiValued="true" />

      <dynamicField name="*" type="ignored" multiValued="true" />
  </fields>

Casi no hace falta explicar nada. En este sencillo ejemplo tenemos un identificador, un origen, un tamaño, una fecha de entrada y una fecha de entrega. Además, con cada mensaje vamos a guardar el estado de entrega para cada destino (pueden haberse realizado varios intentos, por ejemplo a causa del greylisting), y la lista de destinatarios adicionales para los que iba dirigido.

Obviamente, es una estructura limitada. En un entorno real se debería guardar mucha más información (antivirus, antispam, expansión de aliases, ...).

Y con esto ya lo tenemos. Sólo queda volcar el schema en el cluster:

  curl http://ip_cluster:8983/solandra/schema/correo --data-binary @/root/schema_correo.xml -H 'Content-type:text/xml; charset=utf-8'

Como hemos dicho, al igual que un "/schema/correo", se podría definir un "/schema/web", por ejemplo, y usarlos simultáneamente.

El volcado de datos

El volcado de datos se puede hacer de varias formas, pero vamos a limitarnos al uso de ficheros xml. Lo mejor es ver un ejemplo:

 <add allowDups="false">
    <doc>
       <field name="in_from">origenspam@example.com</field>
       <field name="id">b309842a-1cf7-11e0-9759-f896edbeae14</field>
       <field name="in_fentrada">2011-04-30T00:17:24Z</field>
       <field name="in_size">941</field>
       <field name="in_to">destino1@target.example.net</field>
       <field name="in_fsalida">2011-04-30T00:17:25Z</field>
       <field name="in_estado">0 - 192.168.10.24_accepted_message./Remote_host_said:_250_2.0.0_Ok:_queued_as_DF2BD74CA71/</field>
       <field name="in_to_adicional">destino1@target.example.net</field>
       <field name="in_to_adicional">destino2@target.example.net</field>
       <field name="in_to_adicional">destino3@target.example.net</field>
       <field name="in_to_adicional">destino4@target.example.net</field>
    </doc>
    <doc>
       <field name="in_from">origenspam@example.com</field>
       <field name="id">b30991b7-1cf7-11e0-9759-e819bb7f7b58</field>
       <field name="in_fentrada">2011-04-30T00:17:24Z</field>
       <field name="in_size">941</field>
       <field name="in_to">destino2@target.example.net</field>
       <field name="in_fsalida">2011-04-30T00:17:24Z</field>
       <field name="in_estado">0 - 192.168.10.24_accepted_message./Remote_host_said:_250_2.0.0_Ok:_queued_as_A945A21CD6B/</field>
       <field name="in_to_adicional">destino1@target.example.net</field>
       <field name="in_to_adicional">destino2@target.example.net</field>
       <field name="in_to_adicional">destino3@target.example.net</field>
       <field name="in_to_adicional">destino4@target.example.net</field>
    </doc>
    <doc>
       <field name="in_from">cliente1@example.net</field>
       <field name="id">b43de232-1cf7-11e0-9759-d71ac36a357f</field>
       <field name="in_fentrada">2011-04-30T00:04:41Z</field>
       <field name="in_size">6077</field>
       <field name="in_to">greylister@example.com</field>
       <field name="in_fsalida">2011-04-30T00:07:27Z</field>
       <field name="in_estado">0 - 172.16.0.14_does_not_like_recipient./Remote_host_said:_450_4.7.1_<cliente1@example.net>:
          _Sender_address_rejected:_Message_delayed_now.Retry_later,_please./Giving_up_on_172.16.0.14./</field>
       <field name="in_fsalida">2011-04-30T00:12:38Z</field>
       <field name="in_estado">1 - 172.16.0.14_does_not_like_recipient./Remote_host_said:_450_4.7.1_<cliente1@example.net>:
          _Sender_address_rejected:_Message_delayed_now._Retry_later,_please./Giving_up_on_172.16.0.14./</field>
       <field name="in_fsalida">2011-04-30T00:31:53Z</field>
       <field name="in_estado">2 - 172.16.0.14_does_not_like_recipient./Remote_host_said:_451_4.3.0_<greylister@example.com>:
          _Temporary_lookup_failure/Giving_up_on_172.16.0.14./</field>
       <field name="in_fsalida">2011-04-30T01:04:43Z</field>
       <field name="in_estado">3 - 172.16.0.14_accepted_message./Remote_host_said:_250_2.0.0_Ok:_queued_as_CB6A3D4A217/</field>
       <field name="in_to_adicional">greylister@example.com</field>
    </doc>
 </add>

El volcado, otra vez, es muy sencillo.

  curl http://ip_cluster:8983/solandra/correo/update -F stream.file=/tmp/volcado.xml

La conversión de logs desde el más que probable modo texto de syslog a xml, y de ahí al cluster de Solandra, queda fuera de esta serie de posts. De hecho, un servidor piensa que esto es lo realmente importante y difícil para llevar este proyecto a la práctica de una manera "seria".

El Interfaz

¿Qué mejor que un interfaz web para mostrar los datos que hemos almacenado en Solandra? ¡Sorpresa! la gente detŕas del proyecto ajax-solr ya ha hecho la mayoría del trabajo, así que sólo nos queda modificar un puñado de ficheros, algo de código JavaScript, y ya lo tendremos: Demo

Un detalle más: No queremos permitir el acceso directo a Solandra desde la web, así que necesitamos un proxy que filtre las consultas y las redirija al puerto de Solandra (tcp/8983 por defecto), y que en mi laboratorio escucha en localhost. En este caso, como casi siempre que quiero programar algún tipo de servicio para Internet sin dedicarle mucho tiempo, he usado node.js. Para este ejemplo, y por jugar un poco con GeoIP, he escrito un sencillo proxy que permite conexiones sólo si tienen como referer forondarena.net y si vienen desde Europa o América del Norte. Como no podría ser de otra forma, el código de este proxy también está disponible en Github.

(Nota: Esta demo es un Solr normal, pero el funcionamiento es idéntico al de Solandra).

Conclusiones

El "mercado" está lleno de soluciones de todo tipo que nos pueden ayudar en la gestión de logs. Hay aplicaciones comerciales, como Splunk, sistemas basados en software libre, como Solr, tecnología que nos puede permitir crecer "ilimitadamente", como Cassandra, Hadoop o Hbase, pero que requieren algo de trabajo; y también tenemos los mágnificos sistemas de bases de datos, como Mysql o Postgresql. ¿Cuál elegir?

En una primera fase, una buena base de datos con un sencillo interfaz web o un Solr estándar pueden servir perfectamente para gestionar todo tipo de logs. De hecho, tanto Mysql como Solr ofrecen alternativas para el particionado que pueden permitir este esquema en la segunda, tercera o cuarta fase.

Un buen consejo que escuche hace tiempo es el de "no arreglar lo que no está roto". Sólo deberíamos plantearnos el uso de tecnología que probablemente no conozcamos tan bien como las anteriores cuando realmente sea necesario. Llegado ese momento, adelante. Como siempre, la comunidad detrás del software libre es activa y está dispuesta a ayudar. Por si esto fuera poco, cada vez son más comunes las empresas que ofrecen servicios alrededor de este tipo de soluciones, y que pueden asesorarnos llegado el caso.

read more

Gestión de logs con Solandra II

vie, 05 ago 2011 by Foron

Seguimos con el segundo post de la serie, en el que pasamos a dar una descripción un poco más técnica de los componentes necesarios para poner en marcha todo lo descrito en el primero. No vamos a entrar en demasiado detalle. En todo caso, una vez conocidas las aplicaciones es más fácil buscar información en la red.

Aunque Solandra puede encargarse de la instalación de Cassandra, aquí vamos a usar los componentes por separado.

Cassandra

Cassandra es un tipo de base de datos creado siguiendo los principios propuestos por Dynamo (Amazon) y por BigTable (Google). El que quiera entrar en detalle tiene bibliografía y mucha documentación disponible.

Explicar el modelo de datos, la replicación o los niveles de consistencia va más allá del objetivo de este post. Lo más interesante en nuestro contexto es dejar claro que Cassandra es una base de datos completamente distribuida y descentralizada, en la que todas las máquinas del cluster cumplen el mismo y único rol, sin distinciones entre "maestros", "esclavos", "catálogos", .... Esto significa que añadir capacidad a un cluster de Cassandra supone básicamente añadir más hierro. Nada más.

La instalación puede complicarse todo lo que queramos, pero lo básico es:

  # Cuidado con la versión
  cd /tmp/ && wget http://apache.rediris.es/cassandra/0.8.2/apache-cassandra-0.8.2-bin.tar.gz
  cd /usr/local/ && tar xvzf /tmp/apache-cassandra-0.8.2-bin.tar.gz

A partir de aquí se crean los directorios de datos y logs (por ejemplo /var/lib/cassandra y /var/log/cassandra), y se adaptan los ficheros de configuración (que están en /usr/local/apache-cassandra-0.8.2/conf). El que más nos interesa ahora es cassandra.yaml. En github hay un ejemplo de configuración de este fichero, aunque sea casi por defecto, de cada uno de los tres nodos que he usado en esta prueba.

Hay un par de opciones de configuración que pueden servir para comprender la estructura del sistema. Un cluster de Cassandra se entiende como un anillo en el que cada uno de los nodos gestiona un volumen determinado de datos (replicación aparte). Básicamente estamos hablando de una serie de claves (hashes) que se distribuyen de una forma más o menos equilibrada entre todas las máquinas. Aunque no sea estrictamente necesario, como para esta prueba he usado un número fijo de nodos (3), he asignado ya desde el comienzo un 33% de datos a cada uno. Por supuesto, en un entorno real en el que se añaden y quitan nodos dinámicamente la gestión es diferente. La configuración en mi laboratorio es la siguiente:

  # Nodo 1
  initial_token: 0
  # Nodo 2
  initial_token: 56713727820156410577229101238628035242
  # Nodo 3
  initial_token: 113427455640312821154458202477256070485

La otra opción que merece la pena comentar es "seed_provider". Cassandra usa un protocolo tipo Gossip para distribuir la información entre los nodos. Esto significa que, cuando se añade un nuevo miembro al cluster, es suficiente con indicarle un servidor activo del mismo. El protocolo se encarga de propagar esta nueva información en todos los nodos. Por lo tanto, la configuración se limita a especificar una (o varias) IPs activas:

  seed_provider:
      - class_name: org.apache.cassandra.locator.SimpleSeedProvider
        parameters:
            - seeds: 192.168.10.145

Hay mucha más opciones de configuración, por supuesto, pero lo dejamos aquí.

En este momento ya se podría ejecutar Cassandra, pero esperaremos a instalar Solandra.

Solandra

Hablemos antes de lo que es Solr, una vez más, muy muy por encima.

Solr es una plataforma de búsqueda construida sobre la librería Lucene. Simplificando mucho, y en el contexto de este post, ofrece un interfaz XML (es el que nos interesa aquí, pero no el único) para añadir documentos, y un API HTTP a través de cual recibir resultados en formato JSON (entre otros).

Todo se verá más claro cuando creemos el schema para la gestión de logs. Para el que quiera profundizar más en Solr, aquí tiene un libro.

Volvamos a Solandra. La instalación es sencilla. Una vez descargado el tar.gz desde githubsolandra, y con ant y los binarios de java en el path, ejecutamos lo siguiente en cada uno de los nodos:

  # El nombre del fichero cambia
  cd /usr/local && tar xvzf /tmp/tjake-Solandra-4f3eda9.tar.gz
  cd tjake-Solandra-4f3eda9/
  ant -Dcassandra=/usr/local/apache-cassandra-0.8.2 cassandra-dist

Si todo va bien, en unos minutos la salida estándar mostrará lo siguiente:

  ....
  cassandra-dist:
       [copy] Copying 36 files to /usr/local/apache-cassandra/lib
       [copy] Copying 8 files to /usr/local/apache-cassandra/conf
       [copy] Copying 1 file to /usr/local/apache-cassandra/bin
       [echo] Libraries successfully copied into cassandra distribution
       [echo] Start the cassandra server with /usr/local/apache-cassandra/bin/solandra command

  BUILD SUCCESSFUL
  Total time: 2 minutes 43 seconds

Durante la instalación deberían haberse copiado las librerías y scripts en el arbol de Cassandra. Incluyendo algunos ficheros de configuración, que en este caso dejamos por defecto, aunque lo normal sería que los adaptásemos.

Sin más, vamos a arrancar Solandra (y con ello Cassandra), en cada nodo. Como no hemos hecho ningún cambio en el logueo, vamos a ver todos los mensajes por la salida estándar:

  cd /usr/local/apache-cassandra-0.8.2/bin/
  ./solandra &

Y con esto ya debería estar todo listo. El siguiente paso es añadir el schema (parecido a como se haría en un Solr estándar), volcar los datos, y preparar el interfaz web. Pero esto es cosa de un tercer post. No pensaba escribirlo, pero bueno, este ya es demasiado largo.

read more

Gestión de logs con Solandra I

mar, 02 ago 2011 by Foron

Allá por el 2008, Rackspace(Mailtrust) publicaba algunos datos sobre la forma en la que había ido evolucionado su sistema de gestión de logs de la infraestructura de correo electrónico, y que por aquel entonces ya superaba holgadamente los 100GB de crecimiento diario. Junto a este documento, en una de las referencias bibliográficas sobre Hadoop, esta misma empresa explicaba, con algo de detalle técnico, la forma en la que habían implementado su sistema, basado sobre todo en Hadoop y Lucene+Solr.

Aunque Hadoop siga siendo una solución magnífica para la gestión de logs en el contexto del Software Libre (siempre hablando de volúmenes de datos realmente muy grandes), en esta serie de posts vamos a ver cómo podemos llevar la idea de Rackspace a la práctica usando otro tipo de tecnología, y más concretamente, Cassandra.

En realidad, como mis tres lectores no quieren posts demasiado largos, en lugar de entrar en los detalles de lo que sería una implementación más o menos "casera", vamos a usar una de las aplicaciones que Datastax (una empresa que da servicios comerciales para Cassandra) está potenciando como parte de su ecosistema alrededor de Cassandra, y que se llama Solandra.

El problema

Repasemos, simplificando un poco, la evolución de Rackspace:

  1. En una primera fase, los logs se almacenan en máquinas individuales. Cuando hay alguna incidencia, algún técnico tiene que entrar a hacer un grep. Si el negocio va bien, llegará un momento en el que el tiempo perdido haciendo estas búsquedas será, por lo menos, "crispante".
  2. En la segunda fase, los logs pasan a gestionarse a través de un syslog centralizado. En realidad, esta no es más que una versión algo mejorada de la primera evolución, pero al menos facilita el trabajo. En cualquier caso, en el fondo se sigue perdiendo mucho tiempo en la búsqueda manual en logs.
  3. La solución más natural en este punto es volcar los datos a una base de datos, y con ello a algún tipo de interfaz web. Dejaremos a un lado el desarrollo del frontend y de los scripts que cargan los datos en la bbdd (que pueden no ser en absoluto triviales, en función de la complejidad de la plataforma).

Hasta aquí, vale, todo es razonablemente sencillo. Sin embargo, cuando se gestionan digamos que 25 millones de mensajes al día, y cuando se quieren mantener 2 años de información (es un decir), nos encontramos con un problema.

¿Cómo se soluciona?

Aquí ya cada uno toma decisiones en función de su capacidad, su presupuesto, los perfiles que tiene disponibles, .... En algunos casos, mantener 30 días en base de datos (lo que genera la mayoría de incidentes), puede ser suficiente. En otros casos, se trabaja con los mecanismos que ofrecen las bases de datos para escalar (el framework Gizzard de Twitter es un estupendo ejemplo, aunque no hablemos de logs). Y por último, algunos pasan a otras soluciones, ya sean de pago o libres. En el caso de Rackspace, por ejemplo, su opción fue Hadoop y Lucene+Solr.

Una vez más, cada una de estas opciones puede ser "la mejor" en función del entorno en el que se desarrolle. Pero claro, si quiero seguir con este post tengo que optar por la tercera alternativa, obviamente :) .

Vamos por partes:

  1. Queremos almacenar un volumen de datos muy significativo. Para unos pocos GB todo esto no tiene demasiado sentido.
  2. Queremos que lo único necesario para aumentar la capacidad sea añadir nuevo hardware. Nada más. Ni cambios en la programación, ni cambios en la arquitectura.
  3. Queremos poder hacer consultas complejas sobre estos logs, en base a origen, destino, rangos de fechas, .... Por ejemplo, sería estupendo poder consultar todo el spam enviado a cuentas tipo info@ en toda la plataforma en un periodo de tiempo concreto.
  4. Aunque el tiempo real no es un requerimiento, es preferible poder hacer estas consultas y recibir los resultados al momento, en una misma sesión de navegador.

Para conseguir los puntos 1 y 2 Hadoop es una solución estupenda. Para 3 y 4 es necesario más trabajo. El acceso "casi inmediato" a los datos se conseguiría con alternativas como HBase, tan de moda ahora que Facebook ha empezado a usarlo. Además, siempre disponemos de Pig y Hive para simplificar las consultas. Ahora bien, de una u otra manera, con Hadoop es bastante probable que tengamos que programar bastante código.

La otra alternativa viene de la mano de Cassandra. Una vez más, los puntos 1 y 2 son inmediatos con esta tecnología. Al igual que con Hadoop, 3 y 4 no lo son; pero gracias a la aplicación llamada Solandra, que no deja de ser un Solr que guarda sus índices en Cassandra, podemos conseguir la capacidad de búsqueda de Lucene, el interfaz tipo REST que ofrece Solr, y la escalabilidad de Cassandra. Todo en uno.

El post se ha alargado un poco. Dejamos la parte práctica para el segundo (y último) mensaje de esta serie.

read more