Hunting Bears

Los Administradores de Plataforma tienen un problema recurrente cada vez que les toca elegir cómo manejarán la gestión de sus usuarios en sus entornos de trabajo. El problema usualmente se hace mayor cuando varias aplicaciones forman parte de un mismo proyecto, y se necesita unificar la autenticación de los usuarios para mejorar la experiencia de uso.

Para solventar este problema se han desarrollado extensiones y plugins para las principales aplicaciones web como MediaWiki, Plone, WordPress, Drupal, TRAC, entre otros, que permiten sustituir su propio sistema de autenticación por uno externo basado en LDAP o Active Directory. Lamentablemente, la mayoría de estas extensiones adolecen de la flexibilidad y funcionalidad que un Administrador de Plataforma necesita para gestionar eficientemente los usuarios de sus aplicaciones. Incluso, la mayoría tiene graves problemas con los formatos de lectura y escritura de entradas, sin mencionar que no existe un esquema común entre las mencionadas extensiones, requiriendo un trabajo adicional de adecuación para que todas las aplicaciones hablen el mismo idioma. No existe, hasta ahora, una solución integral y directa al problema.

Es por eso que hoy quiero presentarles la primera versión estable de Aguilas (1.0.1), una aplicación en la que he venido trabajando para solventar el problema de gestión de usuarios en la Plataforma Tecnológica del Proyecto Canaima. Aguilas es una “Aplicación para la Gestión de Usuarios con Interfaz para LDAP Amigable y Segura” que está escrita en PHP, basada en los principios de simplicidad, usabilidad, y elegancia.

Como Administrador de Plataforma, podrás tener una base de datos centralizada con todos los usuarios de tu plataforma, a la cual podrás conectar todos los servicios que necesiten leer la lista de usuarios, teniendo la tranquilidad de que sólo Aguilas estará escribiendo tus usuarios, de forma semánticamente correcta y compatible con la mayoría de las aplicaciones que tienen autenticación con LDAP.

Con Aguilas tus usuarios serán capaces de:

• Crear cuentas de usuario en un servidor LDAP.
• Ver o modificar los atributos de usuario de una cuenta.
• Cambiar o reestablecer la contraseña de una cuenta
• Recordar el nombre de usuario en caso de olvido.
• Eliminar una cuenta de usuario.
• Listar todos los usuarios registrados.
• Buscar usuarios dentro de la base de datos.

¿Te interesa? ¡Sigue leyendo!

Continuar Leyendo »

Normalmente es posible instalar un Mail Transport Agent (MTA) como postfix o exim para que sirva como servidor de correo en cualquier computadora conectada a internet con una dirección IP pública asignada. Sin embargo, debido al problema del SPAM, muchos de los servidores de correo de Internet bloquean el correo no autenticado proveniente de direcciones IP dinámicas, que son las habituales en las conexiones domésticas.

Una de las soluciones existentes es instalar un servidor de correo que no envíe directamente el correo al servidor destino, sino que utilice Google Mail (GMail) para que retrasmita los mensajes.

Para poder enviar correo utilizando el servidor SMTP de GMail (smtp.gmail.com) la conexión tiene que estar cifrada con TLS. Para ello necesitaremos tres elementos:

1. Un certificado autenticado por autoridad certificadora válida para GMail.
2. Una cuenta de correo GMail.
3. Un MTA local.

Instalación

Primeramente instalamos Postfix, un MTA bastante completo y configurable. Abrimos una terminal de root (Aplicaciones > Accesorios > Terminal de Root) y escribimos el siguiente comando:

aptitude install postfix

Nota: Postfix tiene conflictos con Exim, pero es seguro remover exim en favor de postfix.

La instalación nos hará algunas preguntas:

1. Tipo de configuración: acá responderemos “Sitio de Internet”.
2. Nombre del sistema de correo: acá pondremos el nombre de dominio de nuestro servidor de correo local. Para nuestro caso, podemos poner el mismo nombre de dominio de nuestra PC. e.g. “micasa”.

Listo, la instalación debe haber finalizado existosamente.

Configuración

Luego tenemos que editar el fichero /etc/postfix/main.cf y añadir las siguientes líneas al final del archivo:

relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl/passwd
smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_CAfile = /etc/postfix/cacert.pem

En resumen, acá le estamos diciendo a postfix que utilice relayhost para conectarse al servidor de Gmail, que utilice smtp_sasl_password_maps para extraer los datos de conexión SASL y que utilice smtp_tls_CAfile como certificado para la conexión segura.

Autenticación

Debemos crear el archivo /etc/postfix/sasl/passwd con el siguiente contenido:

[smtp.gmail.com]:587    [CUENTA]@gmail.com:[CONTRASEÑA]

Por ejemplo:

echo "[smtp.gmail.com]:587    luis@gmail.com:123456" > /etc/postfix/sasl/passwd

Y lo protegemos adecuadamente con:

chmod 600 /etc/postfix/sasl/passwd

Seguidamente, hay que transformar el archivo a un fichero indexado de tipo hash mediante la instrucción:

postmap /etc/postfix/sasl/passwd

Lo que creará el fichero /etc/postfix/sasl/passwd.db

Certificación

Debemos tener instalados los certificados SSL de las autoridades certificadoras para poder realizar éste paso. Los podemos instalar así:

aptitude install ca-certificates

Para añadir la autoridad certificadora Equifax (la que certifica correos de Gmail) al fichero de certificados que utilizará postfix, ejecutamos el siguiente comando en una consola de root:

cat /etc/ssl/certs/Equifax_Secure_CA.pem > /etc/postfix/cacert.pem

Puesta en funcionamiento

Finalmente, reiniciamos postfix para aplicar los cambios, así:

/etc/init.d/postfix restart

Podemos comprobar el funcionamiento abriendo dos consolas. En una ejecutaremos el siguiente comando para monitorear el comportamiento del correo (como root):

tail -f /var/log/mail.log

Y en la otra enviaremos un correo:

echo "Éste es un correo de prueba" | mail prueba@gmail.com

Si hicimos las cosas bien, en la otra consola deberíamos ver algo como ésto:

Dec 18 18:33:40 OKComputer postfix/pickup[10945]: 75D4A243BD: uid=0 from=
Dec 18 18:33:40 OKComputer postfix/cleanup[10951]: 75D4A243BD: message-id=
Dec 18 18:33:40 OKComputer postfix/qmgr[10946]: 75D4A243BD: from=, size=403, nrcpt=1 (queue active)
Dec 18 18:33:44 OKComputer postfix/smtp[10953]: 75D4A243BD: to=
, relay=smtp.gmail.com[74.125.93.109]:587, delay=3.7, delays=0.15/0.14/1.8/1.6, dsn=2.0.0, status=sent (250 2.0.0 OK 1324249500 eb5sm36008464qab.10)
Dec 18 18:33:44 OKComputer postfix/qmgr[10946]: 75D4A243BD: removed

Espero que les sea de utilidad

Acá les dejo la presentación que utilizo para dictar los cursos de desarrollo para Canaima GNU/Linux. Si tienen alguna duda, pueden preguntarme en la sección de comentarios.

Descargar: ODP | PDF

Normalmente, dentro de los procesos involucrados en la creación de sabores o distribuciones derivadas de Canaima (o Debian) necesitamos utilizar paquetes que no se encuentran en repositorios públicos de Debian, Ubuntu u otra distribución porque generalmente son paquetes de autoría propia, diseñados a nuestras necesidades.

En ese sentido, es buena idea hacer un repositorio local para guardar esos paquetes y así agilizar un poco más los procesos de desarrollo y pruebas de software. Además, si tienes la oportunidad de hacerlo público a través de un servidor web, podrías distribuir tus paquetes a otras personas o incluso hacer un sabor Canaima.

Continuar Leyendo »

Muchas veces se hace útil tener una copia idéntica (mirror) del repositorio de paquetes Debian y Canaima en tu computadora: Acelera la instalación de paquetes, la creación de imágenes con canaima-semilla y permite tener un ambiente pruebas en caso de que manejes un repositorio en ambientes de producción.

Hacerlo no es tan difícil y requiere muy poca atención luego de realizado el procedimiento. Eso sí, el tiempo que utilizaremos inicialmente dependerá de tu velocidad de conexión. Podrás elegir cuales arquitecturas replicar y decidir si incluir las fuentes de los paquetes o no.

Continuar Leyendo »