-----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, 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.
Y tú, qué clase de geek eres?.
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:
Para convertir los paquetes con alien hacemos:
Y una vez convertido lo podemos instalar como siempre:
Si por el contrario tenemos el código fuente para compilarlo utilizaremos checkinstall, para ello hacemos:
Y después de unas cuantas preguntas tendremos creado nuestro paquete.deb listo para instalar y mantener.
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.
ivan@doraemon:~$ sudo apt-get install checkinstall alien
ivan@doraemon:~$ sudo alien -d paquete.rpm
ivan@doraemon:~$ sudo dpkg -i paquete.deb
ivan@doraemon:~$ tar zxvf paquete.tar.gz
ivan@doraemon:~$ cd paquete
ivan@doraemon:~/paquete $ ./configure
ivan@doraemon:~/paquete $ make
ivan@doraemon:~/paquete $ sudo checkinstall
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:
SOMEUSER es el usuario que ejecutará Nagios.
SOMEGROUP es el grupo del usuario que ejecutará Nagios.
Después simplemente compilamos:
Y finalmente instalamos en la ruta que hayamos configurado anteriormente:
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.
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.
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.
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.
Definición de grupos de notificación. Los emails a los que notificar separdados por comas y el periodo de notificación definido anteriormente.
Definición de máquinas y agrupación de las mismas.
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
Servlet en Tomcat
Ocupación Filesystem
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.
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:
Como no hay ningún error podemos arrancar Nagios:
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:
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:
Y creamos el archivo de passwords desde el directorio bin de la instalación de Apache añadiendo el usuario 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).
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:
El script check_disk.sh que acabamos de ver y que definíamos anteriormente en el archivo bigger.cfg es el siguiente:
Con los scripts remotos configurados arrancamos el demonio nrpe:
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.
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.
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=SOMEGROUPDonde: 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:
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,...
# '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
}
# '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
}
# '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
}
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
}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!/varEn 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.
 |  |
 |  |
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.
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.
 |
lunes, 28 de enero de 2008
Truecrypt en Linux con kernel 2.6.23
Para el que no lo conozca, Truecrypt es una mágnifica utilidad libre y de código abierto multiplataforma para windows y linux que permite entre otras muchas opciones crear discos virtuales cifrados para poder almacenar nuestra información confidencial de manera segura. Además, proporciona un modo de funcionamiento traveller en el que no es necesario tener nada instalado y que podemos ejecutar desde un pendrive. Así, podemos llevar toda la información de nuestro pendrive cifrada y descifrarla al vuelo y en cualquier ordenador en el momento en que la necesitemos.
En la web existen numerosos tutoriales sobre cómo crear volúmenes cifrados, las distintas opciones, elegir el algoritmo de cifrado,... Además el apartado de documentación de la web oficial es muy completo y extenso. En este artículo lo que quiero contar es cómo compilar truecrypt en linux utilizando un kernel superior a 2.6.23.
Lo primero de todo es descargarlo. Existen binarios compilados para unas cuantas distribuciones (OpenSuSE 10.2, OpenSuSE 10.3 y algunas versiones de Ubuntu), pero en mi caso no me servían porque están pensados para el kernel estándar y yo trabajo con una versión compilada por mi del kernel. Así, me descargué el código fuente y me dispuse a compilarlo e instalarlo. Enseguida encontré el primer problema porque nada más empezar la compilación aparecía un error:
Buscando un poco de información por la red encontré este post en un foro de Fedora en el que cuentan una solución. Todo pasa por editar el archivo Dm-target.c y en la línea 659 quitar el último NULL.
Ahora, compilando de nuevo:
Instalamos
Espero que le pueda servir a alguien porque yo estuve un buen rato buscando hasta que encontré la solución. Ahora ya podemos utilizar esta magnífica herramienta para cifrar toda nuestra información sensible tanto en linux como en windows en nuestro pendrive.
Como nota final diré que hace unos días han publicado en HowtoForge un artículo con una GUI para el Truecrypt de Linux y unos sencillos pasos para configurarlo y dejarlo todo a punto.
En la web existen numerosos tutoriales sobre cómo crear volúmenes cifrados, las distintas opciones, elegir el algoritmo de cifrado,... Además el apartado de documentación de la web oficial es muy completo y extenso. En este artículo lo que quiero contar es cómo compilar truecrypt en linux utilizando un kernel superior a 2.6.23.
Lo primero de todo es descargarlo. Existen binarios compilados para unas cuantas distribuciones (OpenSuSE 10.2, OpenSuSE 10.3 y algunas versiones de Ubuntu), pero en mi caso no me servían porque están pensados para el kernel estándar y yo trabajo con una versión compilada por mi del kernel. Así, me descargué el código fuente y me dispuse a compilarlo e instalarlo. Enseguida encontré el primer problema porque nada más empezar la compilación aparecía un error:
ivan@doraemon:~$ tar zxf truecrypt-4.3a-source-code.tar.gz
ivan@doraemon:~$ cd truecrypt-4.3a-source-code/Linux
ivan@doraemon:~/truecrypt-4.3a-source-code/Linux$ sudo ./build.sh
Checking build requirements...
Building kernel module... /home/ivan/truecrypt-4.3a-source-code/Linux/Kernel/Dm-target.c: In function `dm_truecrypt_init´:
/home/ivan/truecrypt-4.3a-source-code/Linux/Kernel/Dm-target.c:659: error: too many arguments to function `kmem_cache_create´
make[2]: *** [/home/ivan/truecrypt-4.3a-source-code/Linux/Kernel/Dm-target.o] Error 1
make[1]: *** [_module_/home/ivan/truecrypt-4.3a-source-code/Linux/Kernel] Error 2
make: *** [truecrypt] Error 2
Error: Failed to build kernel module
Buscando un poco de información por la red encontré este post en un foro de Fedora en el que cuentan una solución. Todo pasa por editar el archivo Dm-target.c y en la línea 659 quitar el último NULL.
//bio_ctx_cache = kmem_cache_create ("truecrypt-bioctx", sizeof (struct bio_ctx), 0, 0, NULL, NULL);
bio_ctx_cache = kmem_cache_create ("truecrypt-bioctx", sizeof (struct bio_ctx), 0, 0, NULL);Ahora, compilando de nuevo:
ivan@doraemon:~/truecrypt-4.3a-source-code/Linux$ sudo ./build.sh
Checking build requirements...
Building kernel module... Done.
Building truecrypt... Done.
Instalamos
ivan@doraemon:~/truecrypt-4.3a-source-code/Linux$ sudo ./install.sh
Checking installation requirements...
Testing truecrypt... Done.
Install binaries to [/usr/bin]:
Install man page to [/usr/share/man]:
Install user guide and kernel module to [/usr/share/truecrypt]:
Installing kernel module...
Done.
Installing truecrypt to /usr/bin... Done.
Installing man page to /usr/share/man/man1... Done.
Installing user guide to /usr/share/truecrypt/doc... Done.
Installing backup kernel module to /usr/share/truecrypt/kernel... Done.
Espero que le pueda servir a alguien porque yo estuve un buen rato buscando hasta que encontré la solución. Ahora ya podemos utilizar esta magnífica herramienta para cifrar toda nuestra información sensible tanto en linux como en windows en nuestro pendrive.
Como nota final diré que hace unos días han publicado en HowtoForge un artículo con una GUI para el Truecrypt de Linux y unos sencillos pasos para configurarlo y dejarlo todo a punto.
sábado, 19 de enero de 2008
Calendario de Sotfware Libre
Descubrí el otro día en microteknologías un calendario de escritorio de software libre. Cada mes tiene un animal que es la mascota de alguna aplicaciones libre. Así están Tux, el Geeko de openSuSE, Sakila de MySQL o el panda rojo de Firefox entre otros. Me lo descargué y esta mañana he estado montándolo. Estos son los pasos y al final el resultado:
Ya lo tengo listo y preparado para llevármelo el lunes al trabajo y presumir de calendario entre los compañeros.
 |  |
 |  |
Ya lo tengo listo y preparado para llevármelo el lunes al trabajo y presumir de calendario entre los compañeros.
miércoles, 16 de enero de 2008
Administrando un HP Proliant con Integrated Lights-Out
Integrated Lights-Out (iLO) es una tecnología que incorporan algunos servidores HP que permite administrar e interactuar completamente con la máquina en remoto aunque ésta se encuentre apagada. Utiliza una interfaz de red independiente que se puede configurar en el arranque de la máquina. Una vez que le asignamos dirección IP, máscara de red y creamos un usuario ya nos podemos conectar a la máquina desde el navegador web.
Una vez conectados a la consola, introducimos nuestro usuario y password y accedemos a la ventana principal en la que podemos ver el estado del servidor.
Podemos encender el servidor en remoto y desde la consola virtual ver todo el proceso de arranque.
La única pega es que por defecto la consola sólo muestra la información en modo texto y para mostrar gráficos es necesario pasar por caja y comprar una licencia avanzada. No obstante en la web de HP se puede descargar una versión de prueba de 60 días. Así, una vez activada podemos ver el arranque gráfico e interactuar con el servidor.
Esto no me ocurre con el servidor que tengo instalado con VMware ESX puesto que nuestro sistema operativo favorito arranca en modo texto.
No conocía esta gran utilidad que proporcinan los servidores pero me parece realmente útil cuando tenemos muchos en un CPD y ocurre un problema con alguno. Cómodamente sentados en nuestro sitio podemos reiniciar la máquina y comprobar el arranque para ver cual es el fallo. Para nuestros PCs de casa siempre tendremos la opción de utilizar un cable null modem con Linux.
Una vez conectados a la consola, introducimos nuestro usuario y password y accedemos a la ventana principal en la que podemos ver el estado del servidor.
 |
Podemos encender el servidor en remoto y desde la consola virtual ver todo el proceso de arranque.
 |  |
La única pega es que por defecto la consola sólo muestra la información en modo texto y para mostrar gráficos es necesario pasar por caja y comprar una licencia avanzada. No obstante en la web de HP se puede descargar una versión de prueba de 60 días. Así, una vez activada podemos ver el arranque gráfico e interactuar con el servidor.
 |  |
Esto no me ocurre con el servidor que tengo instalado con VMware ESX puesto que nuestro sistema operativo favorito arranca en modo texto.
 |  |
 |  |
No conocía esta gran utilidad que proporcinan los servidores pero me parece realmente útil cuando tenemos muchos en un CPD y ocurre un problema con alguno. Cómodamente sentados en nuestro sitio podemos reiniciar la máquina y comprobar el arranque para ver cual es el fallo. Para nuestros PCs de casa siempre tendremos la opción de utilizar un cable null modem con Linux.
viernes, 11 de enero de 2008
Charlas técnicas de OpenSolaris
Ayer me enteré vía barrapunto que la comunidad hispana de OpenSolaris organiza unas jornadas técnicas gratuitas sobre OpenSolaris en Madrid los últimos viernes de febrero, marzo y abril, así que me decidí y me apunté. Al principio abrieron 30 plazas pero finalmente han sido 40 y he podido inscribirme.
En mi anterior empleo trabajaba mucho con máquinas con Solaris y siempre me ha picado un poco el gusanillo de aprender un poco más y no centrarme sólo en Linux. Además, Alex desde que le gusta Solaris me ha dado la brasa bastante para que le dedique un poco de tiempo a OpenSolaris. Mi única pega es que mis conocimientos de administración de Solaris son nulos y no sabría por donde empezar, así que estas charlas creo que me van a venir muy bien. Si me convence finalmente OpenSolaris prometo un post contando mi experiencia instalándolo y probándolo en casa.
En fín, que si alguno se pasa por allí ya comentaremos qué nos han parecido.
ACTUALIZACIÓN 17/01/2008
Se van a impartir los mismos cursos en otras fechas. Los que se quedaron sin plaza puede que todavía estén a tiempo. Más información en Viernes Técnicos OpenSolaris.
En mi anterior empleo trabajaba mucho con máquinas con Solaris y siempre me ha picado un poco el gusanillo de aprender un poco más y no centrarme sólo en Linux. Además, Alex desde que le gusta Solaris me ha dado la brasa bastante para que le dedique un poco de tiempo a OpenSolaris. Mi única pega es que mis conocimientos de administración de Solaris son nulos y no sabría por donde empezar, así que estas charlas creo que me van a venir muy bien. Si me convence finalmente OpenSolaris prometo un post contando mi experiencia instalándolo y probándolo en casa.
En fín, que si alguno se pasa por allí ya comentaremos qué nos han parecido.
ACTUALIZACIÓN 17/01/2008
Se van a impartir los mismos cursos en otras fechas. Los que se quedaron sin plaza puede que todavía estén a tiempo. Más información en Viernes Técnicos OpenSolaris.
miércoles, 2 de enero de 2008
Pateando el culo a ZP... en la Wii
Otro de los regalos de cumpleaños que tuve en mi cumpleaños fue una Nintendo Wii. Me la regalaron mis padres/abuelos/hermana y desde entonces hemos jugado bastante. Además, ahora con el segundo mando las partidas al WiiSports son mucho más interesantes.
La Wii es una consola totalmente distinta del resto de las disponibles en el mercado, su forma de jugar engancha desde el principio y aunque los gráficos no son como los de la Xbox360 o la PS3 su jugabilidad creo que es muy superior. Si hasta mi mujer se ha enganchado y eso que no le gustan las consolas!!.
Aprovechando el canal Concursos Miis estuvimos viendo los Mii's (muñecos que puedes crear a tu gusto y que te representan en algunos juegos) que había hecho la gente y hemos importado algunos. Ahora tenemos a Doraemon, ZP, Einstein, Urkel,... y he aprovechado para pegarle una buena paliza virtual en el boxeo a ZP. Así le agradezco la ayuda de 2500 euros por hijo nacido sólo a partir del 1 de Julio cuando inicialmente dijo que era a partir del 3 (mi peque nació el 18 de Junio), por el canon digital, el euribor,... y todo lo que se me ocurra.
Podéis ver el Mii que me representa y al otro lado a ZP.
P.D: También tengo importados Miis de Rajoy, Carod Rovira y demás políticos para desestresarme pegándoles un rato :-P
La Wii es una consola totalmente distinta del resto de las disponibles en el mercado, su forma de jugar engancha desde el principio y aunque los gráficos no son como los de la Xbox360 o la PS3 su jugabilidad creo que es muy superior. Si hasta mi mujer se ha enganchado y eso que no le gustan las consolas!!.
Aprovechando el canal Concursos Miis estuvimos viendo los Mii's (muñecos que puedes crear a tu gusto y que te representan en algunos juegos) que había hecho la gente y hemos importado algunos. Ahora tenemos a Doraemon, ZP, Einstein, Urkel,... y he aprovechado para pegarle una buena paliza virtual en el boxeo a ZP. Así le agradezco la ayuda de 2500 euros por hijo nacido sólo a partir del 1 de Julio cuando inicialmente dijo que era a partir del 3 (mi peque nació el 18 de Junio), por el canon digital, el euribor,... y todo lo que se me ocurra.
 |  |
 |  |
Podéis ver el Mii que me representa y al otro lado a ZP.
P.D: También tengo importados Miis de Rajoy, Carod Rovira y demás políticos para desestresarme pegándoles un rato :-P
martes, 1 de enero de 2008
Hosting en Cyberneticos.com
Este análisis está patrocinado por Zync.es
La empresa española Cyberneticos.com ofrece, entre otras opciones, servicios de Alojamiento Web.
Tiene distintos planes de precios adaptados a las necesidades y el bolsillo de cada uno:Plan básico: 100 MB de almacenamiento con 5 GB de transferencia por 31,03€ al año. Plan Personal: 500 MB de almacenamiento con 10 GB de transferencia por 62,07€ al año. Plan Medio: 1000 MB de almacenamiento con 20 GB de transferencia por 93,10€ al año. Plan Avanzado: 2000 MB de almacenamiento con 50 GB de transferencia por 124,14€ al año. Plan Profesional: 5000 MB de almacenamiento con 100 GB de transferencia por 186,21€ al año.
Para poder aprovechar al máximo el plan contratado tenemos un completo panel de control con una gran cantidad de opciones de configuración y distintas ayudas. Entre otras, las principales son:
Gestión multidominio: Para configurar nuestros dominios de manera independiente y sin que se vean afectados por otros dominios del plan. 30 scripts totalmente gratutitos de instalación de Wordpress, Drupal, PHP-Nuke, phpBB, mediaWiki,... Totalmente preparados para una fácil y rápida instalación y configuración. Administración de cuentas de email y de acceso por webmail: Podemos crear todos los emails que necesitemos, redirecciones,... Control total sobre los DNS. Copias de seguridad automáticas cada 48 horas y otras adaptadas a nuestras necesidades. Cuentas de FTP sin límite. Bases de datos MySQL sin límite e independientes en cuanto a backups Directorios protegidos con clave para que sólo las personas que deseemos accedan a ellos.
En este enlace proporcionan una demo del panel de administración para que podamos probarlo antes de contratarlo. El usuario es demo_user y el password es demo.
Aparte de todo esto, Cyberneticos.com ofrece servidores dedicados desde Celeron a 2,4Ghz hasta Dual Xeon y Dual Opteron e incluso tienen un servicio en el que pueden construirte el servidor dedicado que más se adapte a tus necesidades.
La empresa española Cyberneticos.com ofrece, entre otras opciones, servicios de Alojamiento Web.
Tiene distintos planes de precios adaptados a las necesidades y el bolsillo de cada uno:
Para poder aprovechar al máximo el plan contratado tenemos un completo panel de control con una gran cantidad de opciones de configuración y distintas ayudas. Entre otras, las principales son:
En este enlace proporcionan una demo del panel de administración para que podamos probarlo antes de contratarlo. El usuario es demo_user y el password es demo.
Aparte de todo esto, Cyberneticos.com ofrece servidores dedicados desde Celeron a 2,4Ghz hasta Dual Xeon y Dual Opteron e incluso tienen un servicio en el que pueden construirte el servidor dedicado que más se adapte a tus necesidades.
viernes, 28 de diciembre de 2007
Compilando el kernel... ¡qué no hacer!
Después de insistir unas cuantas veces en los comentarios del blog de Vicente Navarro (aka Supercoco) por fin me puse a compilar el kernel de mi Ubuntu Gutsy Gibon. La verdad es que todo fue bien excepto por la instalación de los drivers de nvidia y el sonido.
La instalación de los drivers de nvidia fue rápida y sencilla (aunque previamente tuve que desinstalar los anteriores que traía ubuntu porque había algún conflicto.
Respecto al sonido, me faltaba un módulo que encontré en Device Drivers -> Sound -> Advanced Linux Sound Architecture -> PCI devices -> Intel HD Audio y todo funcionó sin problemas. Desde ese momento ya estoy trabajando con el kernel 2.6.23.11:
Después de esto me decidí a actualizar el kernel del servidor de backup que funciona con Debian Etch. Como (creo) que ya he comentado alguna vez, este ordenador sólo tiene el cable de alimentación y el cable de red. No tiene teclado, ratón, disquetera, lector de dvds,... nada que no utilice porque está pensado sólo para hacer backups e interactuar con él por ssh.
Pues nada, compilo el nuevo kernel, le conecto mi teclado y monitor para ver que todo es correcto en el arranque y me aparece un bonito kernel panic. Esto no habría sido más que una simple anécdota si no fuera porque tenía configurado el grub para que arrancase el kernel por defecto con un delay de 0 segundos, así que entraba una y otra vez en el mismo kernel y no había manera de arrancar la máquina!. Al final tuve que subir al trastero y buscar un lector de cds para arrancar con un live-cd y poder editar el menu.lst para arreglar el estropicio. Después de dejarlo todo funcionando ya he aprendido la lección y ahora espera 5 segundos antes de arrancar, así cuando vuelva a compilar el kernel y no funcione bien a la primera no tenga que perder media mañana en arreglar el problema.
Moraleja: Por ahorrarme 5 segundos en el arranque al final gasté unas cuantas horas...
P.D: No arrancaba porque se me había olvidado crear el initrd...
La instalación de los drivers de nvidia fue rápida y sencilla (aunque previamente tuve que desinstalar los anteriores que traía ubuntu porque había algún conflicto.
Respecto al sonido, me faltaba un módulo que encontré en Device Drivers -> Sound -> Advanced Linux Sound Architecture -> PCI devices -> Intel HD Audio y todo funcionó sin problemas. Desde ese momento ya estoy trabajando con el kernel 2.6.23.11:
ivan@doraemon:~$ uname -a
Linux doraemon.casa 2.6.23.11-ILM #1 SMP Sat Dec 15 10:04:16 CET 2007 i686 GNU/Linux
Después de esto me decidí a actualizar el kernel del servidor de backup que funciona con Debian Etch. Como (creo) que ya he comentado alguna vez, este ordenador sólo tiene el cable de alimentación y el cable de red. No tiene teclado, ratón, disquetera, lector de dvds,... nada que no utilice porque está pensado sólo para hacer backups e interactuar con él por ssh.
Pues nada, compilo el nuevo kernel, le conecto mi teclado y monitor para ver que todo es correcto en el arranque y me aparece un bonito kernel panic. Esto no habría sido más que una simple anécdota si no fuera porque tenía configurado el grub para que arrancase el kernel por defecto con un delay de 0 segundos, así que entraba una y otra vez en el mismo kernel y no había manera de arrancar la máquina!. Al final tuve que subir al trastero y buscar un lector de cds para arrancar con un live-cd y poder editar el menu.lst para arreglar el estropicio. Después de dejarlo todo funcionando ya he aprendido la lección y ahora espera 5 segundos antes de arrancar, así cuando vuelva a compilar el kernel y no funcione bien a la primera no tenga que perder media mañana en arreglar el problema.
Moraleja: Por ahorrarme 5 segundos en el arranque al final gasté unas cuantas horas...
P.D: No arrancaba porque se me había olvidado crear el initrd...
miércoles, 12 de diciembre de 2007
Análisis y trucos de VMware Server ESX
Lo prometido es deuda y aquí continúo con la última parte del análisis de VMware ESX Server.
Una de las primeras dificultades que encontré fue aumentar el número de CPUs en las máquinas virtuales. Cuando creamos una máquina virtual con el asistente podemos elegir el número de CPUs virtuales (vcpus) entre 1 y 2 en función del sistema operativo. Así, con Windows 2003 Server el máximo es 2 y con Windows XP es 1. En seguida encontré cómo aumentar esto ya que como habéis visto en las capturas del artículo anterior, el servidor Windows 2003 tiene asignadas 4 CPUs. Para ello, en la consola de administracción, seleccionamos la máquina virtual que nos interese para ver todas sus opciones. Nos vamos al menú Options y en Verbose Options, añadimos la propiedad numvcpus con el valor que deseemos. En las máquinas virtuales con Windows XP he dejado sólo una y en Windows 2003 Server cuatro. El resultado es:
Veamos un poco más de cerca el linux instalado que se encarga de gestionar todo:
Como ya nos comentó Supercoco en los comentarios del anterior artículo se trata de un kernel linux (en este caso 2.4). Justo "encima" de este kernel linux se ejecuta un vmkernel que se encarga de proporcionar todas las funciones de virtualización como por ejemplo el comando vdf anterior para mostrar los filesystems virtuales.
El sistema de ficheros VMFS es el que está montado en /vmfs/vmhba2:0:0:6 y es donde se almacenan las máquinas virtuales. A diferencia de otras versión de VMware como la Server o la Workstation, en la versión ESX se reserva en el disco toda la capacidad que queramos dar a los discos duros de las máquinas virtuales. Así, aunque después de instalar el sistema operativo en la máquina virtual sólo tengamos ocupados un par de Gbytes, habremos "perdido" el espacio total del disco.
Esta máquina está en una plataforma de pruebas junto con otras 20 que utilizamos en conjunto para probar todas las opciones de la aplicación. Después de instalar unas cuantas versiones, poner parches y demás, las instalaciones de las máquinas se quedan un poco "tocadas". Para evitar estar reinstalando tenemos hechas unas imagenes con Acronis True Image y de vez en cuando restauramos las máquinas al estado inicial. Hacer esto con VMware es tan fácil como apagar la máquina virtual y ejecutar:
Y después, cuando queramos recuperar la máquina, simplemente descomprimimos el archivo .gz y tenemos la máquina restaurada en muy poco tiempo.
Otro de los aspectos a tener en cuenta es la instalación de Windows XP. Según se nos indica cuando seleccionamos la creación de una máquina virtual con dicho sistema operativo, necesitamos descargar los drivers SCSI de la web de WMware para que la instalación de Windows XP reconozca nuestro disco duro virtual. Es una imagen de disquete y para utilizarla tenemos que montar una disquetera virtual en la instalación y decirle que utilice dicha imagen.
Todo el sistema se controla desde una interfaz gráfica que está muy cuidada y que muestra gran cantidad de información de las máquinas virtuales. Así, podemos tener una visión general de las máquina virtuales que están en ejecución, su consumo de memoria, cpu, el tiempo que llevan en funcionamiento,...
Luego, si seleccionamos una máquina virtual concreta podemos tener estadísticas más detalladas de la utilización de las CPUs, acceso al disco o la red, podemos controlar en qué CPUs físicas queremos ejecutar la máquina virtual,... y así un gran número de opciones.
Otra de las opciones que posee VMware ESX es una web de estadísticas en la que podemos ver el estado de las máquinas virtuales, el consumo de CPU, disco duro, ancho de banda,... a lo largo del tiempo. Para activarlas simplemente ejecutamos:
Con lo que cada minuto se ejecutará por crontab el script que recolecta las estadísticas y a través del navegador web podemos analizarlas. Podemos tener una visión general del estado del sistema o centrarnos en una máquina virtual concreta, ver el estado por día, semana,...
Además de todo lo anterior, también podemos exportar e importar las máquinas virtuales al formato de las versiones Server/Workstation:
Finalmente para terminar decir que de momento todo funciona muy bien y estoy muy contento con la oportunidad de haber podido cacharrear con este producto. Soy un fanático de la virtualización y desde las primeras versiones de VMware Workstation tanto para windows como para linux estoy utilizando el producto y me encanta. El futuro es la virtualización porque cada vez tenemos máquinas más potentes a precios más bajos. Evidentemente, en este caso particular de virtualizar máquinas windows, siempre necesitamos otro equipo para conectarnos a través de la consola e interactuar con la máquina virtual. Esto no ocurriría si instalasemos máquinas virtuales linux ya que sólo necesitaríamos acceso por ssh. Aún así, se de primera mano que en grandes empresas se utiliza para virtualizar servidores windows en máquinas Blade.
Una de las primeras dificultades que encontré fue aumentar el número de CPUs en las máquinas virtuales. Cuando creamos una máquina virtual con el asistente podemos elegir el número de CPUs virtuales (vcpus) entre 1 y 2 en función del sistema operativo. Así, con Windows 2003 Server el máximo es 2 y con Windows XP es 1. En seguida encontré cómo aumentar esto ya que como habéis visto en las capturas del artículo anterior, el servidor Windows 2003 tiene asignadas 4 CPUs. Para ello, en la consola de administracción, seleccionamos la máquina virtual que nos interese para ver todas sus opciones. Nos vamos al menú Options y en Verbose Options, añadimos la propiedad numvcpus con el valor que deseemos. En las máquinas virtuales con Windows XP he dejado sólo una y en Windows 2003 Server cuatro. El resultado es:
 |  |
Veamos un poco más de cerca el linux instalado que se encarga de gestionar todo:
[root@esxconsole root]# uname -a
Linux esxconsole 2.4.9-vmnix2 #1 Thu Sep 8 14:46:53 PDT 2005 i686 unknown
[root@esxconsole root]# vdf -h
Filesystem Size Used Avail Use% Mounted on
/dev/cciss/c0d0p2 2.4G 866M 1.4G 38% /
/dev/cciss/c0d0p1 50M 12M 36M 25% /boot
none 188M 0 187M 0% /dev/shm
vmhba2:0:0:6 200G 62G 138G 30% /vmfs/vmhba2:0:0:6
Como ya nos comentó Supercoco en los comentarios del anterior artículo se trata de un kernel linux (en este caso 2.4). Justo "encima" de este kernel linux se ejecuta un vmkernel que se encarga de proporcionar todas las funciones de virtualización como por ejemplo el comando vdf anterior para mostrar los filesystems virtuales.
El sistema de ficheros VMFS es el que está montado en /vmfs/vmhba2:0:0:6 y es donde se almacenan las máquinas virtuales. A diferencia de otras versión de VMware como la Server o la Workstation, en la versión ESX se reserva en el disco toda la capacidad que queramos dar a los discos duros de las máquinas virtuales. Así, aunque después de instalar el sistema operativo en la máquina virtual sólo tengamos ocupados un par de Gbytes, habremos "perdido" el espacio total del disco.
[root@esxconsole root]# ls -lh /vmfs/vmhba2\:0\:0\:6/
-rw------- 1 root root 20G Nov 13 10:28 W2K3_DiskC.vmdk
-rw------- 1 root root 5.0G Nov 13 10:28 W2K3_DiskE.vmdk
-rw------- 1 root root 7.9G Nov 7 09:48 SwapFile.vswp
-rw------- 1 root root 15G Nov 13 10:25 WXP_Client1_DiskC.vmdk
Esta máquina está en una plataforma de pruebas junto con otras 20 que utilizamos en conjunto para probar todas las opciones de la aplicación. Después de instalar unas cuantas versiones, poner parches y demás, las instalaciones de las máquinas se quedan un poco "tocadas". Para evitar estar reinstalando tenemos hechas unas imagenes con Acronis True Image y de vez en cuando restauramos las máquinas al estado inicial. Hacer esto con VMware es tan fácil como apagar la máquina virtual y ejecutar:
[root@esxconsole vmhba2:0:0:6]# gzip -c W2K3_DiskC.vmdk > W2K3_DiskC_CLON.vmdk.gz
[root@esxconsole vmhba2:0:0:6]# ls -lh
-rw------- 1 root root 20G Nov 13 10:28 W2K3_DiskC.vmdk
-rw------- 1 root root 1.7G Nov 8 16:44 W2K3_DiskC_CLON.vmdk.gz
Y después, cuando queramos recuperar la máquina, simplemente descomprimimos el archivo .gz y tenemos la máquina restaurada en muy poco tiempo.
Otro de los aspectos a tener en cuenta es la instalación de Windows XP. Según se nos indica cuando seleccionamos la creación de una máquina virtual con dicho sistema operativo, necesitamos descargar los drivers SCSI de la web de WMware para que la instalación de Windows XP reconozca nuestro disco duro virtual. Es una imagen de disquete y para utilizarla tenemos que montar una disquetera virtual en la instalación y decirle que utilice dicha imagen.
Todo el sistema se controla desde una interfaz gráfica que está muy cuidada y que muestra gran cantidad de información de las máquinas virtuales. Así, podemos tener una visión general de las máquina virtuales que están en ejecución, su consumo de memoria, cpu, el tiempo que llevan en funcionamiento,...
 |  |
Luego, si seleccionamos una máquina virtual concreta podemos tener estadísticas más detalladas de la utilización de las CPUs, acceso al disco o la red, podemos controlar en qué CPUs físicas queremos ejecutar la máquina virtual,... y así un gran número de opciones.
 |
Otra de las opciones que posee VMware ESX es una web de estadísticas en la que podemos ver el estado de las máquinas virtuales, el consumo de CPU, disco duro, ancho de banda,... a lo largo del tiempo. Para activarlas simplemente ejecutamos:
[root@esxconsole root]# vmkusagectl install
Info: Adding cron job
Con lo que cada minuto se ejecutará por crontab el script que recolecta las estadísticas y a través del navegador web podemos analizarlas. Podemos tener una visión general del estado del sistema o centrarnos en una máquina virtual concreta, ver el estado por día, semana,...
 |
Además de todo lo anterior, también podemos exportar e importar las máquinas virtuales al formato de las versiones Server/Workstation:
[root@esxconsole vmhba2:0:0:6]# vmkfstools -e ExportVM.vmdk vmhba2:0:0:6:WXP_Client1_DiskC.vmdk
Exporting disk vmhba2:0:0:6:WXP_Client1_DiskC.vmdk:
Export: 100% done.
[root@esxconsole vmhba2:0:0:6]# ls -lh ExportVM*
-rw------- 1 root root 1.6G Nov 22 09:17 ExportVM-s001.vmdk
-rw------- 1 root root 1.0G Nov 22 09:17 ExportVM-s002.vmdk
-rw------- 1 root root 1.1G Nov 22 09:17 ExportVM-s003.vmdk
-rw------- 1 root root 2.0G Nov 22 09:17 ExportVM-s004.vmdk
-rw------- 1 root root 912M Nov 22 09:17 ExportVM-s005.vmdk
-rw------- 1 root root 2.0G Nov 22 09:17 ExportVM-s006.vmdk
-rw------- 1 root root 1.5G Nov 22 09:17 ExportVM-s007.vmdk
-rw------- 1 root root 1.2M Nov 22 09:17 ExportVM-s008.vmdk
-rw------- 1 root root 614 Nov 22 09:17 ExportVM.vmdk
Finalmente para terminar decir que de momento todo funciona muy bien y estoy muy contento con la oportunidad de haber podido cacharrear con este producto. Soy un fanático de la virtualización y desde las primeras versiones de VMware Workstation tanto para windows como para linux estoy utilizando el producto y me encanta. El futuro es la virtualización porque cada vez tenemos máquinas más potentes a precios más bajos. Evidentemente, en este caso particular de virtualizar máquinas windows, siempre necesitamos otro equipo para conectarnos a través de la consola e interactuar con la máquina virtual. Esto no ocurriría si instalasemos máquinas virtuales linux ya que sólo necesitaríamos acceso por ssh. Aún así, se de primera mano que en grandes empresas se utiliza para virtualizar servidores windows en máquinas Blade.
lunes, 10 de diciembre de 2007
Aprovechando servidor HP Proliant con VMware ESX Server
En el anterior post comentaba que teníamos en el trabajo unos servidores nuevos pero que estaban siendo totalmente desaprovechados. Comenzamos justo donde lo dejé diciendo que había encontrado la forma de poder aprovecharlos. Se trata de utilizar VMware Server ESX 2.5 (como ya acertó Supercoco en los comentarios) para virtualizar el Windows 2003 Server. VMware ESX está basado en linux como sistema operativo base lo que le proporciona gran estabilidad, más concretamente en RedHat 7.1. Además incluye un conjunto de utilidades que actúan como capa de acceso a todo el hardware que proporcionan la virtualización. Utiliza un sistema de ficheros propio, VMFS en el que se almacenan los discos virtuales de cada máquina virtual y que se puede compartir entre varios servidores ESX. Los requisitos para la instalación de VMware ESX son bastante elevados puesto que están pensados para servidores. Así, debemos tener una máquina multiprocesador, gran cantidad de RAM, al menos dos tarjetas de red y controladora SCSI, RAID ó FC principalmente.
La instalación de VMware ESX es muy sencilla, sólo hay que configurar la zona horaria, el password de root, la distribución del teclado y las particiones. La controladora raid fue reconocida sin ningún problema y en poco más de 20 minutos tenía el sistema instalado. Una vez reiniciada la máquina para arrancar ya con ESX me conecté a la web de administración para terminar de configurar el sistema. Aquí lo único necesario es configurar un archivo swap de intercambio y crear un switch virtual para las máquinas virtuales. Tambien es necesario indicar cuanta memoria queremos reservar para el sitema base que se encargará de gestionar las máquinas virtuales. En función del número de máquinas virtuales que deseemos tener, éste variará entre 198 y 800 MB para un total de entre 8 y unas 60-70 máquinas virtuales.
Hecho esto y después del pertinente reinicio para que se reserve la memoria seleccionada para la consola ya podemos crear nuestra primera máquina virtual. El asistente de creación es similar al existente tanto en VMware Workstation como VMware Server y no presenta ninguna dificultad. Una vez hecho esto nos descargamos desde el propio servidor la consola para poder conectarnos a las máquinas virtuales y podemos comenzar con la instalación del sistema operativo.
Después de un rato instalando y configurando todo tenía el Windows 2003 Server listo y con una configuración más equilibrada que la anterior. En este caso le asigné 4 CPUs y 4 GB de RAM (realmente fueron 3600MB por imposición de VMware).
El resto lo dejé libre para crear máquinas virtuales que actuarán como clientes y que necesitan menos recursos. Seguramente serán 4 máquinas virtuales con Windows XP con una CPU y 1 GB de RAM.
Me guardo para el próximo artículo contar desde un punto de vista algo más técnico algunas curiosidades de WMware ESX Server y algunos pequeños trucos y ayudas.
La instalación de VMware ESX es muy sencilla, sólo hay que configurar la zona horaria, el password de root, la distribución del teclado y las particiones. La controladora raid fue reconocida sin ningún problema y en poco más de 20 minutos tenía el sistema instalado. Una vez reiniciada la máquina para arrancar ya con ESX me conecté a la web de administración para terminar de configurar el sistema. Aquí lo único necesario es configurar un archivo swap de intercambio y crear un switch virtual para las máquinas virtuales. Tambien es necesario indicar cuanta memoria queremos reservar para el sitema base que se encargará de gestionar las máquinas virtuales. En función del número de máquinas virtuales que deseemos tener, éste variará entre 198 y 800 MB para un total de entre 8 y unas 60-70 máquinas virtuales.
Hecho esto y después del pertinente reinicio para que se reserve la memoria seleccionada para la consola ya podemos crear nuestra primera máquina virtual. El asistente de creación es similar al existente tanto en VMware Workstation como VMware Server y no presenta ninguna dificultad. Una vez hecho esto nos descargamos desde el propio servidor la consola para poder conectarnos a las máquinas virtuales y podemos comenzar con la instalación del sistema operativo.
 |
Después de un rato instalando y configurando todo tenía el Windows 2003 Server listo y con una configuración más equilibrada que la anterior. En este caso le asigné 4 CPUs y 4 GB de RAM (realmente fueron 3600MB por imposición de VMware).
|
El resto lo dejé libre para crear máquinas virtuales que actuarán como clientes y que necesitan menos recursos. Seguramente serán 4 máquinas virtuales con Windows XP con una CPU y 1 GB de RAM.
Me guardo para el próximo artículo contar desde un punto de vista algo más técnico algunas curiosidades de WMware ESX Server y algunos pequeños trucos y ayudas.
sábado, 8 de diciembre de 2007
Regalo friki de cumpleaños
Hoy cumplo 28 años y este que veis a continuación es el regalo friki (a parte de otros) que me ha hecho mi mujer (gracias cariño!). Llevaba tiempo mirando y buscando por la red para conseguir algo así y por fin hoy ya lo tengo.
A parte de la camiseta, el paquete también es muy friki: la cinta de embalar, el remitente,... Me ha hecho especial gracia el mensaje que pone en la caja: De friki a friki.
Y bueno, si alguien quiere hacerme algún regalo, estoy abierto a cualquier cacharro tecnológico que sea chulo y frikadas varias. Si quereis la información para enviarme un regalo escribidme un email ;-).
 |
A parte de la camiseta, el paquete también es muy friki: la cinta de embalar, el remitente,... Me ha hecho especial gracia el mensaje que pone en la caja: De friki a friki.
Y bueno, si alguien quiere hacerme algún regalo, estoy abierto a cualquier cacharro tecnológico que sea chulo y frikadas varias. Si quereis la información para enviarme un regalo escribidme un email ;-).
lunes, 3 de diciembre de 2007
Instalando un servidor HP Proliant DL360
El cliente del proyecto en el que estoy trabajando nos ha enviado un par de servidores HP Proliant DL360. Estos servidores vienen equipados con 2 procesadores Intel Xeon E5345 Quad Core, 8 GB de RAM, 4 discos duros de 10.000 rpm (pero de sólo 2,5 pulgadas) de 72 GB en RAID 5 (por hardware), 2 tarjetas de red y además con el teclado y monitor integrados en el extraño rack que podéis ver en las fotos (tomadas con un par de móviles).
En estas máquinas instalamos una versión de nuestra aplicación que actua como servidor. El sistema operativo que llevan instalado es Windows 2003 Server y trabajamos con Oracle 10g y Exchange.
Como es de sobra conocido, un sistema operativo de 32 bits como el que tenemos instalado no permite direccionar más de 4 GB de RAM (a lo que hay que restarle la reservada para direccionar la memoria de la tarjeta gráfica). Así, después de tener instalado uno de los servidores, abrimos el administrador de tareas y vemos esto:
A mi se me cayó literalmente el alma a los pies al ver cómo de desaprovechada estaba la máquina. Más de 4 GB de RAM ni siquiera existían para el sistema operativo y las 8 CPUs (4 cores en cada micro) son excesivas para nuestra aplicación, por lo que también están infrautilizadas.
Entonces nos planteamos instalar la versión de 64 bits de Windows 2003 Server, pero finalmente no pudo ser porque teníamos problemas con el Exchange y también con nuestra aplicación. Así, parecía que íbamos a tener ahí esas impresionantes máquinas totalmente desaprovechadas.
Como no me quedé contento con eso pensé una solución para sacarle el mayor partido al hardware que tenemos y al final la encontré, pero eso lo contaré en el siguiente artículo.
 |  |
En estas máquinas instalamos una versión de nuestra aplicación que actua como servidor. El sistema operativo que llevan instalado es Windows 2003 Server y trabajamos con Oracle 10g y Exchange.
Como es de sobra conocido, un sistema operativo de 32 bits como el que tenemos instalado no permite direccionar más de 4 GB de RAM (a lo que hay que restarle la reservada para direccionar la memoria de la tarjeta gráfica). Así, después de tener instalado uno de los servidores, abrimos el administrador de tareas y vemos esto:
 |
A mi se me cayó literalmente el alma a los pies al ver cómo de desaprovechada estaba la máquina. Más de 4 GB de RAM ni siquiera existían para el sistema operativo y las 8 CPUs (4 cores en cada micro) son excesivas para nuestra aplicación, por lo que también están infrautilizadas.
Entonces nos planteamos instalar la versión de 64 bits de Windows 2003 Server, pero finalmente no pudo ser porque teníamos problemas con el Exchange y también con nuestra aplicación. Así, parecía que íbamos a tener ahí esas impresionantes máquinas totalmente desaprovechadas.
Como no me quedé contento con eso pensé una solución para sacarle el mayor partido al hardware que tenemos y al final la encontré, pero eso lo contaré en el siguiente artículo.
lunes, 26 de noviembre de 2007
Los viejos tiempos...
Aunque en mi nuevo trabajo estoy muy contento no sólo porque estoy más cerca de casa y por el horario, sino porque me gusta lo que hago, a veces echo de menos tener minimizadas 12 sesiones de putty en distintas máquinas y cacharrear con algunas cosas que ahora ya no utilizo. He puesto en negrita máquinas porque tenía a mi "disposición" máquinas como esta:
Sí, es una máquina Fujitsu PrimePower 650 con 8 CPUs de 64 bits a casi 1,4 Ghz cada una de ellas y 12 GBytes de RAM (hay que tener en cuenta que esta máquina se compró a principios de 2005 cuando no era tan común tener tanta RAM). Esta máquina corre Solaris 9 y creo que es una de las más potentes de toda Validación Técnica. En esta máquina corrían tres instancias de base de datos Oracle 9i, alguna de ellas de 200 GBytes de datos, unos 12 Apache-Tomcat, 10 WebMethods Integration Server y alguna que otra cosa más y para remetar, le sumamos que está conectada por una tarjeta de fibra óptica a un armario de discos de Clariion con más de 13 TBytes, podéis imaginar cómo lo echo de menos. Antes de que preguntéis en los comentarios debo aclarar que esos 13 TBytes de espacio eran compartidos para todas las máquinas que no eran de producción, es decir, desarrollo y VT, por lo que no vale decir: la cantidad de MP3s y pelis que entrarían ahí ;-).
En una de las intervenciones para el cambio de la systemboard que hubo en esta máquina después de algunos problemas, bajé al CPD aprovechando que tenía enchufe ;-) y le estuve haciendo algunas fotos (eso sí, con el móvil, por lo que la calidad no es muy buena) porque siempre tenía ganas de ver cómo era una máquina de estas por dentro.
En fin, que tengo un poco de nostalgia en ese sentido del trabajo que hacía antes pero también estoy muy contento con el cambio que hice hace casi un año.
$ /usr/platform/sun4us/sbin/prtdiag -v
System Configuration: Sun Microsystems sun4us Fujitsu Siemens PRIMEPOWER650 1- slot 8x SPARC64 V
System clock frequency: 270 MHz
Memory size: 12288 Megabytes
========================= CPUs =========================
Run Ecache CPU CPU
Brd CPU Module MHz MB Impl. Mask
--- --- ------ ----- ---- ----- ----
0 0 0 1349 2.0 5 0.8
0 1 1 1349 2.0 5 0.8
0 2 2 1349 2.0 5 0.8
0 3 3 1349 2.0 5 0.8
0 4 4 1349 2.0 5 0.8
0 5 5 1349 2.0 5 0.7
0 6 6 1349 2.0 5 0.8
0 7 7 1349 2.0 5 0.8
Sí, es una máquina Fujitsu PrimePower 650 con 8 CPUs de 64 bits a casi 1,4 Ghz cada una de ellas y 12 GBytes de RAM (hay que tener en cuenta que esta máquina se compró a principios de 2005 cuando no era tan común tener tanta RAM). Esta máquina corre Solaris 9 y creo que es una de las más potentes de toda Validación Técnica. En esta máquina corrían tres instancias de base de datos Oracle 9i, alguna de ellas de 200 GBytes de datos, unos 12 Apache-Tomcat, 10 WebMethods Integration Server y alguna que otra cosa más y para remetar, le sumamos que está conectada por una tarjeta de fibra óptica a un armario de discos de Clariion con más de 13 TBytes, podéis imaginar cómo lo echo de menos. Antes de que preguntéis en los comentarios debo aclarar que esos 13 TBytes de espacio eran compartidos para todas las máquinas que no eran de producción, es decir, desarrollo y VT, por lo que no vale decir: la cantidad de MP3s y pelis que entrarían ahí ;-).
En una de las intervenciones para el cambio de la systemboard que hubo en esta máquina después de algunos problemas, bajé al CPD aprovechando que tenía enchufe ;-) y le estuve haciendo algunas fotos (eso sí, con el móvil, por lo que la calidad no es muy buena) porque siempre tenía ganas de ver cómo era una máquina de estas por dentro.
 |  |
 |  |
En fin, que tengo un poco de nostalgia en ese sentido del trabajo que hacía antes pero también estoy muy contento con el cambio que hice hace casi un año.
miércoles, 21 de noviembre de 2007
Un año con ADSL y con Emule
Hace aproximadamente un año que tengo adsl en casa y desde entonces he descargado mucho con el emule. Aquí podéis ver unas estádisticas de lo que llevo acumulado tanto de bajada como de subida.
He de decir que aunque al principio empecé descargando muchas cosas y teniendo el servidor emule encendido prácticamente semanas, ultimamente sólo lo enciendo cada 5 ó 6 días para bajar los últimos capítulos de las series que vemos, que no son pocas pero que se bajan enseguida y otra vez lo apago de nuevo. En total y según las estadísticas ha estado encendido casi un 50% del tiempo y he descargado 365GB!!.
El balance de este año con ADSL ha sido muy bueno puesto que el tiempo que estuvimos de alquiler antes de que nos dieran el piso se me hizo muy duro sin tener conexión. Además, con la conexión de 1 MB que tengo contratada actualmente me sobra para todo y no he tenido cortes en todo este tiempo salvo un día en el que estuve sin DNS un par de horas.
Esperemos que dentro de un año siga tan contento porque después de la compra de Ya.com por Orange... me echo a temblar.
 |
He de decir que aunque al principio empecé descargando muchas cosas y teniendo el servidor emule encendido prácticamente semanas, ultimamente sólo lo enciendo cada 5 ó 6 días para bajar los últimos capítulos de las series que vemos, que no son pocas pero que se bajan enseguida y otra vez lo apago de nuevo. En total y según las estadísticas ha estado encendido casi un 50% del tiempo y he descargado 365GB!!.
El balance de este año con ADSL ha sido muy bueno puesto que el tiempo que estuvimos de alquiler antes de que nos dieran el piso se me hizo muy duro sin tener conexión. Además, con la conexión de 1 MB que tengo contratada actualmente me sobra para todo y no he tenido cortes en todo este tiempo salvo un día en el que estuve sin DNS un par de horas.
Esperemos que dentro de un año siga tan contento porque después de la compra de Ya.com por Orange... me echo a temblar.
viernes, 16 de noviembre de 2007
¡Más de 100 suscritos al feed!
Como podéis ver en la gráfica ya sois más de 100, concretamente 104, los que estáis suscritos al feed según Feedburner.
Además, se puede ver que desde principios de agosto en que decidí utilizar feedburner el número de suscriptores ha ido creciendo y se ha duplicado!. Estas estadísticas me dan ánimo para seguir escribiendo porque sé que lo que hago os gusta y mucha gente me lo agradece en los comentarios. Así que ya sabéis, tenéis blog para rato... :-D.
¡Muchas gracias a todos!.
 |
Además, se puede ver que desde principios de agosto en que decidí utilizar feedburner el número de suscriptores ha ido creciendo y se ha duplicado!. Estas estadísticas me dan ánimo para seguir escribiendo porque sé que lo que hago os gusta y mucha gente me lo agradece en los comentarios. Así que ya sabéis, tenéis blog para rato... :-D.
¡Muchas gracias a todos!.
martes, 13 de noviembre de 2007
Cambiar un disco por uno de mayor capacidad con LVM en caliente
En mi anterior artículo sobre simular un raid lineal con LVM, RuBICK nos comentaba:
Tal y como le contesté en los comentarios, ya conté en el artículo inicial del LVM cómo hacerlo, aunque revisando el artículo me he dado cuenta de que me quedó un poco largo y justo eso quedó al final. Así, lo he rescatado para que se vean aún más las posibilidades de LVM.
Partimos de un disco/partición con datos /dev/sda1 y lo que vamos a hacer es reemplazarlo por uno nuevo /dev/sdb1 previamente formateado con LVM.
Creamos un PV en la nueva partición:
Lo añadimos al VG vg01 ya existente:
Mostramos la información y comprobamos que tenemos dos PVs en el mismo VG. Nos fijamos en las extensiones disponibles en cada uno:
Movemos la información de la partición que queremos liberar. Previamente nos aparece un error indicando que necesitamos tener activado en el kernel el mirror, así que cargamos el módulo:
De nuevo, intentamos mover los datos, aunque ahora sí lo conseguimos. Este paso variará en función de la cantidad de datos que se deban mover:
Comprobamos el estado del VG y vemos que el PV /dev/sda1 tiene todas las extensiones disponibles:
Y finalmente eliminamos el PV /dev/sda1 del VG vg01 y comprobamos el resultado:
Así, hemos conseguido cambiar un disco que se nos estaba quedando pequeño por otro de mayor capacidad, en caliente y sin que nadie note nada. Obviamente si es un servidor con discos internos, necesariamente hay que apagar la máquina para añadir/quitar el disco, pero con máquinas conectadas a almacenamiento externo no habría ningún problema.
Luego hay otro "truquillo" para sustituir un disco de ej: 80 GB por uno de 300Gb en caliente y sin que nadie lo note, pero eso seguro que nos lo tiene guardado Iván para otro dia.
Tal y como le contesté en los comentarios, ya conté en el artículo inicial del LVM cómo hacerlo, aunque revisando el artículo me he dado cuenta de que me quedó un poco largo y justo eso quedó al final. Así, lo he rescatado para que se vean aún más las posibilidades de LVM.
Partimos de un disco/partición con datos /dev/sda1 y lo que vamos a hacer es reemplazarlo por uno nuevo /dev/sdb1 previamente formateado con LVM.
shian:~# pvcreate /dev/sdb1
Physical volume "/dev/sdb1" successfully created
shian:~# vgextend vg01 /dev/sdb1
Volume group "vg01" successfully extended
shian:~# vgdisplay -v vg01
Using volume group(s) on command line
Finding volume group "vg01"
--- Volume group ---
VG Name vg01
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size 5.99 GB
PE Size 4.00 MB
Total PE 1534
Alloc PE / Size 256 / 1.00 GB
Free PE / Size 1278 / 4.99 GB
VG UUID BpNJTl-9tlr-DjzM-C8Mb-LfnL-NWDa-uyWDpf
--- Logical volume ---
LV Name /dev/vg01/lvdatos
VG Name vg01
LV UUID 7CYTLY-YgI2-c64S-F50h-vPXH-TEk9-o4hFOE
LV Write Access read/write
LV Status available
# open 1
LV Size 1.00 GB
Current LE 256
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:0
--- Physical volumes ---
PV Name /dev/sda1
PV UUID 1wounc-DIHj-Tf54-4h2c-4rcB-w137-gLH4I6
PV Status allocatable
Total PE / Free PE 511 / 255
PV Name /dev/sdb1
PV UUID N0nwct-jNnY-eU0D-6Evh-tkIN-9vKs-9KsV3v
PV Status allocatable
Total PE / Free PE 1023 / 1023
shian:~# pvmove /dev/sda1
mirror: Required device-mapper target(s) not detected in your kernel
shian:~# modprobe dm_mirror
shian:~# pvmove -v /dev/sda1
/dev/sda1: Moved: 100.0%
shian:~# vgdisplay -v vg01
...
...
--- Physical volumes ---
PV Name /dev/sda1
PV UUID 1wounc-DIHj-Tf54-4h2c-4rcB-w137-gLH4I6
PV Status allocatable
Total PE / Free PE 511 / 511
PV Name /dev/sdb1
PV UUID N0nwct-jNnY-eU0D-6Evh-tkIN-9vKs-9KsV3v
PV Status allocatable
Total PE / Free PE 1023 / 767
shian:~# vgreduce -v vg01 /dev/sda1
Removed "/dev/sda1" from volume group "vg01"
shian:~# vgdisplay -v vg01
Using volume group(s) on command line
Finding volume group "vg01"
--- Volume group ---
VG Name vg01
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 11
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 4.00 GB
PE Size 4.00 MB
Total PE 1023
Alloc PE / Size 256 / 1.00 GB
Free PE / Size 767 / 3.00 GB
VG UUID BpNJTl-9tlr-DjzM-C8Mb-LfnL-NWDa-uyWDpf
--- Logical volume ---
LV Name /dev/vg01/lvdatos
VG Name vg01
LV UUID 7CYTLY-YgI2-c64S-F50h-vPXH-TEk9-o4hFOE
LV Write Access read/write
LV Status available
# open 1
LV Size 1.00 GB
Current LE 256
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:0
--- Physical volumes ---
PV Name /dev/sdb1
PV UUID N0nwct-jNnY-eU0D-6Evh-tkIN-9vKs-9KsV3v
PV Status allocatable
Total PE / Free PE 1023 / 767
Así, hemos conseguido cambiar un disco que se nos estaba quedando pequeño por otro de mayor capacidad, en caliente y sin que nadie note nada. Obviamente si es un servidor con discos internos, necesariamente hay que apagar la máquina para añadir/quitar el disco, pero con máquinas conectadas a almacenamiento externo no habría ningún problema.
viernes, 2 de noviembre de 2007
Actualizando versión de Linux: ¡Aprende Windows!
Hace un par de semanas he actualizado mi Ubuntu Feisty a Gutsy y la verdad es que ha sido mucho mejor de lo que yo me esperaba y para nada traumático.
Al principio me planteé formatear e instalar de cero y posteriormente recuperar todos mis datos del backup. Esta es la mentalidad windows: hay que instalar el sistema operativo de cero y nada de actualizar porque sino se quedan versiones antiguas y hay problemas e incompatibilidades. Pero esto no es windows, sino Linux, así que preferí actualizar mi sistema a ver qué ocurría. Ejecuté el update-manager y comencé la actualización a Gutsy Gibbon. En total se descargaron algo más de 1 Gbyte de paquetes, luego reinicié, instalé los drivers de nvidia y listo. En poco más de 2 horas tenía mi linux actualizado a la última versión de Ubuntu y con todas mis opciones de configuración almacenadas y funcionando sin ningún problema. Luego sólo tuve que configurar Compiz Fusion (hasta ahora tenía Beryl) y listo, el escritorio como lo tenía antes e incluso con efectos más chulos.
En definitiva, que de nuevo me reafirmo en la elección que hice a principios de mayo de este año eligiendo linux como mi nuevo sistema operativo para (casi, sniff) todo.
Al principio me planteé formatear e instalar de cero y posteriormente recuperar todos mis datos del backup. Esta es la mentalidad windows: hay que instalar el sistema operativo de cero y nada de actualizar porque sino se quedan versiones antiguas y hay problemas e incompatibilidades. Pero esto no es windows, sino Linux, así que preferí actualizar mi sistema a ver qué ocurría. Ejecuté el update-manager y comencé la actualización a Gutsy Gibbon. En total se descargaron algo más de 1 Gbyte de paquetes, luego reinicié, instalé los drivers de nvidia y listo. En poco más de 2 horas tenía mi linux actualizado a la última versión de Ubuntu y con todas mis opciones de configuración almacenadas y funcionando sin ningún problema. Luego sólo tuve que configurar Compiz Fusion (hasta ahora tenía Beryl) y listo, el escritorio como lo tenía antes e incluso con efectos más chulos.
En definitiva, que de nuevo me reafirmo en la elección que hice a principios de mayo de este año eligiendo linux como mi nuevo sistema operativo para (casi, sniff) todo.
 |
Suscribirse a:
Entradas (Atom)