amperis, un blog de un informático

etiquetando cintas lto

2011-12-19T17:28:00.000+01:00

Como siempre al comprar nuevas cintas LTO para nuestro robot IBM nos dejamos por pedir las pegatinas de códigos de barra. Pues bien, hemos encontrado esta utilidad para hacerse uno mismo las pegatinas según la numeración que queramos e imprimir directamente en tú impresora en cualquier tipo de papel.

http://tapelabels.librelogiciel.com/

Más informacion:
+ Especificaciones IBM LTO Labels

scp entre maquina unix y windows

2011-12-12T18:06:00.000+01:00

Utilizo mucho los comandos de rsync y/o scp para hacer backups del contenido de servidores Linux/Unix a mi servidor de backup.
Para el caso de maquinas con Windows utilizado la implementación de Winscp y programo los comandos necesarios para hacer esta tarea de forma automática. Por ejemplo, tengo un servidor Windows que cada día genera un Dump de una base de datos. Cada noche tengo copiar este Dump por scp desde la maquina Windows a una maquina Unix.

Para ello creo el siguiente archivo de comandos donde 192.168.34.5 es el servidor Unix de destino y bbdd-backup-full-diaria.bkf es el archivo que quiero transferir:

# contenido de comandos-backup.txt
option batch on
open root:microntraseña1234@192.168.34.5
cd /rsync/backups/servidorbbdd
option transfer binary
put c:\backups\bbdd-backup-full-diaria.bkf
close
exit

Ahora solo queda llamar al Winscp pasándole por linea de comandos las instrucciones que debe ejecutar. Si esto funciona bien podemos poner este comando dentrode una tarea programada de Windows.:

C:\ARCHIV~1\WinSCP\WinSCP.exe /console /script=c:\backups\comandos-backup.txt

calculando la velocidad de mi cabina de disco

2011-12-07T20:47:00.001+01:00

Tengo varias cabinas de disco IBM en diferentes entornos de virtualización vmWare. Una cabina en Fibre Channel y otra en iSCSI. El problema es que aparentemente la iSCSI no está dando la velocidad que tendría que dar. Una manera rápida de verificar la velocidad es detener todas las maquinas virtuales que tengamos (para no tener accesos a discos) y desde cada uno de los nodos ESX hacer una prueba de velocidad sobre los datastores de la cabina (/vmfs/volums). Para ser puristas hay que hacer la prueba por cada nodo y por cada LUN de la cabina.

Para ello utilizamos el comando "dd" y lanzamos una escritura de 1Gb y calculamos el tiempo de escritura:

[root@esx01 ~]# dd if=/dev/zero of=/vmfs/volums/VMS01/test.dump bs=8k count=128k
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB) copied, 3.59712 seconds, 299 MB/s

En este caso el resultado es de 299Mb/s en una cabina Fibre Channel con unas 40 maquinas virtuales funcionando en ese momento.

Otro comando que podemos utilizar es un hdparm.

la ferrata de IT

2011-11-17T16:12:00.007+01:00

que hacer para que nadie entre en el dominio

2011-07-20T21:25:00.002+02:00

Antes de migrar un Samba 3.3 a una versión 3.4/3.5 hay que tener bien claro que parámetros cambian de una versión a otra. Parámetros que creíamos por default al cambiar de versión ya no lo son.

Esto me ha pasado al migrar de la 3.3 a la 3.4 con el efecto que nadie podía logearse en el sistema. En la versión 3.3 el parámetros “passdb backend = smbpasswd” pasa a ser por defecto “passdb backend = tdbsam”. Dado que son valores por defecto es muy complicado encontrar cual es problema ya que no se produce ningún error en el Samba (salvo un Access denied).

Para obtener todos los parámetros ya sean escritos en tú smb.conf como por defecto es dicha versión podemos hacer un: testpam –v –s > smb33.conf.bak Luego podemos comparar la versión de nuestra smb.conf cuando estaba en versión 3.3 con el smb.conf al migrar a la 3.4.

Más información:
+ http://lists.samba.org/archive/samba/2010-May/156135.html
+ http://samba.2283325.n4.nabble.com/problems-after-upgrade-from-3-3-2-to-3-4-0-td2440950.html

validar usuario y contraseña en una linea

2011-07-16T17:04:00.012+02:00

Estoy creando un script PHP para cambiar la contraseña de un usuario creado en un sistema Linux. Previamente a cambiarla debe poner su anterior contraseña y para ello necesito validar un usuario y su contraseña. Es decir, necesito saber si un nombre de usuario y contraseña son válidos. Para ello básicamente cifro la contraseña del usuario y la comparo con el /etc/shadow de mi sistema Linux.

#!/bin/bash

# por Alejandro Moreno (Kernpharma) - julio 2011
# Utilizar en "--method=" el metodo de cifrado deseado (SHA-512, MD5, etc)
# Instalar la utilidad mkpasswd (http://pkgs.org/ubuntu-10.04/ubuntu-universe-i386/mkpasswd_5.0.0ubuntu3_i386.deb.html)

if test $# -lt 2 ;
then
   echo "Error de parametros."
   echo
   echo "Sintaxis:"
   echo "   # ./validatepwd.sh <username> <password>"
   exit 3
fi

username=$1
password=$2

contrl=`cat /etc/passwd | grep $username`

if [ "$contrl" != "" ]
then

   encrypt=`cat /etc/shadow | grep $username | cut -d: -f2 | cut -d$ -f 2`
   salt=`cat /etc/shadow | grep $username | cut -d: -f2 | cut -d$ -f 3`
   contrl=`mkpasswd --method=SHA-512 $password --salt=$salt`

   if [ "$contrl" = "`cat /etc/shadow | grep $username | cut -d: -f2`" ]
   then
      echo "Validacion OK."
      RETVAL=0
   else
      echo "ERROR de validacion."
      RETVAL=1
   fi
else
   RETVAL=2
fi

exit $RETVAL

cuando se cae todo, buena cara

2011-06-12T20:20:00.000+02:00

nagios gadget para windows 7

2011-05-13T22:57:00.013+02:00

El siguiente gadget para Windows permite monitorizar tus servidores y avisarte de las caidas. Ataca directamente a la URL de tú Nagios: http://servidor/nagios/cgi-bin/nagxmlstatus.cgi.

Para ello deberás copiar el siguiente script nagxmlstatus.cgi en tú carpeta de /opt/local/nagios/sbin (o donde apunte tú cgi-bin). Hay que darle permisos de ejecución e instalar los requisitos y librerias necesarias para ejecutar este script en Pearl:

# apt-get install libxml2 libxml2-dev
# perl -MCPAN -e "install XML::LibXML"
# perl -MCPAN -e "install CGI"

Finalmete podrás instalarte el gadget en todas las maquinas Windows que quieras.

Más información:
+ Nagstatus gadget 1.5.3
+ nagxmlstatus.cgi

agente nagios para linux

2011-04-29T21:41:00.007+02:00

Si tenemos Nagios, podemos monitorizar maquinas remotas utilizando el agente de Nagios para Linux o para Windows.
Si la maquina remota es un Windows, podemos instalar el NSClient++. Si la maquina es un Linux, podemos instalar el NRPE. Explicaré cómo se instala el NRPE y cómo se configura Nagios para hacer consultas a esta maquina remota.

Tenemos que tener presente dos tipos de maquinas: la maquina con Nagios Server (por ejemplo 192.168.1.2) y la maquina remota (por ejemplo 192.168.1.3). El funcionamiento es el siguiente: en los dos extremos hay que instalar un NRPE de forma que el daemon de la maquina remota ejecutará los comandos que nosotros definamos, por ejemplo check_disck, check_swap, check_users, check_oracle, etc.

En la maquina remota hacemos:

# wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz
# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz

# useradd nagios
# passwd nagios

Nota: recomiendo editar el /etc/passwd y ponerle un Shell /bin/false a este usuario para que no pueda hacer Login en el sistema.

# tar -xzvf nagios-plugins-1.4.15.tar.gz
# cd nagios-plugins-1.4.15
# export LDFLAGS=-ldl
# ./configure --with-nagios-user=nagios --with-nagios-group=nagios
# make
# make install 
# chown nagios.nagios /usr/local/nagios
# chown -R nagios.nagios /usr/local/nagios/libexec/

# apt-get install xinetd libssl-dev
# tar xvfz nrpe-2.12.tar.gz
# cd nrpe-2.12

# ./configure
# make all
# make install-plugin
# make install-daemon
# make install-daemon-config
# make install-xinetd

Editar /etc/xinetd.d/nrpe para aceptar peticiones solo de nuestro Nagios Server:

only_from       = 127.0.0.1 192.168.1.2

La IP 192.168.1.2 es la de nuestra maquina Nagios Server.

# /etc/init.d/xinetd restart

Pruebas de funcionamiento:

# netstat -ant | grep 5666
tcp        0      0 0.0.0.0:5666            0.0.0.0:*               LISTEN  
# /usr/local/nagios/libexec/check_nrpe -H localhost
NRPE V2.12

Modificar los comandos disponibles para nuestra maquina remota. Editar el /usr/local/nagios/etc/nrpe.cfg y modificar los comandos a nuestro gusto. Yo he creado una consulta llamada check_disk que me dirá el estado de disco /dev/sda1:

command[check_disk]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/sda1

En la maquina Nagios Server hacemos:

# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz
# apt-get install libssl-dev
# cd nrpe-2.1.2
# ./configure
# make all
# make install-plugin

Prueba de funcionamiento:

# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.3
NRPE V2.12
# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.3 -c check_disk
DISK OK - free space: / 33010 MB (96% inode=97%);| /=1126MB;28771;32367;0;35964

Ahora solo queda configurar nuestro Nagios Server para que utilice el comando check_nrpe:

define service{
   use generic-service
   host_name remotehost
   service_description Current Users
   check_command check_nrpe!check_disk
}

Más informacion:
+ http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf

caida ldap

2011-04-13T14:41:00.007+02:00

Hoy se ha ido la luz y nos ha echado abajo el servidor de Samba. Como consecuencia al reiniciar el servidor se ha quedado corrupto el LDAP con el siguiente error:

[root@fileserver]# /etc/init.d/ldap start
Checking configuration files for slapd: bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.
bdb_db_open: Database cannot be opened, err 13. Restore from backup!
bdb(dc=XXXXXX,dc=com): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
backend_startup_one: bi_db_open failed! (13)
slap_startup failed (test would succeed using the -u switch)
[FAILED]
stale lock files may be present in /var/lib/ldap [WARNING]

Antes de restaurar el backup hemos probado un: http://www.blogger.com/img/blank.gif

[root@fileserver]# /usr/sbin/slapd_db_recover -v -h /var/lib/ldap
Finding last valid log LSN: file: 1 offset 5315883
Recovery starting from [1][5315755]
Recovery complete at Sun Jul 30 11:31:56 2006
Maximum transaction ID 8000040d Recovery checkpoint [1][5315883]

Para restauraciones más críticas podemos hacer un backup en texto de tú arbol LDAP, corregir los errores y volver a recrear el arbol de LDAP. En este post hay un buen ejemplo: http://blog.mydream.com.hk/howto/linux/openldap-recovery-howto

envolviendo el vsftp

2011-04-04T22:38:00.011+02:00

Al intentar poner un servicio público en Internet, te das cuenta de la cantidad de intentos de acceso que hay al cabo de un día. Al final, te queda la duda de si pueden o no llevar buen puerto.
Si eres de esos de que leen los Logs cada día o de lo que reciben su Logwatch oportuno, te darás cuenta de estos intentos:

--------------------- pam_unix Begin ------------------------ 
 vsftpd:
    Unknown Entries:
       check pass; user unknown: 168 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=administrator rhost=thirdeyemedia.net : 82 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=administrador rhost=thirdeyemedia.net : 59 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=anonymous rhost=host217-40-235-141.in-addr.btopenworld.com : 17 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=113.107.101.249 : 168 Time(s)
       check pass; user unknown: 168 Time(s)

Para bannear estas IPs, lo puedes realizar de dos formas diferentes: o las cierras directamente en tú firewall perimetral, o lo cierras en el firewall del propio servidor o lo cierras con tcpwrappers.

El concepto de tcpwrappers consiste en envolver tú daemon TCP/UDP en un envoltorio el cual analiza el paquete de red antes de enviárselo a tú daemon. Tcpwrapper permite controlar los accesos a los servicios ofrecidos por el sistema ya sea por máquina, por servicio o por combinaciones de ambos. Para ello el daemon de tcpwrapper llamado “tcpd” lee los archivos de configuración /etc/hosts.allow y /etc/hosts.deny. El primer archivo contie las reglas que especifican las máquinas y servicios que están autorizados y el segundo las maquinas y servicios que no están autorizados.
Personalmente me gusta este sistema porque es posible denegar estas conexiones por un administrador que no tiene acceso a su Firewall porque este está administrador por otro conjunto de personas y además no es necesario rebotar nigún servicio.

En este ejemplo real vamos a denegar los accesos de 113.107.101.249, 217.40.235.141 y 64.40.107.210, que corresponden a diferentes ataque al servicio FTP. Primero de todo verificaremos que el servicio de FTP está compilidado para poder utilizar TCPWrappers:

# whereis vsftpd
vsftpd: /usr/sbin/vsftpd /etc/vsftpd /usr/share/man/man8/vsftpd.8.gz
# ldd /usr/sbin/vsftpd | grep libwrap
        libwrap.so.0 => /lib/libwrap.so.0 (0x0046c000)

Una vez vemos que la librería está cargada, podemos editar el /etc/hosts.deny y meter todas las IP necesarias:

vsftpd: 113.107.101.249, 217.40.235.141, 64.40.107.210

Podemos bloquear también por rangos o por subredes:

vsftpd: 113.107.101.0/255.255.255.0

Podemos denegar todos los accessos a cualquier servicio:

ALL: 113.107.101.0/255.255.255.0

O incluso podemos dejar un mensajito:

vsftpd : .elhacker.net \
: twist /bin/echo "421 %h has been banned from this server!"

Si queremos ver todos los servicios TCP que están compilados para utilizar TCPWrappers, podemos hacer:

# strings -f /usr/sbin/* | grep hosts_access
/usr/sbin/rpc.mountd: hosts_access
/usr/sbin/sshd: hosts_access
/usr/sbin/stunnel: hosts_access
/usr/sbin/stunnel: See hosts_access(5) manual for details
/usr/sbin/tcpd: hosts_access_verbose
/usr/sbin/vsftpd: hosts_access

Más información:
+ http://linux.web.cern.ch/linux/scientific4/docs/rhel-rg-en-4/s1-tcpwrappers-access.html

migrando a mpls

2010-12-07T18:25:00.002+01:00

cuantas visitas tendre

2010-11-27T20:11:00.010+01:00

Acabo de leer un artículo muy interesante sobre las tendencias de las personas al hacer click sobre los resultados aparecidos en Google al realizar una búsqueda.

La Universidad de Cornell ha realizado un estudio llamado "Eye-Tracking Analysis of User Behavior in WWW Search" en el cual se concluye que si tú pagina aparece en la primera posición del buscador tendrás un 56% de posibilidades que finalmente esa persona clique sobre tú Web. Para cualquier SEO este estudio puede ser muy interesante porque le puede ayudar a que un cliente comprenda cuantas visitas puede llegar a recibir si se encuentra bien situado en las búsquedas de Google.

En la siguiente imagen se muestra cómo mira el ojo humano la pagina de Google tras realizar un búsqueda:

La siguiente muestra el % de clicks que se llevaría una pagina si el usuario escogiera esa opción.

Pongamos un ejemplo. Supongamos que mi pagina Web es www.amperisblog.com y que he escrito un articulo que explica cómo bloquear el programa Ultrasurf. Supongamos también que con mi estudio de SEO y con varios meses de trabajo he conseguido posicionar mi página para que aparezca en las primeras posiciones cuando la gente realiza la busqueda “bloquear ultrasurf”. Cómo veis mí pagina aparece en tercera opción (aun me queda un duro trabajo de SEO para posicionarme más arriba).

Ahora veamos desde la utilidad Google Adwords (Herramientas para palabras clave) que la busqueda “bloquear ultrasurf” se realiza 2.400 veces al mes en todo el mundo.

Por tanto: (2400 * 9,82) / 100 = 235 visitas.

Es decir, que cada mes mí página recibirá (aproximadamente) 235 visitas por aparecer en la tercera opción.

Ahora supongamos que soy el dueño de la Web www.softonic.com (creo nadie la cononoce ¿no?). Supongamos que con mi estudio de SEO me he podido posicionar en primera opción cuando alguien busca “descargar software gratis”.
Si miramos en Google Adword, vemos que esta búsqueda se hace un millón de veces al mes.

Por tanto: (1000000 * 56,36) / 100 = 563600 visitas.

Cada mes, Softonic recibe una media de 560.000 visitas cuando la gente busca el termino “descargar software gratis”.

atenuación y ruido

2010-10-31T19:44:00.010+01:00

Cuando nos instalan una ADSL, SDSL o una ADSL2+ los valores de atenuación y ruido son los que nos marcan la velocidad final de esta.
La mayoría de routers tienen acceso a la consulta de estos dos valores. Cuando un técnico nos coloca una xDSL lo primero que mira son estos valores y nos dice: "uff estás un poco lejos de la central y no te daremos la velocidad que has contratado". Naturalmente el router muestra valores aproximados de la atenuación y ruido ya que no son dispositivos pensados para este fin. Existen dispositivos específicos de telecomunicaciones que inyectan señales sinusoidales a diferentes frecuencias y potencias para medir la atenuación final del cable.

La atenuación es la pérdida de señal sufrida al trasmitirse esta por el cable. Características como la distancia del cable (por ejemplo el bucle del abonado), resistencia del cable, tipo de cable, empalmes, vejez del cable, etc, hacen que tengamos una mayor o menor atenuación. La atenuación la encontraremos medida en decibelios (dB). Contra más grande es esta medida peor será nuestra velocidad final.

Tenemos que tener presente también que al pasar de ADSL a ADSL2+ sufriremos mayor atenuación debido a que ADSL funciona a 0,5Mhz y ADSL2+ a 4,4Mhz.
Este aumento de la frecuencia de la señal provoca un aumento de la impedancia del cable y por tanto una mayor resistencia de este.

Los valores óptimos de atenuación según la velocidad que hayamos contratado con el proveedor son:

+ Para 256kbps: 64dB
+ Para 512kbps: 55dB
+ Para 1Mbps (ADSL): 41dB
+ Para 6Mbps (ADSL): 30dB
+ Para 20Mbps (ADSL2+): 20dB

El caso del ruido serán todas las señales externas que perturben nuestra señal útil de la xDSL. Por la propia naturaleza del ruido, este será imposible eliminarlo, pero si podemos reducirlo haciendo una buena instalación. Lo que miden los routers no es exactamente el ruido sino la relación/margen entre la señal y el ruido. El SNR o Signal to noise ratio es el margen que hay entre la potencia de la señal que se quiere transmitir y la potencia del ruido que corrompe nuestra señal. Este margen también se mide en dB y contra más grande mejor para nuestra xDSL.

Los valores óptimos de SNR según la velocidad que hayamos contratado con el proveedor son:

+ 6dB o menos: conexión inexistente
+ Entre 7db y 10 dB: conexión y desconexiones u otros problemas
+ Entre 11 y 20 dB: Señal optima
+ 21 o más dB: Señal excelente

En el caso de un router Cisco, podemos utiliza el comando "show dsl interface atm" para consultar estos valores.

A continuación un ejemplo real de una ADSL2+ de 20Mbps (que no llega, se quedaría en unos 15Mbps).

monitorizando tu bes

2010-08-01T17:47:00.008+02:00

La "Blackberry Enterprise Sever Resource Kit" son unas utilidades que nos pueden permitir leer de forma más clara los ficheros de Logs que genera el BES. Explicaré algunas utilidades que estoy utilizando últimamente y que pueden hacer la vida más fácil a quien no esté familiarizado con la administración de un BES.

Para instalar el Resource Kit basta con descargarlo de Downloads y descomprimirlo en la propia carpeta de instalación de BES. Como veréis es un fichero comprimido y en cada carpeta hay una tool diferente. También hay que tener claro donde se están almacenando los Logs del BES. Para este post supondremos que están guardados en "c:\bes\logs\20100801" y que estoy utilizando un BES 4 para Lotus Domino.

+ Controlar el estado de activación de un smartphone: Lo que más hago con el BES es dar de alta smartphones. Para ello lo mando por mensajero y es el propio usuario que la activa. Para controlar el proceso de activación tenemos la utilidad eastatus. Para controlar el estado de activación del usuario "Alejandro Moreno" haremos lo siguiente:

> EASTatus -l "C:\bes\logs\20100801" -p D -u "Alejandro Moreno/It/miempresa"

Como resultado obtendremos un fichero de texto .csv con el siguiente contenido:

Server,User,Step,Step Info,Time
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step01,AGENT- Enterprise Activation message has been picked up by the BlackBerry Enterprise Server,22:24:12
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step02,AGENT- Encryption Key is being generated,22:24:12
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step03,AGENT- Sending Service Book request to the Policy Server,22:24:14
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step04,POLICY- Policy Server sent the IT Policy to the BlackBerry device,22:24:16
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step05,POLICY- IT Policy was successfully delivered to the BlackBerry device,22:24:28
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step06,POLICY- Policy Server sent the Service Books to the BlackBerry device,22:24:28
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step08,AGENT- The BlackBerry device should be active and able to send and receive messages,22:24:30
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step08,AGENT- The BlackBerry device should be active and able to send and receive messages,22:24:30
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step10,SYNC- The Slow-Sync Process has been initiated by the BlackBerry device,22:25:00
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step11,SYNC- The Slow-Sync Process has completed and the enterprise activation should be complete,22:35:38

+ Ver los mensajes que han pasado por el BES: esta tools es útil si detectamos que el BES parece que no está enviado o recibiendo mensajes.

> messageflow -l "C:\bes\logs\20100801" -p D -u all

Observar las columnas "Posted" que indica la fecha en que el mensaje fue depositado en el buzón del usuario y la "Satus time" que indica la fecha en la que ese mensaje se fue mandado al smartphone del usuario.

+ Ver los mensajes pendientes de enviar: esta es otra manera de ver que algo no está funcionando bien. Si tenemos muchos mensajes en la cola de pendientes de enviar es o porque nos hemos quedado sin conectividad con los servidores de RIM o porque tenemos muchos usuarios que no tienen cobertura en sus smartphones (o las tienen apagadas).

> pending -l "C:\bes\logs\20100801" -p D -u all

certificados caducados en openvpn

2010-06-27T14:04:00.003+02:00

Cuando tienes más de 100 usuarios que pueden entrar por VPN a tú empresa es difícil controlar cuando les caducan sus certificados. El siguiente script muestra todos los certificados que caducan este año. Ahora ya puedes decidir si quieres renovarle o no el certificado al usuario.

#/bin/bash

list=`ls /etc/openvpn/keys/*.crt`
actual=`date '+%Y'`

list () {
   for i in $list ; do
      fecha=`cat $i | grep After`
      fecha="${fecha/Not After :/}"
      fecha="${fecha/GMT/}"
      if [ "$1" != full ]; then
        if [ "$fecha" != "${fecha/$actual/}" ]; then
            echo $i : $fecha
         fi
      else
         echo $i : $fecha
      fi
   done

}

ayuda () {
   echo "listcert v0.1b, por amperis"
   echo
   echo "Uso: listcert [opcion]"
   echo
   echo "-f, --full    Lista la fecha de todos los certificados"
   echo "-e, --expire  Lista los certificados que caducan este año"
   echo "--help        Muestra esta misma ayuda"
   echo
}

case $1 in
   -f | --full)
      list full
      ;;

   -e | --expire)
      list expire
      ;;
   *)
      ayuda
      ;;
esac

Ahora puede programar un cron para que te envie un report cada mes:

root@vpn:~# crontab -l
@monthly /etc/openvpn/keys/listcerts.sh -e | mail -s "Usuarios VPN que caducan proximamente" sysadmin@miempresa.com

test de velocidad entre dos puntos de red (for linux)

2010-06-25T11:35:00.002+02:00

Hace ya un tiempo escribí como calcular la velocidad de red entre dos puntos con una aplicación para Windows. Ahora le toca el turno al mismo concepto, pero con una aplicación para Linux. Esta aplicación es: el neterf.

Funciona exactamente igual que el anterior. Tenemos arrancado esta tool en modo server desde el punto A y desde otro punto B lo lanzamos como cliente.

Veamos como lo lanzamos en modo servidor desde A:

[root@A]# apt-get install iperf
...
[root@A]# iperf -s -f K
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.26.2 port 5001 connected with 192.168.1.191 port 60697
[  4]  0.0-180.4 sec  35400 KBytes    196 KBytes/sec

Observar que quiero el formado de salida en KBytes/sec.

Ahora lanzamos el cliente desde un punto B remoto:

[root@B]# apt-get install iperf
...
[root@B]# iperf -c 192.168.26.2 -f K -t 180
------------------------------------------------------------
Client connecting to 192.168.26.2, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.191 port 60697 connected with 192.168.26.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-180.4 sec  35400 KBytes    196 KBytes/sec

Ver como le indicamos la dirección IP donde se encuentra nuestro servidor, el formato del resultado en KBytes/sec y por ultimo queremos una prueba que dure 180 segundos. Es importante controlar correctamente el tiempo de la prueba, ya que una prueba más larga obtendrá un valor más real.

Este comando lo estoy utilizando para realizar un cambio de operador. Tomo las medidas con el operador antiguo y luego con el nuevo operador. Una vez migrado al nuevo operador veremos cuanto hemos mejorado en las comunicaciones.

Más información:
+ Welcome to the Neterf homepage

tomando temperatura al cpd

2010-06-23T23:58:00.008+02:00

IPMI (Intelligent Platform Management Interface) es una especificación de Intel para el monitoreo a nivel físico de un hardware. Fue impulsado por Dell, HP, Intel y NEC. Sus especificaciones y funcionamiento son independientes del sistema operativo y hardware de la maquina. Nos permite controlar valores como la temperatura de diferentes componentes del servidor, velocidad de los ventiladores, apertura del chasis, voltajes, etc.

El firmware del IPMI se encuentra en la propia placa madre y es totalmente independiente del SO, por tanto es posible monitorizar la maquina aún cuando su sistema operativo está colgado. Dado que se trata de una interfaz para monitorizar podemos utilizar herramientas como clientes SNMP, Nagios o OpenView.

Vamos a describir cómo utilizar un servidor DELL para controlar la temperatura del CPD y enviar un mail en caso de que la temperatura salga de lo habitual.

Primero de todo instalaremos las tools de IPMI. En mi servidor con RedHat es el paquete:

# rpm -q -a | grep IPMI
OpenIPMI-tools-1.4.14-1.4E.13

Una vez rebotado el sistema deberíamos tener arrancados los siguientes módulos en el Kernel. Si no los tenemos arrancados no podremos acceder a la interfaz de IPMI.

# lsmod | grep ipmi
ipmi_devintf           13064  2 
ipmi_si                36648  1 
ipmi_msghandler        31720  2 ipmi_devintf,ipmi_si

También deberíamos tener un dispositivo llamado ipmidev:

# cat /proc/devices | grep ipmi  
252 ipmidev

Consultemos ahora todos los valores que podemos leer con IPDMI:

# ipmitool -I open sensor list
Temp             | 31.000     | degrees C  | ok    | na        | na        | na        | 85.000    | 90.000    | na        
Temp             | 50.000     | degrees C  | ok    | na        | na        | na        | 85.000    | 90.000    | na        
Temp             | 40.000     | degrees C  | ok    | 64.000    | na        | -128.000  | -128.000  | na        | na        
Temp             | 40.000     | degrees C  | ok    | 64.000    | na        | -128.000  | -128.000  | na        | na        
Ambient Temp     | 20.000     | degrees C  | nc    | na        | 3.000     | 8.000     | 20.000    | 47.000    | na        
CMOS Battery     | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na        
ROMB Battery     | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na        
VCORE            | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
VCORE            | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
CPU VTT          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
1.5V PG          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
1.8V PG          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
3.3V PG          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
5V PG            | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
Backplane PG     | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
Flexbay PG       | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
Linear PG        | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
0.9V PG          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
1.5V ESB2 PG     | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
0.9V Over Volt   | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
CPU Power Fault  | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
FAN 1 RPM        | 2475.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 2 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 3 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 4 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 5 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 6 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 7 RPM        | 4500.000   | RPM        | ok    | 14400.000 | na        | 0.000     | 0.000     | na        | na        
FAN 8 RPM        | 4500.000   | RPM        | ok    | 14400.000 | na        | 0.000     | 0.000     | na        | na        
Presence         | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
...      
Memory Mirrored  | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Memory RAID      | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Memory Added     | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Memory Removed   | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Memory Cfg Err   | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem Redun Gain   | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
PCIE Fatal Err   | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Chipset Err      | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Err Reg Pointer  | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem ECC Warning  | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem CRC Err      | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
USB Over-current | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
POST Err         | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Hdwr version err | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem Overtemp     | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem Fatal SB CRC | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem Fatal NB CRC | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
CPU Temp Interf  | na         | discrete   | na    | na        | na        | na        | na        | na        | na

Miremos ahora el log de problemas:

# ipmitool -I open sel list      
   1 | 10/16/2006 | 21:02:21 | Event Logging Disabled #0x72 | Log area reset/cleared | Asserted
   2 | Pre-Init Time-stamp   | Power Supply #0x74 | Redundancy Lost
   3 | Pre-Init Time-stamp   | Power Supply #0x64 | Failure detected | Asserted
   4 | Pre-Init Time-stamp   | Power Supply #0x64 | Power Supply AC lost | Asserted
   5 | 06/09/2009 | 17:35:09 | Drive Slot #0x81 | Drive Present | Deasserted
   6 | 06/09/2009 | 17:37:54 | Drive Slot #0x81 | Drive Present | Asserted
   7 | 06/21/2010 | 15:16:47 | Temperature #0x08 | Upper Non-critical going high

Miremos ahora las alarmas:

# ipmitool -I open sdr list
Temp             | 32 degrees C      | ok
Temp             | 50 degrees C      | ok
Temp             | 40 degrees C      | ok
Temp             | 40 degrees C      | ok
Ambient Temp     | 20 degrees C      | nc
CMOS Battery     | 0x00              | ok
ROMB Battery     | 0x00              | ok
VCORE            | 0x01              | ok
VCORE            | Not Readable      | ns
CPU VTT          | 0x01              | ok
1.5V PG          | 0x01              | ok
1.8V PG          | 0x01              | ok
3.3V PG          | 0x01              | ok
5V PG            | 0x01              | ok
Backplane PG     | 0x01              | ok
Flexbay PG       | 0x01              | ok
Linear PG        | 0x01              | ok
0.9V PG          | 0x01              | ok
1.5V ESB2 PG     | 0x01              | ok
0.9V Over Volt   | 0x01              | ok
CPU Power Fault  | 0x01              | ok
FAN 1 RPM        | 2475 RPM          | ok
FAN 2 RPM        | 2475 RPM          | ok
FAN 3 RPM        | 2550 RPM          | ok
FAN 4 RPM        | 2550 RPM          | ok
FAN 5 RPM        | 2550 RPM          | ok
FAN 6 RPM        | 2550 RPM          | ok
FAN 7 RPM        | 4500 RPM          | ok
FAN 8 RPM        | 4500 RPM          | ok
Presence         | 0x01              | ok
Presence         | 0x02              | ok
Presence         | 0x01              | ok
Presence         | 0x01              | ok
Presence         | 0x01              | ok
PFault Fail Safe | Not Readable      | ns
Status           | 0x80              | ok
Status           | 0x00              | ok
Status           | 0x01              | ok
Status           | 0x01              | ok
RAC Status       | 0x00              | ok
OS Watchdog      | 0x00              | ok
SEL              | Not Readable      | ns
Intrusion        | 0x00              | ok
PS Redundancy    | 0x01              | ok
Fan Redundancy   | 0x01              | ok
Drive            | 0x01              | ok
Cable SAS A      | 0x01              | ok
Cable SAS B      | 0x01              | ok
Cable SAS FB     | Not Readable      | ns
Cable Power FB   | Not Readable      | ns
...
Mem ECC Warning  | Not Readable      | ns
Mem CRC Err      | Not Readable      | ns
USB Over-current | 0x01              | ok
POST Err         | Not Readable      | ns
Hdwr version err | 0x01              | ok
Mem Overtemp     | 0x01              | ok
Mem Fatal SB CRC | 0x01              | ok
Mem Fatal NB CRC | 0x01              | ok
CPU Temp Interf  | Not Readable      | ns

Una vez que sabemos de que van estos comandos podemos ver que el valor que nos interesa es el marcado por el sensor de temperatura llamado “Ambient Temp”. Este valor marca el valor de la temperatura fuera del servidor con un error de +-2Cº.

Si lanzamos el siguiente comando de shell obtendremos la temperatura ambiente:

# ipmitool sdr type Temperature | grep "Ambient Temp" |awk '{ print $10 }' | grep -v  "na" | sed 's/\..*//g' | head -n1

Ahora nos hacemos un script que lea la temperatura y la compare con un máximo. Si se supera ese máximo enviará un mail:

# cat /usr/share/ipmitool/control_temp.sh
#!/bin/bash

TEMPWARNING="31"
TEMPCRITICAL="35"
MAIL="sysadmin@miempresa.com"
LOG=/var/log/control_temp.log

TEMPERATURA=$(/usr/bin/ipmitool sdr type Temperature | grep "Ambient Temp" |awk '{ print $10 }' | grep -v  "na" | sed 's/\..*//g' | head -n1)

if [ -z "$TEMPERATURA"  ];
then
        echo UNKNOWN
        exit 3
fi

if   [ $TEMPERATURA -ge $TEMPCRITICAL ];
then
        echo `date` CRITICAL temperatura ${TEMPERATURA}C >> $LOG
        echo "CRITICAL temperatura ${TEMPERATURA}C" | mail -s "Temperatura CPD CRIT" ${MAIL}
        exit 2
elif [ $TEMPERATURA -ge $TEMPWARNING  ];
then
        echo `date` WARNING temperatura ${TEMPERATURA}C >> $LOG
        echo "WARNING temperatura ${TEMPERATURA}C" | mail -s "Temperatura CPD WARN" ${MAIL}
        exit 1
fi

echo `date` OK temperatura ${TEMPERATURA}C >> $LOG
exit 0

Finalmente programamos este script para que se ejecute cada 15 minutos y compruebe la temperatura:

# crontab -l
0,15,30,45 * * * * /usr/share/ipmitool/control_temp.sh > /dev/null 2>&1

Más información:
+ http://www.intel.com/design/servers/ipmi/
+ http://en.wikipedia.org/wiki/Power_usage_effectiveness

una vez conocí a richard stallman

2010-06-22T17:44:00.002+02:00

Libertad 0: Es “libertad” para ejecutar el programa con cualquier propósito.
Libertad 1: Es “libertad” para estudiar y modificar el programa.
Libertad 2: Es “libertad” de copiar el programa y ayudar con él a tu vecino.
Libertad 3: Es “libertad” de mejorar el programa, y hacer públicas tus mejoras, de forma que se beneficie toda la comunidad.

navegación autenticada con Squid

2010-06-07T21:15:00.012+02:00

El siguiente post muestra un ejemplo de cómo permitir que alguien pueda navegar por Internet solo si se ha autenticado. Es un ejemplo real donde todos los usuarios reciben una IP por DHCP (192.168.1.0/24) y los usuarios "invitados" reciben por DHCP una IP de un rango concreto (192.168.10.0/24).

Dado que todos los usuarios acceden a Internet vía Squid utilizaremos las opciones de autentificación (auth_parm) para logear a los usuarios. Primero de todo creamos un archivo con los usuarios y passwords de los invitados:

# touch /etc/squid/squid.users
# htpasswd /etc/squid/squid.users invitado1
# htpasswd /etc/squid/squid.users invitado2
...

Ahora editamos el archivo de configuración de Squid y configuramos los parámetros auth_parm:

auth_param basic children 3
auth_param basic realm Acceso a Internet restringido. Introduzca su usaurio y 
   contraseña...
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid.users
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

Esta es la descripción de los parámetros anteriores:

+ auth_parm basic children: numero de procesos/daemons que realizaran la autentificación. Dependerá un poco del número total de usuarios que puedan acceder a Internet en un momento dado.
+ auth_parm basic real: es el mensaje que saldrá en la ventana de login de tú navegado.
+ auth_parm basic program: definimos el sistema de autentificación y dónde debe buscar los usuarios. + auth_parm basic credentialsttl: especifica el tiempo que estará validado el usuario antes de volverle a pedirle el login.
+ auth_parm basic casesensitive: define si el nombre de usuario es case-sensitive.

Creamos ahora la ACL para decirle sobre que rango debe Squid pedir un login:

acl ip_invitados src 192.168.10.0/24
acl ip_lan src 192.168.1.0/24
acl auth_invitados proxy_auth REQUIRED
...
http_access allow ip_invitados auth_invitados
http_access allow ip_lan
http_access deny all

Básicamente lo que se necesita son dos listas de accesos. Una para definir las IPs que queremos logear (ip_invitados) y otra para definir el requisito de una autentificación (auth_invitados).

Existen varios métodos de autentificación cómo Basic, Digest, NTLM, Negotiate, cada uno de ellos pudiendo atacar contra un backend diferente: LDAP, MySQL, Radius, Active Direcotory, etc. Aquí hay algunos ejemplo con diferentes configuraciones.

wavecom wmod2a (parte ii de ii)

2010-05-23T17:14:00.005+02:00

Una vez tenemos las tools de Gammu funcionando es hora de montar nuestro gateway. El gateway tendrá un daemon que escuchará el módem y meterá los SMS en una BBDD. Para enviar utilizaremos el comando gammu tal como hemos visto en la primera parte del post.

Para facilitar las cosas utiizaremos una pagina Web escrita en PHP.

Instalamos Apache+MySQL+PHP:

# apt-get install apache2 php5 libapache2-mod-php5 
# apt-get install libapache2-mod-auth-mysql php5-mysql mysql-server mysql-client
# apt-get install libmysqlclient15-dev

Los mensajes SMS recibidos al módem SMS irán almacenados en una BBDD MySQL, para ello tendremos que crear un schema con las tablas necesarias para añadir esta info. Dentro de /usr/share/doc/gammu/examples/sql/mysql.sql.gz econtraremos un schema de tablas que podemos utilizar:

# cp /usr/share/doc/gammu/examples/sql/mysql.sql.gz /tmp
# gunzip /tmp/mysql.sql.gz
# mysqladmin -u root -p create sms
# mysql -u root -p sms < /tmp/mysql.sql

Ahora le decimos al Gammu que los mensajes recibidos los guarde en las tablas de MySQL. Para ello editamos la configuración y añadimos estos parámetros a los ya existentes:

# cat /etc/gammurc
...
[smsd]
#service = files
service = MYSQL
logfile = syslog
CheckSecurity = 0
debuglevel = 1
user = root
password = 12345
pc = localhost
database = sms
inboxpath = /var/spool/gammu/inbox/
outboxpath = /var/spool/gammu/outbox/
sentsmspath = /var/spool/gammu/sent/
errorsmspath = /var/spool/gammu/error/

Nota: Podemos utilizar diferentes tipos de backends. En la configuración anterior se puede utilizar MySQL o directamente ficheros planos alojados en /var/spool/gammu.

Para facilitar la lectura de estas tablas MySQL, hay creada una interfaz PHP que nos ayuda a leer los mensajes recibidos:

# cd /var/www
# wget http://www.syednetworks.com/gammu-sms-gateway.zip
# unzip gammu-sms-gateway.zip

Ahora podemos acceder a esta interfaz desde http://127.0.0.1/gammu-sms-gateway/sms.php. Para que el script sms.php acceda a vuestro MySQL deberéis cambiar la password de acceso a la base de datos por la que tengáis puesta:

Para ello editar el sms.php y cambiamos esta linea:

mysql_connect("localhost", "root", "") or die(mysql_error());

Instalamos y arrancamos el daemon que esperará la llegada de los SMSs:

# apt-get install gammu-smsd
# gammu-smsd -c /etc/gammurc &

Si enviamos un SMS a nuestro módem GSM y vamos mirando el log podremos ir viendo como van entrando los mensajes y cómo se van actualizado las tablas:

# tail -f /var/log/syslog
gammu-smsd[5813]: gammu: 3 "OK"
gammu-smsd[5813]: gammu: RECEIVED frametype 0x00/length 0x1B/27
gammu-smsd[5813]: gammu: 41A|54T|2B+|43C|53S|51Q|0D |0D |0A |2B+|43C|53S|51Q|
   3A:|20 |311 AT+CSQ...+CSQ: 1
gammu-smsd[5813]: gammu: 377|2C,|300|0D |0A |0D |0A |4FO|4BK|0D |0A 
   7,0....OK..     
gammu-smsd[5813]: gammu: Signal quality info received
gammu-smsd[5813]: gammu: Parsing +CSQ: 17,0 with +CSQ: @i, @i
gammu-smsd[5813]: gammu: Parsed int 17
gammu-smsd[5813]: gammu: Parsed int 0
gammu-smsd[5813]: gammu: Leaving GSM_GetSignalQuality
gammu-smsd[5813]: Execute SQL: UPDATE `phones` SET `TimeOut`= (NOW() + 
   INTERVAL 10 SECOND)+0, `Battery`= 0, `Signal`= 51 WHERE `IMEI` = 
   '330122330387360'

Por ultimo queda la parte del envío de SMS. Para ello, desde la pagina sms.php encontraremos un link llamado "Send SMS message" que nos permitirá enviar un SMS desde un formulario Web. Este link llama al archivo send-sms.php. Si lo editamos podremos ver como lo único que realiza es una llamada al binario de gammu:

system( 'sudo /usr/bin/gammu --sendsms EMS ' . escapeshellarg( $destination ) . 
' -text ' . escapeshellarg( $message ) );

Es posible que el path de nuestro binario gammu no corresponda con el de la pagina. Tendremos que cambiar /usr/logal/bin/gammu por /usr/bin/gammu.
Notar que también he añadido la ejecución del comando bajo sudo. Esto es debido a que el usuario que hace la llamada a la función system() es www-data y este usuario no tiene permisos para ejecutar comandos como gammu.

Para que el sudo no pregunte password tenemos que editar el /etc/sudoers y añadir esto:

# cat /etc/sudoers
...
%sudo ALL=NOPASSWD: ALL

Es posible que no tengáis permisos para escribir sobre el fichero de sudoers. Hay que poner permisos de escritura y luego dejarlos como estaba.

Finalmente tenemos que decirle quienes son los usuarios que están dentro de sudoers. Para ello editamos el /etc/groups y modificamos el grupo sudo:

# cat /etc/group | grep sudo
sudo:x:27:usuario1,www-data

wavecom wmod2a (parte i de ii)

2010-05-22T15:20:00.011+02:00

Vamos a montar un gateway para enviar y recibir mensajes SMS. La idea es montar este servicio para poder utilizarlo en Nagios y así poder enviar alertas vía SMS.

En verdad se puede realizar con cualquier teléfono móvil, pero esta vez utilizaré un hardware dedicado y especifico para ello un módem GSM Wavecom modelo wmod2a-g900.

El módem se comunicará con el servidor vía interfaz serie, pero como ya no quedan servidores con puerto de serie utilizaré un conversor USB-to-serial. Por tanto lo primero es ver que se detecta correctamente el conversor:

# dmesg | grep USB
[   77.187320] USB Serial support registered for generic
[   77.187348] usbserial: USB Serial Driver core
[   77.196733] USB Serial support registered for pl2303
[   77.208730] usb 6-2: pl2303 converter now attached to ttyUSB0
[   77.208746] pl2303: Prolific PL2303 USB to serial adaptor driver

Ahora instalaremos el soft básico para acceder al módem. Como todo modem, podríamos acceder a el vía comandos AT, pero tendríamos que leernos la documentación del dispositivo. Utilizaremos las herramientas gratuitas de Gammu:

# apt-get install gammu

Encontraremos un archivo de configuración de ejemplo en /usr/share/doc/gammu/examples/config/gammurc.gz. Nosotros crearemos uno con estos parámetros:

# cat /etc/gammurc
[gammu]
port = /dev/ttyUSB0
connection = at19200
name = wavecom
logformat = textall
logfile = gammu.log
startinfo = yes
use_locking = yes
gammuloc = locfile

Cómo puede verse el dispositivo /dev/ttyUSB0 indica la interfaz donde está conectada el módem GSM.

Una vez encendido el módem veamos si las tools de Gammu son capaces de reconocer el modem. Yo recomiendo quitarle el PIN a la tarjeta SIM para evitar problemas. De esta forma cada ver que reiniciemos el módem este estará listo para enviar SMS:

# gammu -c /etc/gammurc identify
Manufacturer         : Wavecom
Model                : unknown (900P)
Firmware             : 320_G250.53 833584 092499 18:13
IMEI                 : 330142330387360
SIM IMSI             : 214071617085412

Enviemos ahora nuestro primer SMS a otro teléfono y veamos que efectivamente está funcionando:

# echo hola | gammu -c /etc/gammurc sendsms TEXT 6938888888
If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..OK, message reference=115

Más información:
+ Wavecom AT Commands Guide

montando servidores para pequeñas oficinas

2010-04-18T20:15:00.008+02:00

Tenemos una pequeña oficina en Portugal donde varios de sus usuarios se conectan remotamente vía cliente software de VPN. Ahora que van a mejorar sus comunicaciones (creo que se ponen una linea de simétrica de más de 2Mb) es hora de enviarles un router que genere las VPNs y que los clientes no tengan que hacer nada para acceder a la central que está en España.

Dado que utilizamos Linux y OpenVPN para conectar esta oficina y los usuarios que viajan enviaremos un servidor que genere estas VPNs. La idea es montarles el servidor de OpenVPN en el dispositivo más pequeño que encontremos, enviarlo por correo, que se lo pinchen a la red y listo...

Pues bien, después de mucho buscar he encontrado esta maravilla llamada ARTIGO: placa pico-ITX, CPU VIA, 1 Ethernet, 4 USB y un video. Lo mínimo para montar un router con Linux. Viene todo desmontado como si fuera puzzle para que lo disfrutes montándolo. Sólo tienes que ponerle la memoria DDR que quieras y el disco IDE o SATA que quieras. Yo he optado por un disco solido. Al realizar funciones de router no quiero partes moviles que puendan romperse con el paso del tiempo.
Aquí tenéis un proveedor oficial en españa: http://www.ibertronica.es/artigo.htm.

Por lo que he leido también tiene un kit para añadirle una antena Wifi.

Para quién le guste el mundo de los mini PCs o busque otros modelos para montarse un barebone aquí tiene esta página: http://www.mini-itx.com/

coordinar un cambio de MX

2010-04-11T15:39:00.004+02:00

Esta semana hemos migrado las cuentas de correo de un servidor Postfix en Linux a un servidor Lotus Domino en AIX en una maquina física diferente y en otro centro diferente. Entre todas las cosas que hay que coordinar en esta migración una de ellas es el cambio de los registros MX para que dejen de apuntar a la maquina Postfix y apunten a la nueva maquina Domino.

Dependiendo de la forma de trabajar de cada departamento de IT nosotros hacemos estos cambios un viernes por la tarde de forma que sí algo falla tenemos el fin de semana para arreglar el estropicio y que todo funcione el Lunes… aunque esto depende de cada uno.

Durante un cambio en los servidores, una cosa muy importante que tenemos que controlar es el DNS y en especial los registros MX y TXT. Todos los dominios dados de alta en un DNS tienen un campo asignado donde se indica el TTL (tiempo-de-vida) de los registros.
Este valor en muy importante durante una migración ya que indica el tiempo de caducidad de los registros de nuestro dominio. Por ejemplo, si ponemos un TTL de tres dias y realizamos un cambio en los registros MX , eso querrá decir que el resto del mundo no se enterará que hemos cambiado de MX hasta tres días después. Hasta que no pasen tres dias no volverán a consultar los registros de este dominio.

Aquí tenemos un ejemplo de registro de dominio donde se especifica tres dias de TTL:

$TTL 3D
@               IN      SOA     land-5.com. root.land-5.com. (
                                199609206       ; Serial
                                28800   ; Refresh
                                7200    ; Retry
                                604800  ; Expire
                                86400)  ; Minimum TTL
                        NS      land-5.com.
                        NS      ns2.psi.net.

Por tanto, tres días antes de hacer la migración es aconsejable cambiar este TTL por ejemplo a 5 minitos. El campo TTL se indica en segundos desde 0 a 214748364 (64 años). El 0 indica a los DNS que no cacheen los registros.

Pondríamos un:

$TTL 300

Una vez llegado el día de la migración podemos cambiar los registros MX (o cualquier otro registro) con tranquilidad, sabiendo que nuestro cambio estará disponible a nivel mundial cada 5 minutos. Una vez hecha la migración y hayamos comprobado que ya recibimos correo desde el exterior a nuestro nuevo servidor, podemos volver a dejar el valor por defecto del TTL de nuestro DNS. Cómo reglar general el campo TTL lo utilizan los daemons de DNS para controlar la caducidad pero esto depende mucho de la implementación y la configuración no-estándar que sigan el resto de servidores de DNS.
Para ir comprobando si ya hemos propagado este cambio al resto de DNS podemos utilizar herramientas externas como www.mxtoolbox.com.

Otro de los registros que debemos modificar durante la migración del correo y que siempre se olvida es el registro TXT para aquellos que tengamos o deseemos activar el SPF (Sender Police Framework). Recordar que los registros MX indican las maquinas aceptadas para recibir el correo de un dominio y SPF indica las maquinas aceptadas para el envío de correo de ese dominio. SPF se inventó para combatir el problema del Spam. Cómo históricamente no existía ningún registro SPF en el DNS se optó por utilizar el registro TXT existente que hasta hace poco no servía para nada.

Aquí tenéis un ejemplo del registro TXT:

TXT = "v=spf1 ip4:214.229.188.0/25 ip4:80.34.132.42 mx -all"

Lo que indica esta línea es que las maquinas autorizadas para el envío de correo desde dicho dominio son las maquinas dentro de la red 214.229.188.0/25, la maquina 80.34.132.42, la maquinas especificadas en los MX y ninguna más.

ethernet failover (parte 2 de 2)

2010-02-21T15:40:00.007+01:00

Dentro del archivo de configuración /etc/modprobe.conf podemos utilizar diferentes modos de tolerancia a fallos o balanceo de carga.

options bonding mode=<modo> miimon=<msg> downdelay=<msg> updelay=<msg>

El bonding intenta conseguir estos modos:
+ alta disponibilidad: si una interfaz física deja de funcionar el trafico es redireccionado por la otra interfaz.
+ balanceo de carga: el trafico entrante o saliente se puede ir repartiendo por diferentes interfaces a fin de multiplicar el ancho de banda.
Con estas características se definen 7 modos de bonding:

+ modo 0 o balance-rr: se balancea el trafico de la red utilizando el algoritmo de Round-Robin. Con este modo tenemos alta disponibilidad y balanceo.

+ modo 1 o active backup: creo que es el más sencillo. Solo se utiliza una interfaz activa y las otras estan en reposo en caso de fallo. Hay alta disponibilidad pero no balanceo de carga.

+ modo 2 o balanceo-xor: asigna una interfaz a un conjunto de clientes y la otra interfaz a otro conjunto de cliente. Para ello utiliza una formula con la operación binaria xor. Tenemos balanceo de la carga pero no alta disponibilidad.

+ modo 3 o broadcast: se envía la información por todas las interfaces. No veo que este metodo sea una buena idea ¿no?. Hay alta disponibilidad pero no balanceo.

+ modo 4 o 802.3ad: no lo entiendo mucho, pero básicamente lo que hace es formar agrupaciones de interfaces activas y otras esclabas. Este método se basa en un estandard de trunking 802.3ad.

+ modo 5 o balanceo-tbl: el trafico que sale se balancea por cada interfaz. Permite alta disponibilidad y balanceo. Es la mejor alternativa.

+ modo 6 o balanceo-alb: igual que el anterior pero también se balancea la recepción.

Pasemos ahora a explicar los diferentes parámetros del bonding:

+ modo: es el modo de funcionamiento (0,1,2,3,4,5,6 o 7) tal como hemos explicado en el punto anterior.

+ miimon: es el tiempo en milisegundos entre chequeo y chequeo del estado de cada interfaz física.

+ downdelay: tiempo en milisegundos para considerar que una interfaz física ha caido.

+ updelay: tiempo en milisegundos para considerar que una interfaz vuelve a funcionar.

Como regla general los modos 6 y 7 son los recomendados o habituales ya que cada tarjeta física se conectará a un switch diferente. Durante el balanceo cada interfaz utilizará su propia dirección MAC.

En el caso de los modos 0 y 2, las interfaces físicas pueden ir a mismo switch, pero el caso del modo 1 no ya que se dará el caso en que el switch tendrá la misma MAC por dos interfaces físicas diferentes.

ethernet failover (parte 1 de 2)

2010-02-21T15:01:00.015+01:00

Supón que tienes un servidor con varias maquinas virtuales dando servicio y que quieres asegurar la conectividad con la red. Al igual que redundamos las fuentes de alimentación o los discos montando RAIDs, también podemos redundar las interfaces de red Ethernet para asegurar una conectividad de alta disponibilidad. El siguiente esquema de red es típico de un entorno de virtualización, pero puede ser extensible a cualquier tipo de servicio crítico como puede ser una maquina de correo.

La técnica que utilizaremos es el bonding (o vinculación) en la cual crearemos una interfaz virtual vinculada a dos (o más) interfaces Ethernets físicas.

Como veis en el siguiente esquema cada interfaz de red se conecta a un switch redundando y cada switch a su backbone.

Lo que haremos es crear una interfaz virtual llamada bond0 y vincularla con eth0 y eth1. Supondremos que estamos en un CentOS 4.5. Editaremos el /etc/modprobe.conf para que el kernel arranque el modulo de bonding:

alias bond0 bonding
options bond0 miimon=80 mode=5

Ahora crearemos la interfaz virtual bond0. Creamos el archivo /etc/sysconfig/network-scripts/ifcfg-bond0:

DEVICE=bond0
IPADDR=192.168.1.100
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
GATEWAY=192.168.1.1
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

Una vez creada la interfaz virtual editamos nuestras dos interfaces físicas (eth0 y eth1) con este contenido:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
MASTER=bond0
SLAVE=yes

# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
MASTER=bond0
SLAVE=yes

Ahora solo queda reiniciar y hacer pruebas de conectividad con los cables de red para comprobar que efectivamente no perdemos conexión si desconectamos eth0 o eth1.

Si hacemos un ifconfig, veremos como la interfaz virtual es la que coge la dirección IP:

bond0     Link encap:Ethernet  HWaddr 00:1E:C9:D6:DA:6E  
          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21e:c9ff:fed6:da6e/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:5157067 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3927169 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2601662632 (2.4 GiB)  TX bytes:2306432451 (2.1 GiB)

eth0      Link encap:Ethernet  HWaddr 00:1E:C9:D6:DA:6E  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:3593230 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2807046 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2459234475 (2.2 GiB)  TX bytes:2154634747 (2.0 GiB)
          Interrupt:194 Memory:dc000000-dc012800 

eth2      Link encap:Ethernet  HWaddr 00:1E:C9:D6:DA:72  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:1563837 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1120123 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:142428157 (135.8 MiB)  TX bytes:151797704 (144.7 MiB)
          Interrupt:170 Memory:d8000000-d8012800 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6917 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6917 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:6525082 (6.2 MiB)  TX bytes:6525082 (6.2 MiB)

En el siguiente post veremos lo diferentes modos de funcionamiento del bonding y las precauciones que tenemos que tomar según el modo seleccionado.

Más información:
+ Linux Channel Bonding

balancing y failover

2010-01-20T22:11:00.012+01:00

Tengo hasta 5 conexiones de salida a Internet, entre caudales garantizados, ADSL, SDSL, etc.
La idea es centralizar todas estas salidas bajo un único gateway de forma que podamos hacer balanceo de carga y failover. Con el balanceo de carga conseguimos que unas peticiones vayan por una línea y otras por otra de forma automática y transparente para el usuario. Con el failover conseguimos que en caso de caída de una conexión de salida, todo el tráfico continuará saliendo por otra conexión.
Hay que tener presente que esta solución no hace una suma de anchos de banda, simplemente reparte las peticiones sobre una u otra conexión.

En el siguiente ejemplo utilizaremos dos conexiones a Internet ADSL, las dos de 6Mb. Utilizaremos una maquina Linux con tres interfaces Ethernet. Una conectada a una ADSL, otra conectada a otra ADSL y por último una interfaz conectada a nuestra red interna. Esta máquina hará de gateway de todos nuestros usuarios de la red interna.

En vez de utilizar una ruta por defecto, configuraremos una ruta por defecto que es multicamino o "multi-path route". Por defecto el kernel equilibrará las rutas sobre los dos posibles proveedores.

Para realizar balanceo utilizaremos iproute y para realizar el failover utilizaremos el siguiente script gwping que es un daemon (escrito en bash) que lo que hace es comprobar cada cierto tiempo el estado de la línea. Si la línea cae automáticamente realiza el switch. Cuando las dos líneas están activas continua haciendo el balancing.

Lo primero que hacemos es añadir estas instrucciones dentro de nuestro /etc/rc.local:

# activamos el forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# le decimos que todos los paquetes que vienen por una ADSL vuelven por la misma.
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.10 table ADSL1
ip route add default via 192.168.1.1 table ADSL1
ip route add 192.168.0.0/24 dev eth1 src 192.168.0.10 table ADSL2
ip route add default via 192.168.0.1 table ADSL2
ip rule add from 192.168.1.10 table ADSL1
ip rule add from 192.168.0.10 table ADSL2

# la carga se reparte (equitativamente) por diferentes gateway.
ip route add default scope global nexthop via 192.168.1.1 dev eth0 weight 1 
   nexthop via 192.168.0.1 dev eth1 weight 1

# activamos el nat en el gateway
iptables -F
iptables -t nat -F
iptables --delete-chain
iptables -t nat --delete-chain
iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
iptables -A INPUT -p ICMP -j ACCEPT
iptables -A INPUT -p TCP -m state --state RELATED -j ACCEPT
iptables -A FORWARD --in-interface eth2 -j ACCEPT

nohup /usr/sbin/gwping &

Observar como se utiliza el parámetro “weight” para decir que las dos adsl tienen la misma importancia. Tienen la misma velocidad. Si tuviéramos una ADSL 4 veces más rápida que otra pondríamos algo como:

ip route add default scope global nexthop via 192.168.1.1 dev eth0 weight 1 
   nexthop via 192.168.0.1 dev eth1 weight 4

El siguiente paso es añadir las tablas ADSL1 y ADSL2 dentro del iproute. Para ello editamos el /etc/iptables2/rt_tables:

root@failover:~# cat /etc/iproute2/rt_tables 
255     local
254     main
253     default
0       unspec
1 ADSL1
2 ADSL2

Ahora copiamos nuestro script gwping a /usr/sbin y le damos permisos de ejecución:

# chmod 755 /usr/sbin/gwping

Si editamos el script gwping podemos configurar los primeros parámetros para ajustarlos a nuestra configuración.

+ EXTIF1 y EXTIF: nombre de la interfaces externas
+ IP1 e IP2: IP de las interfaces
+GW1 y GW2: IP de las ADSLs
+ W1 y W2: peso de cada una de las ADSLs
+ NAME1 y NAME2: nombre de las ADSLs

Una vez reiniciada la maquina debería correr en fondo el daemon gwping (ps –xa | grep gwping). Para comprobar que todo está funcionando debería crearse un fichero de log llamado /var/log/failover donde es posible comprobar como se va realizando el switch entre las ADSLs:

root@failover:/var/log# tail -f failover 
Ping status changed for ADSL2 from 1 to 0
Uptime status will be changed for ADSL1 from 1
Uptime status will be changed for ADSL2 from 1
Restoring default load balancing
ADSL2 Down
Ping status changed for ADSL2 from 0 to 1
Uptime status will be changed for ADSL2 from 0
Ping status changed for ADSL2 from 1 to 0
Uptime status will be changed for ADSL2 from 1
Restoring default load balancing
ADSL1 Down
Ping status changed for ADSL1 from 0 to 1
Uptime status will be changed for ADSL1 from 0
Switching to ADSL2
ADSL1 Down
ADSL1 Down
Ping status changed for ADSL1 from 1 to 0
Uptime status will be changed for ADSL1 from 1
Restoring default load balancing
ADSL1 Down

Para comprobar que todo funciona podéis hacer diferentes consultas desde diferentes usuarios de la red interna a paginas web como http://www.whatismyip.com y comprobar vosotros mismos como se obtienen IPs diferentes dependiendo de si la petición HTTP ha ido por una ADSL u otra.

Más información:
+ Routing por diferentes proveedores
+ Linux Advanced Routing & Traffic Control HOWTO

squid y mrtg

2010-01-16T18:08:00.010+01:00

El proxy de Squid nos permite generar gráficas desde cualquier aplicación o cliente SNMP. Para ello simplemente debemos activar el servicio de SNMP en el Squid y comenzar a realizar consultas para saber que carga o uso tiene.
Para ello editamos el /etc/squid/squid.conf y añadimos las siguientes líneas:

# creamos una acl donde le decimos el nombre de la comunidad SNMP que utilizamos
acl snmppublic snmp_community public
# por defecto utilizaremos el puerto 3401/UDP para las consultas
snmp_port 3401
# aplicamos la ACL para que solo la maquina local pueda realizar consultas
snmp_access allow snmppublic localhost
snmp_access deny all

Una vez configurado hacemos un reload de la config:

# /etc/init.d/squid reload

Ahora probamos con el comando snmpwalk si tenemos acceso al servicio SNMP de Squid:

# snmpwalk –c public -v 1 localhost:3401 .1.3.6.1.4.1.3495.1.1                            
SNMPv2-SMI::enterprises.3495.1.1.1.0 = INTEGER: 65552
SNMPv2-SMI::enterprises.3495.1.1.2.0 = INTEGER: 6288060
SNMPv2-SMI::enterprises.3495.1.1.3.0 = Timeticks: (129933578) 15 days, 0:55:35.78

Instalamos la herramienta de MRTG (Multi Router Traffic Grapher) que nos permitirá realizar gráficos del uso de Squid. MRTG generará una página Web cada 5 minutos con los datos. Para ello necesitaremos tener también Apache:

# apt-get install mrtg apache

Creamos el fichero de configuración del MRTG para generar dos tipos de gráficos diferentes:

ImageDir: /var/www/mrtg-squid
Workdir: /var/www/mrtg-squid
LoadMIBS: /etc/squid/mib.txt

Target[proxy-hit]: cacheHttpHits&cacheServerRequests:public@127.0.0.1:3401
MaxBytes[proxy-hit]: 100000
Title[proxy-hit]: HTTP Hits
PageTop[proxy-hit]: <H2>proxy Cache Statistics: HTTP Hits/Requests</H2>
Suppress[proxy-hit]: y
LegendI[proxy-hit]:  HTTP hits
LegendO[proxy-hit]:  HTTP requests
Legend1[proxy-hit]:  HTTP hits
Legend2[proxy-hit]:  HTTP requests
YLegend[proxy-hit]: perminute
ShortLegend[proxy-hit]: req/min
Options[proxy-hit]: nopercent, perminute, dorelpercent, unknaszero, growright

Target[proxy-srvkbinout]: cacheServerInKb&cacheServerOutKb:public@127.0.0.1:3401
MaxBytes[proxy-srvkbinout]: 76800
Title[proxy-srvkbinout]: Cache Server Traffic In/Out
PageTop[proxy-srvkbinout]: <H2>Cache Statistics: Server traffic volume (In/Out)</H2>
Options[proxy-srvkbinout]: growright

Tanto las paginas Web como los datos de las estadísticas generados por MRTG se guardaran en /var/www/mrtg-squid. Si no existe la carpeta habrá que crearla.
Por otro lado necesitaremos el archivo /etc/squid/mib.txt donde se especifican los objetos que se deben monitorizar dentro de Squid. Se puede descargar de los archivos fuentes del Squid o de aquí.

Ahora solo hace falta ejecutar el MRTG cada 5 minutos. Para ello editamos el /etc/crontab y añadimos la siguiente línea:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * root LANG=C /usr/bin/mrtg 
   /etc/squid/mrtg-squid.conf --debug="cfg"

Al cabo de unas horas ya podrás apreciar el uso de tú Squid. Al leer los gráficos del MRTG es muy importante saber bajo que velocidad está generado el gráfico para poder compararlo por ejemplo con el gráfico de tú conexión a Internet. En este caso el gráfico “Squid volum traffic” está en KB/s (Kilobytes por segundo).

Podrás acceder a dos tipos de gráficos: el “http Hits and request” (http:///mrtg-squid/proxy-hit.html) y el “Squid traffic volumn” (http:///mrtg-squid/proxy-srvkbinout.html).

El segundo de ellos indica en KB/s el volumen de datos que entran y salen del Squid. Para interpretar el primero de ellos debemos tener claro las diferencia entre “http request” y “http hits”. Las “http request” son las peticiones http que realizan los clientes. Las “http hits” son las peticiones servidas por el proxy o más concretamente servidas por la cache del proxy. Es decir, contra más se parezcan los “http request” a los “http hits” mejor está funcionando el proxy porque eso quiere decir que el cliente a pedido una pagina Web que el proxy tenía cacheada.
Existe otro parámetro que es el “percentage” que indica el porcentaje de acierto del proxy. Un porcentaje alto indica que todas las paginas que van pidiendo los usuarios están ya cacheadas por el proxy.

Más información:
+ Configuración de un proxy transparente
+ SQUID and MRTG: to SNMP or not SNMP?

un miniserver con una fonera

2010-01-01T23:39:00.008+01:00

Hace unos dias que me calló una Fonera 2.0n y no sé muy bien para que. Para el que no sepa que es una Fonera no es más que un access-point bajo Linux al que se le han añadido servicios. La idea es formar una comunidad de Foneros repartidos por todo el mundo de forma que los Foneros compartan una porción de su ancho de banda de conexión a Internet para que otros puedan utilizarlo.

Puedes encontrar un punto de acceso Fon en el mapa oficial de la comunidad: http://maps.fon.com/

Actualmente hay dos Foneras access-points: la Fonera 2n (la más completa) y la Fonera+ (la básica).

Después de trastearla y jugar con ella he decido deshabilitar la Wifi y utilizarla solo de servidor de descargas para bajar ficheros y torrents. La Fonera 2n, a parte de ser access-point (no es un router que elimina la necesidad de nuestra router-ADSL) contiene toda una interfaz Web para administrar torrents, el Facebook, descarga de archivos, el Youtube, el Flicker, etc. Dado que se trata de un aparato muy pequeño es ideal para dejarlo todo el dia encendido bajando cosas. Además tiene la posibilidad de añadirle una llave o disco USB para ir dejando todo lo que estemos bajando.

Estos son los pasos para convertir tú Fonera en un servidor de descargas:

+ Una vez instalada la Fonera y funcionando tal como indica “La guía de instalación rápida” lo que haremos es actualizar el firmware a una versión Developer. La versión Developer permite tener el puerto SSH de la Fonera abierto y poder trastear por su interior. Mi fonera tenía la 2.2.6_ENDUSER y le he puesto la versión 2.3_DEV. Para actualizarla hay que hacer: Panel de control -> Configuración -> Sistema -> Actualizacion Firmware

Para acceder a la configuración Web cargaremos la pagina https://192.168.10.1 una vez que nos hemos conectado al SSID de administración "MyPlace".

+ Cuando tenemos la Fonera con la ultima firmware podemos deshabilitar la compartición libre de nuestra Wifi o el SSID FON_FREE_INTERNET. Haremos: Panel de control -> Configuración -> Fon Spot.
En esto de las Foneras hay dos SSID: uno publico (FON_FREE_INTERNET), que lo acabamos de desactivar y el otro privado (MyPlace) que debe desactivarse por hardware con el interruptor situado detrás de la Fonera.
Una vez hecho esto la Fonera será como otro PC conectado a nuestra red LAN.

Al desconectar las interfaces Wifi debemos acceder directamente vía interfaz Ethernet. Por defecto esta interfaz se configura por DHCP pero desde Panel de control -> Configuración -> Internet es posible asignar una IP a la tarjeta de red de la Fonera. Por ejemplo 192.168.1.99.

+ Ahora lo que tenemos que hacer es activar todos los servicios de administración (Web GUI, SSH, FTP, etc) para que sean accedidos desde nuestro PC de la LAN. Por defecto todos estos servicios solo están disponibles si nos conectamos vía SSID privado, pero lo que queremos es que estén disponibles desde fuera de la Fonera. Para activarlos haremos: Panel de control -> Configuración -> Firewall -> Aplicaciones

Una vez activados todos los servicios deberíamos poder acceder a la Fonera desde nuestra LAN con un https://192.168.1.99.

+ Necesitaremos también un disco o llave USB para las descargas. Una vez introducido, los iconos “Disco USB” y “Navegación de archivos” ya estarán disponibles.

+ Por ultimo solo queda ir al Gestor de descargas o Torrents para controlar nuestras descargas. Para acceder a nuestras descargas podemos ir por carpeta compartida \\192.168.1.99\media con el usuario "fonero" y el password que hayamos puesto durante la instalación.

Nota: al igual que hemos conectado un disco USB, tambien es posible conectar una webcam o una impresora.

Más información:
+ Wiki Fonera 2n

un dia en la oficina con el axis 207mw

2009-12-29T14:22:00.002+01:00

keepass

2009-12-27T17:24:00.005+01:00

Cuando tienes más de 100 passwords para administrar se hace necesaria una herramienta de administración de password muy portable. Portable para Windows, portable para Linux, portable para la Blackberry o portable el iPhone. Cada uno de los técnicos accede a los passwords de una manera diferente.

Necesitamos por tanto que sea multiplataforma y multi-dispositivo. Que encripte lógicamente la información, que permita hacer grupos de password (servidores, access points, switches, etc), que permita adjuntar ficheros como puede ser una config de un Cisco, que permita búsquedas, que permita exportar a un Excel, que permita crear campos como la IP de un servidor o la fecha de la ultima actualización del servidor y sobre todo que sea opensource.

Pues bien, después de mucho probar la solución es: KeePass Password Safe.

Ahora cada vez que conectamos una Blackberry o un iPhone al portátil, sincronizamos el fichero de password automáticamente. Una maravilla…

run kiosco

2009-12-20T13:07:00.020+01:00

Un kiosco en Linux es una máquina dispuesta en un stand para que los usuarios la puedan utilizar a modo de terminal de consulta. Por ejemplo si habéis ido alguna tienda de Pixmania, a la entrada hay un terminal (pantalla+teclado+ratón) donde solo tenéis acceso a su pagina Web para consultar sus productos.

En mi empresa hemos montado tres kioscos para que los empleados tengan acceso al "portal del empleado" y estén siempre al día de la noticias de la empresa. Una está en la cafetería, la otra en el restaurante y la otra aun no se donde irá.

Explico pues como montar una maquina de estas. La idea es que el Linux arranque automáticamente, cargue el firefox con la página de inicio y el usuario solo pueda consultar esta página. Naturalmente no podrá navegar por ningún otro sitio, no podrá reiniciarla, no podrá ejecutar ninguna aplicación, etc.

+ Instalaremos una versión ligera de Linux como Ubuntu Server. La idea es que cualquier maquina con poco disco (unos 2Gb) y memoria (unos 256Mb) nos pueda funcionar. Haremos una instalación estándar y consideraremos los siguientes puntos:

1) Crear el usuario con nombre "operador". Este será el usuario con el que funcionará el Kiosco.
2) No utilizar LVM ya que no es necesario.
3) Instalar OpenSSH Server. Es necesario para realizar un mantenimiento remoto del kiosco.

+ Actualizar la máquina e instalar un entorno X ligero como Blackbox (con 5Mb de RAM ya funciona):

operador@kiosko$ sudo passwd root
operador@kiosko$ su root
root@kiosko# apt-get update
root@kiosko# apt-get upgrade
root@kiosko# apt-get install x-window-system-core blackbox squid firefox mingetty 
flashplugin-nonfree

+ Lo primero que haremos es configurar el Squid para decirle el conjunto de paginas Web por donde podrá navegar el kiosco. Si solo tenemos un kiosco el proxy lo instalaremos en la maquina local, si tenemos varios podemos instalar el proxy en uno de ellos y hacer que el resto de kioscos lo utilicen.

El usuario no puede escribir una URL ya que la pagina inicial le viene impuesta, el problema es que si la pagina contiene un link a otro site no controlado o no previsto, el usuario podrá navegar. Imagina que dentro de la pagina inicial encuentra un link a Google. Si accede a Google podrá navegar por donde quiera.

Para ello creamos el archivo "/etc/squid/kiosko_allow_sites.conf" y dentro colocaremos todos los dominios (incluidos nuestra pagina inicial) por donde queramos que navegue nuestro kiosco:

root@kiosko# cat kiosko_allow_sites.conf 
intranet.miempresa.com
miempresa.com
submiempresa.com

Ahora le decimos a Squid que acepte estos sites y que todo lo demás lo deniegue. Para ello editamos el /etc/squid/squid.conf. Dentro del "Defining an Access List", añadimos la ACL:

acl kiosko_allow_sites url_regex "/etc/squid/kiosko_allow_sites.conf"

Ahora creamos la rule para aceptar estas sites y denegar el resto. Dentro de "Allowing or Denying access based on defined access lists" añadimos:

http_access allow kiosko_allow_sites
http_access deny all

Ahora solo queda reiniciar Squid:

root@kiosko# /etc/init.d/squid restart

+ Ya podemos arrancar el entorno X. Mientras tanto podemos ir conectándonos por SSH y terminar de configurar la maquina:

root@kiosko# startx

Para arrancar Firefox manualmente, hacemos botón derecho en el ratón y ejecutamos xterm. En la ventana de consola podemos escribir "firefox" para ejecutarlo.

Una vez arrancado el Firefox lo configuramos para que siempre arranque nuestra pagina de inicio. Para ellos hacemos "Editar->Preferencias" y modificamos la "Pagina de Inicio".

Es aconsejable revisar todas las opciones de Firefox para no dejarnos nada. Por ejemplo:

1) cambiar la ruta de descargas de archivos a /tmp.
2) deshabilitar la barra de progreso de descargas
3) no recordar nunca los passwords
4) limpiar historial todos los dias
5) deshabilitar las actualizaciones

También debemos decirle a Firefox que utilice el proxy (Squid) que hemos configurado en el punto anterior. Para ello dentro de Preferencias vamos a Advanced->Network->Settings y añadimos:

HTTP Proxy: 127.0.0.1
Puerto: 3127

Otra cosa para configurar es deshabilitar la restauración de la sesión de Firefox al cerrar incorrectamente el navegador. Esto evita que cada vez que arranque el Firefox (al reiniciar el kiosco) pregunte si deseamos restaurar la ultima sesión:

1) En la URL escribimos "about:config" y pulsamos Enter
2) Buscamos "browser.sessionstore.resume_from_crash"
3) Hacemos doble click en el parámetro para ponerlo a false

También pondremos a false el parámetro "network.protocol-handler.external.mailto". Esto lo que hará es que cuando la pagina encuentre un link del tipo "mailto" este no funcione y no cargue ningún Webmail tipo GMail o Yahoo.

Tras finalizar la configuración de Firefox viene la parte más importante que es la instalación de un complemento de Firefox que nos permite eliminar las barras de navegación, la minimización de las ventanas, el botón derecho del ratón, etc: el R-Kiosk.

Lo debemos instalar accediendo a su descarga: https://addons.mozilla.org/en-US/firefox/addon/1659

Una vez arrancado Firefox con este complemento perderemos toda posibilidad de acceder a los menus y al escritorio la maquina. Si queremos arrancar con los menús de Firefox, tendremos que arrancarlo en safe-mode como se indica más abajo.

+ Hacer auto-login y arrancar el entorno grafico automáticamente.

Primero editamos "/etc/event.d/tty1" y cambiamos "exec /sbin/getty 38400 tty1" por "exec /sbin/mingetty –-autologin operador tty1". Esto lo que hace es el auto-login con el usuario "operador" creado durante la instalación.

Para arrancar las X editamos "/home/operador/.profile" y añadimos en la última linea un "startx".

+ Arrancar automáticamente Firefox. Creamos el archivo "/home/operador/.xinitrc". Este archivo se ejecuta cada vez que arranque el entorno gráfico:

root@kiosko# cat .xinitrc 
#!/bin/bash

## Arranque normal de Firefox
firefox &

## Utilizar esta linea para arrancar Firefox en safe-mode
##firefox -safe-mode &

. /etc/X11/Xsession

root@kiosko# chown operador:operador .xinitrc

NOTA: Si no queremos arrancar el R-Kiosk arrancaremos el Firefox con "firefox -safe-mode &".

+ También es necesario que el usuario no pueda hacer un "ctrl+alt+del" y reiniciar el kiosco. Para ello renombramos este archivo:

root@kiosko# cd /etc/envet.d
root@kiosko# mv control-alt-delete control-alt-delete.disable

Otras consideraciones: la máquina al arrancar es vulnerable a que un usuario pueda acceder. Por ejemplo, al arrancar el grub podría modificar los parametros de arranque, podría cambiar de tty mientras está cargado, o podría llegar a ejecutar un xterm antes de arrancar el Firefox.

Por esto unas modificaciones que podrías hacer tú es:

+ Modificar el grub para que el timeout sea 0 segundos.
+ Quitar todos los ttys no necesarios
+ No ejecutar ningún programa una vez dentro de Blackbox.

lvm: ponme un nuevo disco

2009-12-14T16:06:00.003+01:00

Actualmente tengo una maquina con un Oracle al que se le termina el espacio de disco. Tiene un disco de 68Gb en RAID1 montado por LVM (el /dev/sda). Hemos montado otro disco de 68Gb en RAID1 (el /dev/sdb) con la idea de ampliar el espacio del volum-group formado en la maquina.

Miramos primero que se ha reconocido el segundo disco:

root@virtuozo:~# ls -l /dev/sd*   
brw-rw---- 1 root disk 8,  0 2009-12-11 11:50 /dev/sda
brw-rw---- 1 root disk 8,  1 2009-12-11 11:50 /dev/sda1
brw-rw---- 1 root disk 8,  2 2009-12-11 11:50 /dev/sda2
brw-rw---- 1 root disk 8,  5 2009-12-11 11:50 /dev/sda5
brw-rw---- 1 root disk 8, 16 2009-12-12 16:39 /dev/sdb

Miramos cómo está montado el LVM en esta máquina. Miramos los Physical Volumen o los discos físicos que forman mi LVM:

root@virtuozo:~# pvscan
  PV /dev/sda5   VG virtuozo.barcelona   lvm2 [68.00 GB / 0    free]
  Total: 1 [68.00 GB] / in use: 1 [68.00 GB] / in no VG: 0 [0   ]

Vemos que existe un volum-group llamado “virtuozo.barcelona” que está compuesto de la partición física /dev/sda5 de 68Gb.

Vemos ahora como está particionado este volum-group en diferentes logical-volum:

root@virtuozo:~# lvscan
  ACTIVE            '/dev/virtuozo.barcelona/root' [65.18 GB] inherit
  ACTIVE            '/dev/virtuozo.barcelona/swap_1' [2.82 GB] inherit

Está particionado en dos. La primera en “root” de 65Gb y la segunda es “swap_1” de 2Gb.

Ahora que tenemos esto presente, la idea de añadir un nuevo disco (el /dev/sdb) es aumentar el tamaño del logical-volum “root”, pasando de 65Gb a 133Gb aproximadamente.

Vamos pues. Lo primero que haremos es crear una única partición en /dev/sdb de system id “8e” (tipo LVM).

root@virtuozo:~# fdisk /dev/sdb

The number of cylinders for this disk is set to 8908.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-8908, default 1): 
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-8908, default 8908): 
Using default value 8908

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Una vez creada la partición (ver ls –l /dev/sd*), la formateamos. En mi caso es formato ext3:

root@virtuozo:~# mkfs -t ext3 -c /dev/sdb1

Ahora ya podemos añadir nuestro nuevo disco al volum-group:

root@virtuozo:~# pvcreate /dev/sdb1
root@virtuozo:~# vgextend virtuozo.barcelona /dev/sdb1
root@virtuozo:~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda5
  VG Name               virtuozo.barcelona
  PV Size               68.00 GB / not usable 1.27 MB
  Allocatable           yes (but full)
  PE Size (KByte)       4096
  Total PE              17408
  Free PE               0
  Allocated PE          17408
  PV UUID               gextNx-qoAF-aNn9-1ARg-72bY-oQeY-sHaOQ7   
  --- Physical volume ---
  PV Name               /dev/sdb1
  VG Name               virtuozo.barcelona
  PV Size               68.24 GB / not usable 454.00 KB
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              17469
  Free PE               17469
  Allocated PE          0
  PV UUID               dCibq8-B4TY-adnR-HR6j-iLv6-f15H-pBknpX

Para finalizar aumentamos el tamaño del logical-volum llamado “root”:

root@virtuozo:~# lvextend -l+17469 /dev/virtuozo.barcelona/root 
  Extending logical volume root to 133.42 GB
  Logical volume root successfully resized
root@virtuozo:~# lvscan
  ACTIVE            '/dev/virtuozo.barcelona/root' [133.42 GB] inherit
  ACTIVE            '/dev/virtuozo.barcelona/swap_1' [2.82 GB] inherit
# resize2fs /dev/virtuozo.barcelona/root
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/virtuozo.barcelona-root
                      133G  2.8G  123G   3% /
varrun               1008M   84K 1008M   1% /var/run
varlock              1008M     0 1008M   0% /var/lock
udev                 1008M   52K 1008M   1% /dev
devshm               1008M     0 1008M   0% /dev/shm
/dev/sda1             236M   26M  199M  12% /boot

Observar como utilizamos el parámetro +17469 para aumentar el espacio con los “Free PE” (Physical Extended) del nuevo disco que hemos añadido. También podríamos utilizar algo como “lvextend -L+68G /dev/virtuozo.barcelona/root”.

Esta es una tabla de todos los comandos que se pueden utilizar para LVM:

--------------------
Comandos de volúmenes físicos
--------------------
pvchange |  Cambia los atributos de un volumen físico
pvcreate |  Crea un volumen físico
pvdata  |  Muestra información de depuración sobre un volumen físico
pvdisplay  | Muestra información sobre un volumen físico
pvmove   | Mueve extensiones físicas de un volumen físico a otro.
pvscan  | Localiza y enumera todos los volúmenes físicos
--------------------
Comandos de grupos volumen
--------------------
vgcfgbackup  | Hace una copia del área del descriptor de grupo volumen
vgcfgrestore  | Recupera el área del descriptor de grupo volumen al disco
vgchange  | Cambia los atributos de un grupo volumen
vgck   | Comprueba la consistencia del área del descriptor de grupo volumen
vgcreate  | Crea un grupo volumen a partir de volúmenes físicos
vgdisplay  | Muestra los atributos de un grupo volumen
vgexport  | Exporta un grupo volumen del sistema
vgextend  | Añade volúmenes físicos a un grupo volumen
vgimport  | Importa un grupo volumen al sistema
vgmerge  | Combina dos grupos volumen
vgmknodes  | Combina un directorio y los archivos especiales de un grupo volumen
vgreduce  | Elimina volúmenes físicos de un grupo volumen
vgremove  | Elimina un grupo volumen
vgrename  | Renombra un grupo volumen
vgscan   | Localiza y enumera todos los grupos volumen del sistema
vgsplit  | Divide un grupo volumen
--------------------
Comandos de volúmenes lógicos
--------------------
lvchange  | Cambia los atributos de un volumen lógico 
lvcreate  | Crea un volumen lógico
lvdisplay  | Muestra los atributos de un volumen lógico
lvextend  | Incrementa el tamaño de un volumen lógico
lvreduce  | Reduce el tamaño de un volumen lógico
lvremove  | Elimina un volumen lógico
lvrename  | Renombra un volumen lógico
lvscan   | Localiza y enumera todos los volúmenes lógicos, creando /etc/lvmtab 
y /etc/lvmtab.d/*
--------------------
Comandos del Administrador de Volúmenes Lógicos (LVM)
--------------------
lvmchange  | Cambia los atributos del sistema LVM
lvmdiskscan  | Localiza y enumera todos los discos disponibles, los dispositivos 
múltiples y las particiones
lvmsadc  | Recoge información sobre la actividad de LVM
lvmsar   | Muestra información sobre la actividad de LVM

instalar oracle en linux y no morir en el intento (parte ii)

2009-12-12T13:29:00.016+01:00

Es posible que al finalizar ya podamos acceder directamente a la consola de administración desde: http://ip_server:1158/em

Pero si reiniciamos veremos como Oracle no arranca por defecto. Hay muchos scripts por Internet para arrancar automáticamente la BBDD.
Lo que primero haremos es indicarle a Oracle que BBDD queremos arrancar al arrancar Oracle.

Editamos el /etc/oratab e indicamos que queremos que la única base de datos creada arranque:

dbora01:/u01/app/oracle/oracle/product/10.2.0:Y

Iniciar Oracle:

# su oracle
# . oraenv (cargamos las variables de entorno)
$ . oraenv
ORACLE_SID = [oracle] ? dbora01

$ lsnrctl start (arrancamos el listener)
$ dbstart (arrancamos la bbdd)
$ emctl start dbconsole (arrancamos la consola de administración)

Podemos ver todos lo procesos que se arrancan:

$ ps -x
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.3/FAQ
  PID TTY      STAT   TIME COMMAND
 6439 pts/0    S      0:00 bash
 6469 ?        Ssl    0:00 /u01/app/oracle/oracle/product/10.2.0/bin/tnslsnr LISTENER 
-inherit
 6514 ?        Ss     0:00 ora_pmon_dbora01
 6516 ?        Ss     0:00 ora_psp0_dbora01
 6518 ?        Ss     0:01 ora_mman_dbora01
 6520 ?        Ss     0:00 ora_dbw0_dbora01
 6522 ?        Rs     0:03 ora_lgwr_dbora01
 6524 ?        Ss     0:00 ora_ckpt_dbora01
 6526 ?        Ss     0:04 ora_smon_dbora01
 6528 ?        Ss     0:00 ora_reco_dbora01
 6530 ?        Ss     0:02 ora_cjq0_dbora01
 6532 ?        Ss     0:04 ora_mmon_dbora01
 6534 ?        Ss     0:00 ora_mmnl_dbora01
 6536 ?        Ss     0:00 ora_d000_dbora01
 6538 ?        Ss     0:00 ora_s000_dbora01
 6542 ?        Ss     0:00 ora_qmnc_dbora01
 6544 ?        Ss     0:00 ora_q000_dbora01
 6546 ?        Ss     0:00 ora_q001_dbora01
 7029 pts/0    S      0:00 /u01/app/oracle/oracle/product/10.2.0/perl/bin/perl 
/u01/app/oracle /oracle/product/10.2.0/bin/emwd.pl dbc
 7054 pts/0    Sl     0:28 /u01/app/oracle/oracle/product/10.2.0/jdk/bin/java 
-server -Xmx256M -XX:MaxPermSize=96m -XX:MinHeapFreeRa
 7219 ?        Ss     0:00 oracledbora01 (LOCAL=NO)
 7226 ?        Ss     0:01 oracledbora01 (LOCAL=NO)
 7230 ?        Ss     0:04 oracledbora01 (LOCAL=NO)
 7235 ?        Ss     0:02 oracledbora01 (LOCAL=NO)
 7260 ?        Ss     0:00 oracledbora01 (LOCAL=NO)
 7274 ?        Ss     0:00 oracledbora01 (LOCAL=NO)
 7866 pts/0    Sl     0:01 /u01/app/oracle/oracle/product/10.2.0/bin/emagent
 7897 ?        Ss     0:01 oracledbora01 (LOCAL=NO)
 7941 ?        Ss     0:02 oracledbora01 (LOCAL=NO)
 7973 ?        Ss     0:04 oracledbora01 (LOCAL=NO)
 8253 ?        Ss     0:00 ora_j000_dbora01
 8268 pts/0    R+     0:00 ps -x

El primero que arrancamos es el listener. El listener es un servicio TCP que por defecto escucha en el 1521 y provee la conexión de clientes que necesitan realizar operaciones con la base de datos. Por ejemplo si tenemos una aplicación Java o PHP que desea realizar consultas contra la BBDD deberá contactar con el listener de Oracle pasándole su usuario/password y el SID de la base de datos.

La configuración del listener está en: $ORACLE_HOME/network/admin.

Luego levantamos la BBDD y con ello aparecen toda una serie de procesos llamados ora_*. Explicaré rápidamente algunos de estos procesos:

+ Ora_pmon: Es el Process Monitor. Es el encargado de limpiar los bufer y las caches que un usuario haya podido dejar sin liberar. Por ejemplo la conexión de red de un usuario cae y este tiene bloqueos de tablas, pmon libera las tablas, realiza rollbacks, etc de los recursos consumidos.

+ Ora_smon: Es el System Monitor. Es el encargado de recuperar la base de datos en caso de fallo de Oracle. Para ello utiliza los archivos de rehacer.

+ Ora_dbw: Es el Dabase Writer. Es proceso encargado de escribir en los ficheros fisicos los bloques de datos nuevos o modificados. Dependiendo del redimiento y necesidades de nuestro Oracle, podemos arrancar hasta 20 dbw.

+ Ora_lgwr: Es el Log Writer. Es el encargado de escribir los bloques del rehacer. Cuando tenemos una transacción primero se escriben los datos en los registros de rehacer antes que el ora_dbw los escriba finalmente en los ficheros de datos. Una transacción es correcta si ora_lgwr ha podido escribir los datos en sus archivos de rehacer.

Finalmente arrancamos la consola de administración que no es más que una aplicación Java (http://ip_server: 1158/em).
Ahora que parece que todo está arrancado vamos a conectarnos a la base de datos y hacer unas cuantas consultas de administración. No conectamos a la BBDD.

$ sqlplus /nolog
> connect / as sysba
Connected.

Veamos cuantas base de datos tenemos creadas:

SQL> select name, created, log_mode, open_mode, platform_name from v$database;

NAME      CREATED  LOG_MODE     OPEN_MODE
--------- -------- ------------ ----------
PLATFORM_NAME
--------------------------------------------------------------------------------
DBORA01   08/12/09 NOARCHIVELOG READ WRITE
Linux IA (32-bit)

Vemos que tenemos una BBDD llamada DBORA01 y que está abierta para lectura/escritura.

Veamos cuantos tablespaces tiene esta base de datos:

SQL> select tablespace_name, contents from dba_tablespaces;

TABLESPACE_NAME                CONTENTS
------------------------------ ---------
SYSTEM                         PERMANENT
UNDOTBS1                       UNDO
SYSAUX                         PERMANENT
TEMP                           TEMPORARY
USERS                          PERMANENT
EXAMPLE                        PERMANENT

6 rows selected.

Todos a excepción del EXAMPLE son los que nos encontraremos en una instalación estándar de Oracle. En el tablespace EXAMPLE encontraremos tablas de ejemplo para hacer pruebas.

Juguemos ahora con el schema SCOTT que se encuentra dentro del tablespace EXAMPLE. Para ello primero habilitamos el usuario que por defecto está cerrado:

SQL> ALTER USER scott ACCOUNT UNLOCK;

Entramos ahora con este nuevo usuario que por defecto tiene el password “tiger”.

$ sqlplus /nolog
> connect scott/tiger

Veamos ahora su schema:

Sql> select * from cat;
TABLE_NAME                     TABLE_TYPE
------------------------------ -----------
DEPT                           TABLE
EMP                            TABLE
BONUS                          TABLE
SALGRADE                       TABLE

SQL> select ename,job,sal from emp;

ENAME      JOB              SAL
---------- --------- ----------
SMITH      CLERK            800
ALLEN      SALESMAN        1600
WARD       SALESMAN        1250
JONES      MANAGER         2975
MARTIN     SALESMAN        1250
BLAKE      MANAGER         2850
CLARK      MANAGER         2450
SCOTT      ANALYST         3000
KING       PRESIDENT       5000
TURNER     SALESMAN        1500
ADAMS      CLERK           1100

ENAME      JOB              SAL
---------- --------- ----------
JAMES      CLERK            950
FORD       ANALYST         3000
MILLER     CLERK           1300

14 rows selected.

¿Parece que Oracle funciona no?

instalar oracle en linux y no morir en el intento (parte i)

2009-12-08T16:48:00.005+01:00

El éxito o fracaso de una instalación de Oracle en Linux consiste básicamente en leerse un único documento: la Quick Installation Guide. Para la correcta instalación debemos de cumplir una serie de requisitos de hardware, software, parámetros de kernel y directorio requeridos. Si fallamos en uno de ellos el proceso de instalación fallará.

Para el siguiente post instalaremos un Oracle 10g R2 para Linux x86. Para ello lo descargamos directamente de la Web de Oracle. También necesitaremos a mano su guía de instalación.

Primero de todo hemos de revisar los requisitos de hardware de nuestra versión de Oracle dentro de la guía. Para ello necesitaremos una maquina x86, con 1Gb de RAM mínimo y unos 4Gb de disco para el software base de Oracle. Todo lo que sea superior a esto lógicamente será mejor. Por otro lado debemos seleccionar un sistema operativo que esté dentro de los sistemas operativos soportados por Oracle: Red Hat Enterprise 3, 4, SUSE Enterprise 9 y Asianux 1 y 2.

Yo voy a seleccionar un clon de Red Hat 4 como es CentOS 4. Si tuviéramos esta máquina en producción y quisiéramos que Oracle nos diera soporte en caso de problemas tendríamos que optar necesariamente por un sistema Red Hat si no queremos que Oracle se desentienda.

Empezamos pues la instalación:

+ Realizamos una instalación tipo servidor de un CentOS 4.8. Seleccionamos un particionado automático que utilizará LVM, configuramos el TCP/IP, desactivamos el firewall y también el SELinux.

+ Al finalizar la instalación comprobamos que tenemos acceso a Internet y que tenemos espacio suficiente en el sistema:

# ping www.google.com
# free (ver estado de la memoria y de la swap)
# df –h (ver espacio libre en /)

+ Actualizamos el sistema e instalamos los paquetes requeridos para la instalación:

# yum update
# yum groupinstall "X Window System" "GNOME Desktop Environment"
# yum install \
    setarch* \
    compat-libstdc++* \
    control-center* \
    gnome-libs* \
    gdb-6.1post* \
    make* \
    compat-gcc* \
    compat-gcc-c++* \
    glibc* \
    glibc-common* \
    glibc-devel* \
    gcc* \
    gcc-c++* \
    compat-db* \
    openmotif* \
    libstdc++* \
    libstdc++* \
    sysstat* \
    libaio* \
    libaio-devel*
# reboot

La instalación de Oracle utiliza un entorno de ventanas. Por este motivo he instalado el entorno gráfico en el servidor. Lógicamente en entorno solo lo arrancaremos para hacer la instalación, luego lo dejaremos apapagado.

+ Ahora creamos el usuario y los directorios necesarios para la instalación. Por defecto crearemos tres directorios: u01 (software base de oracle), u02 (archivos de la base de datos) y u03 (área de recuperación de datos).

# groupadd oinstall
# groupadd dba
# useradd -g oinstall -G dba oracle
# passwd oracle

# mkdir -p /u01/app/oracle
# chown -R oracle:oinstall /u01/app/oracle   
# chmod -R 755 /u01/app/oracle

# mkdir -p /u02/oradata
# chown -R oracle:oinstall /u02/oradata   
# chmod -R 755 /u02/oradata

# mkdir -p /u03/flash_recovery_area
# chown -R oracle:oinstall /u03/flash_recovery_area   
# chmod -R 755 /u03/flash_recovery_area

+ Configuramos los parámetros del Kernel. Para ello editamos el /etc/sysctl.conf y añadimos las siguientes líneas:

kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144

+ Ahora añadimos las siguientes restricciones en los siguientes archivos:

En el /etc/security/limits.conf:

oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536

En el /etc/pam.d/login:

session required pam_limits.so

Y finalmente en el /etc/profile:

if [ $USER = "oracle" ]; then
   if [ $SHELL = "/bin/ksh" ]; then
      ulimit -p 16384
      ulimit -n 65536
   else
      ulimit -u 16384 -n 65536
   fi
fi

Tras finalizar hacemos un reboot para cargar los nuevos parámetros del Kernel.

+ Ahora ya estamos en disposición de comenzar la instalación de Oracle. Para ello copiamos el “10201_database_linux32.zip” en una carpeta temporal. Por ejemplo en /usr/src/oracle10g.

Descomprimimos el software de Oracle:

# unzip /usr/src/oracle10g/10201_database_linux32.zip

+ Abrimos el entorno gráfico ya que el proceso de instalación de Oracle es en un entorno de ventanas.

# startx
# hostname
oracle.miserver.com
# xhost oracle.miserver.com
# su oracle
$ cd /usr/src/oracle10g/database
$ ./runInstaller

+ Una vez arranca el entorno gráfico de instalación hay que seguir las siguientes pantallas.
SimulacionInstalacion10gR2

+ Al finalizar la instalación no olvidarse de ejecutar (como root) los scripts de postinstalación tal como se recuerda.

# /u01/app/oracle/oraInventory/orainstRoot.sh
# /u01/app/oracle/oracle/product/10.2.0/root.sh

routing por diferentes proveedores

2009-11-29T10:49:00.016+01:00

Supongamos que tenemos un servidor (en este caso un servidor de VPN) que por cualquier razón su conexión a Internet (por el RouterA) se ha quedado pequeña. Hemos decidido comprar un nuevo router simétrico (el RouterB) para garantizar la calidad de la conexiones VPN para ciertas personas. Una grupo de personas se conectarán a la VPN por el RouterA y otros por el RouterB.

Este ejemplo es extensible a cualquier otro tipo de servicio que queramos ofrecer de forma que una parte del trafico va por un sitio y el otro por otro. La dificultad radica en que el tráfico debe volver por el mismo router por el que ha llegado.

Para realizar esto utilizaremos el comando "ip" que nos permite manipular las tablas de rutas, crear políticas de rutas y crear tuneles.

Veamos como está la tabla de rutas del servidor:

root# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     1      0        0 eth1
192.168.1.0     *               255.255.255.0   U     1      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 eth1
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

root# ip route show
192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.2  metric 1
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.6  metric 1
169.254.0.0/16 dev eth1  scope link  metric 1000
default via 192.168.1.1 dev eth0  proto static

Tanto el comando "route" e "ip route show" muestran la misma información. El comando "route" es la versión ligera del comando "ip route show".

Cuando Linux necesita enrutar un paquete busca dentro de las tablas su camino. Por defecto hay tres tablas de enrutamiento: local, main y default.

root# ip rule list
0: from all lookup local
32766: from all lookup main
32767: from all lookup default

Veamos que hay dentro de cada una de ellas:

root# ip route list table local
broadcast 192.168.1.0 dev eth0  proto kernel  scope link  src 192.168.1.6
broadcast 192.168.2.255 dev eth1  proto kernel  scope link  src 192.168.2.2
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
local 192.168.1.6 dev eth0  proto kernel  scope host  src 192.168.1.6
broadcast 192.168.1.255 dev eth0  proto kernel  scope link  src 192.168.1.6
broadcast 192.168.2.0 dev eth1  proto kernel  scope link  src 192.168.2.2
local 192.168.2.2 dev eth1  proto kernel  scope host  src 192.168.2.2
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1

root# ip route list table main
192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.2  metric 1
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.6  metric 1
169.254.0.0/16 dev eth1  scope link  metric 1000
default via 192.168.1.1 dev eth0  proto static

root# ip route list table default
(vacia)

Ver como la tabla por defecto del sistema (la que vemos al hacer "route") se llama main.

Lo que vamos hacer es crear dos tablas más (lan1 y lan2) para que contengan las rutas para cada una de las diferentes salidas a Internet. Para ello editaremos el archivo /etc/iproute2/rt_table con el siguiente contenido:

root# cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
10 lan1
20 lan2

Ahora crearemos las rutas que irán en cada una de estas tablas. Para que estas rutas se carguen en el sistema cada vez que arranquemos, la meteremos en /etc/rc.local:

root# cat /etc/rc.local
#!/bin/sh -e

ip rule add from 192.168.1.6 table lan1
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.6 table lan1
ip route add default via 192.168.1.1 table lan1

ip rule add from 192.168.2.2 table lan2
ip route add 192.168.2.0/24 dev eth0 src 192.168.2.2 table lan2
ip route add default via 192.168.2.1 table lan2

exit 0
root# reboot

Estas órdenes aseguran que el tráfico que proviene de una interfaz, es contestado por la misma interfaz.

Una vez reiniciado el sistema vemos si las rutas se han cargado correctamente en el sistema:

root# ip rule list
0:      from all lookup local
32764:  from 192.168.2.2 lookup lan2
32765:  from 192.168.1.6 lookup lan1
32766:  from all lookup main
32767:  from all lookup default

root# ip route list table lan1
192.168.1.0/24 dev eth0  scope link  src 192.168.1.6
default via 192.168.1.1 dev eth0

root# ip route list table lan2
192.168.2.0/24 dev eth0  scope link  src 192.168.2.2
default via 192.168.2.1 dev eth1

Cuando un paquete llega al servidor este comprueba por orden si se cumple alguna de las reglas de tabla. Primero mira si se cumple "from 192.168.2.2". Si se cumple utiliza la tabla "lan2", de lo contrario pasará a ver si se cumple "from 192.168.1.6". Si se cumple utilizará la tabla "lan2". Por ultimo utilizará la tabla por defecto "main".

Para depurar y ver que todo funciona se puede utilizar el comando tcpdump y ver si el trafico pasa por una interfaz o u otra.

El siguiente escenario también lo podríamos utilizar por ejemplo para un servidor de correo donde queremos que el trafico del webmail (puerto 80 y 443) vaya por una ISP y el trafico al 25 vaya por otro ISP.

Más información:
+ Linux Advanced Routing & Traffic Control HOWTO

mi script de backups

2009-11-08T13:46:00.007+01:00

Cuando empiezas hacer copias de backups, se suele empezar por un pequeño tar, luego lo programas diariamente, te envías un report por correo, luego lo envías a otra maquina y finalmente terminas haciendo copias completas e incrementales.

El siguiente script en Bash es el que utilizo para realizar copias diarias. Se ejecuta cada día en un cron. Los sábados realiza un backup completo y el resto de dias un incremental. Realiza un backup en local y también lo envía por SSH a una máquina remota.

Descargar kbackup.sh.

#!/bin/bash

### modificar las variables segun las necesidades

DATA_BACKUP="/etc/network /etc/ssh /etc/rc.local /var/log/syslog /var/log/auth.log
 /var/log/messages /var/log/dmesg /var/log/daemon.log"
LOCAL_DST_BACKUP="/var/backuplocal"
NAME_BACKUP="mi_srv"

SEND_REMOTE_BACKUP="yes"
REMOTE_DST_BACKUP="/var/backup/mi_srv"
HOST_REMOTE_BACKUP="srvbackup.miempresa"

DAY_FULL_BACKUP="Sun"

### variables especificas del script. No modificar

_LIST="/tmp/backup$$.list"

echo "kbackup.sh v0.1b, por amperis[@]gmail.com"
echo

case $1 in
   --help)
      echo "Sintaxis:"
      echo "  # ./kbackup.sh "
      echo
      echo "  --help: muestra la ayuda"
      echo "  --exec: ejecuta el script"
      echo
      echo "Notas:"
      echo
      echo "1) Editar este script y modificar las variables necesarias."
      echo "   DATA_BACKUP: Lista de directorio o fichero que de desean incluir en 
               el backup."
      echo "   LOCAL_DST_BACKUP: Directorio local donde se guardará la copia local 
               del backup."
      echo "   NAME_BACKUP: Nombre o prefijo del backup."
      echo "   SEND_REMOTE_BACKUP: yes/no, indicar si queremos que el backup tambien
               se copie"
      echo "      en un servidor remoto."
      echo "   REMOTE_DST_BACKUP: Directorio remoto donde debe copiarse el backup."
      echo "   HOST_REMOTE_BACKUP: Nombre de host o IP de la maquina remota que 
               almacena el"
      echo "      backup."
      echo "   DAY_FULL_BACKUP: Día de la semana que queremos hacer el full backup"
      echo
      echo
      echo "2) Crear una tarea programada diaria para este script."
      echo
      echo "   # crontab -e"
      echo "   @daily /root/script/kbackup.sh | mail -s 'Report de Backup' 
               admin@miempresa.com"
      echo
      echo "3) Para realizar el backup remoto es necesario que el servidor destino
               confie"
      echo "   en cliente. Copia su llave al servidor (http://amperis.blogspot.com
               /2009/02/scp-entre-maquinas.html)"
      echo     
      exit 0
      ;;

   --exec)
      echo "-> Inciado a las `date +%H:%M:%S`h"

      if [ -d "$LOCAL_DST_BACKUP" ]; then
        set $(date)
        ## Backup completo. Se realiza solo los sabados
        if test "$1" = "$DAY_FULL_BACKUP" ; then

           echo "-> Ejecutando copia completa del $3 de $2 del $6"
           _NAME_BACKUP="$NAME_BACKUP-full-$6-$2-$3.tgz"
           tar cfzv "$LOCAL_DST_BACKUP/$_NAME_BACKUP" $DATA_BACKUP
           rm -f $LOCAL_DST_BACKUP/$NAME_BACKUP-incr*

        else

           ## Backup incremental, se realiza el resto de dias
           echo "-> Ejecutando copia incremental del $3 de $2 del $6 ..."
           find $DATA_BACKUP -depth -type f \( -ctime -1 -o -mtime -1 \) -print > $_LIST
           _NAME_BACKUP="$NAME_BACKUP-incr-$6-$2-$3.tgz"
           tar cfzTv "$LOCAL_DST_BACKUP/$_NAME_BACKUP" "$_LIST"
           rm -f "$_LIST"

         fi

         echo "-> Backup creado: $_NAME_BACKUP"
         ## Enviado el backup a un servidor externo
         if [ $SEND_REMOTE_BACKUP = "yes" ]; then
            echo "-> Enviando backup a $HOST_REMOTE_BACKUP"
            rsync -avz $LOCAL_DST_BACKUP/ -e ssh root@$HOST_REMOTE_BACKUP:$REMOTE_DST_BACKUP
         fi

      else
         echo "ERROR: El directorio $LOCAL_DST_BACKUP no existe"
      fi
    
      echo "-> Finalizado a las `date +%H:%M:%S`h"
      ;;
   *)
      echo "Utilice la opción --help para más información."
      ;;
  
esac

actualizar versiones antiguas de ubuntu

2009-10-25T16:41:00.013+01:00

Dentro de las actualizaciones de Ubuntu podemos ir a buscar estas en dos repositorios muy diferentes. Uno en http://archive.ubuntu.com/ y el otro en http://old-releases.ubuntu.com/. El primero de ellos es el repositorio oficial donde se encuentran las tres últimas versiones de Ubuntu que aun están en mantenimiento y actualización. En el otro repositorio se encuentran todas las distribuciones de Ubuntu de las que se ha dejando de dar mantenimiento.

Como regla general, Ubuntu presenta nueva versión cada medio año (6 meses) y da mantenimiento de ella un año y medio (18 meses). Existen excepciones en el manteamiento ya que hay versiones de Ubuntu etiquetadas como LTS (Long Term Support) donde se presta un manteniendo de cinco años. Estas han sido la 6.06 LTS y la 8.04 LTS. Las versiones LTS permiten a los sysadmins montar servidores con altos periodos de vida sin necesidad de migrar de versión.

Si te ha dejado de funcionar el apt-get o el synaptic deberías comprobar si tú versión de Ubuntu se encuentra aún mantenida. Si no es así, deberías modificar tú source.list para que apt-get busque las actualizaciones dentro del old-releases.ubuntu.com.

En el siguiente ejemplo buscamos actualizaciones para la versión gutsy (7.10):

deb http://old-releases.ubuntu.com/ubuntu/ gutsy main restricted universe 
   multiverse
deb http://old-releases.ubuntu.com/ubuntu/ gutsy-updates main restricted 
   universe multiverse
deb http://old-releases.ubuntu.com/ubuntu gutsy-security main restricted 
   universe multiverse
deb http://old-releases.ubuntu.com/ubuntu/ gutsy-backports main restricted 
   universe multiverse

test de velocidad entre dos puntos de red

2009-10-01T19:21:00.013+02:00

La idea es saber cómo se encuentran dos puntos de red distantes (por ejemplo entre un centro en Barcelona, otro en Madrid y separados por una FrameRelay, una MPLS o por Internet). Lógicamente también sirve para medir la velocidad entre dos puntos de una misma LAN.

Normalmente haríamos un ping con tamaños variables de los paquetes y observariamos los retardos o simplemente descargariamos de un punto a otro un archivo por ftp, por web o por carpetas compartidas.

Con la utilidad Netcps.exe podemos montar un control de velocidad de un extremo a otro. Simplemente basta con copiar el ejecutable en cada una de las maquinas y poner a funcionar uno como servidor y el otro como cliente. El cliente Netcps.exe se conectará al servidor Netcps.exe del otro extremo y realizará una descarga de 100Mb. Finalmente te dará una media de la velocidad de la linea.

Supongamos que hacemos las pruebas en una red Ethernet a 100Mbps (que son aproximadamente 12.5MB/s). Lanzamos el servidor en una maquina:

C:\>netcps -server
NetCPS 1.0 - Entering server mode. Press ^C to quit
Waiting for new connection...

Ahora lo lanzamos desde la maquina cliente para obtener la velocidad (la dirección 192.168.1.106 es el otro punto extremo):

C:\>netcps 192.168.1.106
NetCPS 1.0 - Entering client mode. Press ^C to quit
Connecting to 192.168.1.106 port 4455... Connected!
---> CPS  11483136.00  KPS: 11214.00  MPS: 10.95
Avrg CPS  11432359.00  KPS: 11164.41  MPS: 10.90
Peek CPS  11509760.00  KPS: 11240.00  MPS: 10.98
Done. 104857600 Kb transferred in 9.17 seconds.

Como resultado vemos que la velocidad obtenida es de 10.9MB/s que lógicamente tiene que estar muy cercano a los 12.5MB/s reales que es la LAN Ethernet.

Más información:
- Conversor de velocidades

activar spf en zimbra

2009-09-22T20:52:00.018+02:00

Hay una persona que me matará cuando lea esta entrada. Seguro que me dirá algo como "¿cabroncete, después de 5 años me dices que no filtra por SPF?".

Se esperaba que con la versión 6 de Zimbra ya se trajera esto activado de serie... pero va ser que no. Y mucho peor, yo creía que ya lo traía de serie. Está muy bien que tú dominio ya esté preparado con los registros de SPF y esas cosas, ¿pero tú Zimbra los está utilizando?.

[root@zimbra ~]# dig txt google.com
...
google.com.   3600   IN   TXT   "v=spf1 include:_netblocks.google.com 
                                 ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
...

La respuesta es no. No tengo ni puta idea de por qué no lo está utilizando sabiendo desde hace años todo el problema del spam y concretamente del phishing.

Quien hace uso de esta funcionalidad dentro de todos los módulos Zimbra es el SpamAssessin. Es más, lo intenta cargar al arrancar:

# cat /opt/zimbra/conf/spamassassin/init.pre | grep SPF
loadplugin Mail::SpamAssassin::Plugin::SPF

Lo que se intenta cargar es el módulo de Perl llamado "Mail::SPF::Query" que normalmente no está instalado en una distribución Linux, tampoco lo instala Zimbra y tampoco está como recomendación. ¿Raro no?.

Simplemente debemos instalar el módulo de Perl Mail::SPF::Query y todos los requisitos que previamente nos hace saber:

# perl -MCPAN -e shell
cpan> install Mail::SPF::Query
cpan> force install Mail::SPF::Query (utilizar este comando si hay algún 
problema durante la instalación)

Ahora solo queda reiniciar Zimbra y ver en el log como se hace uso del nuevo módulo de SPF:

# zcontrol stop && zmcontrol start
# cat /var/log/zimbra.log | grep SPF
Sep 22 21:57:52 zimbra amavis[31739]: extra modules loaded after 
daemonizing/chrooting: Mail/SPF/Query.pm

Enviamos una par de emails de pruebas y miramos el cuerpo del mensaje. Uno utilizado el módulo SPF:

X-Spam-Status: No, score=1.763 tagged_above=-10 required=6.6
 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762,
 SPF_PASS=-0.001] autolearn=no

Y el otro sin utilizar el módulo de Perl:

X-Spam-Status: No, score=0.463 tagged_above=-10 required=6.6 tests=[AWL=1.299,
 BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762]
 autolearn=no

Ver como ahora hay un nuevo filtro llamado SPF_PASS.

Más información:
- http://www.zimbra.com/forums/administrators/33120-zcs-6-0-open-source-enable-spf.html
- http://wiki.zimbra.com/index.php?title=Improving_Anti-spam_system#SPF
- http://www.abuses.es/eswl/doc/spamassassin-eswl.pdf

lluvia en estambul

2009-09-15T18:39:00.004+02:00

La fecha, 9 de septiembre en Estambul, situación, datacenter de Vodafone... llegada de tormentas torrenciales. Momento desesperado el minuto 3:20.

configuración y uso de fetchmail

2009-09-14T17:46:00.004+02:00

fetchmail es una utilidad para UNIX/Linux que nos permite hacer de cliente POP/IMAP y descargar el correo de un buzón (o varios buzones) en local. Originalmente se basaba en otro proyecto llamado popclient hasta que al introducir el protocolo IMAP en 1996 cambio de nombre.

Puede ser utilizado para varias cosas. Una de ellas es para los usuario que no tienen acceso directo a Internet y es un admin (o ellos mismo) el que acceden a la cuenta de correo bajo fetchmail y le entregan el correo es su buzón local de su maquina. Yo, por ejemplo, lo utilizo para acceder a un buzón de correo donde hay multitud de correos para varios destinatarios y lo injecto al MTA de Postfix para que los reparta entre los buzones de los usuario finales.

Permite hacer pool de cuentas, acceder via SSL, liminar el numero de mensajes a descargar para reducir el ancho de banda, programar los pools cada cierto tiempo, descargar correos de un dominio concreto, reescribir direcciones de correo, etc.

A petición popular de zimbra-grupo se ha escrito un manual de fetchmail con casos reales de configuraciones.

configuración y uso de fetchmail.pdf

Más información:
+ Manual de fetchmail

google apps como servidor de correo de backup

2009-09-07T10:46:00.005+02:00

Google Apps tiene una versión gratuita que puede servirnos para usarla como servidor de correo secundario (backup) en nuestra infraestructura de empresa. La idea es que cuando nuestro servidor de correo principal este offline (servidor caído, mantenimiento, caída de la linea de Internet, etc) no perdamos ningún correo de los que nos envían.

Para ello simplemente nos damos de alta en el servicio con nuestro propio dominio y le decimos a Google Apps que comience a aceptar correo de nuestro dominio enviándoselo a una única cuenta de relay o backup.

Posteriormente nosotros, cuando el servidor primario vuelva a funcionar, comenzaremos haciendo un fecth de los correo.

Aquí tenéis toda la información necesaria: servidor_backup_googleapps.pdf

ocultando php

2009-09-06T17:05:00.008+02:00

Hace algún tiempo escribí un post explicando los tres parámetros básico para ocultar el rastro de versión que dejaba Apache y PHP. Aun así, cualquier usuario podía saber si nuestra Web estaba escrita en PHP simplemente viendo que los archivos cargados de la Web terminaban en ".php".
Con ayuda del módulo mod_rewrite de Apache vamos a reescribir todas las URL de forma que el usuario no sepa en ningún momento que tipo de archivo está cargando. Nuestro objetivo es reescribir URLs como "http://miweb/index.php?id=123" por una URL como "http://miweb/index?id=123". Si el usuario quisiera cargar la página "index.php" debería producir un error de que la página no existe ya que realmente la que debe cargar es "index".

Los archivos que creemos no debemos quitarles el .php ya que esto será transparente para el programador Web.

Para crear estas reglas hay que crear un .htaccess en la raiz de nuestra Web o modificar la configuración general (el httpd.conf) de Apache.

RewriteEngine on

# Rescribe /carpeta/archivo.php por /carpeta/archivo
RewriteRule ^([^.?]+)$ %{REQUEST_URI}.php [L]

# Devuelve 404 si hacemos la petición /carpeta/archivo.php
# Para Apache en Windows utilizar esta condición. Para Linux no utilizar [NC]
# RewriteCond %{THE_REQUEST} "^[^ ]* .*?\.php[? ].*$" [NC]
RewriteCond %{THE_REQUEST} "^[^ ]* .*?\.php[? ].*$"
RewriteRule .* - [L,R=404]

Más información:
- Apache mod_rewrite

los peligros del informador

2009-08-27T23:49:00.017+02:00

Una de las cosas que más gusta a un programador es saber en que servidor y que configuración por defecto tiene antes de empezar a programar su Web. Para los programadores de PHP tenemos una función muy bonita llamada phpinfo() que nos muestra una tabla colorida con toda la información de estado actual del motor de PHP, la versión del sistema Linux (o Windows), la ruta por defecto del php.ini, los módulos cargados del Apache, etc.

Muchas veces estas paginas quedan olvidadas dentro de nuestra aplicación Web a la espera que gente "despistada" las llame... nombres como hello.php, info.php e incluso phpinfo.php es lo normal.
Una búsqueda rápida en Yahoo o Google nos da una idea de los despistados programadores que han ido dejando sus pruebas.

La información que puedes encontrar en estas paginas es muy valiosa para la gente "con mucho tiempo libre", ya que puede encontrar números de versiones, módulos de Apache a los cuales poder atacar si existiera un bug, estado de los permisos de archivo o safe_mode o incluso en la variable path puedes encontrar otro tipo de software que corre en la maquina, como por ejemplo: NetBackups, tools de servidores Dell, antivirus, etc.

formularios php con muuu (parte ii de ii)

2009-08-24T15:26:00.003+02:00

muu posee diferentes tipos de datos que podrán utilizarse dentro de la función addField(). Estos pueden ser: text, textarea, password, select, radio o checkbox. Como vemos representan las estrucutas típicas de un formulario HTML.

Estos son algunos ejemplos:

$form->addField("text", "fecha", "Fecha de compra", array("instructions"=>"En 
       formato dd/mm/aaaa"));
$form->addField("checkbox", "vehiculo", "¿Qué vehiculo tienes?", 
       array("checkbixValues"=>array("moto"=>"Motocicleta","coche"=>"coche")));
$form->addField("select", "colores", "Seleccione un color", 
       array("selectValues"=>array("rojo"=>"Rojo","Azul"=>"Azul")));
$form->addField("radio", "sexo", "Sexo", 
       array("radioValues"=>array("hombre"=>"Hombre","mujer"=>"mujer")));
$form->addField("textarea", "opinion", "Su opinion");

Por otro lado, tambien tenemos un montón de tipos de reglas de validación. Veamos las más importantes:

- required: el campo no puede estar vacio.
- email: el campo debe ser una dirección de correo.
- emailorblank: el campo debe ser una dirección de correo o estar en blanco.
- rangelength: la longitud del campo debe estar dentro de un minlength y un maxlength
- equal: el valor del campo debe ser igual a otro valor
- lettersonly: el valor del campo debe tener solo letras
- aphanumeric: el valor del campo contiene letras y numeros
- numeric: el valor del campo contiene solo numeros
- maxvalue: el valor del campo no puede ser mayor del maxvalue
- minvalue: el valor del campo debe ser mayor que el minvalue
- float: el valor del campo debe ser un numero real
- integer: el valor del campo debe ser un numero entero
- ip: el valor del campo debe ser una dirección IP
- url: el valor del campo debe ser una dirección URL
- date: el valor del campo debe contener una fecha en formato dd/mm/aaaa.

Existen otras más y por si aun no se nos satisface nuestras necesidades siempre podemos utilizar la opción de regla "regex" que nos permite crear nuestra propia expresión regular para satisfacer nuestra propia regla de filtrado.

Veamos algunos ejemplos de estas reglas:

$form->addRule("required", "apellido", "El apellido no puede estar en blanco");
$form->addRule("date", "fecha_compra", "La fecha de compra no es correcta");
$form->addRule("rangelength", "password" , "La contraseña debe tener más de 3 
               caracteres", array("minlength"=>4,"maxlength"=>256) );
$form->addRule("equals", "clave", "Contraseñas diferentes", array("equalfield"=>"clave2"));

Para finalizar y una vez comprendido cómo funciona muuu, este es el código completo de una pagina de login desarrollada utilizando las librerías de muuu:

<?php
   include_once("muuu-v0.5.class.php");
   
   //--- campos de mi formulario
   $form= new muuu("form", "post", "login.php");
   $form->addField("text", "login", "Usuario: ", array("instructions"=>"(utiliza tú 
                   dirección de correo)") );
   $form->addField("password", "password", "Contraseña: ");
   $form->addField("submit", "boton", "", array("fieldAdd"=>"value='Enviar'"));

   //--- reglas de mi formulario
   $form->addRule("email", "login", "El nombre de usuario tiene que ser una 
                  direccion de correo válida.");
   $form->addRule("rangelength", "password" , "La contraseña debe tener más de 3 
                  caracteres", array("minlength"=>4,"maxlength"=>256) );
   
   if ( $form->formSuccess() == true ) {
      //--- procesamos los datos del formulario. En este caso se trata de una validación de usuario
      if ( $form->formValue("login")=="usuario@miempresa.com" &&
           $form->formValue("password")=="12345" )
         echo "Ok, estas dentro";
      else
         echo "Este usuario no es correcto";      
   } else {
      //--- arrancamos el formulario
      $form->startForm();
      echo "<fieldset>";
      echo "<legend>Inicio</legend>";
      //--- imprimimos el formulario
      foreach ( $form->fieldsarray as $key=>$value ) {
         echo "<p><label for='$key'>" . $form->labelsarray[$key] . "</label>$value</p>";
         echo "<p id='instructions'>" . $form->instructionsarray[$key] . "</p>";
         echo "<p id='error'>" . $form->errorarray[$key] . "</p>";   
      }
      echo "</fieldset>";
      $form->endForm();
   }
?>

formularios php con muuu (parte i de ii)

2009-08-23T17:56:00.013+02:00

Aunque suene a mugido de vaca española, "muuu" es una clase en PHP para facilitar a los programadores el desarrollo de formularios en PHP. Resulta muy pesado el escribir todo el código HTML del form, los campos, luego validarlos, repetir el campo si este no es correcto...

Para solucionar esto existe una librería libre llamada muuu que con dos funciones addField() y addRule() nos permite crear campos en nuestro formulario y lo más importante crear reglas que validen nuestro formulario. Para ver como funciona imaginemos que queremos una pagina PHP para validar a un usuario (una login.php). Con dos campos: nombre de usuario y contraseña. Como dos reglas, el nombre de usuario será una dirección de correo y la contraseña deberá tener más de 3 caracteres. Si no se cumple ninguna de estas reglas, el formulario no se procesa.

Lo primero que tenemos que hacer es cargar la librería, crear el formulario y añadir los campos que necesitamos (dos campos de texto y el botón de enviar):

   include_once("muuu-v0.5.class.php");
   $form= new muuu("form", "post", "login.php");
   $form->addField("text", "login", "Usuario: ", array("instructions"=>
                   "(utiliza tú dirección de correo)") );
   $form->addField("password", "password", "Contraseña: ");
   $form->addField("submit", "boton", "", array("fieldAdd"=>"value='Enviar'"));

Posteriormente debemos crear las reglas que deben cumplir nuestros campos. El usuario debe ser una dirección de correo electrónico y la contraseña debe tener más de 3 caracteres:

   $form->addRule("email", "login", "El nombre de usuario tiene que ser una 
                  direccion de correo válida.");
   $form->addRule("rangelength", "password" , "La contraseña debe tener más de 3 
                  caracteres", array("minlength"=>4,"maxlength"=>256) );

Una vez configurado nuestro formulario solo falta arrancarlo, imprimirlo en la Web y procesar el formulario si todos los campos han pasado las reglas:

   if ( $form->formSuccess() == true ) {
      //--- procesamos el formulario
   } else {
      //--- arrancamos el formulario
      $form->startForm();
      foreach ( $form->fieldsarray as $key=>$value ) {
         echo "<p><label for='$key'>" . $form->labelsarray[$key] . "</label>
              $value</p>";
         echo "<p id='instructions'>" . $form->instructionsarray[$key] . "</p>";
         echo "<p id='error'>" . $form->errorarray[$key] ."</p>";   
      }
      echo "</fieldset>";
      $form->endForm();
   }

El próximo post veremos el código completo de login.php

obtener todas las direcciones de correo

2009-08-18T13:04:00.000+02:00

La siguiente linea de comandos obtiene todas las direcciones de correo que aparecen dentro del log de Zimbra o cualquier otro archivo de log.

# sed -n -e '/postfix\/smtp\[.*status=sent/s/^.*to=<\([^>]*\).*$/\1/p' /var/log/zimbra.log | sort -u

hackeando el cristal glaseado con celo

2009-08-07T12:29:00.001+02:00

orden de preferencias en mysql

2009-08-03T00:27:00.007+02:00

En infomática por regla general la multiplicación y la división tienen preferencia sobre operaciones como la suma y la resta. Algo similar tambien sucede con operaciones lógicas como AND y OR. Las ANDs tienen preferencia sobre las OR. Una mala construcción de una consulta SQL nos puede jugar malas pasadas:

select true and false --> FALSE
select true or true and false --> TRUE

Esta característica se puede utilizar para saltarse mediante injección SQL paginas de login (en este caso PHP) que tengan una consulta así:

$sql = "
   SELECT * 
   FROM users 
   WHERE username='".$_POST["username"]."' AND password='".md5($_POST["psw"])."'";

Como vemos el campo password no es injectable ya que cualquier valor introducido es filtrado por una función. En este caso un hash md5.
El único parámetro injectable es username. Pongamos lo que pongamos en username siempre arrastraremos un "AND password=md5()" que por tanto deberá evaluarse.

Si tenemos en cuenta la prioridad en las operaciones AND/OR de MySQL podemos injectar con:

Username: ' or username<>'' or password<>'
Password: foo

La consulta SQL queda así:

SELECT * 
FROM users 
WHERE username='' or username<>'' or password<>'' 
      AND password='acbd18db4cc2f85cedef654fccc4a4d8'

La consulta siempre será evaluada a TRUE.

proteger ficheros en apache para su descarga

2009-07-29T15:29:00.008+02:00

Muchas veces cuando programamos directamente sobre una carpeta del DocumentRoot dejamos sin querer todo tipo de archivos como backups de una carpeta, volcado sql de una tabla, backup de un archivo php generado por nuestro editor de texto, archivos de include, etc. Todos estos archivos quedan disponibles para la descarga.

La directiva <FilesMatch> de Apache evita que cualquier archivo no deseado con información sensible pueda ser descargada. Para ello simplemente tenemos que pasarle una expresión regular con los archivo que queremos denegar el acceso y el Apache devolverá un error 403 cada vez que se intente acceder a ellos:

<FilesMatch "\.(old|bak|tgz|sql|inc|tar\.gz|zip|rar)$">
   Order Deny,Allow
   Deny from All
</FilesMatch>

La ultima vez que utilicé esto era para proteger dumps de SQL que se generaban automáticamente (ddmmaaa-backup.sql.tgz) y que por narices debían de permanecer dentro del DocumentRoot de la aplicación.

Solo hace falta darse un a vuelta por la Google Hacking Database para encontrar todo tipo de ficheros como estos por Internet.

¿qué es ITIL? (ii de ii)

2009-07-24T21:30:00.004+02:00

3. Transmisión del servicio

Consiste en preparar y dejar listo el servicio garantizando el menor impacto posible sobre los servicios en producción, las operaciones y la propia organización. Esta fase consta de tres procesos: gestión de cambios, gestión de la configuración y gestión de versiones.

La gestión de cambios tiene como objetivo emplear medios y procedimientos estandarizados para una tramitación eficaz y rápida de todos los cambios, a fin de reducir al mínimo el impacto sobre los servicios relacionados. Se define la figura del comité de cambios como un asesor que se reúne periódicamente para evaluar cambios y ayudar a priorizarlos.

La gestión de la configuración define y controla todos los componentes de una infraestructura IT y mantiene una base de datos con toda la información de las configuraciones (CMDB, Configuration Management Database).

Por último la gestión de versiones garantiza que existen planes de cambios y despliegues necesarios para mantener la alineación con los clientes y el negocio en los proyectos de cambios. Asegura que las versiones podrán crearse, instalarse, testearse y desplegarse exitosamente dentro de los plazos establecidos.

4. Operación del servicio

Consiste en coordinar y ejecutar las actividades, procedimientos y procesos necesarios para entregar y gestionar servicios con los niveles acordados. En esta fase se administra el servicio contratado por el cliente y se le da soporte.

Aparecen cinco procesos: gestión de incidencias, gestión de problemas, gestión de peticiones de servicio, gestión de accesos y gestión de eventos.

La gestión de incidencias tiene como objetivo restaurar la operación normal del servicio tan rápido como sea posible y minimizar el impacto negativo.

La gestión de problemas estudia más tarde y más detalladamente todas las incidencias producidas para evitar que se vuelvan a producir.

La gestión de peticiones define un único canal para que el cliente pueda recibir o solicitar servicios estándares (de nuestro catálogo) y aprobados.

El objetivo de la gestión de accesos es proporcionar a los usuarios autorizados el derecho a utilizar los servicios mientras se impide el acceso a otros. Se basa siempre sobre la gestión de disponibilidad y la gestión de seguridad de los puntos anteriores.

Por último la gestión de eventos proporciona la detección de fallos, proporcionando la capacidad en tiempo de real de comparar el rendimiento de nuestro servicio IT con lo contratado por el cliente en la SLA.

5. Mejora continua del servicio

Su objetivo es hacer recomendaciones sobre cualquier oportunidad de mejora durante toda la fase de vida del servicio. También intenta mejorar la rentabilidad de la prestación del servicio sin sacrificar la satisfacción del cliente.

¿qué es ITIL? (i de ii)

2009-07-24T19:55:00.012+02:00

Últimamente están apareciendo en muchos centros una nueva certificación llamada ITIL Foundation. Yo en su día me tuve que preguntar que era esto de la ITIL...
ITIL son las siglas de Information Technology Infraestructure Library, y como en muchas certificación IT consta de muchos cursos, cada uno con su examen y su pasta para desembolsar.

El primer curso de ITIL es el que se conoce como la ITIL Foundation v3, que básicamente es la base que se debe conocer. El concepto de ITIL recoge un conjunto de las mejores prácticas para la gestión eficiente de una infraestructura de servicios IT. Fue escrita por la agencia de telecomunicaciones británica en los 80 y se ha demostrado con el tiempo su utilidad en cualquier empresa de cualquier tamaño.

La ITIL Foundation se estructura y se estudia según cinco libros (no necesariamente en este orden):

- 1. Estrategia del servicio
- 2. Diseño del servicio
- 3. Transmisión del servicio
- 4. Operación del servicio
- 5. Mejora continua de la calidad del servicio

Como veis se trata de un orden lógico en el diseño, implementación y puesta en marcha de un servicio.

En la ITIL Foundation se da una explicación muy detallada de cada una de estas fases y como se relacionan entre sí. Además proporciona todo un vocabulario muy extenso que debe aprenderse ya que se utiliza constantemente en todos las fases.

Explico que es cada una de estas fases:

1. Estrategia del servicio

El objetivo de esta fase es identificar a la competencia y hacer diferenciar nuestro producto o servicio. Debemos encontrar respuestas a ¿qué servicios ofreceremos y a quién?, ¿cómo nos diferenciaremos?, ¿cómo alcanzamos una calidad de servicio?... En esta fase ITIL distingue tres procesos llamados: gestión financiera, gestión de la demanda y gestión del portfolio.

En la gestión financiera debemos de cuantificar, a través de una análisis de inversión, el coste de cada uno de nuestros servicios IT a lo largo de todo su proceso de vida.

En el proceso de gestión de la demanda debemos calcular con precisión la demanda que puede suponer un servicio y de esta forma ajustar al máximo los recursos IT que poseemos.

Por último en la gestión del porfolio encontraremos todo lo que sabemos hacer. No todo está disponible, pero un buen porfolio nos permite anticipar nuestros servicios IT a la competencia.

2. Diseño del servicio

El objetivo de esta fase es diseñar el servicio IT siempre minimizando los riesgos, cumpliendo los objetivos marcados en la estrategia y ahorrando en tiempo y dinero. En el diseño del servicio se definen 5 procesos: gestión del catálogo, gestión del nivel del servicio, gestión de la disponibilidad, gestión de la continuidad, gestión de los proveedores, gestión de la seguridad y gestión de la capacidad.

La gestión del catálogo es proporcionar una única fuente de información de todos los productos que proporciona nuestra empresa. Se trata de un subconjunto de servicios disponibles en nuestro porfolio (definido en la estrategia del servicio). Nosotros ofrecemos nuestro catálogo de servicio al cliente y cualquier otra cosa que no se encuentre en nuestro catálogo, para ITIL no se puede ofrecer.

La gestión del nivel del servicio controla y mejora los niveles acordados al comprar un servicio. Se define el concepto de SLA (Service Level Agreemet) que se estipula en el contrato del cliente (tiempos de respuesta, tiempos de parada, horarios de atención al cliente, etc).

La gestión de la disponibilidad optimiza los recursos de nuestra IT para que todo funcione correctamente para cumplir la SLA firmada por el cliente.

La gestión de la continuidad del servicio se preocupa de que todo siga funcionando en caso de una fuerza mayor. Por ejemplo redundando lo servicios en otro lugar y siempre teniendo en cuenta que la continuidad de nuestro servicio debe cumplir la SLA.

La gestión de los proveedores negocia y acuerda todos los contratos con terceros. El mantenimiento de una política con nuestros proveedores debe asegurar como siempre los niveles de SLA. No podemos dejar de prestar un servicio porque nuestro proveedor nos ha fallado.

La gestión de la seguridad como este todas políticas de seguridad debe asegurar la confidencialidad, la integridad y la disponibilidad de toda la información que manipulamos. Además incluye políticas sobre control de contraseñas, acceso remoto y el uso correcto de todos los activos por parte de los trabajadores.

Por último la gestión de la capacidad es la encargada de que todos los servicios se vean respaldados por una capacidad de proceso y almacenamiento suficiente. Debemos estudiar que los recursos se aprovechen adecuadamente (ni más ni menos) para evitar inversiones innecesarias. O peor aun, que los recursos que tengamos se queden cortos y no nos permitan cumplir la SLA.

hackeando las pilas

2009-07-24T10:09:00.000+02:00

un ordenador en la luna

2009-07-21T18:04:00.006+02:00

No se que pasa que cada día en la tele estamos llegando a la luna. Cada día estamos celebrando que el hombre llegó a la luna. Yo soy de los que no se cree que llegara, al menos, en la fecha oficial.

Lo que si me ha hecho gracia y he perdido un poco el tiempo es en leer la publicación del diseñó interno del AGC (Apollo Guidance Computer) o para los mortales que veían Start Treck el ordenador de a bordo o TomTom. Viendo los diagramas del diseño y la reducción de puertas lógicas me parecía haber vuelto a la universidad cuando estudiaba la asignatura de estructura de computadores.

Resulta que el AGC puede considerarse el primer computador de circuito integrado empotrado y en tiempo real. Tenía un procesador de 1Mhz y 4Kb de memoria RAM. Además tenia un juego de 11 instrucciones. Este cacharro se utilizaba para realizar los cálculos para los aterrizajes y los acoplamientos. A lo largo de las diferentes misiones del Apollo se fue perfeccionando su funcionamiento ya que en su primera misión este cacharro fallo y los astronautas del Apollo 11 tuvieron que aterrizar de forma manual.

Aquí tenéis los planos del AGC por si queréis montaros uno en casa y subiros en un petardo para llegar a la luna. Son más de 1000 paginas de diseño con un coste de $3000 en componentes.

Ya me veo algún becario de arquitectura de computadores que le manden de proyecto final de carrera la implementación del AGC. A pelearse con los mapas de Karnaugh.

mira dentro de mí

2009-07-15T16:09:00.012+02:00

Cuando enviamos un correo electrónico de una dirección a otra, toda esta información se envía en formato texto ASCII. Incluso cuando adjuntamos una imagen o un archivo PDF el correo resultante que viaja de un servidor a otro lo hace en formato texto.
Para ello se utilizan conceptos como los tipo MIME y la codificación en Base64. Hoy día es difícil ver correos que no este hechos en formato HTML con imágenes y a todo color.

Cuando enviamos un correo no solo estamos enviado el cuerpo del mensaje con su From/To, sino mucha más información como editor de correo donde se escribió el mensaje, cuales han sido los antivirus que han analizado el correo, por donde ha ido pasando el correo etc.
El analizar las cabeceras de un correo electrónico puede ser una manera de depurar errores y de comprender un poco más el funcionamiento del SMTP.

Aquí tenéis un ejemplo de un correo que utilizaré para explicar cada una de las partes que lo componen: example_mail.txt.
Se trata de un correo de publicidad de masters de la Universidad de La Salle (Barcelona) enviado a mí a través de una lista de distribución tal como veremos. Desde cualquier cliente de correo podéis acceder a las cabeceras de un correo electrónico.

Si abrimos este correo de ejemplo lo primero que miraremos es quien lo escribe y quien lo recibe:

From: "BES La Salle" <infosolicitud@lasalleonline.net>
To: <infosolicitud@lasalleonline.net>

Es curioso ver que el emisor y el receptor son la misma persona. ¿Cómo puede ser?. En este caso se trata de una lista de distribución. Para ello debemos fijarnos en:

Delivered-To: amperisblog@gmail.com
List-Unsubscribe: <http://columba.salleURL.edu/cgi-bin/mailman/options/infoalumnes>,
                <mailto:infoalumnes-request@columba.salleURL.edu?subject=unsubscribe>
X-Mailman-Approved-At: Fri, 10 Jul 2009 10:09:03 +0200

Nos da la posibilidad de borrarnos de la lista de distribución. Este tipo de casos también pude darse cuando se envia un mail con copia oculta. En el campo To: no aparece nuestro nombre. Esto es debido a que nos han puesto como copia oculta.

También tenemos el campo Date que indica la hora a la que se escribió el mensaje. No es la hora en la que se descargó el mensaje. Por este motivo si tenemos algún problema con nuestro servidor de correo y los correos llegan tarde, es normal que nos aparezcan en nuestra bandeja de entrada correos de fechas pasadas. Normalmente la bandeja de entrada está ordena por fecha.

Date: Fri, 10 Jul 2009 10:08:34 +0200

También podemos ver los diferentes servidores MX por los que ha ido pasando el correo y extraer mucha información de como una empresa tiene implementado sus servidores de correo. Para ello nos tenemos que fijar en los campos "Received":

Received: by 10.103.218.8 with SMTP id v8cs318399muq;
        Fri, 10 Jul 2009 01:10:31 -0700 (PDT)
Received: by 10.204.50.195 with SMTP id a3mr1643982bkg.123.1247213430935;
        Fri, 10 Jul 2009 01:10:30 -0700 (PDT)
Received: from relay1.salle.url.edu (relay1.salle.url.edu [84.88.232.246])
        by mx.google.com with ESMTP id 27si1340370fxm.114.2009.07.10.01.10.29;
        Fri, 10 Jul 2009 01:10:30 -0700 (PDT)
Received: from columba.salle.url.edu (columba.salleURL.edu [84.88.232.238])
 by relay1.salle.url.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6A8A2sH019065
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
 Fri, 10 Jul 2009 10:10:03 +0200
Received: from columba.salle.url.edu (localhost [127.0.0.1])
 by columba.salle.url.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n6A894eQ014556;
 Fri, 10 Jul 2009 10:09:59 +0200
Received: from jordiribesi00cc (pcjribes.salle.url.edu [172.16.17.189])
 (authenticated bits=0)
 by columba.salle.url.edu (8.14.3/8.14.3/Debian-5) with ESMTP id
 n6A88ZMC014449; Fri, 10 Jul 2009 10:08:35 +0200

El primer Received que encontramos es directamente nuestro servidor donde está alojado el correo a la espera que nosotros lo leamos por POP/IMAP/Webmail. El último "Received" es el primer servidor SMTP que recibió el correo.
Podemos ver como el correo lo escribió una persona llamada jordiribesi00cc, que su ordenador tenia la IP 172.16.17.189 y que se lo envió a su servidor de correo llamado columba.salle.url.edu" que resulta ser un Sendmail versión 8.14.3 con un Debian v5.
Luego lo volvió a recibir la maquina columba.salle.url.edu en la IP 127.0.0.1. Esto es posible porque se lo pasó al antivirus alojado en su misma maquina. Posteriormente se lo envía a una maquina de relay de correo bajo el nombre de relay1.salle.url.edu a través de una sesión cifrada (cipher=DHE-RSA-AES256-SHA). Finalmente esta maquina sale de la empresa salle.url.edu y contacta con Google para entregarle el correo. La maquina relay1.salle.url.edu con IP pública 84.88.232.246 contacta con el servidor mx.google.com y le entrega el correo a las 01:10:30 hora verano del Pacifico Norte (PDT=UTC-7).
Para finalizar, el correo va pasando por dos máquina más de Google hasta que a las 01:10:31 hora verano del Pacifico Norte se almacena en el servidor con IP 10.103.218.8.

Notar que hay 7 saltos para hacer llegar el correo de un servidor a otro. ¿Son 7 o son más?. Realmente no lo podemos saber. Podría ser el caso que algún servidor interno, por ejemplo Google, no notificara en sus cabeceras por donde va pasando dicho correo.
Otra cosa interesante es saber la versión de Sendmail que está utilizando salle.url.edu. Deberíamos evitar que nuestros servidores dejaran información sobre versiones y sistemas operativos de los servidores de correo. Normalmente por cuestiones de seguridad y bugs que puedan ser explotados.

Se está trabajando en técnicas conocidas como "Reciprocation of SMTP Trace Record" para depurar por donde a ido pasando un correo electrónico. Incluso existe alguna Web que haces un copy-paste del tus Received y te dibuja en un mapa la ruta seguida por el correo al más puro estilo Neotrace.

Los antivirus y otros filtros también dejan su marca cada vez que escanean un correo:

X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on relay1.salle.url.edu
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on columba.salle.url.edu
X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on columba.salle.url.edu
X-Virus-Status: Clean
X-Scanned-By: MIMEDefang 2.64 on 84.88.232.246
X-Scanned-By: MIMEDefang 2.64 on 84.88.232.238
X-Scanned-By: MIMEDefang 2.64 on 84.88.232.238

Estamos en lo de simpre... evitar que aparezcan versiones y cualquier tipo de información.

Nota: Para evitar que nuestro Postfix/Sendmail anote sus direcciones IP internas o externas en la cabeceras hay que retocar el código fuente y recompilar.

Para debugear este correo cuando llega al primer servidor de correo se añade una marca de idetificación llamada Message-ID. Esta marca la podemos utilizar para tracear el mensaje dentro de nuestros logs de correo.

Message-ID: <000601ca0135$9f2ab0b0$dd801210$@net>

Finalmente llegamos a la parte del cuerpo del mensaje. Dado de que se trata de un correo con imágenes, en HTML y con archivos adjuntos este correo debe ser compuesto en formato MIME (Multipurpose Internet Mail Extension). El MIME son unas extensiones del protocolo SMTP que me permite intercambiar todo tipo de contenido (video, PDF, imágenes, Words, etc) de forma transparente para el usuario.

Lo primero que debemos encontrar son estas dos cabeceras:

MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----=_NextPart_000_0007_01CA0146.62B380B0"
X-Mailer: Microsoft Office Outlook 12.0

Lo primero indica que estamos utilizando MIME v1 y el segundo nos indica que el mail está estructurado en varias partes (cuerpo, adjuntos, cuerpo en HTML, etc). En este caso cada parte podrá contener más objetos de tipo MIME. Para separar cada parte de los objetos MIME se utilizará la marca "----=_NextPart_000_0007_01CA0146.62B380B0". Vemos también que el cliente de correo que ha construido el mail en formato MIME a sido un Outlook 2007.

Dentro del objeto MIME con marca "----=_NextPart_000_0007_01CA0146.62B380B0" veremos que encontramos otros objetos MIME que lógicamente también contienen su marca. Por ejemplo "----=_NextPart_001_0008_01CA0146.62B380B0" o "----=_NextPart_002_0009_01CA0146.62B380B0".

Bajo la marca "----=_NextPart_002_0009_01CA0146.62B380B0" encontramos el cuerpo del mensaje en formato texto o "text/plain". Este tipo de objeto se añade por si el receptor no tiene un cliente de correo que acepte HTML.
Luego encontraremos bajo esta misma marca el mismo correo pero en formato HTML o "text/html". Este tipo de objeto se añade para los clientes que tienen un cliente de correo compatible con HTML.

Finalmente, los ficheros adjuntos también van dentro de su tipo MIME:

------=_NextPart_001_0008_01CA0146.62B380B0
Content-Type: image/jpeg;
 name="image001.jpg"
Content-Transfer-Encoding: base64
Content-ID: 

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf
IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7
Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAB8AoQDASI
...

En este caso, una de las imágenes a sido añadida como un tipo de fichero adjunto. Para ello le decimos que es de tipo MIME "image/jpeg", que la imagen se llama image001.jpg y que está codificada en Base64. La codificación siempre es necesaria ya que al tratarse de un formato binario este debe convertirse en un formato de texto ASCII para poder ser enviado por SMTP.

Hay otras muchas cabeceras que incluso no salen es este mail de ejemplo. Todas ellas esta explicadas en sus RFCs correspondientes: RFC2045 y RFC2821.

Más información:
- http://es.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions
- http://es.wikipedia.org/wiki/Base64

parando un DoS con nada

2009-07-10T18:06:00.002+02:00

Hay situaciones en las que se produce un ataque de DoS y no tenemos nada para pararlo, o al menos, no tenemos el suficiente control sobre los servidores para detener el ataque. La manera más fácil de denegar las IPs de maquinas que nos atacan es utilizar una cosas que se llama null-route. Es decir, enviar los paquetes a una ruta sin salida.
He de suponer que no tenemos iptables, que no tenemos control sobre los firewall externos, que no tenemos control sobre apache o postfix... solo somos unos pobres admins que nos dedicamos a controlar el estado de la máquina.

Es fácil ver que algo está pasando con un "netstat". Sobre todo cuando tenemos decenas de IPs iguales (DoS) o diferentes (DDoS) conectadas, en un estado de estar pero sin estar: SYN o un SYN_RECV.

Para bannear una IP de estas con un null-route basta con enviar los paquetes de vuelta hacia esa IP por la interfaz de loopback. Supongamos que el ataque viene de 89.140.142.56:

# route add 89.140.142.56 lo

Y ya está. Sin reiniciar, sin iptables, sin tcpwrappers, sin tocar el pix, sin tocar el router... Más información:
- parando un DoS con iptables

mi receta para dom4j

2009-07-09T15:18:00.004+02:00

Hace ya una semana que se publicó un parche para todas las versiones de Zimbra como solución a un bug grave. Lo normal para arreglar bugs era esperar a una nueva versión. Desde la versión 3 solo recuerdo haber añadido un parche de urgencia.

Llevo varios días con el parche instalado y la verdad es que todo funciona igual (es decir, de puta madre). Por lo que he podido ver en el desempaquetado del Jar, el problema debe ir por algún tipo de injección XPath, que tal como dice el descubridor, permite el acceso no autorizado a los archivos situados en el store del Zimbra.

Esta es mi receta de pasos para un Zimbra 5.0.16 bajo CentOS 5. Notar que hay dos archivos Jar para cambiar:

(creamos una carpeta de backup y paramos Zimbra)
# mkdir /backup
# su - zimbra
# zmcontrol stop
# exit
# cd /tmp

(descargamos el patch)
# wget http://files.zimbra.com/downloads/security/dom4j-1.5.jar

(dentro de Zimbra hay dos archivos dom4j-1.5.jar y comprobamos que sean el mismo)
# md5sum /opt/zimbra/lib/jars/dom4j-1.5.jar
# md5sum /opt/zimbra/jetty-6.1.5/common/lib/dom4j-1.5.jar

(hacemos un backup y los sustituimos)
# cp /opt/zimbra/lib/jars/dom4j-1.5.jar /backup
# cp /tmp/dom4j-1.5.jar /opt/zimbra/lib/jars/
# cp /tmp/dom4j-1.5.jar /opt/zimbra/jetty-6.1.5/common/lib/

(les ponemos permisos y arrancamos Zimbra)
# chown zimbra:zimbra /opt/zimbra/lib/jars/dom4j-1.5.jar
# chown zimbra:zimbra /opt/zimbra/jetty-6.1.5/common/lib/dom4j-1.5.jar
# su - zimbra
# zmcontrol start

Más información:
- Una nueva herramienta desde los mandriles

dónde está cada cosa

2009-07-08T13:33:00.002+02:00

Tanto si elegimos una distribución de Zimbra en Ubuntu/Debian como en RedHat/Fedora, encontraremos dentro de la instalación una carpeta llamada /packages. En esta carpeta están todos los archivos necesarios para la instalación de Zimbra en formato binario .deb si bajamos un Ubuntu o .rpm si bajamos una RedHat. Es curioso como como por cada versión va y va creciendo el tamaño de estos paquetes.
¿Alguien ha mirado que hay dentro de cada paquete? ¿qué archivos instala cada paquete?

Esto es un resumen de lo que hay dentro de cada uno de los paquetes .rpm para una versión 5.0.16.

+ zimbra-apache...rpm: Solo encontramos los archivos de Apache HTTP 2.2.8 y sus archivos de configuración.

+ zimbra-core...rpm: Este es el paquete que más cosas instala. Instala los script bashrc y profile del usuario Zimbra, la carpeta bin, conf, CURL 7.18.1, Cyrus-SASL 2.1.22, docs, Heimdal 1.2, el JDK 1.5, la carpeta libexec, OpenLdap Libs 2.3.43, Openssl 0.9.8, Sleepycat 4.2.52, Tcmalloc 0.97 y Zimbramon.

+ zimbra-ldap...rpm: OpenLDAP 2.3.43

+ zimbra-logger...rpm: Instala el logger con un MySQL 5.0.67

+ zimbra-mta...rpm: Amavis-new 2.5.4, ClamAv 0.94.1 y Postfix 2.4.7

+ zimbra-proxy...rpm: memcache 1.2.5 y nginx 0.5.30

+ zimbra-snmp...rpm: net-snmp 5.4.1

+ zimbra-spell...rpm: aspell 0.60.6

+ zimbra-store...rpm: Jetty 6.1.5, MySQL 5.0.67, la wiki y los zimlets.

Como cosa curiosa ver que MySQL se instala dos veces: una para el store y otra para el logger. Una cosa es que tengamos dos instancias del mismo software corriendo, pero ¿instalar dos veces todos los binarios de MySQL?.

este finde estoy disponible (ii de ii)

2009-07-06T14:43:00.001+02:00

Para maximizar la disponibilidad (hacerla tender a 100%) hay que minimizar el riesgo. Hay que tener bien claro cuales pueden ser los posibles fallos de mi sistema, cual es la probabilidad que esos fallos se produzcan y cuales son los impactos en mi sistema de cada uno de esos fallo.
El problema es la aparición de la palabra "probabilidad". ¿Como puedo formular una probabilidad de algo que aun no ha pasado?.

Esto es un pequeño ejemplo de un "calculo de riesgo (relativo)" en un servicio de correo electrónico. Naturalmente es solo una base, ya que dentro de un calculo de riesgo existen varios métodos predictivos e infinidad de variables de riesgo.

Supongamos que tenemos un sistema de correo en el cual, después de un estudio hemos llegado a la conclusión de que solo existen dos posibles fallos de riesgo (naturalmente son muchos más).
Una rotura de disco SCSI que hemos llegado a la conclusión de que es poco probable y por tanto tiene una probabilidad de 0,2. Otro posible fallo es la caída de la linea de Internet que esto es más frecuente con una probabilidad de 0,8.
Por otro lado hemos llegado a la conclusión que la rotura de disco tiene un impacto catastrófico ya que no tenemos RAID. Por tanto el impacto en una escala de 10 sería un 9. Para el caso de la caída de Internet, tenemos un impacto de 2 ya que tenemos una linea de Internet redundante y con un simple cambio volvemos a tener conexión.

                   Prob.    Impac.
rotura disco       0,2      9
caida de internet  0,8      2

Si realizamos este cálculo:

0,2 * 9 = 1,9 riesgo
0,8 * 2 = 1,6 riesgo

Viendo los resultados vemos que la rotura de disco me supone un mayor riesgo y por tanto debería reducir al máximo mi riesgo.
La probabilidad de que se produzca un fallo es de 0,2. Esta probabilidad es imposible cambiarla ya que es inherente al propio hardware, en este caso un disco SCSI. Lo que si puedo minimizar es el impacto si en vez de utilizar un disco SCSI, utilizo dos discos SCSI en RAID y por otro lado realizo copias de seguridad diarias. Si implantamos todo esto vemos que el impacto de la rotura de un disco pasa de 9 a 4. Si volvemos hacer nuestro análisis de riesgo tenemos que ahora (0,2*4=0,8) la caída de la linea de Internet tiene un riesgo mayor.

este finde estoy disponible (i de ii)

2009-07-04T12:47:00.008+02:00

Uno de los parámetros que se pueden medir matemáticamente a la hora de montar nuestro servicio IT es la disponibilidad, la fiabilidad y la mantenibilidad. Todos ellos están relacionados con el tiempo de funcionamiento de nuestro servicio. Es decir, contra menos tiempo parado pase nuestro servicio, más disponible, más fiable y menos mantenible es.
Debemos distinguir entre el tiempo de parada debido a una incidencia (por ejemplo, una caída de Internet, un disco roto, una excepción de programación no controlada, etc) y el tiempo de parada debido a un mantenimiento (actualización mensual del software, un reboot programado, etc). Todo el tiempo de mantenimiento programado no debe contabilizarse desde de la disponibilidad, fiabilidad o mantenibilidad, ya que lo que queremos calcular es el tiempo de paradas no previstas y que por tanto, pueden afectar a la calidad del servicio por lo cual el cliente está pagando.

Una parada programada no afecta a la calidad del servicio ya que el cliente en su contrato ya sabe de la existencia de tantas paradas programadas al mes (por ejemplo el servicio de correo puede sufrir 1 una parada programada al mes de no más de 5 minutos).

Como hemos dicho tenemos tres valores para calcular:

+ Disponibilidad o availability: porcentaje de tiempo activo frente a tiempo inactivo.

+ Fialibilidad o reliability: lapso de tiempo entre fallos de servicio o componentes. Este valor nos lo da el MTBS (Mean Time Between Failures o Tiempo medio entre fallos).

+ Mantenibilidad o maintainability: lapso de tiempo para reparar el servicio o componente. Este valor nos lo da el MTRS (Mean Time to Restore Service o Tiempo medio de restauración del servicio).

Supongamos que tenemos un servicio de correo electrónico con un servidor Zimbra y que durante un año estos han sido los downtimes del servicio:

05/03/2008 -> 1h de caída del servicio
16/06/2008 -> 2h de caída del servicio
01/08/2008 -> 0,5h de caída del servicio
23/11/2008 -> 8h de caída del servicio
24/11/2008 -> 2h de caída del servicio

5 paradas de 13,5 horas de caída del servicio
Horas de un año: 365 dias * 24h = 8760h

Calculamos pues la disponibilidad, la fiabilidad y la mantenibilidad:

D = ( (8760-13,5)/8760 ) * 100% =  99,8% (disponibilidad)
MTBF = (8760-13,5)/5 =  1749h entre cada fallo (tiempo medio entre fallo)
MTRS = 13,5/5 = 2,7h de reparación (tiempo medio reparación)

Ahora la pregunta es: ¿esto es malo?, ¿el cliente podría quejarse?, ¿podría cancelar el servicio de correo electrónico?. La respuesta es depende. Depende lo que hayamos firmado. Es decir, dentro del contrato existen lo que se llaman las SLA (Service Level Agreement o Acuerdos del nivel del servicio). Si en la SLA firmada por el cliente dice que la disponibilidad del servicio no será menor de 99,0% pues el cliente no tiene base para poder realizar una queja ya que estamos en el nivel establecido.

file descriptors (ii de ii)

2009-07-03T09:35:00.000+02:00

Hasta ahora no hemos hablado para nada de la salida estandard STDERR. Este tipo de salida es utilizada por los procesos para mostrar los errores o para trabajos de diagnóstico. Como mencioné en el primer post la STDIN y la STDERR se muestran por el terminal. La información "buena" del proceso y la información de error se entremezclan.

Supongamos que tenemos un proceso el cual es susceptible de producir errores. Supongamos también que se lanza cada día en un cron de la siguiente forma:

# miproceso > /var/log/miproceso.log

Aparentemente, el proceso cada día se ejecutará y almacena su resultado dentro de /var/log/miproceso.log. No es correcto del todo. Dentro del miproceso.log solo encontraremos el resultado de la STDOUT de miproceso, pero no los errores que se hayan producido. Es decir, el resultado legitimo del programa lo hemos redireccionado a un fichero, pero los errores se siguen mostrando por el terminal. Para solucionar esto, tenemos que redidireccionar la STDOUT y la STDERR con la siguiente sintaxis:

# miproceso > /var/log/miproceso.log 2>&1

Le estamos diciendo que la STDERR (o file descriptor 2) se redireccione al mismo sitio donde esta redireccionado la STDOUT (o file descriptor 1).

También es posible redireccionar cada salida a un archivo diferente. Es decir que los resultados vayan a un log y los errores a otro log:

# miproceso 1> /var/log/resultado.log
# miproceso 2> /var/log/errores.log

Veamos un ejemplo real de la existencia y del funcionamiento de STDERR. Supongamos que tenemos un archivo llamado "pepe.txt" que no existe. Si intentamos ver su contenido se producirá un mensaje de error. Este mensaje de error, aunque haya gente que cree lo contrario, lo vemos por pantalla pero no viene de la STDOUT. Viene de la STDERR. Redireccionemos los errores del comando cat a un fichero de log.

# cat pepe.txt
cat: pepe.txt: No existe el fichero ó directorio
# cat pepe.txt 2>error.log
# cat error.log
cat: pepe.txt: No existe el fichero ó directorio

Otro ejemplo muy utilizado de los redirectores es utilizarlo junto con el dispositivo null. El dispositivo /dev/null es un dispositivo que todo lo que enviemos se perderá en el infinito. Pensémoslo como un dispositivo papelera. Se utiliza mucho cuando queremos ejecutar un proceso y no queremos almacenar nada de su resultado. Es decir, no queremos que muestre nada por el terminal:

# miproceso > /dev/null 2>&1

Tanto la STDOUT como la STDERR las envio a la papelera.

Un comando muy utilizado junto con las pipe es el comando de Linux tee. Si utilizamos un redirector hacia un archivo, el problema que tenemos es que ya no veremos nada por el terminal. Si lo que queremos es redireccionar y al mismo tiempo ver por el terminal debemos utilizar un tee:

# cat /etc/passwd | grep root | tee resultado.txt | less
root:x:0:0:root:/root:/bin/bash
# cat resultado.txt 
root:x:0:0:root:/root:/bin/bash

El comando tee recibe por su STDIN unos datos que los almacena en resultado.txt y al mismo tiempo los manda por su STDOUT lo que posibilita que los veamos por el terminal.

No solo Linux/UNIX dispone de esta potencia en sus shells. Windows con la aparición de la Windows Power Shell también dispone de todas estas funciones.

file descriptors (i de ii)

2009-06-30T16:17:00.016+02:00

La potencia de los shells de Linux (como puede ser Bash) radica en la posibilidad de unir comandos pasando la información de uno hacia el otro. Tareas que a primera vista pueden resultar complicadas con un simple comando se hacen bastante sencillas con la unión de comandos usando conductores y redirectores.

En Linux/UNIX tenemos tres archivos llamados STDIN, STDOUT y STDERR. Estos archivos y las capacidades de la "standard I/O" nos ofrecen la posibilidad de controlar el flujo de datos que entran, salen o muestran información de error.
Como comportamiento estandard, un flujo de STDIN o entrada está provocado por las pulsaciones de un teclado. Por ejemplo, cuando arrancamos el programa "mail" este estará leyendo de STDIN todas las pulsaciones de teclado para ir construyendo el mail.
Para el caso de STDOUT, este como comportamiento estandard está enlazado con el monitor. Por tanto todo lo que enviemos aquí se verá reflejado por el monitor.
El caso de STDERR es similar al de STDOUT. Por defecto su contenido se enviará al monitor.

Estos archivos también reciben el nombre de "standard input", "standard output" y "standard error". También se les puede indentificar con un numero, "file descriptor 0", "file descriptor 1" y "file descriptor 2" respectivamente.

Cada vez que lanzamos un proceso asociamos estos tres file descriptors correspondientes.

Veamos ahora las dos herramientas que me permiten cambiar el flujo de datos de un sitio a otro. Estas herramientas son las pipes y los redirectors.
Las pipes se representan por el carácter "|" y su función es redirigir la STDOUT de un proceso a la STDIN de otro proceso igual o diferente. Es decir, el resultado que produzca un procesos (que normalmente lo veremos por el monitor) lo redireccionamos como si fueran pulsaciones de teclado a otro proceso.

Por ejemplo:

# cat /var/log/messages | grep kernel

El resultado de cat que sale por STDOUT se redirecciona al STDIN del comando grep. Por tanto lo que estamos haciendo es listar el contenido de /var/log/messages y sobre este resultado filtrar y buscar las lineas que contengan la palabra kernel.

Las pipes se pueden anidar formando comandos más complicados.

Por ejemplo:

# cat /etc/passwd | cut -d: -f6 | uniq | sort | nl
     1 /bin
     2 /bin
     3 /bin
     4 /dev
     5 /home/amperis
     6 /home/clamav
     7 /home/klog
     8 /home/saned
     9 /home/syslog
    10 /nonexistent
    11 /root
    12 /usr/games
    13 /usr/sbin
    14 /var/backups
    15 /var/cache/man
    16 /var/lib/avahi-autoipd
    17 /var/lib/gdm
    18 /var/lib/gnats
    19 /var/lib/libuuid
    20 /var/list
    21 /var/mail
    22 /var/run/avahi-daemon
    23 /var/run/dbus
    24 /var/run/hald
    25 /var/run/hplip
    26 /var/run/ircd
    27 /var/run/PolicyKit
    28 /var/run/pulse
    29 /var/spool/lpd
    30 /var/spool/news
    31 /var/spool/uucp
    32 /var/www

Con la siguiente anidación de pipes, listamos el contenido de /etc/passwd, luego recortamos para obtener la columna donde están los homes, ordenados el resultado y enumeramos las lineas. Lo que estamos haciendo es pasar el resultado que proporciona un proceso a la entrada del siguiente proceso. El ultimo proceso como no tiene ningún tipo de redirección mostrará su resultado por su STDOUT, es decir por el monitor.
No confundir "cat /etc/passwd | cut -d: -f6 | uniq | sort | nl" con "cat /etc/passwd; cut -d: -f6 ; uniq; sort; nl". En este último caso los procesos se ejecutan uno por uno, pero no existe ninguna relación entre ellos.

Con la herramienta de los redirectors lo que podemos hacer es redireccionar el contenido de un archivo a la entrada de un proceso o la salida de un proceso enviarla a un archivo.
Veamos un ejemplo de como enviar el contenido de un archivo a un proceso. Supongamos que tenemos un archivo llamado "email.txt" con el cuerpo del mensaje de un correo electrónico. Se lo queremos enviar a un usuario llamado "paco":

# mail paco < email.txt

Lo que estamos haciendo es redireccionar el contenido de fichero a la STDIN del proceso mail.

Veamos el caso contrario, es decir, cómo guardar el contenido de un proceso en un fichero. Supongamos que queremos guardar en un fichero de log las 10 ultimas lineas de otro log:

# tail /var/log/messages > mini.log

El comando tail muestras las 10 últimas lineas de /var/log/menssages. Esta salida la redireccionamos al fichero mini.log.
La redirección utilizando ">", siempre crear el archivo en caso de no existir. Si existe el archivo lo sobreescribe. También tenemos la posibilidad de hacer un append, es decir, si existe continuar por su ultima linea y si no existe crearlo. Para ello utilizamos los caracteres ">>":

# tail /var/log/messages >> minilog.log; sleep 60; tail /var/log/messages >> minilog.log

Ahora que ya conocemos estas dos herramientas podemos utilizarlas en conjunción. Veamos como almacenar el resultado del segundo ejemplo en un fichero:

# cat /etc/passwd | cut -d: -f6 | uniq | sort | nl > /tmp/homes.txt

Otro ejemplo utilizando todas las herramientas:

# tr '[a-z]' '[A-Z]' < /etc/passwd | cut -d: -f6 > homes.txt
# head homes.txt
/ROOT
/USR/SBIN
/BIN
/DEV
/BIN
/USR/GAMES
/VAR/CACHE/MAN
/VAR/SPOOL/LPD
/VAR/MAIL
/VAR/SPOOL/NEWS

En el ejemplo anterior enviamos el contenido de /etc/passwd al proceso tr que nos lo convierte todo en mayúsculas. El resultado de esto los cortamos para quedarnos con los homes de los usuarios y lo guardamos en el fichero homes.txt.

prioridades en linux (ii de ii)

2009-06-24T10:10:00.003+02:00

Los comandos nice y renice nos permiten cambiar las prioridades de los procesos. Las prioridades van en un rango entre el -20..0 y el 0..19. El -20 es máxima prioridad y por tanto máxima apropiación de la CPU y el 19 es la mínima apropiación de la CPU. El 0 es la prioridad que se da por defecto a todos los usuarios del sistema. Otra cosa muy importante es que solo root puede dar prioridades negativas.

Para ser más correcto lo que estamos cambiando no es exactamente la prioridad sino "el valor de nice". Como hemos explicado anteriormente la apropiación y tiempo de uso de una CPU se calcula en base a uno o varios algoritmos de planificación y en base a muchos parámetros entre ellos, el valor de nice.

Para lanzar un nuevo proceso con un valor de nice haremos lo siguiente:

# nice -n -15 xeyes (lanzamos xeyes con una prioridad alta)

Si por el contrario queremos cambiar la prioridad a un proceso ya en ejecución, utilizaremos el comando renice:

# renice 10 -p 1967 (lanzamos el proceso con PID 1967 con una prioridad baja)

Para ver que nice tiene asignado cada proceso hay que consultar la columna NI que muestra el comando top:

top - 23:18:30 up 10:52,  5 users,  load average: 0.00, 0.31, 0.40
top - 23:25:57 up 10:59,  5 users,  load average: 0.28, 0.19, 0.28
Tasks: 139 total,   3 running, 136 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.3%us,  3.7%sy,  1.0%ni, 84.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3989648k total,  3425068k used,   564580k free,    97340k buffers
Swap:  4000176k total,        0k used,  4000176k free,  2796996k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                           
 3035 root      20   0  495m  60m  15m R  7.0  1.6   9:37.19 Xorg                                                                                                                                              
 3638 amperis   20 -20  317m  49m  17m S  4.3  1.3   2:42.72 bucle.sh                                                                                                                                       
17023 amperis   39  19  578m 122m  27m S  2.0  3.1   1:05.72 bucle.sh                                                                                                                                           
17067 amperis   20 -15  199m  20m  10m R  1.7  0.5   0:58.31 xeyes                                                                                                                                    
17959 root      20   0 19116 1344  988 R  0.3  0.0   0:02.62 top 
...

Como regla general Linux por si mismo ya es lo suficiente eficiente para mantener el buen uso de la CPU, por tanto, no es necesario ir cambiando los nice. Si este no fuera tú caso, lo normal es cambiarlo o jugar con ellos en aplicaciones como audio, video, diseño, donde los retardos en los resultados es muy apreciable.

Para los que le gusta tunear su Kernel existen parches para compilarlo utilizando opciones de tuning y real-time. Existen proyectos dedicados al real-time del Kernel.

Para hacer notar el poder del nice podéis crear un script con un bucle infinito que vaya mostrando números por pantalla. Lo lanzáis dos veces en dos terminales diferentes. Por defecto, los dos procesos entraran en ejecución con un nice 0. Ahora a uno le ponéis un -20 y al otro un 19. Veréis como uno incrementará su velocidad y el otro irá más lento. En verdad no va más lento, sino que recibe la CPU menos veces por unidad de tiempo.

#!/bin/bash

while [ 1 ] 
do
  echo $RANDOM
done

prioridades en linux (i de ii)

2009-06-23T12:34:00.021+02:00

Todos los sistemas operativos tienen algún tipo de algoritmo de planificación más o menos eficiente que permite a todos los procesos del sistema y del usuario poder hacer uso de la CPU. Un buen algoritmo de planificación debe ser capaz de controlar todos estos parámetros:

+ equitatividad: cada proceso debe recibir su parte justa de CPU y recursos.
+ eficiencia: la CPU debe ser usada todo el tiempo. No desaprovecharla.
+ throughput: producir el mayor numero de trabajos terminados por hora.
+ respuesta: minimizar el tiempo de respuesta en las aplicaciones interactivas.

Manejar todos estos parámetros es muy difícil ya que dentro de un sistema podemos encontrar diferentes tipos de procesos y tareas cada una con sus propias características y necesidades. Por ejemplo, tenemos procesos que utilizan intensamente la CPU y otros que estarían todo el día parados esperando E/S. Por tanto, cuando Linux empieza a ejecutar un proceso, no sabe 100% cuanto tiempo necesitará ese proceso la CPU.

Durante el diseño de sistemas de compartición y scheluding han ido surgiendo diferentes tipos de algoritmos de palanificación:

+ planificación por round-robin: quizás el más conocido y que se estudia más durante la carrera informática. Es uno de los más antiguos y tal vez el más sencillo de implementar y justo. Se basa en mantener una cola o lista de procesos, asignándoles un tiempo de ejecución a cada proceso. Pasado ese tiempo le quitamos al proceso la CPU y se la damoss a otro. Lo más difícil de calcular es el ¿cuanto tiempo?. Si ponemos poco tiempo haremos mucho swaping entre procesos y eso puede ser malo porque podemos perder mucho tiempo en cambiar de contexto. Si decidimos poner mucho tiempo, podemos perjudicar a otros procesos que son muy interactivos con el usuario.

+ planificación por prioridades: consiste en dar una prioridad al proceso. Contra más prioridad tenga un proceso antes utilizará la CPU. Dentro de este tipo de planificación podemos encontrar que las prioridades se pueden asignar estática o dinámicamente.

+ planificación por colas: consiste en tener varias colas donde los procesos alojados en una cola utilizan la CPU X ms., los alojadas en la segunda cola la utilizan 2X ms., y así sucesivamente. Una vez los procesos utilizan todo su tiempo van rotando por las diferentes colas.

+ planificación en tiempo real: quizás estos algoritmos son los más complicados ya que deben asegurar respuestas a posibles eventos. Por ejemplo, un sistema que controle la altura de un vuelo. Si salta la alarma de altura, el proceso que controla este evento tiene que estar dentro de la CPU para poder tomar el control. Una respuesta correcta pero tarde, puede ser peor que no obtener respuesta.

+ otros planificadores: planificación por lotería, planificación garantizada, planificación en varios niveles, etc.

En Linux tenemos una mezcla de varios de los planificadores que he explicado, pero básicamente sería algo como un round-robin con prioridades. En realidad podemos planificar cada proceso con una política diferente. Estas son las políticas de Linux:

+ SCHED_OTHER: en Unix es la planificación clásica. No es aplicable en tiempo real. Examina las prioridades dinámicas (calculadas como combinación de las especificadas por el usuario y las calculadas por el sistema). Los procesos que llevan más tiempo en el sistema van perdiendo prioridad.

+ SCHED_FIFO: El primero en entrar en la cola es el primero en ser servido. Los procesos esperan en cola y se ejecutan secuencialmente. Se sigue calculando un cuanto de tiempo para el proceso, aunque normalmente no se use porque con esta planificación no se fuerza al proceso a abandonar la CPU. Se usa en procesos de tiempo real.

+ SCHED_RR: round-robin. Funciona como el FIFO pero ahora cuando un proceso acaba su cuanto de tiempo (time slice) se le desaloja. El siguiente proceso se escoge de la lista de procesos con SCHED_RR o de la lista SCHED_FIFO. Son procesos en tiempo real.

+ SCHED_YIELD: No es una política de planificación, sino un modificador que afecta a las tres políticas anteriores. El proceso cede la CPU a cualquier otro que esté listo.

Más información:
- Understanding the Linux 2.6.8.1 CPU Scheduler

envio de sms en linux

2009-06-11T22:34:00.017+02:00

Una de las cosas chulas de Nagios es que puedes ir creando servicios de notificación para enviar mensajes por diferentes medios cuando un servicio cae. Lo normal es hacer que Nagios te envíe un mail cuando un disco se llene, cuando una impresora deje de funcionar o cuando el ancho de banda de un router esté al 80%.
Otra forma curiosa de enviar notificaciones es enviar todas estas a Twitter. Simplemente echando un vistazo a tú Twitter puedes ver que está pasando con tus servidores... ¿arriesgado?.

Lo más efectivo es el envio de SMS a tú móvil en caso de que un servicio importante deje de funcionar. El uso de la notificación por correo (o el Twitter) solo funciona si tú conexión a Internet está funcionando. ¿Que pasa si monitorizas tú conexión a Internet y esta ha caído?.
Para ello he rebuscado y rebuscado entre todos lo móviles de la empresa hasta encontrar uno con conexión USB y sobre todo que sea capaz de cargarse la batería también por el mismo cable USB... al final encontré uno muy chulo: un Motorola V3.

Lo primero que tenemos que hacer es verificar si es capaz de detectar el móvil. Para ello lanzamos un lsusb (todos los resultados están bajo un Fedora 7):

[root@server ~]# lsusb
Bus 001 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 003 Device 007: ID 22b8:4902 Motorola PCS E398 GSM Phone
Bus 003 Device 001: ID 0000:0000

Como resultado también obtendremos un nuevo dispositivo mapeado en /dev/ttyACM0. Un dispositivo ttyACM identifica a un módem USB, y como tal módem es capaz de ser atacado vía comandos AT. Los comandos AT son cadenas de texto que nos permiten interactuar con cualquier módem para inicializarlo, marcar un número, transferir un fichero o colgar una llamada. Los móviles son modems GSM y, por tanto, también acepta comandos AT.

Los comandos AT que debemos enviar para que el móvil envie un SMS son los siguientes:

AT+CMGF=1 (le dice al módem que enviamos los SMS en formato texto).
AT+CSCA="+34607003110" (le decimos que el número del centro de mensajes es el 
                        +34607003110)
AT+CMGS="696342572" (le decimos el número donde debe enviar el SMS)
> Hola caracola <Ctrl+Z> (escribimos el mensaje y lanzamos un Ctrl+Z).

Lo único que necesitamos saber es el número del centro de mensajes SMS de nuestra operadora. En mi caso el SIM de la tarjeta es Vodafone y el centro de mensajes es el +34607003110. Esta información la puedes encontrar dentro de la configuración del móvil o te la puede dar la operadora.

Una vez sabemos como funciona todo, podemos crear un script en Perl que nos permita hacer todo esto en una simple línea de comandos.

#!/usr/bin/perl

$_SMS_CM="+34607003110";
$_SMS_MODEM="/dev/ttyACM0";

if ($#ARGV != 1 ) {
   print "sendsms.pl v0.1b, por amperis[@]gmail.com\n\n";
   print "Uso:\n";
   print "   ./sendsms.php <numero destino> \"<mensaje>\"\n\n";
   exit;
}

use Device::Modem;

my $modem = new Device::Modem( port => $_SMS_MODEM );

if ( $modem->connect( baudrate => 115200 ) ) {
   $modem->echo(1);
   $modem->verbose(1);

   $modem->atsend( 'AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0'.Device::Modem::CR);
   print $modem->answer()."\n";

   $modem->atsend( 'AT+CMGF=1'.Device::Modem::CR);
   print $modem->answer()."\n";

   $modem->atsend( 'AT+CSCA="' . $_SMS_CM. '"'.Device::Modem::CR);
   print $modem->answer()."\n";

   $modem->atsend( 'AT+CMGS="' .$ARGV[0]. '"'.Device::Modem::CR);
   print $modem->answer()."\n";

   $modem->atsend( $ARGV[1].chr(26));
   print $ARGV[1]."\n\n";

   print "\nFin de la conexion.\n\n";


} else {
   print "ERROR: No encuentro el modem.\n";
}

Nota: Tenemos que tener instalado en Perl el paquete Device::Modem. Para instalar paquetes en Perl hacemos un "perl -e shell -MCPAN" y luego haremos un ">install Device:Modem".

Ahora solo queda dar permisos de ejecución al script (chmod +x sendsms.pl) y ejecutarlo:

# ./sendsms.pl 696342572 "Error a las 19:35h. Router Cisco 877 sin conexión"

Más información:
+ Using AT commands to Send and Receive SMS

calcular el tamaño de una instalación zimbra

2009-05-31T23:11:00.010+02:00

Este es un script para calcular el tamaño físico que debería tener tú instalación de Zimbra en función del numero de usuarios y del tamaño máximo de los buzones.
Naturalmente el resultado final es orientativo.

Más informacion:
+ Zimbrablog

estadísticas de un mailbox

2009-05-29T10:19:00.010+02:00

De la cantidad de script que hay dentro de /opt/zimbra/bin uno muy útil es el zmmailbox. Su utilización es muy parecida al zmprov. Este comando se utiliza para manejar los buzones. Lo podemos lanzar (al igual que zmprov) por línea de comandos o simplemente utilizar su consola.

[zimbra@zimbra ~]$ zmmailbox --help
zmmailbox [args] [cmd] [cmd-args ...]

  -h/--help                                display usage
  -f/--file                                use file as input stream
  -u/--url      http[s]://{host}[:{port}]  server hostname and optional port. must
                                           use admin port with -z/-a
  -a/--admin    {name}                     admin account name to auth as
  -z/--zadmin                              use zimbra admin name/password from
                                           localconfig for admin/password
  -y/--authtoken {authtoken}               use auth token string(has to be in JSON
                                           format) from command line
  -Y/--authtokenfile {authtoken file}      use auth token string(has to be in JSON
                                           format) from command line
  -m/--mailbox  {name}                     mailbox to open
  -p/--password {pass}                     password for admin account and/or mailbox
  -P/--passfile {file}                     read password from file
  -r/--protocol {proto|req-proto/response-proto} specify request/response protocol
                                                 [soap11,soap12,json]
  -v/--verbose                             verbose mode (dumps full exception stack 
                                           trace)
  -d/--debug                               debug mode (dumps SOAP messages)

 zmmailbox is used for mailbox management. Try:

     zmmailbox help admin           help on admin-related commands
     zmmailbox help account         help on account-related commands
     zmmailbox help appointment     help on appoint-related commands
     zmmailbox help commands        help on all commands
     zmmailbox help contact         help on contact-related commands
     zmmailbox help conversation    help on conversation-related commands
     zmmailbox help filter          help on filter-realted commnds
     zmmailbox help folder          help on folder-related commands
     zmmailbox help item            help on item-related commands
     zmmailbox help message         help on message-related commands
     zmmailbox help misc            help on misc commands
     zmmailbox help permission      help on permission commands
     zmmailbox help search          help on search-related commands
     zmmailbox help tag             help on tag-related commands

Este es un ejemplo de como obtener una estadística (tamaño, carpetas, correos leídos) de un buzón. En mi caso voy a sacar las estadísticas del buzón admin@dominio.com:

[zimbra@zimbra ~]$ zmmailbox
mbox> adminAuthenticate admin@dominio.com mipsw1234

mbox> selectMailbox admin@dominio.com
mailbox: admin@dominio.com, size: 7.01 MB, messages: 531, unread: 330

mbox admin@dominio.com> GetAllFolders
        Id  View      Unread   Msg Count  Path
----------  ----  ----------  ----------  ----------
         1  conv           0           0  /
        16  docu           0           0  /Briefcase
        10  appo           0           1  /Calendar
        14  mess           0           0  /Chats
         7  cont           0           0  /Contacts
         6  mess           0           0  /Drafts
        13  cont           0           1  /Emailed Contacts
         2  mess           0           6  /Inbox
      4818  mess           3           9  /Inbox/jupiter
      8509  mess           2          15  /Inbox/asterisk
      4817  mess           0           0  /Inbox
      5279  mess          91         111  /Inbox/antivirus
      6025  mess           0           1  /Inbox/backup
      5283  mess           1           1  /Inbox/mail report
      5280  mess           7          24  /Inbox/virus
      5281  mess           9          48  /Inbox/xtras
         4  mess          26          26  /Junk
        12  wiki           0           0  /Notebook
         5  mess           0           3  /Sent
        15  task           0           0  /Tasks
         3  conv         191         285  /Trash

También es posible sacar las estadísticas sin necesidad de entrar en la consola del comando:

zmmailbox -z -m user@domain.com gms -> Tamaño de un buzón
zmmailbox -z -m user@domain.com gaf -> Estadisticas de un buzón

Más información:
+ zmmailbox

bind para el correo (parte iii de iii)

2009-05-26T18:57:00.003+02:00

Por último vamos a securizar un poco nuestros dos servidores. Cuando un DNS quiere descargar la zona de otro servidor DNS, este realiza peticiones AXFR. Es decir si no tenemos correctamente configurado nuestro servidor de DNS es posible que alguien pueda descargarse nuestra base de datos de zona.

Aquí tenéis un ejemplo de un servidor DNS mal configurado que responde a las peticiones AXFR (actualmente el bug lo tienen arreglado):

amperis@akoya:~$ dig @ns2.microXXXX.net microXXXX.net axfr

; <<>> DiG 9.5.1-P2 <<>> @ns2.microXXXX.net microXXXX.net axfr
; (1 server found)
;; global options:  printcmd
microXXXX.net.          86400   IN      SOA     ns1.microXXXX.net. sysop.microXXXX.net.
2009051302 86400 7200 2419200 86400
microXXXX.net.          86400   IN      NS      ns1.microXXXX.net.
microXXXX.net.          86400   IN      NS      ns2.microXXXX.net.
microXXXX.net.          86400   IN      A       62.97.115.117
microXXXX.net.          3600    IN      MX      5 tauri.microXXXX.net.
microXXXX.net.          3600    IN      MX      10 dsl1.microXXXX.net.
microXXXX.net.          3600    IN      MX      20 mx.microXXXX.net.
abydos.microXXXX.net.   86400   IN      A       213.27.212.92
actuava.microXXXX.net.  86400   IN      CNAME   atlantis.microXXXX.net.
adminwww.microXXXX.net. 86400   IN      CNAME   asgar.microXXXX.net.
algerie.microXXXX.net.  86400   IN      CNAME   atlantis.microXXXX.net.
altas.microXXXX.net.    86400   IN      CNAME   asgar.microXXXX.net.
altes.microXXXX.net.    86400   IN      CNAME   asgar.microXXXX.net.
ambitogrupo.microXXXX.net. 86400 IN     CNAME   atlantis.microXXXX.net.
anubis.microXXXX.net.   86400   IN      CNAME   tauri.microXXXX.net.
arianconstruccion.microXXXX.net. 3600 IN CNAME  asgar.microXXXX.net.
asgar.microXXXX.net.    86400   IN      A       62.97.115.112
asuran.microXXXX.net.   86400   IN      A       213.27.212.32
atlantis.microXXXX.net. 86400   IN      A       213.27.212.72
baal.microXXXX.net.     86400   IN      A       62.97.115.62
... (la zona es mucho más larga)

Nota: el dominio real ha sido alterado por seguridad.

Si realizamos la misma consulta a nuestros servidores DNS obtenemos:

[root@dns2 var]# dig @192.168.1.8 amperisblog.com axfr

; <<>> DiG 9.3.4-P1 <<>> @192.168.1.8 amperisblog.com axfr
; (1 server found)
;; global options:  printcmd
amperisblog.com.        86400   IN      SOA     dns1.amperisblog.com. 
admindns.amperisblog.com. 20090522 21600 3600 604800 86400
amperisblog.com.        86400   IN      NS      dns1.amperisblog.com.
amperisblog.com.        86400   IN      NS      dns2.amperisblog.com.
amperisblog.com.        86400   IN      MX      10 mail1.amperisblog.com.
amperisblog.com.        86400   IN      MX      20 mail2.amperisblog.com.
amperisblog.com.        86400   IN      A       222.222.222.223
dns1.amperisblog.com.amperisblog.com. 86400 IN A 222.222.222.221
dns2.amperisblog.com.amperisblog.com. 86400 IN A 222.222.222.222
ftp.amperisblog.com.amperisblog.com. 86400 IN CNAME 
server1.amperisblog.com.amperisblog.com.
mail1.amperisblog.com.amperisblog.com. 86400 IN CNAME 
server1.amperisblog.com.amperisblog.com.
mail2.amperisblog.com.amperisblog.com. 86400 IN CNAME 
server2.amperisblog.com.amperisblog.com.
server1.amperisblog.com.amperisblog.com. 86400 IN A 222.222.222.224
server2.amperisblog.com.amperisblog.com. 86400 IN A 222.222.222.223
www.amperisblog.com.amperisblog.com. 86400 IN CNAME 
server2.amperisblog.com.amperisblog.com.
amperisblog.com.        86400   IN      SOA     dns1.amperisblog.com. 
admindns.amperisblog.com. 20090522 21600 3600 604800 86400
;; Query time: 10 msec
;; SERVER: 192.168.1.8#53(192.168.1.8)
;; WHEN: Sat May 23 18:01:22 2009
;; XFR size: 15 records (messages 1)

El objetivo es evitar que la transferencia de zona pueda realizarse desde Internet. Solo debe realizarse entre los dos servidores de DNS de confianzza.

Para ello en el servidor de DNS primario añadimos al named.conf la siguiente config:

options {
   allow-transfer { none; };
   ...
};


zone "amperisblog.com" in {
   allow-transfer { 192.168.1.9; };
   ...
};

Al DNS principal le decimos que solo puede transferir la zona al DNS secundario (192.168.1.9).

Por otro lado, el DNS secundario no tiene que transferir ninguna zona a nadie. Pondremos la siguiente config en el secundario:

options {
   allow-transfer { none; };
   ...
};

Para entornos en producción donde podemos tener muchos servidores de DNS existe la posibilidad de utilizar firmas para garantizar la autenticidad de una transferencia de zona. Aquí teneis un ejemplo de la utilización de firmas en Bind 9.

bind para el correo (parte ii de iii)

2009-05-25T09:00:00.002+02:00

Para el servidor de DNS secundario realizaremos los mismos pasos de instalación que con el DNS primario.
Una vez instalado todo el software de Bind editamos el /etc/named.conf con el siguiente contenido:

options {
   directory "/var/named/slaves";
};

logging{
  channel simple_log {
    file "/var/log/named.log" versions 3 size 5m;
    severity warnings;
    print-time yes;
    print-severity yes;
    print-category yes;
  };
  category default{
    simple_log;
  };
};

zone "amperisblog.com" in {
   type slave;
   file "amperisblog.com.zone";
   masters{ 192.168.1.8; };
};

Si reiniciamos Bind con un "sevice named restart" veremos como solo al arrancar se creará un archivo de backup de la zona en /var/named/slaves/amperisblog.com.zone.

Si observamos named.log del DNS secudario veremos como inicialmente la zona no existe y como se contacta con el servidor de DNS principal para descargar la zona:

23-May-2009 17:14:37.957 general: debug 1: zone amperisblog.com/IN: no database 
exists yet, requesting AXFR of initial version from 192.168.1.8#53
23-May-2009 17:14:37.960 xfer-in: info: transfer of 'amperisblog.com/IN' from 
192.168.1.8#53: connected using 192.168.1.9#58874
23-May-2009 17:14:37.964 general: debug 1: zone amperisblog.com/IN: zone transfer 
finished: success

Las direcciones 192.168.1.9 y 192.168.1.8 son las direcciones IP internas de los servidores de DNS que se encuentran dentro de la DMZ. Las direcciones 222.222.222.221 y 222.222.222.222 son las direcciones IP públicas de los servidores de DNS desde Internet.

bind para el correo (parte i de iii)

2009-05-24T09:20:00.000+02:00

Como todos sabéis el DNS es uno de los principales servicios que sustentan Internet y, por tanto, es fundamental para la distribución del correo (y otras cosas)... Quien no sepa como funciona el DNS que se vaya leyendo la Wikipedia.

El objetivo de estos tres post son:

+ Configuración de dos maquinas Linux (master+slave) servidoras de DNS por Bind.
+ Configuración de varias zonas de DNS en especial para su uso con el correo.
+ Replicación de zona de un servidor a otro (mensajes AXFR).
La distribución que utilizaré para los dos servidores será CentOS 5.2. Antes de empezar a instalar Bind necesitaremos las dos maquinas perfectamente configuradas (TCP/IP), parcheadas y conectadas a Internet.

Instalamos el soft necesario:

# yum search bind | grep ^bind
# yum install bind.i386

Como resultado tendremos instalado bind, bind-libs y bind utils.

Configuraremos el firewal de iptables para que cualquiera pueda realizar consultas DNS sobre esta maquina. Para ello abrimos el puerto 53/UDP.

Editamos /etc/sysconfig/iptables:

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

Reiniciamos iptables:

# service iptables restart

Intentamos iniciar Bind, pero debería fallar ya que aun no lo tenemos correctamente configurado:

# service named restart

Empezamos primero configurando el DNS principal y cuando este todo correcto montaremos el secundario.
El archivo de configuración de Bind se encuentra dentro de /etc/named.conf. Lo crearemos y colocaremos el siguiente contenido:

options {
   directory "/var/named/data";
};


zone "amperisblog.com" in {
   type master;
   file "amperisblog.com.zone";
   allow-update { none; };
};

zone "." {
   type hint;
   file "root.cache";
};

Nota: He creado una zona llamada "." que apunta a un fichero de configuración llamado "root.cache". Esto nos sirve por si queremos que nuestro DNS sepa resolver otros dominios. Es decir, que nuestro servidor de DNS haga a la vez de cache de DNS. Para ello hay que crear /var/named/data/root.cache y pegar el contenido de: http://www.tux.org/~mayer/linux/book/node155.html

El parámetro "directory" nos está diciendo dónde se encontrarán los archivos de configuración de nuestro dominio. En mi caso tenemos un archivo de configuración para mi dominio amperisblog.com que se encontrará dentro de /var/named/data/amperisblog.com.zone.
El parámetro "type" nos indica si ese dominio será master o slave. Para un DNS principal este campo será master.

Creamos ahora el archivo de configuración para la zona ampeisblog.com. En ella se encontraran todos los campos A, CNAME, MX, NS, etc. Creamos el archivo /var/named/data/amperisblog.com.zone con el siguiente contenido:

$TTL 86400
amperisblog.com.  IN     SOA    dns1.amperisblog.com.     admindns.amperisblog.com. (
                    20090522   ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     dns1.amperisblog.com.
      IN     NS     dns2.amperisblog.com.

      IN     MX     10     mail1.amperisblog.com.
      IN     MX     20     mail2.amperisblog.com.

             IN     A       222.222.222.223

server1      IN     A       222.222.222.224
server2      IN     A       222.222.222.223
dns1         IN     A       222.222.222.221
dns2         IN     A       222.222.222.222

ftp          IN     CNAME   server1
mail1        IN     CNAME   server1
mail2        IN     CNAME   server2
www          IN     CNAME   server2

Vamos a explicar la configuración de este archivo de zona. Lo primero que se especifica es el registro de SOA, donde aparece el nombre de nuestro dominio, el DNS primario (dns1.amperisblog) y la dirección de correo del administrador del DNS (admindns.amperisblog.com).

Otros datos que encontramos dentro de SOA son los tiempos de cacheo y refresco:

20090522: es un número de serie autoincremental que deberíamos incrementar cada vez que hagamos una modificación en la zona.
21600: indica al DNS esclavo cada cuando tiempo tiene que chequear la configuración del DNS maestro. En nuestro caso no tiene sentido porque este servidor es primario.
3600: si el refresco del esclavo falla, esto indica cada cuanto tiempo tiene que probar.
604800: si el refresco del esclavo sigue fallando, esto indica cuando el DNS esclavo debe dejar de funcionar.
86500: indica a un cache de DNS el tiempo de vida de la traducción DNS.
NS: indica los nombres de los dos servidores de DNS de nuestra zona.
MX: indica con peso 10 y peso 20 cuales son los servidores de correo que deben responder al dominio amperisblog.com.
A: indica las direcciones IP de todas las maquinas publicas en Internet. En este caso tenemos dos servidores de DNS (dns1, dns2) y dos servidores (server1, server2).
CNAME: indica los alias. Tenemos dos alias de mailX que apuntan a nuestros server1 y server2. Tenemos un alias de www para alojamiento Web que apunta a server2 y por ultimo tenemos un alias de ftp que apunta al server1.

Si todo ha ido bien ya podemos arrancar otra vez el DNS con un "service named restart" y comprobar el archivo de log para ver si todo a ido bien:

# cat /var/log/messages | grep named
May 23 15:33:29 dns1 named[13573]: starting BIND 9.3.4-P1 -u named
May 23 15:33:29 dns1 named[13573]: found 1 CPU, using 1 worker thread
May 23 15:33:29 dns1 named[13573]: loading configuration from '/etc/named.conf'
May 23 15:33:29 dns1 named[13573]: listening on IPv4 interface lo, 127.0.0.1#53
May 23 15:33:29 dns1 named[13573]: listening on IPv4 interface eth0, 192.168.1.8#53
May 23 15:33:29 dns1 named[13573]: command channel listening on 127.0.0.1#953
May 23 15:33:29 dns1 named[13573]: command channel listening on ::1#953
May 23 15:33:29 dns1 named[13573]: zone amperisblog.com/IN: loaded serial 20090522
May 23 15:33:29 dns1 named[13573]: running
May 23 15:33:29 dns1 named[13573]: zone amperisblog.com/IN: sending notifies (serial
20090522)

Ahora ya podemos realizar peticiones de consultas sobre nuestro nuevo servidor de DNS:

[root@dns1 data]# dig @localhost amperisblog.com

; <<>> DiG 9.3.4-P1 <<>> @localhost amperisblog.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14375
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;amperisblog.com.               IN      A

;; ANSWER SECTION:
amperisblog.com.        86400   IN      A       222.222.222.223

;; AUTHORITY SECTION:
amperisblog.com.        86400   IN      NS      dns1.amperisblog.com.
amperisblog.com.        86400   IN      NS      dns2.amperisblog.com.

;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat May 23 15:

Veamos también si es capaz de cachear/traducir otros dominios:

[root@dns1 data]# dig @localhost google.com

; <<>> DiG 9.3.4-P1 <<>> @localhost google.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38954
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       74.125.45.100
google.com.             300     IN      A       74.125.67.100
google.com.             300     IN      A       209.85.171.100

;; AUTHORITY SECTION:
google.com.             345600  IN      NS      ns1.google.com.
google.com.             345600  IN      NS      ns2.google.com.
google.com.             345600  IN      NS      ns3.google.com.
google.com.             345600  IN      NS      ns4.google.com.

;; Query time: 699 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat May 23 15:38:55 2009
;; MSG SIZE  rcvd: 148

Si queremos controlar las peticiones podemos añadir un log dentro del /etc/named.conf:

logging{
  channel simple_log {
    file "/var/log/named.log" versions 3 size 5m;
    severity warning;
    print-time yes;
    print-severity yes;
    print-category yes;
  };
  category default{
    simple_log;
  };
};

Si estamos debugeando nuestro DNS cambiaremos "severity warning;" por un "severity debug;".

¿qué pasa cuando google street no llega?

2009-05-23T14:26:00.000+02:00

tamaño de los buzones en tiempo real

2009-05-21T12:19:00.004+02:00

Por defecto Zimbra almacena los mensajes recibidos dentro de /opt/zimbra/store. En algunas ocasiones como en pruebas de stress podéis utilizar esta linea de bash para ver como va creciendo y disminuyendo todo el correo que tenemos en los buzones. Irá creciendo mientras vayamos recibiendo correo por SMTP e irá disminuyendo conforme los usuarios accedan al correo vía POP o borren correo vía IMAP/Webmail.

# while [ true ]; do clear; du -bcs /opt/zimbra/store/ | grep total; sleep 5;  done

tagged address con tmda

2009-05-17T15:46:00.006+02:00

Cada día son más las técnicas que aparecen para saltarse los filtros antispam, pero afortunadamente también son más las técnicas que intentan evitarlo. TMDA son las siglas de "agente de entrega de mensajes por etiquetado". Se trata de un software libre que implementa varias técnicas antispam para QMail, Sendmail, Exim o Postfix.
Utiliza tres técnicas conocidas, más una nueva técnica desarrolladas por ellos y llamada "etiquetado de direcciones".

Las tres primeras técnicas las describiré rápidamente y me centraré en la última que es la más interesante:

+ listas negras: son listas de direcciones de correo, dominios o rangos de IPs de las cuales está totalmente prohibido recibir un correo. Cuando el MTA recibe un correo de un remitente que se encuentra en esta lista, el correo es eliminado.

+ listas blancas: son listas de direcciones de correo, dominio o rangos de IPs de las cuales se acepta el correo sin aplicar ningún otro tipo de filtrado. Cuando un MTA recibe un correo de un remitente que se encuentra en esta lista, este es aceptado inmediatamente sin realizar ningún otro filtrado.

+ lista gris (greylist) o de safio/respuesta: Consiste en denegar un mensaje a nivel SMTP, de forma que forzamos al MTA del remitente a que reenvíe el correo otra vez al cabo de un tiempo (minutos, horas, depende de la configuración del MTA del remitente). Si el otro MTA reenvía el correo, nuestro MTA lo acepta y mete al remitente es su lista blanca para que la segunda vez que envíe un correo no vuelva a repetir este proceso.
Es interesante observa que cuando utilizamos greylist el correo es rechazado la primera vez y vuelto a reintentar porque muchos spammers no implementan el reenvío. Los spammers envían miles de correos y no les importa si el correo se ha entregado o no.

La otra técnica interesante de TMDA es el "etiquetado de direcciones". Con esto podemos hacer:

+ etiquetado de la dirección from: con esto es posible reescribir todas las veces que quiera su dirección de correo "por un alias" y que esta dirección tenga un tiempo de vida finito. De esta forma, por ejemplo, podrás participar en una lista de distribución, grupo o mailing sin que tú dirección real sea comprometida por spmmers.
Por ejemplo si tú dirección real es alejandro-moreno@miempresa.com tú dirección "etiquetada" con un tiempo de vida de 5 días tendrá este aspecto:

alejandro-fecha-989108708.a17f80@miempresa.com

Notar que se utilizan técnicas de crifrado para generar esta dirección de correo y por tanto no es posible que un spammer genere una dirección "etiquetada" valida. Una vez expirada la dirección de correo, los mensajes enviados a esta dirección son rechazados.

+ etiquetado de direcciones del remitente: al igual que la dirección del "from" también es posible etiquetar la dirección del remitente con la misma técnica anterior.
Esto puede servir para que cuando un remitente esté suscrito a una foro, grupo o mailing su dirección no sea comprometida por un spammer. Solo podrá recibir correo a esta dirección "etiquetada" si proviene del dominio de foro o lista de distribución.
Los spammers utilizan el campo "Return-path" para determinar cual es la dirección real del remitente de la lista de distribución. Si cambiamos la dirección del "Return-path" por una dirección etiquetada (alejandro-sender-a751af@midominio.com) podremos decirle que solo acepte correo de lista@distribucion.com.

+ etiqueta de direcciones con palabras clave: también es posible etiquetar un dirección con una palabra clave o key. Algo como:

alejandro-palabra clave-.8w06e8@miempresa.com

Este tipo de etiquetado puede se útil para una cierta relación emisor-receptor como por ejemplo crear una cuenta ebay.com, suscribirse a un feed, etc.

Como véis todas estas opciones permiten crear tantos "alias" de nuestra dirección de correo como necesitemos con el objetivo de no dar a conocer nuestra dirección real de correo.

PD: Gracias a Arturo Jara por el enlace.

mc990d en ubuntu 9.04

2009-05-12T22:44:00.008+02:00

El MC990D es el módem USB 3G que está dando telefónica a sus clientes. Te permite una velocidad máxima de bajada de 7,2Mbps y 2Mbps de subida. Lo llaman 3G Plus o técnicamente HSUPA. También incorpora una tarjeta micro-sd de 1Gb.

La mejor solución para "Linux-Modem Movistar" es utilizar el "escritorio movistar para Linux" que es un clónico del que se instala bajo Windows. Este escritorio movistar para Linux está bajo GPL pero aun no reconoce el modelo MC990D (la web dice que sí) y además no está soportado para Ubuntu 9x. Se puede bajar del Movil OpenForum.

Así que toca hacer funcionar el módem a mano.

Una vez conectado al puerto USB tiene que ser detectada por tú Ubuntu 9.04:

$ lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 1410:7001 Novatel Wireless 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0bda:0158 Realtek Semiconductor Corp. Mass Stroage Device

Una vez detectado el módem tenéis que cargar el modulo usbserial. En Ubuntu 9.04 este modulo no viene separado del Kernel, sino que ya viene compilado dentro, por tanto no tenemos que hacer un "modprobe usbserial vendor=XXXX product=YYYY". Lo que tenemos que hacer es arrancar el Kernel con los parámetros del usbserial. Para ello modificamos el /boot/grub/menu.lst y añadimos los paámetros a nuestro Kernel por defecto:

kernel  /boot/vmlinuz-2.6.28-11-generic root=UUID=0a31bb4b-cc96-47e5-b783-5b00957a141e 
   ro quiet splash usbserial.product=0x7001 usbserial.vendor=0x1410

Una vez reiniciado ya podemos comenzar a configurar nuestra conexión Movistar 3G. Instalamos la utilidad wvdial que nos permite crear conexiones PPP (apt-get install wvdial).
Creamos el archivo /etc/wvdial.conf con el siguiente contenido:

[Dialer Defaults]
Dial Command = ATD
Stupid Mode = 1
Modem = /dev/ttyUSB0
Modem type = USB Modem

[Dialer pin]
Init1 = AT+CPIN=1234

[Dialer movistar]
ISDN = 0
Username = movistar
Password = movistar
Baud = 460800
Phone = *99***1#
Init2 = AT
Init3 = AT&F&D2&C1E0V1S0=0
Init4 = AT+IFC=2,2
Init5 = ATS0=0
Init6 = AT
Init7 = AT&F&D2&C1E0V1S0=0
Init8 = AT+IFC=2,2

Cambiar en "1234" dentro del "Dialer pin" por el PIN de vuestro SIM.

Ahora ya podemos arrancar el módem. Por defecto al conectar la llave se creará /dev/ttyUSB0. Por algún motivo que desconozco hasta que no haces un "extraer de forma segura" la unidad de disco que te crea al introducir el módem, no aparece el /dev/ttyUSB0.
Podéis verlo al consultar los mensajes del Kernel con el comando "dmesg".

Lo que haremos es un:

# eject /dev/sr0
# wvdial pin
# wvdial movistar

Tendréis que ver algo como:

# wvdial pin
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: AT+CPIN=1234
AT+CPIN=1234
OK
--> Modem initialized.
--> Configuration does not specify a valid phone number.
--> Configuration does not specify a valid login name.
--> Configuration does not specify a valid password.

# wvdial movistar
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: AT
AT
OK
--> Sending: AT&F&D2&C1E0V1S0=0
AT&F&D2&C1E0V1S0=0
OK
--> Sending: AT+IFC=2,2
OK
--> Sending: ATS0=0
OK
--> Sending: AT
OK
--> Sending: AT&F&D2&C1E0V1S0=0
OK
--> Sending: AT+IFC=2,2
OK
--> Modem initialized.
--> Sending: ATD*99***1#
--> Waiting for carrier.
CONNECT HSDPA 7.2
--> Carrier detected.  Starting PPP immediately.
--> Starting pppd at Tue May 12 22:34:15 2009
--> Pid of pppd: 3591
--> Using interface ppp0
--> local  IP address 213.99.235.106
--> remote IP address 10.64.64.64
--> primary   DNS address 194.179.1.100
--> secondary DNS address 194.179.1.101

Se puede automatizar todo con un script "movistar.sh":

#!/bin/bash

echo "Si no tienes conectado el modem, conectalo ahora !!!..."
sleep 30

echo "Desmontando unidad del modem..."
ID=$(dmesg | grep "Attached scsi CD-ROM" | tail -1 | awk "{print \$8;}")
#echo $ID
eject /dev/$ID
sleep 10

echo "Marcando PIN..."
wvdial pin
sleep 30

echo "Llamando a Movistar..."
wvdial movistar

Como veréis después de cada comando hago un sleep para dejar tiempo por ejemplo para que el módem detecte la red a conectarse.

Si te gustan las ventanas y lo colores puedes crear el dialing utilizando gnome-ppp o kppp. Los dos internamente llaman a wvdial.

una rallita para tu iphone

2009-05-10T17:15:00.000+02:00

slow postfix

2009-05-07T19:30:00.006+02:00

Por defecto la configuración de Postfix estándar no debería dar cuellos de botellas ni retardos en los correo.
Aun así un gran tráfico de spam, una secuencia de correos grandes que no deberían estar en la cola, un hardware lento o una mala configuración de nuestra red puede provocarnos muchos problemas.

Si este es el caso, tendremos que repasar estos puntos:

DNS
Una mala configuración de Postfix puede afectar de forma negativa a la velocidad del correo. Durante la entrada y salida del correo el DNS es un servicio muy usado y por tanto mientras el DNS no produzca una respuesta el correo no saldrá ni entrará.
Conviene revisar nuestros DNS dentro de /etc/resvolv.conf y verificar la velocidad de estos.

[root@mta ~]# dig -tmx google.com

; <<>> DiG 9.3.4-P1 <<>> -tmx google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29611
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;google.com.                    IN      MX

;; ANSWER SECTION:
google.com.             10731   IN      MX      10 smtp1.google.com.
google.com.             10731   IN      MX      10 smtp2.google.com.
google.com.             10731   IN      MX      10 smtp3.google.com.
google.com.             10731   IN      MX      10 smtp4.google.com.

;; ADDITIONAL SECTION:
smtp1.google.com.       3531    IN      A       209.85.237.25
smtp2.google.com.       3531    IN      A       64.233.165.25
smtp3.google.com.       3531    IN      A       209.85.137.25
smtp4.google.com.       3531    IN      A       72.14.221.25

;; Query time: 78 msec
;; SERVER: 10.1.2.13#53(10.1.2.13)
;; WHEN: Tue May  5 22:46:28 2009
;; MSG SIZE  rcvd: 180

Una respuesta adecuada no tendría que sobrepasar los 100 o 150ms. Para segundas consultas sobre el dominio el tiempo tendría que ser de 0ms ya que la respuesta queda cacheada por un periodo de tiempo.

Si aun así persisten los retardos en el DNS seria aconsejable pensar de colocar servidor DNS local a nuestra red (o en el propio servidor) que permita cachear todas las peticiones de DNS.

También es aconsejable comprobar si estamos utilizando los DNS proporcionados por nuestro propio ISP u otros ajenos a ellos.

Cortafuegos y uso de red
Otro aspecto a verificar son los firewalls, tanto de la propia maquina de correo como los que puedan haber durante salida hacia Internet. Debemos tener el máximo caudal posible hacia afuera para asegurarnos que los correos permanecen el mínimo de tiempo en la cola de salida.

Podrías hacer alguna vez un test de velocidad (http://www.adsl4ever.com/test/) y comprobar la velocidad de upload de tú servidor.

Open relay
Un open relay es una configuración especial de un MTA por la cual cualquiera que se conecte podrá utilizar nuestro servidor para enviar correo. Esta opción debería estar restringida solo para las maquinas de nuestra red. De lo contrario podría ser utilizada para el envió masivo de spam. Con el tiempo esto provocaría que fuéramos a parar a una lista de negra como Spamhaus, Sorbs, etc.

Para ello revisa el parametro "mynetworks" de Postfix (http://www.postfix.org/postconf.5.html#mynetworks).

# postconf | grep mynetworks
mynetworks = 127.0.0.0/8 192.168.2.0/24 10.5.0.0/16 10.6.0.0/16

En este caso solo las redes 192.168.2.0, 10.5.0.0 y 10.6.0.0 tienes derecho a enviar correo por este MTA.

Tambien puede revisar el parámetro "relay_domains":

myhostname = mxta.domain.com
mydomain = domain.com
mydestination = $myhostname, $mydomain
relay_domains = $mydestination
mynetworks = 127.0.0.0/8 192.168.1.0/24

Listas negras
Otra manera de reducir drásticamente el correo que entra (posible spam), el correo que rebota y tambien el correo que sale, es utilizar listas negras para filtrar el correo. Esto consiste en utilizar bases de datos de IPs de maquinas consideradas spammers.

Para configurar la utilizacion de listas negras se utiliza "smtpd_recipient_restrictions" y "reject_rbl_client".
En este caso utilizados tres bases de datos que contienen listas negras (Spamhaus, Sorbs y Spamcop).

Esto es una ejemplo de cómo utilizar el parámetro de configuración de Postfix dentro de main.cf:

smtpd_recipient_restrictions =
 reject_non_fqdn_recipient,
 permit_sasl_authenticated,
 permit_mynetworks,
 reject_unauth_destination,
 reject_unlisted_recipient,
 reject_invalid_hostname,  
 reject_non_fqdn_sender,
 reject_unknown_sender_domain,
 reject_rbl_client sbl-xbl.spamhaus.org,
 reject_rbl_client dnsbl.sorbs.net,
 reject_rbl_client bl.spamcop.net,
 permit

Teniendo en cuenta que actualmente el 80% del correo de Internet es spam, esto puede evitar la entrada de mucho correo en la cola. Yo, para unos 100 usuarios bloqueo unos 15.000 correos al día.

Otra buena opción es utilizar tambien un "reject_unknown_sender_domain" que rechaza el correo si el dominio del remitente no existe.

Cola deferred
En esta cola van a parar los mensajes que no se han podido enviar a alguno de los destinatarios y por tanto Postfix tiene que volver a reintentar el envío. Tanto las colas de incoming y deferred se miran periódicamente para ver si hay algún mensaje para enviar. Hay tres parámetros básicos en Postfix para controlar cada cuanto se miran estas colas y que afectan al rendimiento de postfix:
queue_run_delay, minimal_backoff_time y maximal_backoff_time.

El funcionamiento es el siguiente: cuando un mensaje llega este es procesado por el mta y enviado a la cola incoming. Por otro lado cuando se decide enviar un mensaje y Postfix se tiene que poner en contacto con otros mta, estos mensajes son enviados a la cola active. Si por cualquier motivo el mensaje no puede ser enviado a otro mta este pasará a la cola deferred hasta que pueda ser entregado más tarde o expire el tiempo de vida. El tiempo de vida de un mensaje en la cola deferred viene marcado por la variable $maximal_queue_lifetime. Si transcurrido este tiempo el mensaje no se pudo enviar este mensaje se devuelve al remitente pero solo en un tamaño concreto marcado por la variable bounce_size_limit. Si el remitente ha enviado un mail del 50Mb no tiene sentido devolverle otra vez el mail de 50Mb.

El escaneo de la cola de deferred para los reintentos sigue un algoritmo un poco complicado pero que básicamente es algo así: la cola deferred se escanea cada $queue_run_delay en busca de mensajes para enviar. Cuando un mensaje está en esta cola se le pone una marca de tiempo T. Si a los T segundos se hace el envío y este no tiene éxito, el siguiente envío se hace a los 2T y así sucesivamente.

Si quieres vaciar la cola de deferred más rápidamente, puedes modificar $maxima_queue_lifetime, que por defecto son 5 dias, para que los correos no permanezcan mucho tiempo en la cola.

Qshape
Una utilidad para controlar el estado de tú cola es qshape. Qshape te muestra la vejez de un correo dentro de la cola.

Si quieres saber más sobre qshape leete esto.
http://amperis.blogspot.com/2009/02/controlando-la-cola-con-qshape-parte-1.html< http://amperis.blogspot.com/2009/02/controlando-la-cola-con-qshape-parte-2.html

Denegando archivos
El denegar cierto tipo de archivos se puede considerar una manera de reducir ancho de banda para nuestro servidor y también tiempo de procesado de CPU en el caso que el correo se filtrara por un antivirus.

Es costumbre en los MTA finales restringir cierto tipo de archivos como: .exe, .pif, .reg, etc.
No estaría mal tampoco restringir archivos como mpge, mp3, avi, etc, siempre que podamos.
Hace como restringí los archivos wav de audio y no nos dimos cuenta de que la centralita telefónica necesitaba enviar mails con estos adjuntos para los mensajes de voz de los empleados.

Para denegar ciertas extensiones en un Postfix hay que utilizar el parámetro "$mime_header_checks". Aquí tines un ejemplo de como implementarlo: http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.html Para finalizar
Lo recomendable siempre es hecharle un vistazo a la documentacion de tuning del producto. Aquí está la documentacion ofical sobre tuning para Postfix: http://www.postfix.org/TUNING_README.html

¿sabes de algo más para repasar?

rastrear un log en tiempo real

2009-04-28T22:23:00.006+02:00

Buscar dentro de un log de correo puede resultar una tarea bastante complicada si buscamos un mail muy concreto y no para de entrar y salir correo. Una manera de filtrar un log de correo es hacerlo en tiempo real y filtrando por la dirección de correo que estamos buscando. Para ello utilizamos dos comando básicos de Linux. Por un lado el comando "tail" que te permite, por defecto, ver las 10 ultimas lineas de un fichero. Por otro lado el comando "grep" que te permite filtrar.

Podemos utilizar estos comandos por ejemplo para filtrar el archivo de log de Zimbra y comprobar como se comporta una dirección de correo al ser recibida por nuestro servidor. En este ejemplo, queremos ver que está pasando con los correos que vienen de "amperisblog[@]gmail.com".

# tail -f /var/log/zimbra.log | grep "amperisblog[@]gmail.com" --color

El parámetro "-f" pone el tail en tiempo real y el comando "--color" nos colorea lo que estamos buscando.

Este es el resultado:

mysql machacado

2009-04-20T18:09:00.001+02:00

Estoy un poco preocupado. Hoy se ha anunciado la compra de Sun por tarde Oracle, el de la bases de datos.
No solo ha comprado un entorno de arquitectura como Java, un montón de hardware en forma de servidores y un sistema operativo llamado Solaris que cada día tiene más agujeros que los calcetines de mi abuelo.

Estoy preocupado por MySql. No se si la gente lo sabe, pero resulta que fue comprada hace ya más de un año por Sun (en agosto del 2008), y ahora MySql es de Oracle. ¿Que puede pasar ahora?. Solo pueden pasar tres cosas: o el proyecto continua tal cual sin interferencia directa de Oracle, o Oracle inyecta más programadores aportando nuevo conocimiento al proyecto o finalmente queda desterrado al recuerdo de lo que pudo ser y no fue.

Que alegría me lleve el día que con el nuevo MySql 6 veríamos un nuevo engine llamado Falcon que decían que podría estar a la altura de Oracle. Sinceramente creo que el proyecto saldrá beneficiado con una nueva base de conocimiento y con el tiempo veremos un MySql con una cara nueva, manteniendo siempre una distribución libre.

Otro proyecto que corría por las manos de Sun era OpenOffice... a este si que le veo con más peligro. Hasta ahora el 80 o 90% de los programadores de OpenOffice estaban aportados por el propio Sun. Los otros que programaban líneas para OpenOffice era IBM, Google, RedHat, Novell... creo que IBM dejará de programar nada para OpenOffice después de que le quitaran el pastel. No veo a Oracle apostando nada nuevo por OpenOffice... creo que continuará pero cada vez irá a menos.

Oracle ha ganado más al comprar Sun que si hubiera sido IBM.

¿tendré que migrar a postgresql?... ¿tendremos que pagar las licencias de Office y quitarnos las piratas?.

¿soy un proxy?

2009-04-14T23:09:00.011+02:00

Otra de las cosas extrañas (ver el caso del Dfind) que puedes encontrar dentro de cualquier log de un webserver, son peticiones web de urls que no existen dentro de tú servidor.

Peticiones como estas, encontradas en un log de Apache:

217.76.199.246 - - [08/Apr/2009:13:52:34 +0200] "GET http://www.cship.info/azenv.php HTTP/1.0" 404 207
87.118.124.104 - - [14/Apr/2009:23:06:41 +0200] "GET http://www.ip-adress.com/proxy_callback.php HTTP/1.0" 404 216
209.8.45.202 - - [14/Apr/2009:23:38:31 +0200] "POST http://www.trafflow.com/testpr/eng.php HTTP/1.0" 404 212
67.225.243.14 - - [15/Apr/2009:11:45:12 +0200] "GET http://www.secretipaddress.com/ip.php HTTP/1.1" 404 204

Se trata de peticiones (posiblemente de robots) que van en busca de direcciones IP que contengan algún tipo de proxy anónimo funcionando. El objetivo es que alguien pueda utilizar nuestra dirección para navegar anónimamente.. posiblemente lo consigan porque no hemos sido cuidadosos al montar nuestro server.

Mírate proxy4free si buscas proxys anónimos para utilizar en tus fechorias.

En el anterior ejemplo alguien en la dirección IP 67.225.243.14 ha intentado solicitar a mi servidor la url http://www.secretipaddress.com/ip.php y yo como no la tengo o no tengo ningún servicio de Proxy le he devuelto un error 404.
Vamos a simular esta petición haciendo un Telnet, o mejor aun, utilizando alguna tool de fetch. Yo utilizaré wfetch de Microsoft:

Como veis el servidor le contesta con un error 404 de “Request not found”.

Probamos ahora utilizando un Proxy anónimo. Por ejemplo 221.226.153.178:3128 que está en China:

Ahora sí que vemos cómo al solicitar una url a la IP 221.226.153.178, esta nos devuelve un resultado. El resultado de “ip.php” resulta ser la dirección IP del solicitante de la url. En este caso el solicitante no soy yo desde mi casa con la tool wfetch sino el Proxy anónimo que para eso es su función.

Si por cualquier motivo tú server está haciendo de Proxy y se te están colando para navegar de forma anónima (y pronto aparecerás en listas de proxys anónimos) o porque tienes un squid funcionando o porque tienes activada la opción de proxy en Apache. Muy posiblemente tengas en Apache activado el ProxyRequest.

Si ves peticiones de esta clase en tú log de Apache, no esta de más que te verifiques que no haces de Proxy. Aquí tienes una web donde puedes comprobar sí tú dirección IP hace de Proxy: http://www.ip-adress.com/Proxy_Checker/

Más información:
+ Montar un Proxy cache utilizando Apache
+ Fortificando un servidor Apache (¿el malo malote hablando de Apache?)

no more secrets

2009-04-12T21:07:00.011+02:00

Una de las cosas que realmente me gustan es coleccionar fotos de CPDs. Quedé realmente impresionado cuando ví por primera vez el datacenter de Colt en Barcelona. Me acuerdo la primera vez que me dieron unos cubre zapatos como los que se ponen los médicos al entrar en el quirófano… Creía que estaban de cachondeo conmigo, pero realmente había que ponérselos para entrar.

Lo primero que ví fue a una mujer de la limpieza pasando el aspirador por debajo de de los racks. Resulta que todo el suelo es flotante de un par de metros. La mujer iba sacando baldosa por baldosa y se iba metiendo dentro para sacar el polvo. Creo que han pasado ya unos siete u ocho años de eso.

Realmente sabes como es un administrador dependiendo de lo limpio y ordenado que tenga su CPD.

Hace unas semanas Cnet publicó una entrevista desvelando como eran los datacenters de Google. Todo el mundo sabía que se los fabricaban ellos mismos y que utilizaban una especie de containers modulares en forma de rack.
Los videos y las fotografías me parecieron espectaculares. Como ya sabíamos todos se fabrican ellos mismos los servidores:

Este es uno de los servidores de Google:

Como veis en la foto utilizan una placa Gigabyte modelo GA-9IVDP con 8Gb de RAM y dos procesadores (Intel o AMD, les es indiferente). Además utilizan dos discos SATA de marca Hitachi. De fuete de alimentación utilizan una de la marca Magnetick de la cual salen unos cables hacia una batería (no hay fuentes redundantes ni nada esos). Todo esta montado sobre una base de hojalata especialmente cortada para alojar todos estos componentes. No hay tapa, no hay ventiladores y todo está atado por unas tiras de velcro. ¿Cuánto tiempo tardarías en cambiar una fuente o un disco a este servidor? En cuanto a la placa base no intentes comprarla porque no está disponible. Posiblemente hayan llegado a un acuerdo y sean placas especialmente creadas y diseñadas para Google.

Todo el mundo compra servidores a Dell, HP, IBM o Sun, pero Google se los fabrica. Si a esto le sumamos que utilizan versiones con Linux especialmente compilados por ellos, les sale el servidor por cuatro duros.

Pero realmente lo sorprendente de este diseño es la inclusión de una batería de 12V en cada servidor. Según ellos es un problema de costes respecto a un SAI que alimente a todos los servidores. Este modelo ya está patentado y seguro que veremos pronto servidores de Dell o HP que incluyan un batería en su interior. La obsesión de Google por el ahorro energético y la optimización ya venía de lejos con sus creadores. Larry y Sergey ya preveían la cantidad inmensa de energía que necesitarían para alimentar todos los servidores en los siguiente años con la expansión del buscador.

Otro ejemplo. Su fuente de alimentación especialmente creada por la empresa Magneteck suministra 12V a la placa y no 12V+5V como las convencionales. Si os fijais en la pegatina de la fuente de alimentación tiene hasta su propio “Google Part Number”… fuentes especiales para Google.

Ben Jai es el ingeniero de Google que lleva diseñando estos servidores desde el 2005 y ya se encuentran en su séptima generación de diseño.

Bueno ya tenemos el servidor, ahora hay que enrracarlo.

Google no pone servidores en su datacenter, sino que pone contenedores llenos de 1.160 servidores dentro. No es la única empresa que utiliza contenedores con servidores dentro, ya lo hace Sun o Rackable Systems con su IceCube Modular datacenter, pero sí fue el primero.

Utilizan un contenedor (como los de los barcos) de tamaño 1AAA y lo equipan con su puerta de entrada, su salida de emergencia, su sistema de refrigeración y todas las estanterías para meter todos los servidores como el que hemos visto. Una vez tienen un container montado es muy fácil llevarse todos estos de una lado a otro del planeta y montar un datacenter de Google en cualquier sitio.

Aquí tenéis los tres videos que hizo Google en su conferencia de 6 horas para presentar el modelo y diseño de sus datacenters:

¿Veremos en un futuro a Google como proveedor de datacenters?

Si alguien se ha quedado impresionado como yo aquí tenéis un video de todo. Vale más una imagen que mil palabras:

Fotografías originales de Cnet.

service zimbra start

2009-04-09T21:01:00.007+02:00

Al instalar Zimbra bajo un RedHat o CentOS este te creará un servicio llamado zimbra dentro de tú /etc/init.d que te permitirá arrancar de formá más sencilla con un “service zimbra stop” o un “service zimbra start” sin necesidad de entrar como usuario zimbra y luego hacer un zmcontrol.
El problema es que este servicio montado de esta forma no da información de nada (excepto mirando el log).

Para evitar este comportamiento editamos /etc/init.d/zimbra y cambiamos la línea 31. Esta línea contiene algo como:

su - zimbra -c "zmcontrol $1  </dev/null >> /opt/zimbra/log/startup.log 2>&1"

Lo cambiaremos simplemente por:

su - zimbra -c "zmcontrol $1"

Reiniciamos el servidor y vemos la diferencia:

Lo probamos tambien a pelo:

el mejor paseo por mi pueblo

2009-04-03T20:26:00.002+02:00

Mar y Montaña en Street View from Buceante Johnston on Vimeo.

Enlace original

generar certificado zimbra con microsoft certification authority

2009-04-02T17:06:00.027+02:00

Supongamos que en nuestra empresa tenemos instalado un Microsoft Certification Authority en local que nos proporciona todos los certificados que necesitamos. Por ejemplo para nuestros sitios web ASP de IIS.

Voy a utilizar esta autoridad de certificación para generarme un certificado para Zimbra. De esta forma como todas mis maquinas de Windows de la empresa tienen instalado dentro de sus "autoridades de certificación de confianza" el certificado raiz de mi autoridad, cuando entren en Zimbra por SSL no tendrán ningún problema.

He de suponer que ya tienes instalado el Microsoft Certification Authority en tú server y que sabes más o menos como funciona. Si no lo tienes instalado haz "Inicio->Configuración->Panel de control->Añadir o quitar programas->Añadir o quitar componentes de Windows". Selecciona servicios de certificación e instálalo. Créate una autoridad de certificación por ejemplo con el nombre "miempresa_CA".

Una vez instalado tienes que tener la consola accesible desde las Herramientas Administrativas de tú Windows Server.

Comenzamos:

+ Primero tenemos que decirle a Zimbra que queremos hacer una petición de certificado a una autoridad de certificación externa. Ya sea comercial como Verisign o local como en nuestro caso.

Necesitamos generar un CSR (Certification Signing Request). Nos vamos a la consola de admin y buscamos Configuracion->Certificados->Instalar certificado.

Seleccionamos nuestro nombre de servidor. Por ejemplo misrvzimbra.miempresa.com. Luego le decimos que genere la función CSR.

Luego rellenamos los datos que nos piden para generar el certificado. El campo más importante es el "Nombre común". Este debe coincidir con el nombre de URL que utilizarás para acceder a tú webmail. Es decir, tú servidor se llama misrvzimbra.miempresa.com, pero cuando accedas vía Web lo harás con webmail.miempresa.com. Si no colocas este nombre correctamente el IE te dirá que estas accediendo a un sitio peligroso porque el certificado no es correcto.

Para finalizar debes descargarte el fichero .csr. Este es el archivo que tendrías que enviar a la autoridad de certificación.

+ Una vez tengamos nuestro .csr nos vamos a nuestra CA. Para ello cargamos la pagina web de nuestra autoridad de certificación de Microsoft. Accedemos a http://miserverwindows/certsrv y nos aparece algo como:

Lo primero que haremos es descargamos el certificado raíz de la CA. Para ello vamos a "Download CA certificate...". Seleccionamos Base64 y descargamos el certificado con "Download CA certificate". Este es el certificado que tendríamos que instalar en todas nuestras maquinas dentro de "Autoridades de certificación de confianza".

+ Ahora ya podemos generar nuestro certificado Zimbra con la ayuda del .csr. Nos vamos otra vez a http://miserverwindows/certsrv y le decimos "Request a certificate->Advanced certificate request". Seleccionamos la opción "Submit a certificate request by using a base-64...".

Abrimos con el notepad el .csr anterior y pegamos dentro de la web su contenido. Además tendremos que decirle que lo que estamos pidiendo es un certificado para un servicio web.

Una vez enviada la petición nos generará nuestro certificado. Seleccionamos base-64 y le decimos "Download certificate".

+ Ya tenemos los dos certificados. El de la autoridad de certificación y el que hemos pedido para Zimbra. Ahora como paso excepcional para Zimbra tenemos que hacer una pequeña modificación dentro de los dos archivos .cer. Esta modificación consiste en abrirlos con el notepad y dejar una linea en blanco después del "-----END CERTIFICATE----- ". Esto es debido a un bug de Zimbra que no es capaz de detectar el final del archivo.

+ Estamos listo para cargar el certificado dentro de Zimbra. Volvemos a la consola de administración de Zimbra y le volvemos a decir "Instalar certificado".

Esta vez no volvemos a generar la función CSR otra vez sino que le diremos "Instalar certificado firmado comercialmente".

Para finalizar le diremos el path donde se encuentra nuestro nuevo certificado para Zimbra como el propio certificado de la autoridad de certificación.

Una vez instalado y sin ningún error ya podemos reiniciar Zimbra y comprobar como nuestro webmail se carga por SSL con el nuevo certificado.

Si hay algún otro problema para instalar los certificados comerciales lo mejor es hacerlo desde la linea de comandos como root:

# zmcertmgr deploycrt comm /tmp/certnew.cer  /tmp/certificado_empresaCA.cer

Más información:
+ Conceptos básicos sobre SSL
+ Zimbra-grupo
+ Commercial certificates in Zimbra

resultados de "el quiz 1"

2009-03-28T17:49:00.013+01:00

Felicidades a todos los participantes de "el quiz 1"!!!

Os paso la lista de los 8 concursante que se atrevieron a entregar sus respuestas. A los tres ganadores pronto les enviaré un mail para que se puedan descargar su premio.

En total habian 15 personas inscritas... espero en el próximo "quiz 2" sea más numeroso.

Puntos Concursante                Envío Quiz
------------------------------------------------------------
29     o.navarro.san...@gmail.com 2009-03-23 14:05:00 GANADOR 1
29     ignacio.p...@gmail.com     2009-03-26 18:32:00 GANADOR 2
24     guevat..@gmail.com         2009-03-15 02:17:00 GANADOR 3
20     bacanchil..@gmail.com      2009-03-17 21:00:00 
16     artemic...@gmail.com       2009-03-16 11:03:00 
13     richze...@gmail.com        2009-03-16 15:43:00 
7      cool.ron...@gmail.com      2009-03-26 00:41:00 
2      cejodr...@gmail.com        2009-03-23 15:10:00

Aquí tenéis las respuestas para descargar y espero que todo el mundo las entienda y no haya ninguna confusión:
elquiz1_conrespuestas.pdf

Estás son las consultas SQL de las tablas para que veáis que no hay ni trampa ni cartón :).

Hasta la próxima pequeños spammers.

w00tw00t.at.ISC.SANS.DFind

2009-03-23T18:51:00.001+01:00

Hace unas semanas en SecurityByDefault se discutía de la presencia de unas peticiones raras en los servidores Web.

Peticiones del estilo: GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1

Varias y varias de estas peticiones se pueden encontrar continuamente en los logs de los servidores web. Aparentemente peticiones que no acaban en ningún ataque concreto. Aun teniendo la posibilidad de analizar la tool DFind se apresuran a decir que no puede ser este escaner el que genera ese tráfico.

Pues bien, Dfind es un escaner de puertos que al generar sus peticiones coloca "w00tw00t.at.ISC.SANS.DFind". Este escaner se puede bajar de heapoverflow.

Aquí tenéis unas cuantas capturas de la aplicación y de la captura del tráfico:

whitelist y blacklist en amavis

2009-03-20T23:29:00.009+01:00

Una de las maneras más fáciles de crear una whitelist/blacklist para Zimbra es utilizar un parámetro de configuración de Amavis llamado read_hash(). No he encontrado mucha documentación sobre esta función pero básicamente es para leer ficheros de texto.

Supongamos que tenemos un conjunto de direcciones a las que no queremos aplicarles ninguna comprobación de spamassessin (whitelist) y otro conjunto que directamente queremos bloquear (blacklist).
Para ello creamos dos archivos llamados /etc/zimbra/whitelist y /etc/zimbra/blacklist:

# cat /etc/zimbra/whitelist
amYYY@gmail.com
# cat /etc/zimbra/blacklist
amZZZ@gmail.com

Con el siguiente ejemplo siempre denegaremos cualquier correo de amperisblog@gmail.com y siempre aceptaremos correos de amperis@gmail.com. A las direcciones dentro de la whitelist no se le aplicará ningún test de antispam.

Ahora solo tenemos que decirle al Amavis donde están estos dos archivos. Para ello editamos el /opt/zimbra/conf/amavisd.conf.in y añadimos las siguiente lineas:

read_hash(\%whitelist_sender, '/etc/zimbra/whitelist');
read_hash(\%blacklist_sender, '/etc/zimbra/blacklist');

Por último reiniciamos Amavis o Zimbra:

# su - zimbra
# zmamavisdctl stop
 Killing amavisd with pid 2000 done.
# zmamavisdctl start
 Started amavisd: pid 4957

Si intentamos enviar un correo desde amperisblog@gmail.com (que está dentro de la blacklist) a test@miempresa.com veremos como dentro del Log de Zimbra se denegará el correo:

# cat /var/log/zimbra.log | grep amperisblog
...
Mar 20 23:20:45 srv amavis[2092]: (02092-01) Blocked SPAM, [219.85.216.175] 
amperisblog@gmail.com -> test@miempresa.com, Message-ID: 
<220528c0903201520o6d42864et8445ed29abebaac6@mail.gmail.com>, mail_id: 
Me6GVPFvH3Um, Hits: -, size: 2490, 13055 ms

Lo contrario, si enviamos un mail desde amperis@gmail.com este llegará y si observamos las cabeceras del correo veremos como no se le aplica ninguna comprobación antispam:

X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=x tagged_above=-10 required=5 WHITELISTED tests=[]

en tú casa con 24Gb de ram

2009-03-11T18:45:00.000+01:00

Resulta que Kingston tiene ya memorias DDR3 de 4Gb ($173 unidad). Por tanto si utilizamos la nueva Gigabyte GA-EX58 UD5 (unos $300 sin CPU) podemos tener hasta 24Gb de RAM para nuestro VMWare. 9 maquinas virtuales (más la física) corriendo en tú casa.

reinicio masivo de polycoms

2009-03-10T18:45:00.002+01:00

Existen varias maneras de reiniciar los teléfonos Polycom desde Asterisk, pero todas se basan en el comando de consola "sip notify polycom-check-cfg [num_extension]". Este comando se puede lanzar desde un dialplan, desde la propia consola o desde un script. También hay algún loco que se atreve a construir el paquete UDP de SIP y lanzarlo a la red.

Para que los Polycom acepten este tipo de eventos externos tenemos que cambiar en sip.cfg de los teléfonos el parámetro voIpProt.SIP.specialEvent.checkSync.alwaysReboot y cambiar el 0 por un 1. Una vez reiniciado el teléfono este ya es capaz de aceptar paquetes especiales, como por ejemplo los de reinicio.

El siguiente script en Perl hace una consulta a la base de datos MySql de Asterisk, lee todas las extensiones SIP existentes y va una por una reiniciando los teléfonos.

#!/usr/bin/perl

use Mysql;

$dbhost = "localhost";
$dbname = "asterisk";
$dbuser = "asteriskuser";
$dbpsw  = "pswastx";

$connect = Mysql->connect($dbhost, $dbname, $dbuser, $dbpsw);
$connect->selectdb($dbname);

$myquery = "
   SELECT extension 
   FROM users
   ORDER BY extension";

$execute = $connect->query($myquery);

print "Reboot All Polycom v0.1b, por amperis <amperis\@gmail.com>\n";
while ( @results = $execute->fetchrow() ) {
   print " -> Reiniciando extension $results[0]...\n";
   sleep 1;
   system("/usr/sbin/asterisk -rx \"sip notify polycom-check-cfg $results[0]\"");
}

print "Fin. Todos los telefonos estan reiniciados.\n\n";

secuestrando sesión del admin de zimbra

2009-03-08T20:51:00.013+01:00

El peligro de que Zimbra no redirecciona por defecto a SSL es que si el admin de Zimbra lee su correo vía webmail es posible secuestrar su sesión y utilizarla desde un atacante para entrar en su correo. Posteriormente puede cambiar la contraseña una vez dentro y por tanto entrar en el panel de administración.

La idea es sniffar la red en buscar de la cadena de autentificación. Lo que buscamos es ZM_AUTH_TOKEN (o tambien authToken) que se utiliza por ejemplo para la cokkie que genera Zimbra cuando le decimos recordar contraseña y de esta forma no tenemos que escribir la password cada vez.

Arrancamos un sniffer y con paciencia capturamos el authToken del admin o de cualquier otro usuario de Zimbra que despistado de el no utiliza SSL. Capturamos tráfico del 80/TCP y buscamos dentro de los paquetes la dirección de correo del admin (en mi caso busco admin@amperisblog.com).

Si el admin utiliza SSL tendremos que inventarnos otros sistemas para entrar. Por ejemplo si tenemos acceso a sus carpetas de su disco podríamos robarle el archivo físico de la cookie y buscar dentro de ella ZM_AUTH_TOKEN. Otra posibilidad es hacer una ataque XSS que al visitar cierta Web nos envíe su cookie.

Ya tenemos la cookie:

authToken =
0_573b037a47ee191358f4172bdc5acf5c23ff6cb6_69643d33363a34353462313238662d326538662d3430
65382d622236612d6627356432666331643864303b6578703d31333a313233363731323638393232343b747
270653d363a7a696d6272613b

Ahora solo nos queda utilizar esta autentificación para validarnos como admin. Abrimos Firefox e instalamos un complemento como "Cookie Editor". Lo que vamos hacer es coger nuestra cookie de validación de Zimbra que nos permite entrar como alejandro@amperisblog.com sin necesidad de estar poniendo la password cada vez y vamos a sustituir el ZM_AUTH_TOKEN.

Buscamos nuestra cookie:

La editamos y ponemos el authToken que hemos encontrado anteriormente:

Finalmente refrescamos nuestro webmail y deberíamos entrar automáticamente como administrador:

Intentamos ahora cambiar la contraseña del admin, hacemos "Preferencias -> General -> Cambiar contraseña"... opsss me pide la contraseña antigua... :(

fiberparty 2009

2009-03-07T17:13:00.006+01:00

Hoy he estado en la fiber party que cada año se celebra en la UPC. La idea era ir a ver la cantidad de gente que se reune allí a jugar y beber redbull, y al terminar pasarme por dos charlas que me interesaban. Una de Drupal y la otra de virtualización sobre Linux con KVM.

No se si el destino lo quería pero he visto un tio leyendo su correo por Zimbra que luego resultaba ser el ponente de la charla de KVM. Resulta que tiene un servidor de Zimbra virtualizado con Ubuntu+KVM... corriendo en total 7 servidores virtuales, con un Quad Core y 8 Gb de RAM.

Bueno estas son algunas fotos. Fijaos como una de las chicas está toda maquillada y arreglada para jugar al campeonato de Call Of Duty.

Todas las fotos en flicker.

el quiz 1 de zimbra-grupo

2009-03-06T23:51:00.006+01:00

Hace casi un año que está funcionando el zimbra-grupo y ya hay 106 miembros y casi 1000 mensajes.
Para celebrarlo he creado un juego en forma de test... para saber quien es el más listo de todos... Están invitados todos los miembros del grupo. La idea es ir haciendo más pruebas (no necesariamente tests) e ir sumando puntos.

Aquí encontrareis las normas del juego.

En un futuro habrán más novedades. Se está trabajando en migrar el grupo a algo más potente como un foro en phpbb... siguiente objetivo: Zimbra Community.

Un saludo pequeños spammers.

añadir antivirus f-prod a zimbra

2009-02-26T19:02:00.009+01:00

Describo como añadir otro de los pocos antivirus gratuitos que hay para Linux para que trabaje junto Zimbra. El F-prot antivirus for Linux.

+ Descargar la versión free de F-Prot Antivirus para Linux (fp-Linux-i686-ws.tar.gz) desde:
http://www.f-prot.com/products/home_use/linux/
+ Copiar el archivo comprimido en /opt y descomprimir:

# tar -xzvf fp-Linux-i686-ws.tar.gz
# cd /opt/f-prod

+ Una vez decomprimido instalar con el siguiente script:

# ./install-f-prot.pl

El proceso de instalación es muy rápido y no pide nada de especial.

+ Lanzar el comando "fpupdate" para actualizar las firmas. Utilizar este mismo comando para programar un cron para que se actualice el antivirus de forma automática varias veces al dia.

+ Para que lo reconozca Amavis debemos añadir esta nueva definición de antivirus dentro del amavisd.conf.in. Si esta definición no existe dentro de tú Zimbra 4 o 5 añadirla tal cual:

@av_scanners = (
...
### F-prot Antivirus
['F-PROT Antivirus for UNIX',
['fpscan'],
'--report --mount --adware {}',
# consider: --applications -s 4 -u 3 -z 10
[0,8,64], [1,2,3, 4+1,4+2,4+3, 8+1,8+2,8+3, 12+1,12+2,12+3],
qr/^\[Found\s+[^\]]*\]\s+<([^ \t(>]*)/
],
### fin F-prod
...

+ Reiniciamos Zimbra o el daemon de amavis:

# su - zimbra
# cd /opt/zimbra/bin
# ./zmamavisdctl stop
# ./zmamavisdctl start

+ Verificamos que una vez arrancado el Amavis este es capaz de encontrar el nuevo antivirus. Para ello miramos dentro del log de Zimbra:

# cat /var/log/zimbra.log grep F-PROT
Feb 26 13:07:59 srvzimbra amavis[25125]: Found primary av scanner F-PROT Antivirus for
 UNIX at /usr/local/bin/fpscan

+ Utilizamos un virus Eicar y vemos si realmente el nuevo antivirus (junto al resto) están detectando los virus:

scp entre maquinas

2009-02-23T08:04:00.000+01:00

Existen varias formas de copiar archivos entre dos maquinas Linux: rsync, nfs, samba o como en este caso scp.
SCP es una tool para copiar archivos de forma segura entre dos maquinas utilizando el protocolo SSH.

El siguiente ejemplo copia de forma segura el archivo "backup.tar.gz" de la maquina srv1 a la maquina srv2 y lo deja en la carpeta /tmp.

[root@srv1 tmp]# scp backup.tar.gz srv2.miempresa.com:/tmp
The authenticity of host 'srv2.miempresa.com (10.1.2.34)' can't be established.
RSA key fingerprint is e9:40:f0:67:6b:4c:3b:03:ad:22:9f:38:98:51:56:29.
Are you sure you want to continue connecting (yes/no)? 

root@srv2.miempresa.com's password: 
backup.tar.gz      100%    0     0.0KB/s   00:00

scp es de lo más fácil de utilizar y seguro, pues a diferencia de nfs o samba no tienes que configurar nada de especial, ni dar permisos especiales ni nada. Normalmente todos los servidores Linux tienen levantado el daemon de SSH para la gestión remota, por tanto scp hará uso de ello.

El problema es cómo hacer que scp sea automático y no pida el intercambio de llaves, ni la contraseña cada vez que lancemos el comando contra un servidor. Esto puede ser necesario si queremos programar scp en un cron para que copie archivos de un servidor a otro de forma automática.

+ Generamos unas llaves de autentificación 1024 bits.

[root@srv1 tmp]# ssh-keygen -t rsa -b 1024
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase):
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
10:cc:98:90:5b:7f:9e:ef:bb:7a:f7:6c:d2:a2:ca:7d root@srv1.miempresa.com

+ Copiamos la clave publica al servidor de destino. En nuestro caso “srv2”.

[root@srv1 tmp]# scp /root/.ssh/id_rsa.pub srv2.miempresa.com:/root/.ssh/
root@srv2.miempresa.com password: 
id_rsa.pub          100%  232     0.2KB/s   00:00

+ En la maquina remota renombramos el archivo copiado y damos los permisos oportunos.

[root@srv2 .ssh]# cp id_rsa.pub authorized_keys
[root@srv2 .ssh]# cd
[root@srv2 ~]# chmod go-w . .ssh .ssh/authorized_keys

+ Ahora como ya hemos intercambiado las llaves entre estos dos servidores ya podemos entrar de uno al otro sin necesidad de password. Podemos utilizar tanto ssh como scp.

[root@srv1 tmp]# ssh srv2.miempresa.com
Last login: Fri Feb 20 22:00:56 2009 from srv1.miempresa.com
[root@srv2 ~]#