Category Archives: System Administration

Convert Rackspace Cloud Server images to OVA

I wrote an script to convert Rackspace Cloud Server Images to OVA files. This file can be imported to Vmware and Virtualbox (and may be other hypervisors).

You have to get a copy of .tgz files generated from Cloud Servers snapshots and then provide it as first argument of this script.

The script is here.

In the comments you can see the requirements and how to use it.

Feedback is welcome.

Post to Twitter

Load balance between source IPs in Linux

Today I received a question about how to distribute the outgoing connections between several IP addresses attached to an interface. Suppose that you have 3 IPs in the eth0 interface and you want to do round robin between that IPs for outgoing connections. With regular iproute commands you can’t. Doing some tricks with fwmarks, ip rule and ip route neither.

The only way that I’ve found to it is using SNAT and statistics to get a real Round Robin balance:


iptables -t nat -A POSTROUTING  -m statistic --mode nth --every 3 -j SNAT --to

iptables -t nat -A POSTROUTING  -m statistic --mode nth --every 2 -j SNAT --to

iptables -t nat -A POSTROUTING  -m statistic --mode nth --every 1 -j SNAT --to

The IPs described in the example should be local IPs.

Post to Twitter


There are a lot of people that don’t understand how to configure /etc/hosts. There are services that complains about that, for example: Zimbra, Apache, Squid, etc. The right syntax of every entry in /etc/hosts file MUST be:

For example: myserver

If you write that wrong, there are some functions of libc that don’t work properly because they are expecting “ “.

To be sure that you /etc/hosts is right, run hostname -f and hostname. They should return the FQDN and the hostname respectively.

One last thing. The hostname of your server is the short name, not the FQDN!

Post to Twitter

Zimbra archiving with compression, the numbers

Today I calculated the space saved in one of the stores thanks to archiving+compression in one of the Zimbra servers that I’ve installed more than one ayer ago. The archiving volume has 273GB of email that uses 159GB of disk after compression. That’s 42% of saving.

I’m using a script to archive mails in the Open Source Edition that I’ve developed last year, running without any problems for more that 12 months.

It’s in my toolbox:

Post to Twitter

cron, /etc/timezone and Debian

Today I had a problem with cron. One of that typical situation where a cron job doesn’t run and you don’t know the reason. If I ran the cron daemon from the command line, the cron job was executed. If I ran the daemon from the init script, nothing. Debugging the problem I executed the init script with “bash -x” where I saw that the script set the variable TZ with the content of /etc/timezone. This file had a different timezone from /etc/locatime link. The problem was that the job was working, but at different time. Cron has been a source of headaches…

Conclusion, if you have a problem with check, check /etc/localtime and /etc/timezone. They should point to the same timezone.

Post to Twitter

Synchronizing files with Csync2

When you have to synchronize configuration files between servers you always think in Ssh/Rsync at first. Then you remember that you need to enable login to some account and some security issues appears. You are giving full shell access and you only need copy and execution and nothing else. If you have root login disabled you’ll have problem with permissions too.

I always desired an application that only synchronizes files and executes some action after the copy until I found Csync2. This application is a simple tool to copy configuration files (and other types of files) and do something after that (usually reload the config.). It doesn’t require a shell account because it runs as service. The configuration of Csync2 is simple: a list of hosts, a list of files and a list of actions to execute if it detects a change in a file. Let’s start the configuration.

The following steps must be executed in all servers.

First, you need the configuration file, /etc/csync2.cfg:

group cluster1 {

        host server1;
        host (server2);
        host (server3);

        include /etc/resolv.conf;
        include /etc/apache2/;
        exclude /etc/apach2/ports.conf;

        action {
                pattern /etc/apache2;
                exec "/etc/init.d/apache2 restart";
                logfile "/var/log/csync2/apache-restart.log";

Looks easy, right? I’ll explain it anway:

  • host: Each line defines the members of the syncronization group. The hosts with parenthesis are slaves, they only receive files from the member with parenthesis. I usually have all the servers as slaves except one. I prefer to have only one point where you modify the configuration.
  • include: This lines list the files to sync.
  • exclude: If you are synchronizing directories, sometimes you need to exclude some files inside them.
  • action: This section defines a command to execute if a file matching the pattern changes. You can set a file to save the output of the command and do-local tells Csync2 to execute the action in the host where you are going to dispatch the sync.

This file must be in all the servers.

In the second step, you have to create the X.509 certificates to use SSL. Csync2 doesn’t use X.509 authentication, it only requires the certificates to enable a secure communication. This should be in the developer’s TODO list. So, don’t worry about creating good certs, the following commands are enough:
# openssl genrsa -out /etc/csync2_ssl_key.pem 1024 # yes '' | openssl req -new -key /etc/csync2_ssl_key.pem -out /etc/csync2_ssl_cert.csr # openssl x509 -req -days 600 -in /etc/csync2_ssl_cert.csr -signkey /etc/csync2_ssl_key.pem -out /etc/csync2_ssl_cert.pem

The third and last step of configuration is to create the authentication key. This key must be the same in all servers. It’s created with the following command:
csync2 -k /etc/csync2.key
At this point, you are ready to sync files:
csync -xr
You have to execute that command in the server without parenthesis in the csync2.cfg. As I said before, I prefer to have one master server where I make the configuration changes.
If you have problems, Csync2 is not very verbose by default. There are two things that you can do. You can execute “csync2 -xr” with -vvv and you should see something useful. If not, you can execute the service in the failing server in foreground. First, stop inetd (Csync2 runs under Inetd by default in Debian/Ubuntu) and then execute “csync2 -ii -vvv”. Now try the sync. again.

Post to Twitter

Crypt, 8 bytes, password policy y LDAP

Hoy estaba probando en un cliente el módulo de ppolicy de OpenLDAP. Su función es agregar políticas de password como bloqueo de cuentas por ingreso de contraseña inválido, caducidad de claves, forzar complejidad de claves en el cambio de las mismas, etc. Haciendo las pruebas cree un usuario “diegows” con password “lanux123” y empezó a loguearme con la clave “lanux1234” para ver si la cuenta se bloqueaba. Supuestamente se tenía que bloquear a los 3 intentos y yo iba por 20 y nada. Es más, me el login (bind en lenguaje LDAP) funcionaba perfecto.

Luego de revisar la configuración 20 veces, me doy cuenta de un detalle, algo que ya me había pasado hace un tiempo. Las claves estaban guardadas en el LDAP cifradas con Crypt. Ésta algoritmo usa solamente los 8 primeros caractéres para encriptar la clave. Intentar loguearme con “lanux123” era lo mismo que loguearme usando “lanux1234567890”.

La moraleja es: no usar nunca CRYPT!!!! Además de ser inseguro, te hace perder el tiempo.

Si le pasa, ya saben…

Post to Twitter

SMTP y TLS: cifrado y autenticación del servidor y del cliente


Este artículo describe como usar SMTP y TLS para cifrar la comunicación entre el cliente y el servidor, incluyendo la autenticación de ambas partes. La ides es que el servidor nos autentique como usuarios validos usando certificados x509.

Configuración en el servidor (Postfix)

smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_tls_ask_ccert = yes
smtpd_tls_loglevel = 1

smtpd_recipient_restrictions =

relay_clientcerts = hash:/etc/postfix/relay_clientcerts

Este es un fragmento con los parámetros de configuración que se agregaron al de Postfix. A continuación la explicacion:

  • tls-cert.pem y tls-key.pem son las claves publica y privada del SMTP servidor.
  • cacert.pem es la clave publica de la CA.
  • El certificado, la clave privada y el certificado de la CA se crearon con el script que viene con openssl:
    1. Agregue -extensions v3_ca a la linea
      $CA -out ${CATOP}/$CACERT $CADAYS -extensions v3_ca -batch
    2. ./ -newca

      pide la passphrase y otros parámetros necesarios para el certificado.

    3. Edite el y le agregue -nodes a la línea:
      $REQ -new -keyout newkey.pem -out newreq.pem $DAYS
    4. ./ -newreq

      para crear el request del certificado para el postfix.

    5. ./ -sign

      para firmar el request.

    6. cp newcert.pem /etc/postfix/tls-cert.pem
      cp newreq.pem /etc/postfix/tls-key.pem
    7. Pongan los permisos de tls-key.pem a 600 por seguridad.

Y listo!

Configuración de un cliente (msmtp)

Como uso Mutt+msmtp para enviar correo configure el segundo para que se valide con Postfix usando los certificados x509.

  1. Cree el certificado del lado cliente de la misma forma que lo hice del lado servidor (ver sección anterior, ./ -newreq y ./ -sign).
  2. Copie elnewcert.pem y newkey.pem como postfix-cert.pem y postfix-key.pem respectivamente al ~/.ssl/ de mi desktop.
  3. Luego configure el ~/.msmtprc con los siguientes datos:
    account example
    tls on
    tls_starttls on
    tls_certcheck off
    tls_key_file ~/.ssl/postfix-key.pem
    tls_cert_file ~/.ssl/postfix-cert.pem
    tls_trust_file ~/.ssl/cacert.pem
    account default: example

Y eso seria todo…

Post to Twitter