Hunting Bears

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

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 »

Un backport es un paquete (o un conjunto de paquetes) que pertenecen a un estado superior de desarrollo. La idea general con los backports es incluir software más nuevo en una distribución estable, que por sus características tiende a quedarse con software viejo.

Es de esperarse entonces, que un software diseñado para un ambiente de interacciones con otros programas, no funcione de igual forma en un ambiente diferente (a menos que su interacción con los demás no dependa en gran medida del ambiente).

Esta premisa varía mucho dependiendo de la naturaleza del paquete y sus dependencias. Determinar cuan riesgoso es backportear un paquete se convierte entonces en una tarea de análisis minucioso.

Por otra parte, backportear un paquete que necesite funciones que no están presentes en el sistema, puede traer consecuencias tan sutiles como un “flickering” en un borde de ventana, o tan catastróficas como un “kernel panic”, sino se toman las previsiones necesarias, ni se hacen las pruebas correspondientes.

Existen algunas consideraciones que deben hacerse.

• Si el paquete del estado superior tiene dependencias con librerías trascendentales que se encuentren en versiones superiores, – como por ejemplo python, perl, c++, entre otros -, entonces ese paquete debe ser modificado (y empaquetado) para que funcione con las librerías que se encuentran en versiones inferiores en el estado donde se quiere incluir el software.

ó

• Incluir también las dependencias junto con el paquete del estado superior.

Un caso de backporting en debian es, por ejemplo, incluir el navegador web Iceweasel 7.0 (actualmente en Inestable) e incluirlo en un sistema estable. Para este ejemplo en particular, estamos manejando un software modular (al igual que muchas otras aplicaciones), es decir, no depende de librerías que cambien mucho entre estados, y las dependencias que necesita vienen con él, es decir, se puede “enchufar y desenchufar” sin muchos detalles de los cuales estar pendiente.

Por otro lado, actualmente gnome necesita GTK2 para la distribución Estable, y GTK3 en la distribución Inestable. En este caso, backportearlo a estable implica incluir GTK3 (con todas las posibles consecuencias) o modificar gnome para que funcione con GTK2 (implica deshabilitar alguna de sus funcionalidades nuevas, además de ser un trabajo titánico). Lo mismo ocurre con muchos otros paquetes que están ligados a librerías trascendentales, como por ejemplo: el kernel, apt, aplicaciones basadas en python o perl, entre otros.

A manera de referencia, en Canaima 3.0 se incluyeron programas de estados superiores que tenían un comportamiento modular y por tanto, mínimo riesgo de conflictos, específicamente:

• Libreoffice
• Cunaguaro
• Guácharo
• BURG

Backportear un kernel

Backportear un kernel implica muchos otros aspectos a los ya mencionados:

• El kernel depende de muchas librerías fundamentales como perl, c++, y las reglas udev que deben estar presentes para que funcione. Perl, por ejemplo es una librería que usualmente varía entre los estados de desarrollo.
• El kernel, aunque no es una librería de por si, muchos programas están diseñados para trabajar con versiones específicas de el. Por ejemplo, los módulos de kernel, los drivers de video, algunos drivers de sonido, están empaquetados para versiones específicas de kernel. Cambiar el kernel significa que esos drivers dejarán de funcionar, a menos que también se incluyan los paquetes de esos drivers específicos para el nuevo kernel.
• El kernel es una de las partes más sensibles de una distribución. Utilizar un kernel que no haya pasado por todos los estados de desarrollo puede significar que no esté lo suficientemente probado. Un pequeño error desapercibido en el kernel puede generar errores catastróficos en la experiencia de usuario (p. ej. kernel panic).
• No siempre es cierto que para soportar nuevos dispositivos es necesario incluir un nuevo kernel. Existen módulos de kernel genéricos que están ajustados a un patrón de diseño de dispositivos y no a un modelo en particular, permitiendo que el mismo sirva para una serie de dispositivos existentes (y por existir).

La recomendación final es, si piensas utilizar backports en tu distribución estable, ten mucho cuidado con lo que haces, podrías generar una inestabilidad incluso mayor a la existente en la distribución inestable.

Como usuario de alguna distribución GNU/Linux, seguramente has oído/leído acerca de los metapaquetes, esos paquetes que no pesan mucho pero que instalan un montón de cosas. Si bien el concepto detrás de un metapaquete es bastante sencillo, son piezas clave en la construcción organizada y engranaje de subsistemas dentro de una distribución GNU/Linux.

Por ejemplo, imagínate por un instante que queremos incorporar una nueva línea de ensamblaje de computadores a nuestra fábrica “Bien Barato Electrónica“. Si pudieras de alguna forma comprar la línea completa a través de un nombre o marca, en vez de comprar los tornillos, las tuercas, las cintas rodantes, los rodillos, los tubos, los brazos robóticos, los cables, etc. y armarla tu mismo, entonces eso sería instalar un metapaquete dentro de tu distribución “Bien Barato Electrónica“.

En definitiva, un metapaquete es un paquete que sirve para instalar otro conjunto de paquetes a través de sus dependencias. Generalmente está casi vacío (es decir, no se copian archivos al sistema cuando se instala); sin embargo, si está bien construido, siempre se incluye una pequeña documentación (changelog, copyright, entre otros).

Continuar Leyendo »