MailScanner, instalación rápida
La filosofía Unix es disponer de pequeñas herramientas que hagan cosas simples, pero que las hagan bien y de forma segura. Uniendo las funcionalidades de las diferentes herramientas podemos conseguir un sistema funcional y con múltiples características donde el único límite es nuestro conocimiento. En los servidores de correos hay 3 elementos indispensables. MTA, AntiSpam y Antivirus. Para cada servicio existe una aplicación, pero hacerlas funcionar en conjunto no suele ser sencillo la primera vez.
MailScanner nos va a ayudar a unir nuestro AntiSpam y Antivirus con el MTA, creando de esta forma un servicio de correo estable y seguro. Este es un pequeño manual que nos guiará en los pasos básicos para tener funcionando Postfix + MailScanner (Spamassassin + Clamav).
Instalación
apt-get install mailscanner clamav unrar zip spamc razor pyzor
Muy complicado…
Configuración
Paramos el servicio de postfix con /etc/init.d/postfix stop. Es importante que postfix corra enjaulado en /var/spool/postfix, si no, habrá que meterlo.
Editamos /etc/postfix/main.cf y añadimos la siguiente línea:
header_checks = regexp:/etc/postfix/header_checks
Dicho fichero debe tener el siguiente contenido:
/^Received:/ HOLD
Su finalidad es sencilla de entender. Con esas líneas le indicamos a postfix que los correos los deje en la cola HOLD. Mailscanner recogerá los correos de la cola, les pasará antivirus y antispam para terminar dejándolos en Incoming, donde postfix terminará de entregarlo.
Dentro de /etc/MailScanner/MailScanner.conf se deben cambiar como mínimos estas líneas:
%report-dir% = /etc/MailScanner/reports/es Run As User = postfix Run As Group = postfix Incoming Queue Dir = /var/spool/postfix/hold Outgoing Queue Dir = /var/spool/postfix/incoming MTA = postfix
Por último enviamos editamos el /etc/default/mailscanner:
run_mailscanner=1
Y ya podemos arrancar mailscanner con /etc/init.d/mailscanner start
¡Importante! Al intentar arrancar mailscanner te dirá que directorios no tiene los permisos correctos. Esto es así porque mailscanner correrá como usuario postfix, por lo tanto todas las carpetas donde sea necesario escribir y eliminar fichero deberán tener como propietario a postfix.
Pruebas
Para enviar un mail que sea detectado como virus debe contener el siguiente texto en el cuerpo:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Este será el resultado:
Jan 3 17:36:36 dominioirontec MailScanner[21784]: Virus and Content Scanning: Starting Jan 3 17:37:27 dominioirontec MailScanner[21784]: /var/spool/MailScanner/incoming/21784/ ./9A0989A81D8.80660/msg-21784-1.txt: Eicar-Test-Signature FOUND Jan 3 17:37:27 dominioirontec MailScanner[21784]: Virus Scanning: ClamAV found 1 infections Jan 3 17:37:27 dominioirontec MailScanner[21784]: Infected message 9A0989A81D8.80660 came from 127.0.0.1 Jan 3 17:37:27 dominioirontec MailScanner[21784]: Virus Scanning: Found 1 viruses
De la misma forma, para que sea detectado como Spam debe tener el siguiente texto en el cuerpo:
XJSC4JDBQADN1.NSBN32IDNENGTUBE-STANDARD-ANTI-UBE-TEST-EMAILC.34X
Este será el resultado:
Jan 3 17:55:56 dominioirontec MailScanner[21784]: Spam Checks: Found 1 spam messages
Recetas de Postfix
Algunos trucos y consejos que siempre viene bien tener a mano :)
Habilitar uso de TLS
# TLS parameters smtpd_tls_cert_file=/etc/postfix/ssl/smtpd.pem smtpd_tls_key_file=/etc/postfix/ssl/smtpd.pem smtpd_tls_CAfile=/etc/postfix/ssl/smtpd.pem smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
Para crear el certificado usamos el comando:
openssl req -new -x509 -nodes -out smtpd.pem -keyout smtpd.pem -days 3650
Activar chequeo de listas negras
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated # Activa chequeo de PTR reject_unknown_client # Seleccionamos las listas negras a usar reject_rbl_client xbl.spamhaus.org reject_rbl_client sbl.spamhaus.org reject_rbl_client list.dsbl.org # Mensaje de error que se enviará si el emisor se encuentra en listas negras default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain.
Es recomendable realizar los chequeos de listas negras en el propio postfix, desactivándolos en el spamassasin. De esta forma evitamos cargar aún más el sistema analizando correos que casi en un 99% serán spam.
Cambiar la dirección del remitente
Se hace mediante los llamados smtp_generic_maps. El cambio únicamente se realizará en la salida de los correos. Se crea el fichero generics:
/etc/postfix/generic: root@localdomain.local otrocorreo@miguelangelnieto.net
Se crea la base de datos a partir del fichero con:
postmap /etc/postfix/generic
Por último se configura main.cf para que use los generic_maps.
smtp_generic_maps = hash:/etc/postfix/generic
Se reinicia postfix y ya debería funcionar. Más información en:
http://www.postfix.org/postconf.5.html#smtp_generic_maps
http://www.postfix.org/generic.5.html
Si queremos también en entrada usaremos las direcciones canónicas que se verán más abajo.
Utilizar distintos relays dependiendo del destino
Se hace mediante los transport. Creamos /etc/postfix/transport con los siguientes datos:
primero@miguelangelnieto.net smtp:[85.112.9.44]:25 segundo@irontec.com smtp:[82.194.75.72]:25 tercero@google.com smtp:gmail.com
Creamos la base de datos con:
postmap /etc/postfix/transport
Configuramos main.cf para que use los transports:
transport_maps = hash:/etc/postfix/transport
Comprobar las direcciones de destino
Con esta solución, postfix comprobará que las direcciones de destino existen realmente. Si no existen rechazará la recepción del correo.
Primero se debe crear un fichero con las direcciones de correo válidas para el sistema. Su sintaxis es la siguiente:
prueba@dominioirontec.local OK prueba2@dominioirontec.local OK admin@dominioirontec.local OK
Dicho fichero, una vez completado, debemos convertirlo en una base de datos con postmap.
En main.cf las opciones son las siguientes:
# Restricciones de la vida para direcciones externas (para las que se hará relay) relay_recipient_maps = hash:/etc/postfix/valid_recipients # Restricciones de la vida para direcciones locales (sin relay) local_recipient_maps = hash:/etc/postfix/valid_recipients
Direcciones Canonicas
Una dirección canónica es la dirección de correo electronico con la que se termina enviando un email.
De esta forma, si cuando enviamos un email con la dirección de remitente usuario@dominio y este tiene una dirección canónica luser@hotmail.com, la dirección de remitente se reescribirá por esta última.
Para ello creamos un fichero /etc/postfix/sender_canonical donde se guardan las direcciones canónicas con el siguiente formato:
usuario luser@hotmail.com
Dicho fichero lo postmapeamos y añadimos a /etc/postfix/main.cf:
sender_canonical_maps = hash:/etc/postfix/sender_canonical
Esto también se aplicará a los correos que recibamos.
Maildrop
Programa utilizado para entregar el correo a distintas carpetas según unos filtros definidos. Su fichero de configuración se encuentra en /etc/maildroprc
Para que postfix haga uso de el es necesario configurar main.cf poniendo la siguiente opción:
mailbox_command = /usr/bin/maildrop -d $USER -f $SENDER
En el ejemplo que pegaré a continuación se definen una serie de acciones teniendo en cuenta el las cabeceras o destinatarios del correo.
# Global maildrop filter file# Uncomment this line to make maildrop default to ~/Maildir for # delivery- this is where courier-imap (amongst others) will look. DEFAULT="$HOME/Maildir" # Si el correo es spam lo movemos # a la carpeta de spam y lo aprendemos. \if (/^X-Spam-Flag: YES/) { cc "|/usr/bin/sa-learn --spam" to "Maildir/.Spam" } if (/^Delivered-To: ebay@midominio.net/) { cc "|/usr/bin/sa-learn --ham" to "Maildir/.Ebay" } if (/^Delivered-To: curriculum@midominio.net/) { cc "|/usr/bin/sa-learn --ham" to "Maildir/.Curriculum" } # El resto lo aprendemos como correo NO spam # y lo dejamos en nuestro INBOX. cc "|/usr/bin/sa-learn --ham" to "Maildir"
Excusas BOFH para Android
Gracias al gran proyecto iniciado por Ivan Mosquera (Irontec) llamado PHP for Android me enteré de la existencia de Scripting Layer for Android, un proyecto que nos permite desarrollar scripts para nuestro sistema móvil favorito. Entre los lenguajes que soporta se encuentran:
- Python
- Sh
- Perl
- Rhino
- Lua
- Ruby
- ...
Mediante unos sencillos scripts es posible acceder a funciones para controlar el TTS, GPS, Bateria, Bluetooth, SMS, etc. Vamos, que en pocas líneas te puedes hacer cositas bastante interesantes. Yo como administrador de sistemas estoy acostumbrado a programar Scripts (y no aplicaciones completas), por lo que esto se convierte en un juguete muy divertido sin necesidad de meterte con el monstruo Java.
La instalación es sencilla. En primer lugar instalamos SL4A:
A continuación desde http://code.google.com/p/android-scripting/downloads/list te puedes instalar los interpretes para alguno de los lenguajes mencionados anteriormente. Para el ejemplo que vamos a ver a continuación usaremos Python:
Y listo, solo nos queda hacer nuestros scripts y subirlos a /sdcard/sl4a/scripts
Yo os pongo un ejemplo, que es simple y facil de entender. Es un script en python que se descarga una lista de excusas BOFH de una URL en concreto y escoge una al azar para mostrartela en pantalla. Siempre viene bien tener a mano estas frases para responder a las típicas preguntas "oyeee, que no me funca el aparatooo". Así que para tenerlo accesible creamos un enlace en el escritorio:
Lo lanzamos y tenemos nuestra excusa:
Aquí el código. Se aceptan críticas y mejoras :P
import android import urllib2 from random import randint droid = android.Android() try: f = urllib2.urlopen("http://pages.cs.wisc.edu/~ballard/bofh/excuses") except urllib2.HTTPError, e: print "ERROR" print e.code exit(1) except urllib2.URLError, e: print "ERROR" print e.reason exit(1) ex = f.read() # Separamos las frases por los saltos de lineas, convirtiendolo en una lista ex = ex.split("\n") f.close() # Buscamos el numero de frases que hay (otra forma mas bonita de hacerlo?) c = 0 for i in ex: c = c + 1 # Cogemos una al azar r = randint(0, c) # La mostramos droid.dialogCreateAlert("BOFH Excuse", ex.pop(r - 1)) droid.dialogSetPositiveButtonText('Close') droid.dialogShow()
Arrancando nuestro primer cluster
Una vez que conocemos la teoría, vamos a poner en marcha nuestro primer Cluster. Estará compuesto únicamente por 3 ordenadores.
Nodo 1 (192.168.1.106):
- ndb_mgmd
- mysqld
Nodo 2 (192.168.1.104):
- ndbd
Nodo 3 (192.168.1.105):
- ndbd
Esto es, el nodo 1 será un Management Node + API Node y los dos restantes Data Nodes.
Lo primero de todo es descargarnos MySQL Cluster de http://dev.mysql.com/downloads/cluster/
La instalación es tan sencilla como descomprimir el fichero y copiar a nuestro PATH los ejecutables que necesitemos. Por lo tanto, llevaremos a /usr/bin/ los ejecutables ndbd, ndb_mgmd, ndb_mgm, mysqld, mysqld_safe.
Para tener un poco ordenadas las cosas, creamos la carpeta /etc/mysql-cluster/ donde alojaremos el fichero de configuración del cluster config.ini.
# cat /etc/mysql-cluster/config.ini [ndbd default] NoOfReplicas=2 DataDir=/var/lib/mysql-cluster DataMemory=512M IndexMemory=128M TransactionDeadlockDetectionTimeout=5000 MaxNoOfConcurrentOperations=100000 MaxNoOfLocalOperations=110000 [ndb_mgmd] Id=1 HostName=192.168.1.106 [ndbd] Id=5 HostName=192.168.1.104 [ndbd] Id=6 HostName=192.168.1.105 [mysqld] Id=7
Como vemos, en primer lugar indicamos los valores por defecto para todos los Data Nodes (ndbd). Por ejemplo se indican el número de replicas, donde se almacenarán los datos, la cantidad de memoria usada para almacenar datos e índices, número de operaciones concurrentes, etc. Estos valores no están ni calculados ni ajustados a la realidad, solamente son funcionales para este ejemplo y para trabajar con la base de datos employees. Cada caso y cada base de datos necesitará distintos valores que se deberán ajustar en función de la carga y cantidad de datos a almacenar.
El Management Node será el número 1 con la IP indicada, mientras que los Data Nodes serán los ID 5 y 6 con sus respectivas IPs. El API node (o en este caso más concreto Mysql Node) no tiene una ip asignada, por lo que se podría conectar desde cualquier equipo de la red.
Una vez que tenemos el fichero procedemos a arrancar el Management Node:
# ndb_mgmd -f /etc/mysql-cluster/config.ini 2010-07-25 19:30:06 [MgmtSrvr] INFO -- NDB Cluster Management Server. mysql-5.1.44 ndb-7.1.4b 2010-07-25 19:30:06 [MgmtSrvr] INFO -- Reading cluster configuration from '/etc/mysql-cluster/config.ini'
Arrancamos la consola y vemos que nodos tenemos arrancados:
# ndb_mgm -- NDB Cluster -- Management Client -- ndb_mgm> show Connected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=5 (not connected, accepting connect from 192.168.1.104) id=6 (not connected, accepting connect from 192.168.1.105) [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.1.106 (mysql-5.1.44 ndb-7.1.4) [mysqld(API)] 1 node(s) id=7 (not connected, accepting connect from any host)
Solo tenemos el Management Node en marcha. Vamos a proceder a arrancar los Data Nodes. Nos conectamos a cada nodo y ejecutamos:
# ndbd --connect-string=192.168.1.106 --initial -n 2010-07-25 19:31:38 [ndbd] INFO -- Configuration fetched from '192.168.1.106:1186', generation: 1
La opción --initial se usa cuando iniciamos por primera vez el Cluster para arrancar con el sistema de ficheros limpio. -n indica que el nodo no se autoarranque y --connect-string indica la IP del Management Node al que nos conectaremos.
Una vez que Data Node se conecta al Management Node, este último les entrega el fichero de configuración con los parametros necesarios para que se configuren. Ahora, desde la consola de administración podremos arrancar los dos Data Nodes:
ndb_mgm> 5 start Database node 5 is being started. ndb_mgm> Node 5: Start initiated (version 7.1.4) ndb_mgm> 6 start Database node 6 is being started. ndb_mgm> Node 6: Start initiated (version 7.1.4) ndb_mgm> show Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=5 @192.168.1.104 (mysql-5.1.44 ndb-7.1.4, Nodegroup: 0, Master) id=6 @192.168.1.105 (mysql-5.1.44 ndb-7.1.4, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.1.106 (mysql-5.1.44 ndb-7.1.4) [mysqld(API)] 1 node(s) id=7 @192.168.1.106 (mysql-5.1.44 ndb-7.1.4)
Ya tenemos los Data Nodes en marcha.
Para arrancar el Api Node únicamente hay que ejecutar el demonio mysqld:
# mysqld_safe --ndbcluster &
No es necesario indicarle la IP del Management Node ya que se encuentran en la misma máquina.
Listo! Si ahora nos conectamos con el cliente mysql a localhost y creamos una base de datos usando tablas ndbcluster, estas se almacenarán en nuestro recién creado Cluster :)
Introducción a MySQL Cluster
MySQL Cluster es una base de datos que como su nombre indica funciona en un Cluster de servidores. Mucha gente confunde terminos y define un conjunto de servidores con replicación como un MySQL Cluster, pero hay que tener en cuenta que son dos conceptos totalmente distintos. MySQL Cluster nos ofrece:
- Alta disponibilidad
- Escalabilidad
- Failover automático
- Redundancia
- Alto throughput
La versión actual es la 7.1 y puede descargarse de http://www.mysql.com/products/database/cluster/
Componentes
Un Cluster MySQL está compuesto por los siguientes componentes:
Manager (ndb_mgmd): es un servicio encargado de poner en marcha el cluster, conectar nuevos servidores y ejecutar distintos comandos de administración mediante el CLI ndb_mgm. Una vez que hemos levantado el cluster no es necesario ni un requisito indispensable que esté levantado.
Data Nodes (ndbd): son nodos encargados del almacenamiento de los datos. Se recomiendan al menos dos para disponer de redundancia y alta disponibilidad. Estas serán las máquinas más potentes del cluster, almacenarán los índices en memoria y los datos en memoria o disco. Todos los Data Nodes deben tener el mismo hardware para evitar crear cuellos de botella.
API nodes (mysqld): aunque el más usado sea mysqld, un API node puede ser cualquier aplicación que haciendo uso de la API acceda al cluster. El típico, también conocido como SQL Node, es el demonio mysqld típico (compilado con soporte nbdcluster). De esta forma podremos escribir o leer datos de nuestra BBDD como hemos hecho hasta ahora, mediante comandos SQL.
Se recomienda que cada componente esté instalado en una máquina física distinta.
Funcionamiento interno
Internamente, el funcionamiento del cluster se basa en dos conceptos básicos. Replicación interna síncrona y auto particionado de datos. La primera nos ofrece la redundancia y el segundo nos da la escalabilidad. Importante diferenciarlo de la replicación típica de MySQL (asíncrona). En este caso, hasta que los datos no han sido replicados en los nodos seleccionados no se devuelve el control al usuario, obteniendo de esta forma la consistencia que no tenemos en la replicación asíncrona.
El particionado (PARTITION BY KEY) es también totalmente automático. El cluster se encarga de dividir las tablas en distintas particiones y dividir los datos entre los distintos Data Nodes. Aunque es posible que definamos nuestro propio particionado, no se recomienda. Añades complejidad y posiblemente el rendimiento no sea el esperado.
Replicas
A la hora de configurar nuestro cluster, una de los valores más importantes a tener en cuenta es decidir el número de replicas que tendremos de nuestros datos. No podemos decidir cualquier número, si no que tendremos que seguir unas sencillas reglas. Pongamos por ejemplo que tenemos 4 Data Nodes. En este caso podremos tener 1, 2 y 4 replicas. Esto es, el número de nodos debe poder ser divisible por el numero de replicas. Aún así, no se debería tener una única replica, ya que eso no nos da ningún tipo de alta disponibilidad ya que al caerse un solo nodo perderíamos el acceso a los datos.
Node Groups
MySQL Cluster agrupa automáticamente los Data Nodes en grupos. Esto no está bajo nuestro control ni podemos decidir que nodo está en que grupo, será trabajo del cluster hacer estas agrupaciones. Siguiendo el ejemplo anterior, si tenemos 4 Data Nodes y 2 réplicas, MySQL Cluster nos generará dos Node Groups (4/2=2). Además hay que tener en cuenta que el número de particiones que se harán de nuestros datos siempre será igual al número de Data Nodes.
Por lo tanto, imaginemos que tenemos el N1 y N2 en el grupo 1 (G1) y N3 y N4 en el grupo 2 (G2). A la hora de particionar y repartir los datos es necesario pensar en la alta disponibilidad, por lo que el particionado se hará de la siguiente forma:
G1 N1 = P1 y P2' N2 = P2 y P1'G2 N3 = P3 y P4' N4 = P4 y P3'
Siendo PX el número de la partición y PX' una copia de la partición de Backup.
Sabiendo esto, podemos imaginar cuando dispondremos de alta disponibilidad. Mientras al menos uno de los nodos de un grupo esté levantado, el cluster estará online. Por ejemplo se podrían caer N1 y N4 o N3 y N2 y todo seguiría funcionando. Pero una caida de N1 y N2 dejaría el cluster completamente caido.
A mayor número de replicas menos posibilidades de fallo, más escalabe y más throughput :)
Próximamente extenderé el tema de MySQL Cluster con más entradas según vaya profundizando en el estudio de la certificación. La intención será termianr teniendo un mini manual para andar por casa que nos permita dar los primeros pasos.
Postfix TLS con múltiples certificados
Cuando hablamos de TLS o SSL siempre nos encontramos con el mismo problema, el certificado. Este debe ser único por puerto e IP, de forma que dependiendo de a donde se conecte el cliente le entregamos un certificado u otro acorde a su dominio. Esto es algo con lo que tenemos que pelear constantemente en Apache, creando un VirtualHost por cada IP y asignándole un certificado.
Postfix no se libra y también necesitamos una IP por certificado, de forma que a cada cliente le muestre el certificado de su dominio y nos evitemos los famosos warning. Para hacerlo en primer lugar es necesario tener una IP por cada dominio. Una vez completado ese simple requisito pasamos a configurar Postfix. Primero ponemos TLS a nivel global en Postfix dentro del main.cf:
#TLS smtpd_use_tls = yes smtpd_tls_key_file = /etc/ssl/dominio1.com.key smtpd_tls_cert_file = /etc/ssl/dominio1.com.crt smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom
Ahora tenemos que hacer que Postfix arranque un proceso smtpd por cada una de las IPs/Dominios. Esto lo hacemos en el master.cf. Al mismo tiempo que indicamos la IP, también le indicamos el certificado que usará:
#========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) #========================================================================== 10.10.10.1:smtp inet n - - - - smtpd 127.0.0.1:smtp inet n - - - - smtpd 10.10.20.1:smtp inet n - - - - smtpd -o smtpd_tls_cert_file=/etc/ssl/dominio2.com.crt 10.10.30.1:smtp inet n - - - - smtpd -o smtpd_tls_cert_file=/etc/ssl/dominio3.com.crt 10.10.40.1:smtp inet n - - - - smtpd -o smtpd_tls_cert_file=/etc/ssl/dominio4.com.crt
Listo, en cada IP entregará un certificado :)
Replicación maestro-esclavo en MongoDB
Esta es una entrada cortita, gracias en parte a la extrema facilidad de administrador de nuestra base de datos NoSQL favorita. En esta ocasión vamos a ver como crear una replicación dentre dos sistemas MongoDB, en arquitectura Maestro-Esclavo. Como pasa bastante habitualmente, la arquitectura Maestro-Maestro, a pesar de ser posible, no la recomiendan. Esta, al igual que en MySQL, se basa en el truco de hacer que un esclavo sea al mismo tiempo maestro.
Yo voy a mostrar la opción recomendada, Maestro-Esclavo.
Para ello, lo primero es instalar dos MongoDB en Debian Lenny.
El primero se llamará Maestro con IP 192.168.1.105 y el segundo Esclavo con IP 192.168.1.101.
Arrancamos el maestro indicando que actuará con ese Rol:
debian1:/usr/local/mongodb# bin/mongod --master Sat Jun 12 16:41:23 Mongo DB : starting : pid = 2158 port = 27017 dbpath = /data/db/ master = 1 slave = 0 64-bit Sat Jun 12 16:41:23 db version v1.4.3, pdfile version 4.5 Sat Jun 12 16:41:23 git version: 47ffbdfd53f46edeb6ff54bbb734783db7abc8ca Sat Jun 12 16:41:23 sys info: Linux domU-12-31-39-06-79-A1 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_41 Sat Jun 12 16:41:23 waiting for connections on port 27017 Sat Jun 12 16:41:23 ****** Sat Jun 12 16:41:23 creating replication oplog of size: 944MB (use --oplogSize to change) Sat Jun 12 16:41:23 ****** Sat Jun 12 16:41:23 allocating new datafile /data/db/local.ns, filling with zeroes... Sat Jun 12 16:41:23 done allocating datafile /data/db/local.ns, size: 16MB, took 0.026 secs Sat Jun 12 16:41:23 allocating new datafile /data/db/local.0, filling with zeroes... Sat Jun 12 16:41:23 done allocating datafile /data/db/local.0, size: 64MB, took 0.185 secs Sat Jun 12 16:41:23 allocating new datafile /data/db/local.1, filling with zeroes...
Una vez hecho, arrancamos el Esclavo indicándole por parámetro donde está su Maestro:
debian2:/usr/local/mongodb/bin# ./mongod --slave --source 192.168.1.105:27017 Sat Jun 12 16:42:03 Mongo DB : starting : pid = 2172 port = 27017 dbpath = /data/db/ master = 0 slave = 1 64-bit Sat Jun 12 16:42:03 db version v1.4.3, pdfile version 4.5 Sat Jun 12 16:42:03 git version: 47ffbdfd53f46edeb6ff54bbb734783db7abc8ca Sat Jun 12 16:42:03 sys info: Linux domU-12-31-39-06-79-A1 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_41 Sat Jun 12 16:42:03 waiting for connections on port 27017 Sat Jun 12 16:42:03 web admin interface listening on port 28017 Sat Jun 12 16:42:04 allocating new datafile /data/db/local.ns, filling with zeroes... Sat Jun 12 16:42:04 done allocating datafile /data/db/local.ns, size: 16MB, took 0.028 secs Sat Jun 12 16:42:04 allocating new datafile /data/db/local.0, filling with zeroes... Sat Jun 12 16:42:05 done allocating datafile /data/db/local.0, size: 64MB, took 0.185 secs Sat Jun 12 16:42:05 building new index on { id: 1 } for local.sources Sat Jun 12 16:42:05 Buildindex local.sources idxNo:0 { name: "_id", ns: "local.sources", key: { _id: 1 } } Sat Jun 12 16:42:05 done for 0 records 0secs Sat Jun 12 16:42:05 repl: from host:192.168.1.105:27017 Sat Jun 12 16:42:05 repl: applied 1 operations Sat Jun 12 16:42:05 repl: end sync_pullOpLog syncedTo: Sat Jun 12 16:42:00 2010 4c139cb8:1
Ya tenemos las dos bases de datos en marcha:
Creamos una nueva base de datos llamada test y añadimos una colección:
> use test switched to db test > a = { nombre : "Miguel Angel", apellido : "Nieto" } { "nombre" : "Miguel Angel", "apellido" : "Nieto" } > db.gente.save(a);
Comprobamos que se ha añadido en Maestro:
Comprobamos que se ha añadido en Esclavo:
Y lo buscamos en el Esclavo:
Más facil y rápido imposible :)
Finalmente no me certifico en MySQL Cluster
Realmente no es porque yo no quiera, que en realidad tengo muchas ganas, si no que el pésimo servicio de atención al cliente de Oracle me lo impide por su completa inutilidad operativa. Llevo meses esperando que hagan algo que a priori es sencillo, comprobar mis certificados en PearsonVUE para permitirme sacar la nueva certificación en Prometric. Algo tan sencillo como eso, más aún siendo Oracle cliente también de PearsonVUE, se ha convertido en una hazaña imposible.
Desde la última vez que me pidieron algunos datos y documentos desde "suncert_ww@oracle.com" no he vuelto a saber de ellos. Y cuando escribo ya no me llega ni el mensaje de respuesta automática. Por lo tanto, ¿que puedo pensar de esto? O que estoy filtrado de por vida o que son unos completos inútiles. Desde aquí lanzo unas preguntas:
- ¿Si tuviese una cuenta en Metalink u Oracle Support me harían más caso?
- ¿Y Si estuviese interesado en certificarme en Oracle?
Estas pidiendo ayuda al servicio de soporte para poder certificarte y te sientes como si estuvieras mendigando.
Si alguien ha tenido un problema similar y ha logrado solucionarlo, ¡que se comunique conmigo para saber como! Contacto
El guardián entre el centeno
Si no fuera porque su autor es J. D. Salinger podría jurar que lo escribí yo :P
Pensé que encontraría trabajo en una gasolinera poniendo a los coches aceite y gasolina. Pero la verdad es que no me importaba qué clase de trabajo fuera con tal de que nadie me conociera y yo no conociera a nadie. Lo que haría sería hacerme pasar por sordomudo y así no tendría que hablar. Si querían decirme algo, tendrían que escribirlo en un papelito y enseñármelo. Al final se hartarían y ya no tendría que hablar el resto de mi vida. Pensarían que era un pobre hombre y me dejarían en paz. Yo les llenaría los depósitos de gasolina, ellos me pagarían, y con el dinero me construiría una cabaña en algún sitio y pasaría allí el resto de mi vida. La levantaría cerca del bosque, pero no entre los árboles, porque quería ver el sol todo el tiempo. Me haría la comida, y luego, si me daba la gana de casarme, conocería a una chica guapísima que sería también sordomuda y nos casaríamos. Vendría a vivir a la cabaña conmigo y si quería decirme algo tendría que escribirlo como todo el mundo. Si llegábamos a tener hijos, los esconderíamos en alguna parte. Compraríamos un montón de libros y les enseñaríamos a leer y escribir nosotros solos.
¡Grande! Toca leérmelo otra vez, el ritual... una vez al año.
MogileFS, sistema de ficheros distribuido a través de la red
MogileFS es un sistema de ficheros distribuido que funciona en activo-activo o dicho de otra forma, es un RAID a través de la red. Algunas de sus características:
No requiere de ningún parche en kernel ni módulos especiales ya que funciona completamente a nivel de aplicación.
No hay ningún SPOF(single point of failure) ya que todos los elementos que forman MogileFS pueden estar distribuidos en múltiples máquinas.
Se pueden especificar clases de ficheros. Las clases definirán cuantas réplicas pueden llegar a tener. Por ejemplo, un fichero de log poco importante puede ser suficiente con dos réplicas, pero los datos bancarios de la empresa necesita 10 réplicas. Dependiendo de la clase, MogileFS hará automáticamente las réplicas que sea necesario.
No importa el sistema de ficheros que tengamos debajo. Puede ser Ext3, Ext4, XFS…
Está compuesto por varios componentes, cada uno de los cuales puede estár en diferentes máquinas y replicado tantas veces como quieras:
Base de datos: MySQL ;) Se almacenan los metadatos y los namespaces y debería estar en HA o tendremos un punto de fallo.
Tracker (mogilefsd): es el proceso encargado de recibir las peticiones del cliente y gestionarlas.
Nodos de almacenamiento (mogstored): donde los datos se guardan físicamente. Estos nodos son simplemente servidores HTTP que recibe peticiones PUT, GET, DELETE
Vamos con la instalación ;)
1- Instalar dependencias:
# apt-get install debhelper dpkg-dev fakeroot # apt-get install libio-aio-perl libdanga-socket-perl libnet-netmask-perl libstring-crc32-perl # apt-get install gearman-server libgearman-client-perl libgearman-client-async-perl
2- Instalar perlbal:
# cd /usr/src # svn co http://code.sixapart.com/svn/perlbal # cd perlbal/trunk # dpkg-buildpackage -rfakeroot # dpkg -i ../libperlbal-perl_1.70-1_all.deb
3- Instalar mogileFS:
# cd /usr/src # svn co http://code.sixapart.com/svn/mogilefs # cd mogilefs/trunk # bin/build-all-debian.sh # dpkg -i ./api/perl/libmogilefs-perl_1.00-1_all.deb # bin/build-all-debian.sh # dpkg -i packages/mogilefsd_1.00-2_all.deb packages/mogilefs-utils_0.01-1_all.deb packages/mogstored_1.00-2_all.deb
4- Crear base de datos:
$ mysql -u root -p mysql> create database mogilefs; mysql> grant all on mogilefs.* to 'mogile'@'%' identified by 'mogilepw'; mysql> flush privileges; mysql> quit
5- Crear esquema:
$ /usr/bin/mogdbsetup --yes --dbname=mogilefs --dbuser=mogile --dbpassword=mogilepw
Al menos tiene que existir un tracker, se puede configurar en el mismo nodo de storage:
zimbra:/var/mogdata# cat /etc/mogilefs/mogilefsd.conf #daemonize = 1 # Database connection information db_dsn = DBI:mysql:mogilefs:host=127.0.0.1 db_user = mogile db_pass = mogilepw # IP:PORT to listen on for mogilefs client requests listen = 127.0.0.1:7001 # Optional, if you don't define the port above. conf_port = 7001 # Number of query workers to start by default. query_jobs = 10 # Number of delete workers to start by default. delete_jobs = 1 # Number of replicate workers to start by default. replicate_jobs = 5 # Number of reaper workers to start by default. # (you don't usually need to increase this) reaper_jobs = 1 # Number of fsck workers to start by default. # (these can cause a lot of load when fsck'ing) #fsck_jobs = 1 # Minimum amount of space to reserve in megabytes # default: 100 # Consider setting this to be larger than the largest file you # would normally be uploading. #min_free_space = 200 # Number of seconds to wait for a storage node to respond. # default: 2 # Keep this low, so busy storage nodes are quickly ignored. #node_timeout = 2 # Allow replication to use the secondary node get port, # if you have apache or similar configured for GET's #repl_use_get_port = 1
Una vez hecho, se añaden los hosts de almacenamiento:
mogadm --trackers=127.0.0.1:7001 host add hostmolon1 --ip=10.10.0.122 --port 7500 --status=alive mogadm --trackers=127.0.0.1:7001 host add hostmolon2 --ip=10.10.0.122 --port 7500 --status=alive
Se listan para ver si es correcto:
zimbra:/var/mogdata# mogadm --trackers=127.0.0.1:7001 host list hostmolon1 [1]: alive IP: 127.0.0.1:7500hostmolon2 [2]: alive IP: 10.10.0.122:7500
Se añaden los dispositivos de almacenamiento:
mogadm --trackers=127.0.0.1:7001 device add hostmolon1 1 mogadm --trackers=127.0.0.1:7001 device add hostmolon2 2
El último valor es el id, por lo tanto en hostmolon1 habrá que crear la carpeta:
/var/mogdata/dev1/
y en hostmolon2:
/var/mogdata/dev2/
El propietario de la carpeta tiene que ser “mogstored”. Generalmente lo que se suele hacer es montar discos duros sata directamente en dichas carpetas.
Comprobamos que tira:
zimbra:/var/mogdata# mogadm --trackers=127.0.0.1:7001 device list hostmolon1 [1]: alive used(G) free(G) total(G) dev1: alive 1.539 5.567 7.106hostmolon2 [2]: alive used(G) free(G) total(G) dev2: alive 2.502 4.604 7.106
Para poder catalogar los ficheros es necesario definir dos cosas, dominios y clases. El dominio sería como una separación de un grupo de ficheros. El dominio a su vez puede tener definido un número n de clases.
mogadm --trackers=127.0.0.1:7001 domain add irontec mogadm --trackers=127.0.0.1:7001 class add irontec miclase
Y ya podemos añadir ficheros. Estos se deben gestionar mediante API, ya sea con PHP, Python o cualquier otro que nos guste más. Esto es así porque los ficheros no se escriben en la carpeta como si se tratase de un sistema de ficheros normal, si no que hay que hacerlo a través de un tracker para que este se encarge de las réplicas. Nosotros, en lugar de hacer uso de estas APIs, tiraremos de la herramienta de consola mogtool.
mogtool inject /boot/vmlinuz-2.6.26-2-686 vmlinuz --trackers=127.0.0.1:7001 --domain=irontec
Buscarlos:
zimbra:/var/mogdata# mogtool locate vmlinuz --trackers=127.0.0.1:7001 --domain=irontec http://127.0.0.1:7500/dev2/0/000/000/0000000005.fid [^] http://10.10.0.122:7500/dev10/0/000/000/0000000005.fid [^] 0000002 paths found
Y extraerlos:
zimbra:/var/mogdata# mogtool extract vmlinuz /tmp/test --trackers=127.0.0.1:7001 --domain=irontec Fetching piece 1... Trying http://10.10.0.122:7500/dev10/0/000/000/0000000005.fid... [^] Done. zimbra:/var/mogdata# md5sum /tmp/test /boot/vmlinuz-2.6.26-2-686 f6690b230573b7f791e84c33adf0804c /tmp/test f6690b230573b7f791e84c33adf0804c /boot/vmlinuz-2.6.26-2-686
Todo esto tiene una mejora importante sobre los RAID por software o hardware. El RAID por si mismo te salva si se rompe alguno de los discos, ¿pero que pasa si se rompe el servidor? ;) Nada mejor que un RAID distribuido a través de la red para evitar estos problemas.