¿Sabes tú qué es un “empírico”?

Una persona que desarrolla habilidades de manera autodidacta en un oficio o campo de la ciencia y que llega a ser tanto o más bueno que un catedrático.

Generalmente estamos graduados de algo que no ejercemos.

Guardamos con devoción en nuestra casa, el libro que nos darían si llegáramos al tercer año de la carrera universitaria que deberíamos estudiar.

No leemos los libros que nos obligan. Leemos los que nos interesan.

No podemos ir a la universidad porque suspendemos las pruebas en las que nos preguntan cosas que hace 6 años leímos o cosas que No nos interesan.

Cuando llegamos a preescolar sabíamos las vocales, los colores y contar del uno al diez. Odiábamos a la profesora por obligarnos a atender su aburrida clase.

Somos gente que pensamos diferentes y no encajamos en el montón. Algunos nos llaman “rosca izquierda” otros nos llaman “originales”.

Sabemos que colar un café es una reacción exotérmica porque dimos química en noveno grado.

Sabemos que de día sopla la brisa y de noche el terral, porque dimos “mundo en que vivimos” en 5to grado.

VAMOS A LA ESCUELA A APRENDER, no a sacar buenas notas.

No nos expliques nada, solo déjanos ver como lo haces.

Sabemos hacer muy pocas cosas pero no tenemos rivales en las pocas que hacemos.

Si hay un camino a la derecha y otro a la izquierda, hacemos uno nuevo por el medio; con la esperanza de hacerlo mejor.

No somos mejores ni peores que nadie porque no nos comparamos.

Tenemos una ortografía terrible porque escribimos en cualquier idioma menos en el nuestro.

Sabemos un montón de cosas y no nos acordamos cuando o porque lo aprendimos.

Los que nos aprecian o admiran nos llaman “geniales” o “inteligentes”. Los que nos repudian o envidian nos llaman “autosuficientes” o “excéntricos”.

Solo somos “empíricos”

De siempre, me ha parecido que los autenticadores de squid son unas canchanfletas. Realmente antes me parecían otra cosa, porque la palabra “canchanfleta” no existía, pero nunca me simpatizaron mucho los autenticadores.

El hecho de que para administrar los usuarios se necesite una aplicación aparte y por lo general bien estrafalaria; es por si solo una verdadera jodienda.

El despliegue aquí en el Calixto fue prácticamente una locura. Todo a la carrera. A pesar de eso, escribí un autenticador de lo mas chulo. Al enviarle como argumento un usuario, generaba una contraseña firme y creaba un fichero bajo el directorio “/etc/squid/digest/”. El nombre de dicho fichero era el nombre de usuario y el contenido: un digest irreversible (el password).

Problema 1:

La necesidad de crear usuarios y cambiar contraseñas, pujaba la necesidad de una mecanismo más óptimo. El problema era correr ruby on rails en el server para manejar los usuarios; matar moscas a cañonazos. El rails podía crear los ficheros en mi máquina y luego cotejarlo con el servidor manualmente con “scp”, lo cual seguía siendo un fastidio. Además NO SE POR QUE, después de crear un usuario, había que reiniciar el servidor, muy a pesar de que el directorio se releía cada vez que se pedía un usaurio.

Sumado a eso, la evidente aparición de un presunto servidor de correo y la inspiración que resulta el esquema de infomed; me dejaron caer una vieja escupía en la frente; yo que era tan renuente a SQL.

Bueno, todos los usuarios pa una base de datos y problema resuelto.

Además, tengo planificado más de un servicio, así que alé por el típico esquema de una cuenta para todos los servicios.

1

SELECT password FROM users WHERE username="fulanito"

La cantidad de código del autenticador se redujo considerablemente y con ello el margen de error. La cuestión quedó sencilla: Una consulta SQL que determina si el usuario está en la base de datos y si tiene permisos de navegación. En futuro si se requiere un sistema de quotas, saldrá por ahí también.

Problema 2:

Pero entonces surgió un nuevo problema. Cuba, tierra de salvajes apagones y feroces mosquitos. La luz falla y la máquina del informático se cae. Cuando el autenticador comete algún error, squid dice que el autenticador está fallando y lo deja de pinchar. Aún si arrancase la base de datos, squid no vuelve a echar a andar el autenticador.

Entonces volvemos a lo mismo: -lazarito! no hay internet??! Junto a un nagios histérico que manda correos a diestra y siniestra. PÁFATA! De vuelta al subdesarrollo, ssh pal servidor y “squid -k reconfigure”

Solución:

El autenticador debe seguir en pie, aún cuando la base de datos no sea accesible.

La única forma de lograr esto de forma transparente hacia squid; es verificar si la conexión a la base de datos está operacional y denegar todas las autenticaciones si esta no lo estuviere.

Implementación:

Pero un autenticador de squid, es un ciclo infinito que lee stdin y habla por stdout; cargar una subrutina de rescate en cada vuelta, sería caerle a puñaladas a la memoria RAM.

Solución: En cada vuelta, se compruebe si la base de datos está en linea. En caso de no estarlo, se llama una función que establece la conexión. Este es un iterador que intentará establecer la conexión hasta que lo logre. Mientras tanto toda la autenticación en el proxy será “usuario no válido”.

1
2
3
4
5
6
7
8
9
10
11

if my
   @auth=false
else
   begin
      my = Mysql.new('10.1.1.14', 'usuario', 'password', 'basededatos') rescue false
   rescue
      STDERR << "ERR Fallo la conexión al servidor SQL #{$!}\n"
      STDERR.flush
      next
   end
end # if sql

El iterador principal sigue viendo la variable que hace como semáforo (“my” en este caso) en false y no se toma la molestia de encuestar una base de datos que ya sabe; está off-line. La variable “my” será false mientras no se redeclare con la conexión de Mysql.new. No confundir con @auth que en este caso es el valor por definicion de la autenticacion. Osea, no se autenticó.

La variable my será true cuando la función logre establecer la conexión con la base de datos.

De está forma, falla de manera silente, segura y controlada.

En el episodio anterior, vimos como dovecot se sumaba al esquema mysql. Faltaría solamente postfix, para tener entonces un “completo servidor MySQL”

Cabe reconocer que el futuro de MySQL es incierto, pero meintras PostGres sea la gran basura que es, que conmigo ni cuenten.

Normalmente postfix, entrega a través de procmail, pero ahora, nuestro dovecot con sus flamantes características, tendrá una manera más compleja de entregar. Por tanto, debemos usar el LDA (Local Deliver Agent) de Dovecot como el MDA por defecto de postfix.

Al fichero /etc/postfix/main.cf le agregamos en el fondo un nuevo transport.

1
2

dovecot unix - n n - - pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user}@${domain} -m ${extension}

Además de lo usual, al main.cf le declaramos que su nuevo transporte es un tal “dovecot” y le agregaremos unas cuantas gangarreas extras que ya explicaré.

1
2
3
4
5
6
7

# el resto de tu confuiguracion arriba
virtual_transport=dovecot
mailbox_command = /usr/lib/dovecot/deliver
mydestination = localhost, blackjack
virtual_mailbox_domains = hcg.sld.cu
virtual_mailbox_maps = $virtual_mailbox_domains
virtual_alias_maps = hash:/etc/aliases

1. Un comentario a prueba de imbéciles.
2. Declaramos el nuevo transporte para el dominio virtual.
3. Declaramos además, que se use el LDA de dovecot.
4. Declaramos que solo localhost y blackjack son destinos locales.
5. El dominio virtual será “hcg.sld.cu”.
6. Y lo mapeamos igual.
7. Por último, lo alias se quedan en el fichero tradicional.

Ahora si creamos un usaurio llamado “usuario” en la base de datos; usuario@localhost no será válido porque solo existe en el domino virtual.

Además, le agregamos que los alisas, son un hash en /etc/alisas, al estilo antiguo. No vamos a cargar la base de datos con los alisases. Sobre todo teniendo en cuenta lo pocos que son. De esta forma, cuando por ejemplo, se manda un correo a root que es una alias de lazaro, postfix preguntara quien es lazaro y responderá un usaurio del dominio virtual. Genial eh?

Tanto los alisas como los dominios virtuales, podrían ser tablas de MySQL, pero como mi aplicación no maneja eso, lo haces al estilo tradicional. En caso de que más adelante desarrollase algún esquema tipo proveedor de servicios; otro gallo cantaría.

No olvidemos “postfix reload”

Otra escupía que me cae en la frente. Desde que conozco linux, estoy oyendo hablar de postfix con ldap, postfix con mysql y siempre mi criterio era el peor.

Por lo general, veía a mis paisanos copiar guías y pasar mil trabajos creando la base de datos sin tener una finalidad útil. Ahora me doy cuenta que en un esquema monstruosamente grande; MySQL resulta útil.

Por ejemplo, aquí tengo planificado un gran despliegue de tecnología estrafalaria y voy a necesitar un esquema como el de google:

“una cuenta para todos los servicios”

Por el momento le va tocando el turno al correo, que aunque aún no tenemos operando el dominio; esta pronto a cumplirse.

Primero y principioso, instalar todo:

1

root@blackjack:~# aptitude install postfix-mysql dovecot-mysql

Seguidamente crearemos los usaurios del sistema. El esquema vmail corre como un usaurio aparte por una cuestión de seguridad.

1
2
3
4

root@blackjack:~# groupadd -g 5000 vmail
root@blackjack:~# useradd -g vmail -u 5000 vmail -d /var/vmail
root@blackjack:~# mkdir /var/vmail
root@blackjack:~# chown vmail:vmail /var/vmail

La base de datos, tienes más o menos esta estructura:

1
2
3
4

lazaro@leviatan:~/ejemplo$ rails console
Loading development environment (Rails 4.1.1)
irb(main):001:0> User.column_names
=> ["id", "username", "realname", "password", "created_at", "updated_at", "telefono", "correo", "quota"]

Lo que más nos interesa de aquí es username y password, sobre todo teniendo en cuenta que que se almacena cifrado, osea, un chorro de mierda hexagesimal.

Ahora vamos al fichero “/etc/dovecot/conf.d/10-auth.conf”. al fondo, le descomentamos el autenticador sql y le comentamos el de pam. Nos quedaría así

1
2
3
4
5
6
7

#!include auth-system.conf.ext
!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-vpopmail.conf.ext
#!include auth-static.conf.ext

Ahora le diremos al autenticador como conectarse a la base de datos. El irá solito a buscar la table “users”. Especificamos las conexión. También le diremos las linea sql que debe tirar para buscar el username y el password.

También modificaremos el mecanismo de cifrado, le diremos que use SHA256 que es el generado por Ruby en mi esquema.

1
2
3
4
5

connect = host=10.1.1.14 dbname=labasededatos user=usuario password=notelodiré
default_pass_scheme = SHA256
password_query = \
  SELECT username, password \
  FROM users WHERE username = '%n'

Por último y antes de pasar a postfix. En el fichero conf.d/auth-sql.conf.ext declaramos como se gestionará la base datos.

1
2
3
4
5
6
7
8
9

passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}

userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/vmail/%n
}

Osea que el correo se almacene en /var/vmail/fulano y con usuario vmail. De hecho TODO el correo se almacenará con el usuario vmail; poniendo fin al perpetuo temor de escalada de permisos que descansa en el típico esquema /var/mail/fulano

En este caso, se chequeará el password contra SQL pero el almacenamiento se hará en /var/vmail, con eso no vamos contra el princpio del cual siempre me agarro y es que las Bases de datos, NO son sistemas de archivos.

Veremos en la próxima entrada, como se hace a postfix jugar con todo esto…

Recién se ha puesto de moda, en el mundo entero, “wordpress”. No hace mucho leí un twit de no se que perico de los palotes; diciendo que el 22% de los sitios en internet son wordpress.

En infomed wordpress es un boom. Incluso se escriben plugins y temas para wordpress.

Al llegar aquí me encontré con un drupal tirado en una IP detrás de un “/intranet” y con un estado de abandono tremendo. Ni siquiera había un DNS así que ni hablar de virtualhost.

Lo primero fue crear un virtualhost para una intranet que albergaría un wordpress.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

lazaro@leviatan:~/octopress$ cat /etc/apache2/sites-enabled/wordpress
<VirtualHost *:80>
        ServerAdmin lazaro@localhost
        ServerName intranet.hcg.sld.cu

        DocumentRoot /usr/share/wordpress/

        <Directory /usr/share/wordpress/>
                Options FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Declaramos el virtualhost en el DNS. En este caso, es hacer un puntero a la maquina donde está el wordpress. Como uso dnsmasq, basta con agregarlo al virtuahost.

1
2
3
4
5

root@blackjack:~# cat /etc/hosts|grep intranet
10.1.1.14   intranet.hcg.sld.cu

root@blackjack:~# /etc/init.d/dnsmasq restart
Restarting DNS forwarder and DHCP server: dnsmasq.

E instalar wordpress:

1

root@leviatan:~# aptitude install wordpress

Como si fuese poca la carga de mi servidor SQL, resulta que cada sitio de wordpress, es simplemente una configuración y una base de datos.

Basta copiar la configuración de ejemplo y bautizarla en /etc/wordpress con el prefijo config- seguido del nombre del virtualhost.

1

lazaro@leviatan:~/octopress$  cp /usr/share/wordpress/wp-config-sample.php /etc/wordpress/config-intranet.hcg.sld.cu.php

Dentro del fichero, la configuración, es un bien comentado script de PHP, que figura los datos para una conexión a la base de datos. Obviemos los comentarios para ahorrar espacio. El fichero me quedó así.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

<?php

define('DB_NAME', 'wordpress');

define('DB_USER', 'wordpress');

define('DB_PASSWORD', 'secretisimo');

define('DB_HOST', 'localhost');

define('DB_CHARSET', 'utf8');

define('DB_COLLATE', '');

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');


$table_prefix  = 'wp_';

define('WPLANG', 'es_ES');

define('WP_DEBUG', false);


if ( !defined('ABSPATH') )
        define('ABSPATH', dirname(__FILE__) . '/');

require_once(ABSPATH . 'wp-settings.php');

define('WP_ALLOW_REPAIR', true);

Como ven, hay un “algo”; no se si variable. Bajo el nombre DB_NAME, declaramos el nombre de la base de datos y así sucesivamente lo obvio hasta DB_HOST.

De ahí pa alante, no tocamos más nada.

Ya estamos listo para crear la base da datos. La rutina clásica: Haremos un usuario con el mismo nombre de la base y le daremos todos los permisos.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

lazaro@leviatan:~/octopress$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 42
Server version: 5.5.30-1.1 (Debian)

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Y ahora creamos la base de datos y el usuario con estas sentencias
NOTA: en nuestro ejemplo tanto la base de datos como el usuario son wordpress, reemplazar PASSWORD_DB por el password que deseen asignarle a la base de datos.

mysql> CREATE DATABASE wordpress;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL ON wordpress.* TO wordpress@localhost IDENTIFIED BY 'secretisimo';
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql> \q
Bye

COMPLETO! Reinicia apache, reinicia dnsmasq y apunta un navegador al nombre del servidor para ver que pasa.

http://intranet.hcg.sld.cu

¡Me han asignado mi segundo servidor en el calixto! Un cliente ligero con 2 gigas de RAM, un buen micro y un disco duro de un tera. La fuente funciona de milagro y está sujeta al chásis mediante bridas.

Le he instalado archlinux (para variar) a partir del que tengo en la laptop. Aquí pienso instalar el servidor de correo, un servidor web para una serie de aplicaciones y un pequeño servidor ftp para disponer instaladores y actualización de antivirus. No soporta virtualización (¿y con que se sienta la cucaracha si lo soportara?). Por tanto, usaremos archlinux como hypervisor de lxc.

Por suerte, en infomed; hay un excelente repo de debian

Para crear contenedores de debian en arch, necesitaremos debootstrap, que por suerte, viene en el repo de arch.

Este archlinux está instalado sobre BTRfs con el COW activado. Me imagino que crear snapshots de los contenedores sea mucho más óptimo.

Creamos entonces el contenedor, usando el repo de infomed como mirror

1
2
3
4

lxc-create -n debian -t \
/usr/share/lxc/templates/lxc-debian -- -r jessie \
--mirror=http://ftp.sld.cu/debian \
--security-mirror=http://ftp.sld.cu/debian

O sea, crea un contenedor, llamado (-n) debian, del release (-r) jessie y usa como repo (–mirror y –security) al de infomed.

Pasé toda la noche resando para que no se fuera a caer la conexión, ya que la operación create de LXC falla de nada. Por suerte todo salió de acorde al plan.

1
2

[root@leviatan ~]# du -hs /var/lib/lxc/
248M /var/lib/lxc/

La idea es, crear un snapshot del básico y restaurarlo con un nuevo nombre.

Pero este está demasiado básico. DESNÚ más bien. Partiremos de ese contenedor como base para crear nuevos contenedores mediante snapshots. Así que a este le instalaremos una selección básica de software. Arrancamos el contenedor:

1

[root@leviatan ~]# lxc-start -n debian

y enclavamos (attach) la consola, o sea, básicamente, entramos al container

1
2
3
4
5
6
7
8

[root@leviatan ~]# lxc-console -n debian

Connected to tty 1
       Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself

Debian GNU/Linux 8 debian tty1

debian login: 

Según la plantilla de archlinux, el password por defecto del container es “root”. Entramos al mismo y le cambiamos el password. Apto seguido, instalar el software.

En mi opinión un container básico, requiere al menos:

mc, tmux, vim, aptitude, iputils-ping

Pero además, puede que quizás te guste añadirle:

manpages, resolvconf, telnet, iptables

Terminada la faena, damos logout y luego presionamos la combinación “Ctrl+a q”. O sea, “control A” primero, luego suelta ambas y presiona “q”. Con eso desenclavas (detach) la consola del container (que sigue corriendo).

Bello verdad?! Linux es un sistema multitareas y multiusuario.

Empezar a aprovisionarnos es tan simple como copiar el contenedor. O sea el contenedor debian lo usaremos como plantilla para crear los contenedores mail, web y ftp.

1
2
3
4
5
6
7
8
9

[root@leviatan ~]# lxc-copy -n debian -N mail
[root@leviatan ~]# lxc-copy -n debian -N web
[root@leviatan ~]# lxc-copy -n debian -N ftp
[root@leviatan ~]# lxc-ls -f
NAME   STATE   AUTOSTART GROUPS IPV4 IPV6
debian STOPPED 0         -      -    -
mail   STOPPED 0         -      -    -
ftp    STOPPED 0         -      -    -
web    STOPPED 0         -      -    -

Ya tenemos las tres máquinas. Ahora es tu desición si conservas o no el contenedor primario. A ese primer contenedor, que en este caso se llama “debian” yo lo llamo matriz. La matriz la mantengo actualizada y afinada. En algún momento podría necesitar hacer máquinas nuevas. Además, si te decides a hacer algún servidor desde cero; conservando las configuraciones, simplemente haces una nueva copia de la matriz (actualizada).

No vale pena tener ssh corriendo en los contenedores. Simplemente le haces ssh al servidor y attach al contenedor. Esto lo hace incluso hasta más seguro.

La mecánica de trabajo en este esquema, es prácticamente la misma que vimos ahora. Arrancar el container y enclavar la consola.

¿Notaste que puse a iptables como paquete opcional? Pues el iptables del hypervisor, o sea, del arch de afuera, controla todo el tráfico.

Otra cosa buena que puedes hacer es lincar todas las cache de apt de los debian. Por ejemplo, el directorio de la matriz sería:

/var/lib/lxc/debian/rootfs/var/cache/apt/archives

Mientras que el de “mail” sería

/var/lib/lxc/mail/rootfs/var/cache/apt/archives

Simplemente montas con bind el archive de debian en el de mail. El fstab quedaría así:

1

 /el/debian/archives  /el/mail/archives  none  bind,nofail 0  0

Nota para imbéciles: La ruta es muy larga, por eso usé ese aforismo. En el fstab debes poner ambas rutas como se ven arriba “/var/lib/lxc/rootfs/fulanito”

Como no usamos red en bridge, todos los container tiran por la misma ip. En el servido web, se usa el puerto 80 y 443, en el de correo el 25 y 110; pero todos en la misma ip. Por esta razón, no corro ssh en los contenedores; diría que el puerto 22 ya se encuentra en eso.

Aquí les dejo entonces la configuración de este container, con red del tipo “none”

1
2
3
4
5
6
7
8

 [root@leviatan ~]# cat /var/lib/lxc/debian/config |grep -v '#'
 lxc.include = /usr/share/lxc/config/debian.common.conf
 lxc.tty = 4
 lxc.arch = amd64
 lxc.network.type = none
 lxc.rootfs = /var/lib/lxc/debian/rootfs
 lxc.rootfs.backend = dir
 lxc.utsname = debian

Por otra parte, cosas como el mysql, que el servidor de correo necesita encuestarlo, simplemente, podrías ponerlo a escuchar por la 127.0.0.1 y así el container del servidor sql, escucha por la 127 y los demás container (incluso el hypervisor) se conectan al localhost donde está el mysql. O sea, la 127.0.0.1 sería como la red interna de todos los container. ¿Es seguro verdad?

Podemos confiarle ahora, a la frescura y robusteza de archlinux, la estabilidad de debian.