roster compartido en prosody

En el post anterior hablamos sobre un servidor de jabber con prosody y hablamos sobre sus características expandibles. Como servidor Muc, BOSH y roster compartido. Empezemos por la que más me gusta.

El mal llamado roster compartido, es en realidad un grupo en el que varios JID ya están declarados y no han de ser añadidos. De esta forma, un nuevo usuarios se incorpora y estará en la lista, además, tendrá a todos los usuarios en la suya. Evita tener que agregar usuario por usuario. Para crear este grupo especial, debemos tener habilitado un módulo llamado "groups", si no sabe como hacer esto, diríjase al post anterior.

Una vez habilitado, escribiremos su parámetro de configuración fuera de la sesión donde declaramos los módulos. El parámetro se llama groups_file y sería más o menos así.

echo 'groups_file = "/etc/prosody/sharedgroups.txt"' >> /etc/prosody/prosody.cfg.lua

Pero tenemos un fichero nuevo, un tal sharedgroups.txt. Dicho fichero no existe aun así que lo crearemos. Ahí declararemos un grupo llamada "Usuarios" y le pondremos los usuarios deseados. Los grupos se declaran poniendo el [Nombre] entre corchetes. Puede poner todo los grupos que quiera. Debajo del grupo pondremos la JID, podemos agregarle un nombre real con un "="

echo '[Usuarios]'
echo 'admin@dominio.cu'
echo 'fulano@dominio.cu'
echo 'contabilidad@dominio.cu=Hilda Maria
echo 'chicho@gmail.com'
echo 'pepe@jabber.org'

Con eso creamos un grupo llamado Usuarios. El roster de esos tres usuarios tendrá a lo mismos autorizados; listos para hacer click e iniciar la charla. Además, tendrá otros dos extras.

Pero sería desesperante tener que escribir en un fichero cada vez que se crea un usaurio. Mejor sería algo que mantenga esa lista de manera automática. Por eso, cree un fichero que al ser corrido, recoge todos los
usuarios del sistema y recrea el fichero.

Para esto, vamos a necesitas un módulo extra:

curl http://prosody.im/files/mod_listusers.lua > /usr/share/lua/5.1/prosody/modules/mod_listusers.lua

Ojo con la versión y la ruta. Bajamos un módulo especial que NO se usará dentro del servidor. ¿Se recuerdan que prosodyctl hacia mas cosas de las que dice hacer? Una vez bajado el módulo corremos:

prosodyctl restart
prosodyctl mod_listusers

¡Y sorpresa! una lista con todos los usaurios de nuestro sistema. ¿Qué podemos hacer con ella? Mire:

root@donor:~# cat /usr/local/bin/update_prosody_roster.sh
#!/bin/bash
echo '[Usuarios]' > /etc/prosody/sharedgroups.txt
prosodyctl mod_listusers >> /etc/prosody/sharedgroups.txt
killall -9 lua
/etc/init.d/prosody start

De esta forma, cuando un usuario se agregue o cuando lo agreguemos manualmente, solo tenemos que correr "update_prosody_roster.sh" y para tener todos los usaurios en el roster masivo. Si tienes el módulo
"watchregistrations" te enterarás cada vez que un usuario se registre y podrías correr el script. De otra forma, si los agregas tu a mano, corres el script despues de agreagarlos, o modifica el escript para mandarle el usuario como parámetro y que este ejecute el add de prosodyctl.

En el próximo post, veremos como configurar un servidor MUC para conferencias...

servidor jabber con prosody

Lua, es uno de los tantos lenguajes interpretados que hay. Echo por los Brasileños; aunque lo de ellos definitivamente es la samba y el futboll. Lo digo porque ese fue uno de los primeros lenguajes que estuve manoseando y No creo que halla un buen motivo para escribir algo con él.

¡Pero Prosody, demuestra que me equivoco!

La robusteza, simplicidad y el rendimiento de este servidor quizás sean superiores a la de ejabberd (que está escrito en Erlang, un lenguaje aún más exótico que Lua). Por otra parte, su todo en uno, lo hace más versátil que otros cuantos. No tiene nada que envidiarle al cochino OpenFire y toda su parafernaria de Java.

Prosody cuenta de manera incorporada con servidor MUC (sala de charla), pasarelas hacia servicios, logger de error, loger normal, logger de debug, servidor BOSH, discovery, mensaje masivo, MOTD y todo lo que necesita un completo servidor jabber. Incluso un servidor http y una interfaz de telnet. No piense usted que todo eso es obligado e incluido por defecto.

En su estado natural, prosody solo viene con lo básico. Ampliarlo, es solo cuestión de modificar la configuración. No piense en una extraña interfaz web como la de ejabber, hablamos de un fichero de configuración ".lua" con todo comentado.  No necesitamos saber Lua para configurarlo porque hay mas
comentarios que código en dicho fichero. La exoticidad de Lua radica en que un comentario es "--" en vez de "#"

Prosody tiene un bonito esquema modular. Los módulos del llamado tipo "core", son lo básico del jabber: iq, precense, etc... No son funciones del servidor, son módulos, módulos base que incluso pueden ser deshabilitados. De forma que el servidor es un núcleo monolítico, compuesto por varios módulos. Ampliarlo, es solo cuestión de quitar comentarios y las cosas más específicas, como un roster compartido, es solo  uestión de insertarle un módulo y parametrisarlo; no hay compilar nada.

Comenzamos. En debian todo es muy fácil:

aptitude install prosody

Esto dará lugar un fichero de configuracion en: /etc/prosody/prosody.cfg.lua

De ahí modificaremos lo que necesitamos. Primero, poner la JID del admin, eso lo haremos aunque nuestro dominio no halla sido declarado.

admins = { 'tu_usaurio@tudominio.cu' }

Ahora vamos a la sesión modules_enabled. Todo bien comentadito. Yo lo habilito todo menos el servidor http y el telnet, como que no me da buena espina.

Si habilitamos el módulo "motd" nuestro servidor contará con un MOTD, pero debemos especificarlo. De esta forma cada módulo es una función que puede o no llevar parámetros de configuración. Para argumentar la configuración de motd, escribimos FUERA de las sesión de módulos.

motd_text = 'este es el motd de mi server'

Pero "motd_text" no estaba escrito en ninguna parte. Para ver si un módulo tiene o no configuración, sus detalles, que hace y hasta un ejemplo, podemos verlo en la lista de módulos.

http://prosody.im/doc/modules

Pero volvamos a la configuración. La siguiente linea de interés es la que permite el registro de usuarios.

allow_registration = true;

OJO! se requiere un ";" al final de la configuración (razón por la cual abandoné Lua). Si no quieres que los usuarios se registren déjalo en false. Puedes usar la aplicación de control para crear usuarios. Ejecuta prosodyctl sin parámetros y veras una pantalla aprueba de imbéciles que te dice como crear los usuarios y otras opciones interesantes. Lo bueno que tiene esa aplicación es que hace más cosas de la que dice.

Lo siguiente es el SSL, no es bueno desabilitarlo porque muchos cliente jabbers traen por definición usar ssl. Mejor seguir a las que dice:

c2s_require_encryption = false
s2s_require_encryption = false

Poniéndolas en false, el servidor usara lo mismo SSL que plana.

Pero aún no hemos declarado el dominio. Resulta que como te dije todo es modular. Los dominios son VirtualHost. Al igual que en apache, incluso el dominio por defecto, es un virtual host. Podemos declarar varios dominios y dejarlos deshabilitados.

VirtualHost "tudominio.cu"

Ya tenemos un dominio, podríamos tener más con solo agregarlos pero con eso ya tenemos un servidor con lo indispensable. Veamos en el próximo post, como es el caso de un servidor con sala de conferencias y con roster compartido, dos características que no faltan en servidor jabber corporativo.

dovecot chrueco

Ahora la han cogido de gracia en dovecot, poner los mailbox en un lugar extraño. Cunado haces un upgrade de sistema, el despingue es de alcurnia. Para los enchapados a la antigua, así ponemos los mailboxes en /var/mail/$USERNAME

En el fichero /etc/dovecot/dovecot.conf localizamos la parte esta:


# See </usr/share/doc/dovecot-common/wiki/Variables.txt>\
# Some examples:
#
#   mail_location = maildir:~/Maildir                     
#   mail_location = mbox:~/mail:INBOX=/var/mail/%u
#   mail_location = mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n
#
# </usr/share/doc/dovecot-common/wiki/MailLocation.txt>
#
mail_location = mbox:~/mail:INBOX=/var/mail/%u

Cambiamos el parámetro mail_location por lo señalado en rojo.

recoleción de dominio en un buzón

Se sabe poco sobre los orígenes de ese aborto de la naturaleza que es conocido por alguno como "recolección aPOP" o por otros como "DomainPOP" . Haciendo referencia al hecho de bajar todo el correo para un dominio de un pop remoto. La historia se remonta a un popular, potente y hermoso servidor de correo, para windows llamado MDeamon (pronunciado como "emodimons") creado por la compañía Alt-New Technolgy, muy conocido por su simple pero elegante cliente web, el World Client. Entre sus features, podemos ver el almacenamiento de TODO el correo de un dominio en un mismo buzón. Esto, sumado a que en cuba todo el software es gratis :D lo convirtió en la herramienta definitiva para las redes conmutadas.

Por otra parte, no todo se le impugna windows. Cuando aún el morro era de palo, ya citmatel usaba un  CuciPOP (vean que clase de nombre "Cubic Circles = CuCiPOP") para depositar el correo de sus clientes por lineas conmutadas; una clara implementación de aPOP. Esto resolvió ser la manera mas burda pero eficiente de resolver el problema de correo en lineas conmutadas.

Lo único que perturba este barato panorama, es el hecho de que si el correo no tiene un To: bien claro, se jode todo y te ves obligado a usar MDeamon, que en ese aspecto se saca todos los premios, porque su puesto, el es una de la principales implementaciones de este modelo. A menudo nos encontramos con que al
bajar el correo con fetchmail, uno o varios correos como los de las listas, no van a su destino, por el contrario, van al postmaster sin tener coincidencias de usuarios locales.

Hay quien esta acostumbrado a que el postmaster este LLENO de correos y eso le parece normal, cuando el buen funcionamiento de un servidor, se mide por el postmaster vacío.

Si un correo tiene un To: o un Cc: cuando fetchmail lo parsea (del infintivo "parsear"), entonces localiza una dirección de nuestro dominio basándose en que tiene el dominio en la configuración. Como le dijimos 'is * here' buscará cual nombre que este delante de lo que se parezca a nuestro dominio y lo entregara.

Pero: Qué pasa si el To: o el Cc: NO tienen una dirección de nuestro dominio?

Supongamos que el correo viene Bcc: (blink carbon copy) o que proviene de una lista. Donde el destino es la dirección de la lista. En ese caso los destinos se especifican en la orden RCPTO durante la sesión SMTP. Algunos servidores incluyen encabezados como: "Delivery-To","Envelope-To" o "X-Orignial-To" En mi opinión todos están de más, porque el Received: tiene esta información; pero bueno, podríamos decirle a fetchmail que ademas de esos, parsee encabezados Received:

Eso parecería una solución, el único problema es que no pincha :-P

Lo ideal sería un "algo" que parcee los Received uno a uno en busca de coincidencias locales. Por ejemplo, veamos el aspecto de un conveniente Received.

Received: from mx.jovenclub.cu (unknown [200.55.152.25]) by
mailserver.tudominio.cu (Postfix) with ESMTP id 6ADEC35055E
for <fulano@tudominio.cu>; Wed, 28 Nov 2012 15:44:53 -0500 (CST)

Es tan simple como detectar un Received: con nuestro dominio involucrado y ver que hay con el nombre de usuario. NO ENTIENDO por que carajo no funciona en fetchmail. El parametro include sería definitivamente un batazo si pinchara.

PERO!

Con este script

He parseado los Received: e incluso, sin parsear los To: no falla. La versión actual también incluye el parseo de todos los pertinentes encabezados, aunque hasta el momento, lo resuelve solamente con lo Received: sin problemas. Solo tienes que dárselo a fetchmail como "mda" y configurar tu dominio. En las primeras lineas del fichero están las configuraciones e instrucciones para la instalación.

MRTG y SNMP

MRTG es una herramienta que nos permite graficar el uso de laz interfaces; tener una idea visual de como se explota el canal. Pero; todos sabemos que el ancho de banda no alcanza, veremos un gráfico verde completo en lugar de picos. En mi opinión, no tiene ningún sentido instalar MRTG para saber algo que es tan obvio, pero como está la moda, TODO el mundo la considera una herramienta definitiva :-P

MRTG es solamente un graficar que procesa el protocolo SNMP. Por tanto, necesitamos priemro un servicio snmp. Creamos un fichero de configuracion nuevo

aptitude install snmp snmpd
cd /etc/snmp
mv snmpd.conf snmpd.conf.old
touch snmpd.conf

y al fichero le escribimos


com2sec paranoid   default                 public
com2sec readonly  192.168.1.0/24      public
com2sec readwrite default                  private

group MyROSystem v1        paranoid
group MyROSystem v2c       paranoid
group MyROSystem usm       paranoid
group MyROGroup v1         readonly
group MyROGroup v2c        readonly
group MyROGroup usm        readonly
group MyRWGroup v1         readwrite
group MyRWGroup v2c        readwrite
group MyRWGroup usm        readwrite

view all    included  .1                               80
view system included  .iso.org.dod.internet.mgmt.mib-2.system

access MyROSystem ""     any       noauth    exact  all    none   none
access MyROGroup ""      any       noauth    exact  all    none   none
access MyRWGroup ""      any       noauth    exact  all    all    none

syslocation TUDOMINIO
syscontact lazarito <tucorreo@tudominio.tld> 

# EOF

Salvamos y cerramos. Ahora, no se porque, esto da palo.
Vamos a /etc/default/snmpd

y lo dejamos solamente la liena que dice:

TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid'


las demas las comentamos y reiniciamos snmp

/etc/init.d/snmpd restart

Lo probamos

snmpwalk -v 1 192.168.1.1 -c public system

Ahora, en la máquina donde tenemos el servidor web (quizas la misma), vamos instalar mrtg

 aptitude install mrtg

Ahora el directorio en www

mkdir -p /var/www/mrtg/enlace
cp /etc/mrtg.cfg /etc/mrtg.cfg-OLD

Ahora utilizamos la herramienta de configuracion de mrtg ejecutando.

cfgmaker \
--global "workdir: /var/www/mrtg/" \
--global "Options[_]: bits,growright" \
--output /etc/mrtg.cfg \
--community=public \
192.168.1.1 \

MRTG corre solo por el cron, pero para empezar lo corremos manual

mrtg

y buscamos en la carpeta /var/www/mrtg/

Facilíto verdad?