jueves, 31 de mayo de 2007

Monitorizando un Raid en Linux: Estado y Ocupación

   Enlazando con el artículo anterior del envío de alarmas al móvil utilizando el API de Google Calendar, le he dado utilidad al programa. Desde hace unos días lo utilizo para monitorizar el estado del raid 1 del servidor de backup y enterarme de manera instantánea de cualquier problema con algún disco.

   Utilizando mdadm en modo monitor lo configuré para que ejecutara un script cuando detectara algún evento del raid. De todos los eventos posibles, los que a mi me interesan son:
  • Fail: Cuando se produce un fallo en algún disco del raid.
  • DegradedArray: Si se ha producido un fallo en algún disco y se ejecuta de nuevo el mdadm, se genera este evento. El caso más típico para un raid 1 es que ha fallado un disco y hemos reiniciado la máquina y estamos trabajando sólo con el otro disco. Sirve a modo de recordatorio de que hay que cambiar el disco defectuoso y reconstruir el raid.
  • RebuildStarted: Este evento se genera cuando comienza la reconstrucción del raid.
  • RebuldFinished: Cuando se ha terminado de reconstruir el raid se lanza este evento.

  •    El resto de eventos no me afectan demasiado, así que simplemente los guardaré en un log. Para ejecutar un script cuando se produce un evento en el raid en lugar de la notificación por email, es necesario hacer un pequeño cambio en el archivo /etc/init.d/mdadm.
  • Definimos la ruta del script:
    PROGRAM=/root/scripts/monitorRaid.sh
  • En "start" cambiamos la instrucción que viene por:
    start-stop-daemon -S -p $PIDFILE -x $MDADM -- -F -i $PIDFILE -p $PROGRAM -f --scan

  •    El script monitorRaid.sh que he creado es el siguiente:
    shian:~# cat scripts/monitorRaid.sh
    #!/bin/sh
    # Script de generación de alarmas según el estado del raid
    #
    # Iván López Martín
    # http://lopezivan.blogspot.com
    #####

    RAID_EVENT=$1
    LOG_DIR=/var/local/raid
    LOG_FILE=monitor_raid.log
    SMS_PROGRAM=/root/scripts/enviaSMS.sh
    GMAIL_USER=usuario@gmail.com
    GMAIL_PASS=mipassword

    if [ $RAID_EVENT == "Fail" ]; then
    date >> $LOG_DIR/$LOG_FILE
    echo Fail >> $LOG_DIR/$LOG_FILE
    echo >> $LOG_DIR/$LOG_FILE

    # Envío del SMS
    $SMS_PROGRAM $GMAIL_USER $GMAIL_PASS "ERROR CRITICO: Ha fallado un disco del raid."

    elif [ $RAID_EVENT == "DegradedArray" ]; then
    date >> $LOG_DIR/LOG_FILE
    echo DegradedArray >> $LOG_DIR/$LOG_FILE
    echo >> $LOG_DIR/$LOG_FILE

    # Envío del SMS
    $SMS_PROGRAM $GMAIL_USER $GMAIL_PASS "RECORDATORIO: El raid está funcionando con un solo disco."

    elif [ $RAID_EVENT == "RebuildStarted" ]; then
    date >> $LOG_DIR/$LOG_FILE
    echo RebuildStarted >> $LOG_DIR/$LOG_FILE
    echo >> $LOG_DIR/$LOG_FILE

    elif [ $RAID_EVENT == "RebuildFinished" ]; then
    date >> $LOG_DIR/$LOG_FILE
    echo RebuldFinished >> $LOG_DIR/$LOG_FILE
    echo >> $LOG_DIR/$LOG_FILE

    # Envío del SMS
    $SMS_PROGRAM $GMAIL_USER $GMAIL_PASS "INFO: Ha terminado la reconstrucción del raid."

    else
    date >> $LOG_DIR/$LOG_FILE
    echo $RAID_EVENT >> $LOG_DIR/$LOG_FILE
    echo >> $LOG_DIR/$LOG_FILE
    fi

       Para probar que está todo bien configurado, podemos ejecutar el monitor del raid en modo Test:
    shian:~# mdadm -F -p /root/scripts/monitorRaid.sh --scan -t -1

    shian:~# tail -3 /var/local/raid/monitor_raid.log
    Mon May 21 18:15:17 CEST 2007
    TestMessage

       Si vemos el mensaje de prueba significa que la monitorización es correcta, ahora sólo queda esperar a que falle algún disco (ojalá no ocurra) para que el programa de alarmas por sms cumpla su función.

       Adicionalmente he creado otro script que ejecuto por medio de crontab cada 10 minutos que monitoriza la ocupación de los filesystems (en este caso sólo el del raid) y cuando se supera un umbral se envía una notificación por SMS.
    shian:~# cat monitorFS.sh
    #!/bin/sh
    # Script de monitorización del tamaño de un filesystem y envío de alarmas por SMS
    #
    # Iván López Martín
    # http://lopezivan.blogspot.com
    ######

    FILESYSTEM=$1
    TMP_DIR=/root/scripts
    SMS_PROGRAM=/root/scripts/enviaSMS.sh
    GMAIL_USER=usuario@gmail.com
    GMAIL_PASS=mipassword

    SPACE_USED=`df | grep $FILESYSTEM | awk '{print $5}' | sed 's/%//g'`

    if [ "$SPACE_USED" -gt 90 ] ; then
    if ! [ -f $TMP_DIR/.fs_90 ] ;then
    SEND_SMS=YES
    THRESHOLD=90
    touch $TMP_DIR/.fs_90
    fi
    elif [ "$SPACE_USED" -gt 80 ] ; then
    if ! [ -f $TMP_DIR/.fs_80 ] ;then
    SEND_SMS=YES
    THRESHOLD=80
    touch $TMP_DIR/.fs_80
    fi
    elif [ "$SPACE_USED" -gt 70 ] ; then
    if ! [ -f $TMP_DIR/.fs_70 ] ;then
    SEND_SMS=YES
    THRESHOLD=70
    touch $TMP_DIR/.fs_70
    fi
    elif [ "$SPACE_USED" -gt 60 ] ; then
    if ! [ -f $TMP_DIR/.fs_60 ] ;then
    SEND_SMS=YES
    THRESHOLD=60
    touch $TMP_DIR/.fs_60
    fi
    fi

    if [ "$SEND_SMS" == "YES" ] ; then
    # Envio del SMS
    $SMS_PROGRAM $GMAIL_USER $GMAIL_PASS "El filesystem" $FILESYSTEM "supera el "$THRESHOLD"%."
    fi

    domingo, 20 de mayo de 2007

    Usando el API de Google Calendar: Alarmas por SMS

       Hace un tiempo descubrí Google Calendar, y aunque no lo utilizo mucho tiene una característica que me llamó la atención desde el principio. Una vez que defines una cita o evento, puedes asociarle un recordatorio para que te avise por email o con un pop-up si tienes la web abierta; hasta aquí ninguna novedad. Lo realmente novedoso es que también permite avisarte por medio de un SMS al móvil y además, en el caso de España es gratis. Sólo hay que asociar a nuestra cuenta de google nuestro número de teléfono móvil y después de una verificación de identidad podemos añadir el aviso por sms como recordatorio de las citas.

       Teniendo esto en mente pensé que sería realmente útil poder enviar alarmas al móvil con el estado de los servidores de casa. Así, si normalmente tenemos alguna tarea programada en crontab que nos avisa por email cuando termina mal, algún monitor de los servicios, espacio en los filesystems,... podríamos añadir una llamada a un programa adicional que introdujese un evento en nuestro calendario de google para que nos llegara el aviso por medio de un sms al móvil y así estar informados en todo momento del estado de nuestras máquinas :-).

       Pues dicho y hecho, me puse a buscar y lo que encontré no pudo ser mejor. Google proporciona un acceso completo a su API, con ejemplos, foros, y además disponible desde varios lenguajes de programación (Java, .Net, PHP y Python). De todos estos, el que más conozco y con el que más he trabajado (aunque ya haga tiempo que no lo toco demasiado) es Java. Además, tiene la ventaja de que al ser multiplataforma podría monitorizar también máquinas windows.

       Me instalé Eclipse y la máquina virtual de Sun 1.5 (ojo que esto es importante, no funciona con la 1.4.2) por medio de un simple apt-get. De la web de google descargué las librerías cliente para java y me puse a probar alguno de los ejemplos. La verdad es que el código es muy sencillo y está muy bien explicado. Hay ejemplos de autenticación, consulta de los eventos del calendario entre determinadas fechas, alta de eventos, borrado, actualización...

       Después de realizar un par de pruebas tenía un esqueleto que funcionaba aunque había que afinar. Examinando con más detalle las clases con Eclipse y con unas pocas pruebas posteriores terminé la versión 0.1 que permite insertar un evento en nuestro calendario y recibir un aviso por sms en 1 minuto. Aspectos a tener en cuenta del código:
  • Para conseguir que llegue el aviso dentro de un minuto lo que hago es poner la hora de comienzo del evento dentro de 6 minutos y la notificación por sms 5 minutos antes. Aunque por código es posible fijar el recordatorio dentro de 1 minuto, luego, cuando se envía la petición se nos muestra un error diciendo que no es válida.
  • Parece que la clase DateTime de Google no se lleva muy bien con la clase Date. Al principio creé un objeto con la hora actual para asignarselo al comienzo del evento, pero una vez asignado, la fecha que ponía era de dos horas antes!. Lo resolví creando un TimeZone para "Europe/Madrid" y utilizándolo en la creación de dicho objeto. Luego hablando con un compañero y comentándole esas 2 horas de diferencia (yo pensé que debería ser sólo una por eso de que estamos en zona GMT+1), me dijo que, con el cambio a horario de verano hemos pasado "automáticamente" a GMT+2. En fin, misterio aclarado. Gracias Jose!.
  • El programa recibe como parámetros el usuario, el password y el texto que queremos enviar. Aunque a priori no hay limitación en la longitud del texto, al móvil sólo nos llegarán los primeros 57 caracteres.
  • Después de construir la petición y enviarla, por la consola aparece un error. Según he investigado parece como si la versión que utilizo de las librerías de google fuera antigua, aunque realmente estoy trabajando con la última. En principio no afecta al funcionamiento, aunque queda un poco "feo".
  • Adicionalmente, es necesario descargar las librerías mail.jar del API JavaMail y activation.jar del Framework de Sun JavaBeansActivation.

  •    Y ya, sin más divagaciones, el código:
    /*
    * Programa para el envío de alarmas por SMS al móvil por medio del API Google Calendar
    *
    * Iván López Martín
    * http://lopezivan.blogspot.com
    *
    */

    import java.net.URL;
    import java.util.Calendar;
    import java.util.GregorianCalendar;
    import java.util.TimeZone;

    import com.google.gdata.client.calendar.CalendarService;
    import com.google.gdata.data.DateTime;
    import com.google.gdata.data.Person;
    import com.google.gdata.data.PlainTextConstruct;
    import com.google.gdata.data.extensions.EventEntry;
    import com.google.gdata.data.extensions.Reminder;
    import com.google.gdata.data.extensions.When;


    public class EnviaSMS {

    public static void main(String[] args) {

    // Comprobamos los argumentos necesarios: usuario, password y texto del mensaje
    if (args.length < 3) {
    System.err.println("Uso: EnviaSMS <usuario> <password> <texto>");
    return;
    }

    String userName = args[0];
    String userPassword = args[1];
    String sms = "";
    // El máximo son 57 caracteres
    for(int i=2; i<args.length; i++) {
    sms = sms + args[i] + " ";
    }
    sms = sms.trim();

    try {
    URL feedUrl = new URL("http://www.google.com/calendar/feeds/" + userName + "/private/full");

    CalendarService myService = new CalendarService("EnviaSMS");

    // Nos autenticamos en google Calendar
    myService.setUserCredentials(userName, userPassword);

    // Creamos el evento
    EventEntry myEntry = new EventEntry();
    myEntry.setTitle(new PlainTextConstruct(sms));

    Person author = new Person(userName, null, userName);
    myEntry.getAuthors().add(author);

    // Definimos la zona horaria
    TimeZone tz = TimeZone.getTimeZone("Europe/Madrid");

    Calendar cal = GregorianCalendar.getInstance();
    cal.add(Calendar.MINUTE, 6);
    DateTime startTime = new DateTime(cal.getTime(), tz); //6m

    cal.add(Calendar.MINUTE, 1);
    DateTime endTime = new DateTime(cal.getTime(), tz); //7m

    // Definimos la hora de comienzo y de fin del evento
    When eventTimes = new When();
    eventTimes.setStartTime(startTime);
    eventTimes.setEndTime(endTime);
    myEntry.addTime(eventTimes);

    // Añadimos el recordatorio sólo como SMS y que avise 5 minutos antes
    Reminder reminder = new Reminder();
    reminder.setMinutes(new Integer(5));
    reminder.setMethod(Reminder.Method.SMS);
    myEntry.getReminder().add(reminder);

    // Enviamos la petición para insertar el evento en el calendario
    EventEntry insertedEntry = (EventEntry)myService.insert(feedUrl, myEntry);
    } catch (Exception e) {
    e.printStackTrace();
    }
    }
    }

       Para la ejecución desde la línea de comandos, he creado un pequeño script:
    ivan@doraemon:~$ cat enviaSMS.sh 
    #!/bin/sh
    #################################
    # Iván López Martín #
    # http://lopezivan.blogspot.com #
    #################################
    SMS_HOME=/home/ivan/workspace/GoogleCalendar

    CLASSPATH=$SMS_HOME/lib/activation.jar:$SMS_HOME/lib/gdata-calendar-1.0.jar:$SMS_HOME/lib/gdata-client-1.0.jar:$SMS_HOME/lib/mail.jar:$SMS_HOME/bin

    java -classpath $CLASSPATH EnviaSMS $@

    ivan@doraemon:~$ ./enviaSMS.sh usuario@gmail.com password "Visita el blog de Iván López. http://lopezivan.blogspot.com"

       En nuestro calendario de google aparece el nuevo evento con las opciones que hemos indicado:

       Y un minuto después, en el móvil el sms:


       Como ya he dicho, se trata de la versión 0.1, aunque me parece que no la voy a modificar mucho más porque lo único que necesito es el envío de los sms. No voy a borrar los eventos del calendario, ni actulizarlos, ni consultarlos desde el programa,...

       Cualquiera es libre de modificar el código, usarlo y mejorarlo siempre que por favor respete el comentario del autor y el enlace a este blog. Además, si lo mejoras por favor házmelo saber para poder actulizar este artículo.

       Que lo disfrutéis...

    Backups con Rsync

       Después de mi entrada anterior sobre el sistema de backup que voy a utilizar, quiero ampliar un poco la información diciendo que después de haber tenido un rato para terminarlo de configurar completamente he lanzado el backup completo de los 21 GB de datos. El resultado con rsync ha sido muchísimo mejor de lo que me esperaba a priori ya que ha tardado apenas 40 minutos en realizar la copia frente a las 3 horas que tardó BackupPC. Estoy encantado con haber elegido finalmente rsync y aunque finalmente no tenga todos los añadidos de BackupPC creo que ha sido la mejor elección.
       Muchas veces, lo más simple es lo mejor y en este caso, un pequeño script me ha solucionado todos los problemas.

    lunes, 14 de mayo de 2007

    Rsync vs BackupPc vs Link-Backup

       Llevo las últimas semanas buscando y probando distintos sistemas de copias de seguridad para poder tener los backups centralizados en casa en una única máquina, hacerlos de una manera eficiente, fiable y organizada. Los requisitos que debe cumplir el sistema son los siguientes:
  • Debe funcionar bajo linux: Voy a reutilizar mi antiguo Duron instalándole la nueva Debian Etch y quiero montar un raid 1 para tener fiabilidad en el backup.
  • Se deben poder hacer backups de máquinas windows y linux: Tengo que hacer backups de mi sobremesa con Ubuntu y del portatil de mi mujer con windows XP.
  • Debe permitir backups totales, parciales e incluso un histórico o versionado de archivos: Realmente lo único imprescindible es hacer un backup completo la primera vez e irlo ampliando con backups incrementales posteriores. Si además puedo tener un versionado de todos los archivos o almacenarlos en directorios distintos según el día, pues mejor que mejor.
  • No debe requerir tener el servidor encendido 24x7: No quiero un sistema de backup que deba tener encendido todo el día puesto que la idea es hacer un backup completo la primera vez y luego, según sea el trabajo diario encenderlo y hacer incrementales de vez en cuando.
  • Posibilidad de utilizar una interfaz gráfica (GUI): Más que para su utilización y/o configuración, para ver los archivos que se han almacenado de una manera fácil y cómoda.

  •    Así, con estas premisas me puse a buscar por internet y a leer foros y me quedé con tres herramientas para hacer pruebas y decidir cual era la mejor para mi: Rsync, BackupPC y Link-Backup.

    Rsync: Es un clásico en sistemas Unix/Linux. Entre las muchas opciones que permite sirve para realizar una copia de toda la información y posteriormente actualizar sólo los fragmentos que se modifican de los archivos. Cuando digo los fragmentos que se modifican de los archivos me refiero a que posteriormente, si de un archivo de 300 MB sólo modificamos una parte, sólo esa parte será enviada en la siguiente copia.
       En aspectos negativos decir que no tiene GUI de consulta de archivos.

    BackupPC: Me ha sorprendido mucho esta herramienta y además según he podido leer hay mucha gente que la utiliza con muy buenos resultados. De todos mis requisitos el único que no cumple es el de no poder apagar el servidor puesto que una vez al día ejecuta tareas de reorganización de índices y además el servidor decide cuando quiere hacer la copia de las máquinas (aunque es cierto que se pueden ejecutar backups bajo demanda). Tiene GUI para su utilización (que no configuración), versiona los archivos, permite backups completos y parciales y permite guardar la información de máquinas windows y linux. La recuperación de los archivos también está muy bien puesto que permite restaurarlos en su localización inicial, en otra máquina e incluso crear un zip con los archivos que queramos.
       Para funcionar utiliza rsync y crea hard links para reducir la utilización de espacio en el servidor. Así, la primera vez que hacemos un backup transfiere el archivo completo pero en posteriores copias, si detecta que el archivo es el mismo lo único que hace es crear un hard link, por lo que no consume más espacio en disco, pero sí inodos. Esto último, en función del sistema de archivos que utilicemos y del número de máquinas a gestionar puede traernos problemas.

    Link-Backup: Es una utilidad muy parecida a BackupPC aunque no tan "vistosa". Se trata de un script escrito en python y que también utiliza rsync para realizar la transferencia de los ficheros. Permite backups completos e incrementales y también utiliza hard links para reducir el espacio ocupado en disco. No tiene interfaz gráfica aunque en la web del autor hay disponible un pequeño cgi que sirve de interfaz gráfica para poder navegar por los distintos backups.

       Como tanto BackupPc como Link-Backup se basan en rsync y además aportan funcionalidad adicional, me centré directamente en estas dos herramientas.

       Comencé por BackupPC. Lo descargué, lo instalé y para la configuración, que fue muy sencilla, seguí este tutorial. Posteriormente cambié la configuración para utilizar rsyncd (el demonio rsync) en lugar de las transferencias cifradas por ssh. Después de un par de pequeñas pruebas transfiriendo unos cuantos archivos configuré todos los directorios a guardar y lancé el backup. En total fueron 21 GB y la copia tardó poco más de 3 horas. Durante este tiempo tuve a la vista el monitor de red de la máquina origen para comprobar la utilización de la red y he de decir que no se aprovechaba todo el ancho de banda ni mucho menos y apenas se llegó a utilizar el 40-50%. Una vez terminado el backup completo lancé el backup incremental para comprobar que se chequeaban todos los archivos y al no tener que transferir ninguno la copia se haría en pocos minutos. Al final, la copia incremental tardó 65 minutos! por lo que pensé que debía tener algo mal configurado. Estuve buscando algo más de información por internet y la conclusión a la que llegué es que BackupPC tiene que reconstruir toda la estructura de directorios, crear los hard links y actualizar su catálogo con la información de los ficheros. Además, debe calcular CRCs de los archivos para decidir si han cambiado y es necesario transferirlos de nuevo.

       El uso y configuración de Link-Backup es más sencillo todavía, sólo hay que tener python instalado para ejecutar el script. La sintaxis es similar a la del comando scp (usuario@maquina:/directorio) y no posee demasiadas opciones de configuración. Como no quería que me pasase lo mismo que con BackupPC, hice una prueba con un directorio de sólo 4 GB y los resultados fueron muchísimo mejores. Durante la transferencia la utilización de la red era de prácticamente el 90-100%, por lo que el tiempo del primer backup se redujo muchísimo. Después volví a ejecutar de nuevo el script y esta vez sí, en 5 segundos terminó indicando que no había nada que copiar.
       Luego instalé el cgi para tener la posibilidad de navegar por los backups y aunque la interfaz gráfica no se puede ni comparar con la de BackupPC, para el uso que yo quiero me sirvía.
       Cuando ya me iba a decidir por esta herramienta me dí cuenta que no era capaz de indicarle que realizara la copia de más de un directorio a la vez y crease un catálogo único, así que después de unas cuentas pruebas intentándolo, la descarté.

       Busqué alguna herramienta más por internet como Bacula pero requiere el servidor encendido y que el origen de los backups sea el servidor, por lo que también la descarté.

       Finalmente, me decidí por la opción de crearme yo mis propios scripts de backup utilizando rsync con la opción de crear hard links para ocupar menos espacio en el disco y crear un snapshot en cada ejecución.

       El script que realiza el backup se llama desde los clientes indicándole el nombre de la máquina origen por medio de ssh:
    ivan@doraemon:~$ ssh rsync@shian /home/rsync/scripts/backup.sh doraemon

       El contenido del script es el que muestro a continuación. Está algo hardcodeado porque no he sido capaz de pasarle como parámetro la lista de directorios al rsync. El problema está en que si es más de un directorio tiene que ir entre comilla simple ' y aunque "escape" el caracter con \ no funciona el rsync. Lo que hace el script es calcular el último snapshot y crear la nueva copia basándose en la anterior. Así, cada vez que lo ejecutamos se crea un nuevo directorio backup.X con la falsa ilusión de que es un backup completo por la magia de los hard links.
    #!/bin/bash

    # Comprobación de los parámetros
    if [ -z $1 ] ; then
    echo Uso `basename $0` hostname
    exit 1
    fi

    # Destino del backup
    DEST_DIR=/mnt/raid/datos

    HOST=$1
    FULL_DEST_DIR=$DEST_DIR/$HOST

    # Calculo del último snapshot del backup y del nuevo
    LAST_SNAPSHOT=`ls -ltr $FULL_DEST_DIR | tail -1 | awk {'print $8'} | cut -d . -f 2`
    ((NEW_SNAPSHOT=LAST_SNAPSHOT+1))

    # En función de la máquina de la que queramos hacer el backup, ejecutamos con unos u otros parámetros
    if [ $HOST == "doraemon" ] ; then
    rsync -av --delete --link-dest=$FULL_DEST_DIR/backup.$LAST_SNAPSHOT/ ivan@doraemon:'/Dir1 /Dir2 /Dir3' $FULL_DEST_DIR/backup.$NEW_SNAPSHOT > $FULL_DEST_DIR/files_$NEW_SNAPSHOT.txt
    mv $FULL_DEST_DIR/files_$NEW_SNAPSHOT.txt $FULL_DEST_DIR/backup.$NEW_SNAPSHOT/files.txt
    elif [ $HOST == "dorami" ] ; then
    rsync -av --delete --link-dest=$FULL_DEST_DIR/backup.$LAST_SNAPSHOT/ ana@dorami:'/MisDocs' $FULL_DEST_DIR/backup.$NEW_SNAPSHOT > $FULL_DEST_DIR/files_$NEW_SNAPSHOT.txt
    mv $FULL_DEST_DIR/files_$NEW_SNAPSHOT.txt $FULL_DEST_DIR/backup.$NEW_SNAPSHOT/files.txt
    else
    exit 2
    fi

       Lo único necesario es configurar el acceso por ssh sin password desde mi pc con linux (doraemon) y el portatil de mi mujer (dorami) al servidor de backup (shian) y desde éste a los clientes puesto que el backup parte de shian. Sé que es algo engorroso tener que configurar la conexión ssh sin password en ambos sentidos, pero prefiero hacerlo así porque quiero que el momento en el que se realice el backup se decida en el lado cliente.

       Instalé en el portatil de mi mujer Cygwin y lo configuré como sigue para conectarme por ssh sin tener que utilizar ninguna clave:
  • Primero, en windows, desde cygwin generamos el par de claves pública/privada:
    $ ssh-keygen -t dsa -b 1024
    Generating public/private dsa key pair.
    Enter file in which to save the key (/cygdrive/c/Documents and Settings/ana/.ssh/id_dsa): INTRO
    Enter passphrase (empty for no passphrase): INTRO
    Enter same passphrase again: INTRO
    Your identification has been saved in /cygdrive/c/Documents and Settings/ana/.ssh/id_dsa.
    Your public key has been saved in /cygdrive/c/Documents and Settings/ana/.ssh/id_dsa.pub.
    The key fingerprint is:
    7b:9a:c6:e9:ee:f1:2e:b0:00:fc:68:c6:58:2b:d6:a0 ana@dorami.casa
  • Copiamos la clave pública al servidor de backup:
    $ scp id_dsa.pub rsync@shian:/home/rsync/.ssh/id_dsa_ana.pub
    Password:
    id_dsa.pub 100% 605 0.6KB/s 00:00
  • Ahora nos conectamos al servidor de backup con el usuario rsync y añadimos la clave pública en el archivo de claves autorizadas para poder conectarnos por ssh sin necesidad de password:
    rsync@shian:~$ cat ~/.ssh/id_dsa_ana.pub >> ~/.ssh/authorized_keys
  • En este momento ya nos podemos conectar por ssh sin password desde la máquina windows (dorami) al servidor de backup (shian):
    $ hostname
    dorami

    $ ssh rsync@shian
    Last login: Fri 11 21:50:47 2007 from doraemon
    rsync@shian:~$
  • Para afinar un poco más la configuración y eliminar el agujero de seguridad de permitir sesiones por ssh con el usuario utilizado para el backup, editamos el archivo de claves autorizadas y añadimos al principio la limitación de sólo poder conectarnos desde esa máquina, no permitir redirección de puertos y no permitir sesiones interactivas, quedando así:
    rsync@shian:~$ cat .ssh/authorized_keys
    from="dorami.casa",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAAB3Nza................y6SzRKqzW6V9PpwQ== ana@dorami.casa
  • De esta manera, si ahora intentamos conectarnos por ssh al servidor, obtenemos el siguiente error:
    $ ssh rsync@shian
    stdin: is not a tty

  •    Repetí los pasos desde mi máquina aunque obviamente sin la parte de capar el acceso por ssh ;-). Adicionalmente hay que hacer lo mismo para configurar las conexiones sin password pero desde el servidor hacia los clientes.

       Ahora, para finalizar, lo que hago es crear un script en cygwin para lanzar el backup y otro script .bat para crear un acceso directo en windows para que mi mujer pueda ejecutar sus backups sin ningún problema.
    # En cywin
    $ cat backupAna.sh
    #!/bin/sh
    ssh rsync@shian /home/rsync/scripts/backup.sh dorami


    # En windows
    @echo off
    REM EjecutaBackup.bat
    echo Ejecutando backup...
    C:\cygwin\bin\bash --login -i /usr/local/bin/backupAna.sh
    pause

       Y esto es todo, mi mujer puede lanzar su backup cuando quiera y yo desde mi máquina tengo un script similar.

       Como conclusiones finales me quedo con un cierto mal sabor de boca por no haber elegido BackupPc puesto que me parece la solución más completa aunque también es cierto que los tiempos de backup incrementales son bastante elevados. Aunque bastante menos elegante, la solución del script manual es mucho más eficiente y cómoda para mi.

    miércoles, 2 de mayo de 2007

    Migración a Linux

       Llevo ya dos semanas trabajando en casa casi exclusivamente con linux, más concretamente con Ubuntu 7.04 Feisty Fawn. Durante este tiempo estoy intentando adaptarme al nuevo sistema operativo, instalando los programas que necesito, buscando sustitutos a las aplicaciones windows que utilizaba,... De momento la transición está yendo mejor de lo que pensaba.

       La instalación fue de lo más sencillo y no presentó ninguna complicación. Después, instalé los drivers de la tarjeta nvidia y posteriormente, con un simple apt-get instalé beryl sin ningún esfuerzo. La verdad es que aunque había visto bastantes videos en youtube de lo que se podía hacer me ha dejado gratamente impresionado. El cubo es chulísimo y los efectos al maximizar, desplazar, minimizar,... las ventanas están muy logrados. Además, lo mejor es que aún está en la versión 0.2, por lo que cuando llegue a la 1.0 va a ser increíble.


       En windows me gusta tener en la barra de tareas la monitorización de las temperaturas del sistema para controlar cómo está todo. Después de buscar algo similar para linux me encontré con lm-sensors, hddtemp y unos applets para el panel de gnome que hacen de interfaz y muestran las temperaturas. De nuevo, todo fue muy sencillo y leyendo un par de tutoriales no tuve ningún problema en configurar todo. Aún estoy buscando la forma de poder mostrar la temperatura de la tarjeta gráfica sin tener que arrancar la utilidad nvidia-settings, aunque tampoco es crítico para mi.

       Otro aspecto que me ha gustado ha sido la facilidad para utilizar los archivos de video y música. Das doble click a un divx, aparece un mensaje indicando que no tienes los codecs instalados, aceptas y automáticamente se descargan, se configuran y listo, a ver la serie. Lo mismo ocurre con la música, automáticamente se ha descargado los codecs MP3 necesarios para poder escuchar las canciones.

       Me he hecho una lista de los programas que utilizo en windows para buscar un sustituto. Así, ya utilizo VLC para ver los videos, Gaim como gestor de mensajería para conectarme a GoogleTalk, Gthumb para ver fotos, OpenOffice, Gimp,... y así poco a poco voy probando nuevos programas y quedándome con los que más me gustan.

       Una cosa magnífica de la que deberían aprender otros sistemas operativos es la gestión de paquetes. Es increíble la cantidad de programas que hay en los repositorios. Sólo hay que buscar lo que quieres y enseguida tienes una gran cantidad de programas listos para descargar y probar. Lo mejor sin duda es la gestión de las dependencias, así, si algo ya no lo necesitas, lo puedes desinstalar y automáticamente se desinstalan todos los programas y librerías que ya no son necesarios. Así, el sistema no se va corrompiendo poco a poco y no se va quedando basura en algo como el famoso registro de windows.

       Mi intención es hacer por fín el cambio de windows a linux aunque vaya siendo poco a poco. Para los programas que no encuentre sustituto (por ejemplo para la declaración de la renta), para las webs que sólo funcionan con iexplorer,... me he instalado una máquina virtual windows con VmWare. Para solucionar un problema de compilación de los módulos he seguido el interesante artículo Cómo solucionar incompatibilidades entre una versión de VMWare y un kernel más reciente de Vicente Navarro y nuevamente ha sido todo muy sencillo. En fin, que ya iré contando poco a poco mis progresos.