miércoles, 27 de febrero de 2008

El código Geek

   El otro día navegando encontré el Código Geek. De vez en cuando me he encontrando en alguna web esa especie de código raro que no entendía. El caso es que hoy le he dedicado un rato y como buen geek que se precie, aquí teneis el mío.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT/ d- s: a- C++ UL++ P L++ E--- W+++ N o? K- w O-- M?
V PS PE Y-- PGP t 5? X R tv b DI D+++ G e+++ h--- r+++ y+++
------END GEEK CODE BLOCK------

   Y tú, qué clase de geek eres?.

miércoles, 20 de febrero de 2008

Crear paquetes deb desde otros formatos

   Cuando utilizaba RedHat, SuSE o Slackware hace algún tiempo para probar y cacharrear o simplemente para hacer las prácticas de la facultad y tenía que instalar algún programa no tenía ningún problema en compilarlo e instalarlo "a lo loco" e incluso trabajar como root. Por aquel entonces, aunque linux me gustaba sólo lo utilizaba como una ayuda durante la carrera para no tener que pasarme las horas en el centro de cálculo pegándome por un terminal VT100 de fósforo verde que me destrozaba la vista. Qué tiempos aquellos... y eso que "sólo" han pasado 10 años desde aquel 1997 en que empecé la carrera (que por cierto ya terminé).

   En fin, que compilaba, hacía make install y no me preocupaba de desinstalar ni de cómo podía quedar el sistema después de eso (total, lo reinstala y punto, no me suponía demasiado). Ahora, desde que utilizo linux como mi sistema operativo principal me preocupa que si me pongo a compilar e instalar compulsivamente o simplemente quiero probar algo, luego me resulte complicado mantener el control de lo que está instalado, desinstalarlo con facilidad,... Aunque con el magnífico apt este problema desaparece para cualquier paquete que descarguemos, en el caso de las compilaciones o de utilidades de las que no existan paquetes .deb la cosa es más compleja. Así, he descubierto un par de utilidades que me van a hacer la vida aún más fácil: alien y checkinstall.

Alien: En ocasiones no hay paquetes en formato .deb pero sin embargo sí existen en formato .rpm. Con esta utilidad los podemos convertir a nuestro formato favorito.

Checkinstall: Cuando compilamos un programa, el paso final suele ser make install que instala los binarios, las librerías, la ayuda del man,... En muy pocas ocasiones viene con un target uninstall del make, por lo que una posterior tarea de desinstalación suele ser algo tediosa. Checkinstall sirve para crear paquetes .deb a partir del código compilado, por lo que si posteriormente queremos desinstalar algo sólo hay que hacer un simple apt-get remove paquete.
  • Instalarlos es algo tan sencillo como:
    ivan@doraemon:~$ sudo apt-get install checkinstall alien

  • Para convertir los paquetes con alien hacemos:
    ivan@doraemon:~$ sudo alien -d paquete.rpm
  • Y una vez convertido lo podemos instalar como siempre:
    ivan@doraemon:~$ sudo dpkg -i paquete.deb

  • Si por el contrario tenemos el código fuente para compilarlo utilizaremos checkinstall, para ello hacemos:
    ivan@doraemon:~$ tar zxvf paquete.tar.gz
    ivan@doraemon:~$ cd paquete
    ivan@doraemon:~/paquete $ ./configure
    ivan@doraemon:~/paquete $ make
    ivan@doraemon:~/paquete $ sudo checkinstall
  • Y después de unas cuantas preguntas tendremos creado nuestro paquete.deb listo para instalar y mantener.
  • lunes, 11 de febrero de 2008

    Monitorizando sistemas con Nagios

    Nagios es un sistema de código abierto de monitorización de redes, máquinas, servicios, sistemas, filesystems... muy flexible que permite definir distintos tipos de alertas en función de la disponibilidad de los objetos monitorizados.

       En mi anterior trabajo lo instalé y configuré para monitorizar distintos entornos que gestionábamos y también para la monitorización remota de filesystems. He rescatado el pequeño documento que hice en su momento y este es el resultado después de completarlo con explicaciones más detalladas, ejemplos y alguna captura.

       Lo primero que debo aclarar es que está basado en la versión 2.4 de Nagios, siendo la versión estable actual la 2.10. No debería haber muchas diferencias por lo que supongo que todo lo que voy a contar funcionará sin problemas. La máquina en la que monté el servidor Nagios es una Sun Fire 280R con Solaris 8 y obviamente no tenía permisos de root, por lo que la instalación está hecha con un usuario normal (vtprov) siendo su home /internet/vtprov. Además, al ser una máquina con Solaris no hay paquetes de binarios ya compilados, por lo que toca compilar desde el código fuente. El caso de la instalación para Linux debería ser similar.

    Instalación
    Después de descargar y desempaquetar el .tar generamos el fichero Makefile:
    $ ./configure --prefix=PREFIX --with-nagios-user=SOMEUSER --with-nagios-group=SOMEGROUP
    Donde: PREFIX es la ruta en donde queremos instalar y que llamaremos $NAGIOS_HOME.
               SOMEUSER es el usuario que ejecutará Nagios.
               SOMEGROUP es el grupo del usuario que ejecutará Nagios.
    Después simplemente compilamos:
    $ make all

    Y finalmente instalamos en la ruta que hayamos configurado anteriormente:
    $ make install

       Para comprobar el estado de los servicios, sistemas,... Nagios utiliza diversos plugins programados en C. Es necesario descargar y compilar dichos plugins e instalarlos en Nagios. La utilización de plugins hace que Nagios sea muy potente respecto a los sistemas que puede monitorizar puesto que si no existe ningún plugin que nos interese, siempre es posible crear uno a medida.
       La compilación de los plugins es exáctamente igual a la de Nagios y una vez compilados deben almacenarse en el directorio $NAGIOS_HOME/libexec.

    Configuración
       Nagios se configura mediante archivos de texto que se encuentran en $NAGIOS_HOME/etc. Los principales archivos son:
  • nagios.cfg: Es el archivo principal de Nagios. En él, además de diversas opciones de configuración se definen las rutas del resto de archivos de configuración. Podemos elegir si queremos un archivo con toda la configuración o múltiples archivos más pequeños. En mi caso elegí un único archivo.
  • checkcommands.cfg: En este archivo se define el nombre lógico y físico de los comandos de monitorización que se utilizarán así como los parámetros de reciben.
  • misccommands.cfg: Se definen las plantillas que se utilizarán para los emails de notificación.
  • bigger.cfg: Archivo principal en el que se configuran los servicios que se desean monitorizar, notificaciones, comandos para la monitorización, agrupación de servicios,...

  •    A continuación muestro con un poco más de detalle los archivos de configuración y añado ejemplos de configuración. Sólo he seleccionado algunas partes concretas puesto que algunos son muy grandes y tienen muchas opciones. Cada una de ellas viene con una pequeña explicación sobre su utilización.

    nagios.cfg
       Hay que prestar especial atención a la opción check_external_commands puesto que sin habilitarla no podremos comprobar el estado de un servicio que deseemos en un momento determinado, sino que sólo se ejecutará la comprobación según se haya planificado.
    # OBJECT CONFIGURATION FILE(S)

    # Plugin commands (service and host check commands)
    cfg_file=/internet/vtprov/nagios/etc/checkcommands.cfg

    # Misc commands (notification and event handler commands, etc)
    cfg_file=/internet/vtprov/nagios/etc/misccommands.cfg

    # You can split other types of object definitions across several
    # config files if you wish (as done here), or keep them all in a
    # single config file.
    cfg_file=/internet/vtprov/nagios/etc/bigger.cfg

    # NAGIOS USER
    nagios_user=vtprov

    # NAGIOS GROUP
    nagios_group=users

    # EXTERNAL COMMAND OPTION
    # This option allows you to specify whether or not Nagios should check
    # for external commands (in the command file defined below). By default
    # Nagios will *not* check for external commands, just to be on the
    # cautious side. If you want to be able to use the CGI command interface
    # you will have to enable this. Setting this value to 0 disables command
    # checking (the default), other values enable it.

    check_external_commands=1
    [...]

    checkcommands.cfg
       Estos son algunos de los comandos (plugins) que podemos usar para comprobar el estado de los servicios. Por ejemplo, el comando check_http realiza una simple llamada GET a la máquina definida en el parámetro $ARG1$, al puerto $ARG2$ y a la URL $ARG3$. Esta llamada la usábamos para comprobar el estado de diversos servlets que estaban corriendo en distintas instancias de servidores tomcat.
       El comando check_http_wm es una personalización del anterior (fijaos que el command_line es el mismo) pero se conecta con un usuario y password que pasamos como parámetro.
       También muestro el ejemplo del ping y también el comando check_nrpe que veremos posteriormente para ejecutar scripts en máquinas remotas y en función del resultado lanzar o no una alarma.
    define command{
    command_name check_ping
    command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
    }

    define command{
    command_name check_http
    command_line $USER1$/check_http -H $ARG1$ -p $ARG2$ --url=$ARG3$
    }

    define command{
    command_name check_http_wm
    command_line $USER1$/check_http -H $ARG1$ -p $ARG2$ -a USER:PASSWD
    }

    define command{
    command_name check_nrpe
    command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -p $ARG1$ -c $ARG2$ -a $ARG3$ $ARG4$ $ARG5$
    }

    misccommands.cfg
       En mi caso cambié el command_line que venía por defecto por el que muestro a continuación puesto que así se envía más información en la alerta que nos llega por email.
    # 'notify-by-email' command definition
    define command{
    command_name notify-by-email
    command_line /usr/bin/printf "Subject: ** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ ** %b\n\n ***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$" | /usr/bin/mail $CONTACTEMAIL$
    }

    bigger.cfg
       Como ya he comentado este es el archivo de configuración en el que damos de alta todos los servicios que queremos monitorizar. Además, también definimos los periodos de monitorización, usuarios, agrupamos los servicios,...

  • Definición de periodos en los cuales se notifican los cambios de estado de los servicios. En este caso definimos dos: 24x7 y Workhours. Luego, al dar de alta un servicio para monitorizar le asociamos uno de estos periodos, de tal forma que sólo se envían notificaciones si estamos en el periodo definido.
    # '24x7' timeperiod definition
    define timeperiod{
    timeperiod_name 24x7
    alias 24 Hours A Day, 7 Days A Week
    sunday 00:00-24:00
    monday 00:00-24:00
    tuesday 00:00-24:00
    wednesday 00:00-24:00
    thursday 00:00-24:00
    friday 00:00-24:00
    saturday 00:00-24:00
    }

    # 'workhours' timeperiod definition
    define timeperiod {
    timeperiod_name Workhours
    alias "Normal" Working Hours
    monday 08:00-19:00
    tuesday 08:00-19:00
    wednesday 08:00-19:00
    thursday 08:00-19:00
    friday 08:00-15:00
    }

  • Definición de grupos de notificación. Los emails a los que notificar separdados por comas y el periodo de notificación definido anteriormente.
    # 'vt-prov' contact definition
    define contact {
    contact_name vt-prov
    alias Nagios Admin
    service_notification_period 24x7
    host_notification_period 24x7
    service_notification_options w,u,c,r
    host_notification_options d,u,r
    service_notification_commands notify-by-email
    host_notification_commands host-notify-by-email
    email user1@empresa.com,user2@empresa.com
    }

  • Definición de máquinas y agrupación de las mismas.
    # 'host1' host definition
    define host{
    use generic-host
    host_name host1
    alias Servidor host1
    address 172.24.88.169
    check_command check-host-alive
    max_check_attempts 10
    check_period 24x7
    notification_interval 120
    notification_period 24x7
    notification_options d,u,r
    contact_groups vt-prov
    }

    # 'solaris-servers' host group definition
    define hostgroup{
    hostgroup_name solaris-servers
    alias Solaris Servers
    members host1,host2,host4,host6
    }

  • Definición de servicios a monitorizar: Esta es la parte más importante y es donde realmente damos de alta todos los servicios que deseamos monitorizar. Como ejemplo muestro el ping para saber si la máquina está activa, la comprobación de un servicio corriendo en un tomcat y la ocupación de un filesystem:
    Ping
    define service{                             
    use generic-service
    host_name host1
    service_description PING
    is_volatile 0
    check_period 24x7
    max_check_attempts 4
    normal_check_interval 1
    retry_check_interval 1
    contact_groups vt-prov
    notification_interval 120
    notification_period 24x7
    notification_options w,u,c,r
    check_command check_ping!100.0,20%!500.0,60%
    }

    Servlet en Tomcat
    define service{
    use generic-service
    host_name host2
    service_description ENTORNO1 - Servicio2
    is_volatile 0
    check_period 24x7
    max_check_attempts 1
    normal_check_interval 5
    retry_check_interval 1
    contact_groups vt-prov
    notification_interval 10
    notification_period 24x7
    notification_options w,u,c,r
    check_command check_http!host2!10102!/servicio/jsp/autent/login.jsp
    }

    Ocupación Filesystem
    define service{
    use generic-service
    host_name host2
    service_description host2 - /var
    is_volatile 0
    check_period 24x7
    max_check_attempts 1
    normal_check_interval 5
    retry_check_interval 1
    contact_groups vt-prov
    notification_interval 120
    notification_period 24x7
    notification_options w,u,c,r
    check_command check_nrpe!7997!check_disk!7!5!/var
    }

  • Agrupación de servicios en un grupo: De esta forma se actua sobre todo el grupo a la vez. Esto es útil cuando por ejemplo hay una intervención en una máquina o se está actualizando un entorno completo y se quieren deshabilitar todas las alarmas de ese entorno a la vez.
    define servicegroup{
    servicegroup_name ENTORNO1 - TOMCATs
    alias ENTORNO1 - TOMCATs
    members host2,ENTORNO1 - Servicio2,host2,ENTORNO1 - Servicio3,host2,ENTORNO1 - Servicio8
    }

  •    Una vez definidos los servicios que deseamos monitorizar, podemos verificar si el archivo de configuración es correcto o contiene algún error. Desde el directorio $NAGIOS_HOME/bin:
    $ nagios -v ../etc/nagios.cfg
    Nagios 2.4
    Copyright (c) 1999-2006 Ethan Galstad (http://www.nagios.org)
    Last Modified: 05-31-2006
    License: GPL

    Reading configuration data...

    Running pre-flight check on configuration data...

    Checking services...
    Checked 82 services.
    Checking hosts...
    Checked 5 hosts.
    Checking host groups...
    Checked 1 host groups.
    Checking service groups...
    Checked 16 service groups.
    Checking contacts...
    Checked 1 contacts.
    Checking contact groups...
    Checked 1 contact groups.
    Checking service escalations...
    Checked 0 service escalations.
    Checking service dependencies...
    Checked 0 service dependencies.
    Checking host escalations...
    Checked 0 host escalations.
    Checking host dependencies...
    Checked 0 host dependencies.
    Checking commands...
    Checked 26 commands.
    Checking time periods...
    Checked 4 time periods.
    Checking extended host info definitions...
    Checked 0 extended host info definitions.
    Checking extended service info definitions...
    Checked 0 extended service info definitions.
    Checking for circular paths between hosts...
    Checking for circular host and service dependencies...
    Checking global event handlers...
    Checking obsessive compulsive processor commands...
    Checking misc settings...

    Total Warnings: 0
    Total Errors: 0

    Things look okay - No serious problems were detected during the pre-flight check

       Como no hay ningún error podemos arrancar Nagios:
    $ nagios -d ../etc/nagios.cfg

       En este momento se empezarían a monitorizar los sistemas que tengamos definidos y se enviarían notificaciones por email si se han configurado.

    Interfaz Web
       Para poder interactuar con el sistema y ver todo de un modo gráfico es necesario configurar la consola web de Nagios. Para ello es necesario un servidor Apache. Instalamos el servidor y en el archivo httpd.conf añadimos lo siguiente:
    ScriptAlias /nagios/cgi-bin "/internet/vtprov/nagios/sbin/"
    <Directory "/internet/vtprov/nagios/sbin">
    AllowOverride AuthConfig
    Options +ExecCGI
    Order allow,deny
    Allow from all
    </Directory>

    Alias /nagios "/internet/vtprov/nagios/share"
    <Directory "/internet/vtprov/nagios/share">
    Options None
    AllowOverride AuthConfig
    Order allow,deny
    Allow from all
    </Directory>

       Reiniciamos apache y ya nos deberíamos poder conectar a la consola de administración:


    Control de Acceso
       Se pueden definir distintos usuarios para conectarse a Nagios con diferentes permisos y que verán únicamente los servicios en los que se hayan añadido como contacto. Para ello utilizamos las opciones de autenticación que ofrece Apache.
       Creamos el archivo .htaccess en los directorios share y sbin con el siguiente contenido:
    AuthName "Acceso a Nagios"
    AuthType Basic
    AuthUserFile /internet/vtprov/nagios/etc/htpasswd.users
    require valid-user

       Y creamos el archivo de passwords desde el directorio bin de la instalación de Apache añadiendo el usuario nagios.
    $ htpasswd -c /internet/vtprov/nagios/etc/htpasswd.users nagios

       Ahora al conectarnos a Nagios nos aparecerá la típica ventana solicitando nuestro usuario y password.


    Comandos remotos
       Para poder ejecutar scritps en máquinas remotas, como por ejemplo, para comprobar el tamaño de los filesystems de otras máquinas, necesitamos instalar un pequeño servidor en dichas máquinas. Este servidor se llama NRPE (Nagios Remote Plugin Executor). Es necesario descargarlo y compilarlo tal y como hemos hecho con Nagios.

       La configuración es muy sencilla: En cada máquina que queramos monitorizar la ocupación de sus filesystems debemos configurar el archivo nrpe.cfg en el que básicamente hay que indicar el puerto en el que queremos levantar el servidor, el usuario y el grupo que lo ejecutan y activar la opción para permitir recibir comandos remotos con parámetros. El fichero de configuración tiene el siguiente aspecto (como antes, incluyo sólo lo más importante).
    # PORT NUMBER
    server_port=7997

    # SERVER ADDRESS
    server_address=172.24.88.169

    # ALLOWED HOST ADDRESSES
    # This is a comma-delimited list of IP address of hosts that are allowed
    # to talk to the NRPE daemon.
    allowed_hosts=127.0.0.1,172.24.86.11

    # NRPE USER
    nrpe_user=nrpe

    # NRPE GROUP
    nrpe_group=users

    # COMMAND ARGUMENT PROCESSING
    # This option determines whether or not the NRPE daemon will allow clients
    # to specify arguments to commands that are executed. This option only works
    # if the daemon was configured with the --enable-command-args configure script
    # option.
    #
    # *** ENABLING THIS OPTION IS A SECURITY RISK! ***
    # Read the SECURITY file for information on some of the security implications
    # of enabling this variable.
    #
    # Values: 0=do not allow arguments, 1=allow command arguments
    dont_blame_nrpe=1

    # COMMAND DEFINITIONS
    command[check_disk]=/home/user/nrpe/check_disk.sh $ARG1$ $ARG2$ $ARG3$

       Hay que destacar la opción dont_blame_nrpe ya que tal y como se indica activarla puede representar un problema de seguridad porque estamos aceptando parámetros y podría realizarse algún tipo de ataque a la máquina por este medio. En mi caso lo habilité porque el script que comprueba el tamaño del filesystem necesita dichos parámetros y no representaba ningún problema de seguridad.
       Al final también hemos añadido el comando remoto que se ejecutará (check_disk) y la llamada al script con los parámetros necesarios. Este script debe existir en la máquina de la que deseamos monitorizar los filesystems.

       Recordemos que antes definimos la ejecución del script check_disk (para un filesystem y máquina concretos) como:
    check_nrpe!7997!check_disk!7!5!/var
       En esta llamada 7997 es el puerto del nrpe en la máquina remota, check_disk es el nombre lógico del script y 7, 5 y /var son los parámetros del script. Éste comprueba el porcentaje de espacio libre del filesystem que recibe como parámetro y lo compara con los dos umbrales que le pasamos. Si es menor de un 7% genera un warning y si es menor de un 5% genera un error crítico.

       El script check_disk.sh que acabamos de ver y que definíamos anteriormente en el archivo bigger.cfg es el siguiente:
    #!/bin/ksh
    # check_disk.sh: Comprueba el tamaño de un filesystem y
    # devuelve el estado en función de dos umbrales definidos.
    #
    # Iván López Martín

    warning=$1
    critical=$2
    filesystem=$3

    STATE_OK=0
    STATE_WARNING=1
    STATE_CRITICAL=2

    size=`df -k $filesystem | grep $filesystem | awk '{print $4}'`
    sizeMB=`echo "$size/1024" | bc`
    percentage=`df -k $filesystem | grep $filesystem | awk '{print $5}' | sed -e s/%//g`
    freePercentage=`echo "100-$percentage" | bc`

    if [ "$freePercentage" -le "$critical" ]; then
    echo "DISK CRITICAL - free space: "$filesystem" $sizeMB MB"
    return $STATE_CRITICAL
    fi
    if [ "$freePercentage" -le "$warning" ]; then
    echo "DISK WARNING - free space: "$filesystem" $sizeMB MB"
    return $STATE_WARNING
    fi

    echo "DISK OK - free space: "$filesystem" $sizeMB MB"
    return $STATE_OK

       Con los scripts remotos configurados arrancamos el demonio nrpe:
    $ nrpe -c nrpe.cfg -d

       Como veis, me he hecho mi propio script para comprobar remotamente los filesystems de las distintas máquinas. Aunque dije inicialmente que los plugins que vienen con Nagios están escritos en C, se puede utilizar cualquier lenguaje que soporte la máquina para comprobar el estado del servicio que deseemos.

       Este script nos era especialmente útil sobre todo para comprobar la ocupación del filesystem /var. Cuando veíamos que estaba bastante lleno sólo teníamos que enviar un email a administración Unix para que borrasen logs antiguos y nos liberaran algo de espacio.

    Interfaz gráfica
       A continuación muestro una serie de capturas de pantalla de la interfaz gráfica con todos los servicios que teníamos configurados en su momento.
    Servicios
    Máquinas

    Agrupación de servicios
    Opciones de servicios


    Conclusiones
       Lo que más me gusta de Nagios es que es muy sencillo de configurar y que con el simple hecho de dar de alta un servicio, automáticamente ya lo estamos monitorizando.
       En su momento también probé herramientas como Hyperic HQ y aunque visualmente son más bonitas, descubren automáticamente los servicios que hay corriendo en las máquinas,... al final son más engorrosas. En mi caso, en algunas máquinas descubría "demasiados" servicios y había que estar eliminando todos los que no queríamos monitorizar. Además, había que definir una a una las alarmas para cada uno de esos servicios. Al final, después de probarla durante un tiempo la descarté y me quedé con Nagios.

    martes, 5 de febrero de 2008

    Primer Viernes Técnico de OpenSolaris

       Como ya comenté hace unas semanas me apunté a unas charlas técnicas que impartía la comunidad española de OpenSolaris. La primera de ellas fue el pasado viernes 2 de febrero y estuvo genial. Nos dieron una documentación muy completa con ejemplos de todo lo que nos contaron y un DVD para que nos animáramos a instalarlo en casa. La charla fue muy amena y se notaba que el nivel de los participantes era muy alto porque en algunas ocasiones completaban las respuestas que ofrecían los organizadores. Los temas que trataron fueron:
  • Distintas versiones de OpenSolaris.
  • La instalación.
  • En nuevo gestor de arranque SMF (Service Management Facility).
  • La virtualización con zonas.
  • Vimos una máquina SunFire 280R "por dentro" puesto que la mayoría no conocíamos la arquitectura Sparc.

  •    Además también me dieron esta camiseta que veis a continuación (tienes envidia Alex? :-P)

       También conocimos a Álvaro López que es el creador de Cherokee, el nuevo servidor web que está llamado a sustituir a Apache. En su blog ha colgado algunas fotos del evento y es posible que en alguna se me vea un poco... ;-)

       Ahora ya me ha picado el gusanillo y cuando tenga un rato lo instalaré en una máquina virtual para probar. Además tengo muchas ganas de que lleguen las dos próximas charlas sobre Virtualización y ZFS.

       Como anécdota final diré que en el office que había al lado de la sala de la charla se veía el siguiente cartel (foto con móvil) y que me llamó la atención porque a primera vista parecía un cartel de salida de emergencia pero luego ponía HP AWAY y la lista de empresas que habían migrado a servidores Sun.