May 31, 2010

Distribución automática de software con Opsi (I)

Opsi (open pc server integration) es una aplicación open source basada en Linux que permite gestionar de forma remota, la instalación y el mantenimiento del software relacionado con equipos Microsoft Windows.

Entre sus principales características cabe destacar la posibilidad de instalar de forma automática sistemas operativos (Windows 2000, XP, Vista y Server 2003/2008) a través de imágenes (arranque PXE), despliegue automático de software y control de versiones, inventarios hardware y software, etc.

Opsi está basado en una arquitectura cliente-servidor. En cada una de las máquinas Windows que se quiera gestionar a través de Opsi se instalará un agente (wInst - Windows Installer). A su vez, dentro del servidor se depositará el software que se quiera desplegar en dichas máquinas y éste recogerá de forma centralizada la información de todos sus nodos.

Cuando arranque el sistema Windows, el cliente se logueará en el módulo preLoginLoader del servidor, y examinará si existe alguna actualización disponible. En caso afirmativo, wInst comenzará de forma automática la tarea de instalación. El servidor proporcionará los scripts de instalación y los paquetes software a través de un espacio de almacenamiento compartido (Samba).

Antes de que los paquetes puedan ser instalados por wInst, deben de prepararse en formato Opsi. Comentar también que en los sistemas Windows puede instalarse el módulo loginblocker para prevenir que un usuario se loguee antes de que el proceso de instalación/actualización de wInst haya finalizado.

Opsi se encuentra disponible a través de un repositorio para sistemas basados en Debian y derivados, aunque también se puede utilizar directamente a través de una máquina virtual creada específicamente para VMware, o instalar directamente a través de una ISO, la cual está formada por una imagen de Debian con los paquetes de Opsi ya configurados.

Vamos a instalar y configurar la última versión estable de Opsi, la 3.4, en una Ubuntu Server 10.04 cuyo nombre será opsiserver.ubuntu.local. En primer lugar vamos a instalar una serie de paquetes requeridos por Opsi.

root@opsiserver:~# aptitude install wget lsof host python-mechanize p7zip-full cabextract openbsd-inetd

También será necesario instalar Samba.

root@opsiserver:~# aptitude install samba samba-common smbclient smbfs samba-doc

Opsi guarda por defecto todos los datos de los inventarios y del tema de licencias en ficheros de texto planos. Si queremos que en lugar de emplear dichos archivos se utilice una base de datos, instalaremos MySQL. Después de instalarlo, ejecutaremos la aplicación mysql_secure_installation con el objetivo de establecer el password para el usuario 'root', remover el usuario 'anonymous' y eliminar la base de datos test.

root@opsiserver:~# aptitude install mysql-server

root@opsiserver:~# mysql_secure_installation

Para instalar la parte servidora de Opsi vamos a tener que añadir la siguiente línea al fichero sources.list. Posteriormente instalaremos los paquetes opsi-atftpd, opsi-depotserver y opsi-configed.

root@opsiserver:~# cat /etc/apt/sources.list
...
deb http://download.uib.de/debian lenny opsi3.4

root@opsiserver:~# aptitude update

root@opsiserver:~# aptitude install opsi-atftpd opsi-depotserver opsi-configed

Durante la instalación de Opsi, el asistente nos hará una serie de preguntas de cara a la generación de un certificado electrónico. También nos solicitará la password para el usuario 'pcpatch'.

El siguiente paso que haremos será crear un usuario administrador (lo llamaremos opsi), el cual será dado de alta también para Samba.

root@opsiserver:~# useradd -m -s /bin/bash opsi

root@opsiserver:~# passwd opsi

root@opsiserver:~# smbpasswd -a opsi

root@opsiserver:~# adduser opsi opsiadmin

root@opsiserver:~# adduser opsi pcpatch

Si queremos que Opsi no actué como servidor DHCP, eliminaremos el servicio.

root@opsiserver:~# /etc/init.d/dhcp3-server stop

root@opsiserver:~# update-rc.d -f dhcp3-server remove

root@opsiserver:~# update-rc.d dhcp3-server stop 20 2 3 4 5 .

Por último, sólo nos quedará por configurar la base de datos en donde Opsi guardará el inventario de los nodos. Para ello ejecutaremos el script init-opsi-mysql-db.py.

También modificaremos dos variables dentro del fichero 30_vars.conf para indicar a Opsi que utilice MySQL para almacenar los datos del inventario hardware y software.

root@opsiserver:/usr/share/opsi# ./init-opsi-mysql-db.py

root@opsiserver:/etc/opsi/backendManager.d# cat 30_vars.conf
...
self.swinventBackend = BACKEND_MYSQL
self.hwinventBackend = BACKEND_MYSQL
self.licenseBackend = BACKEND_MYSQL
...

root@opsiserver:~# service opsiconfd restart

May 24, 2010

CentOS 5.5 disponible!

Ya se encuentra disponible desde hace más de una semana en los repositorios de CentOS, su nueva versión 5.5.

CentOS (Community ENTerprise Operating System) es una distribución de Linux que viene a ser un clon binario de RHEL (Red Hat Enterprise Linux), compilada y generada a partir del código fuente que Red Hat libera, y destinada principalmente al ámbito empresarial o corporativo, ya que es un sistema operativo especialmente diseñado para realizar tareas de servidor.

Prácticamente nos encontramos ante una versión de mantenimiento, donde se han presentado muy pocas novedades: soporte para nuevas plataformas hardware, numerosas mejoras en cuanto a virtualización KVM, interoperabilidad con Microsoft Windows 7 y ampliación en la integración con el Directorio Activo.

En el primer enlace podemos ver las características de la versión y en el segundo, sus detalles técnicos.

Esta última versión, que viene a suceder a su predecesora (CentOS 5.4), cerrará el ciclo completo de la rama 5, la cual seguirá teniendo soporte técnico hasta el año 2014. Tendremos que esperar hasta finales de 2010 a que Red Hat presente su nuevo RHEL 6 para ver la nueva versión de CentOS 6.

May 18, 2010

El protocolo SNMP

SNMP (Simple Network Management Protocol) es un protocolo perteneciente al nivel de aplicación y utilizado para el intercambio de información por parte de los dispositivos de una red (ordenadores, routers, switches, etc.). Actualmente coexisten tres versiones: 1, 2 y 3.

La arquitectura SNMP está formada por un agente que se instala en la máquina que se desea monitorizar y un sistema de administración encargado de interactuar con los agentes.

La principal función del agente es la de recopilar cierta información (uso de CPU, estado de la memoria, interfaces de red, etc.) del huesped y proporcionársela al sistema de administración cuando éste la solicite. También el agente puede ser configurado para que envíe mensajes (traps) cuando se cumpla algún tipo de evento previamente establecido (por ejemplo que quede menos de un 10% de espacio en disco).

A su vez, el sistema de administración se va a encargar de recibir dichos traps y de solicitar información a los agentes. Esa información se organiza de manera jerárquica en una estructura de datos en forma de árbol conocida como MIB (Management Information Base) o Base de Información Gestionada.

En la siguiente figura puede observarse la estructura de la MIB, la cual está formada por diferentes elementos conocidos como objetos o OIDs, los cuales son asignados por diferentes organizaciones.



Existe un OID denominado enterprise (1.3.6.1.4.1) del cual cuelgan por ejemplo los OIDs de diferentes compañías: Oracle (111), Cisco (9), VMware (6876), etc.

A su vez, la MIB-II (base de datos común para la gestión de equipos en Internet) cuelga del OID 1.3.6.1.2.1. De esta forma, si queremos obtener el nombre de la máquina, tendremos que acceder al OID SNMPv2-MIB::sysName.0, que se corresponderá con 1.3.6.1.2.1.1.5.0.

Existen distintos tipos de mensajes SNMP (por defecto se utiliza el puerto UDP 161). Los más importantes son los siguientes:
  • GetRequest: se solicita al agente el valor almacenado en un OID.

  • GetNextRequest: se solicita al agente el valor del siguiente OID con respecto al que se pidió con anterioridad (esta clase de mensajes se utiliza para recorrer el árbol).

  • SetRequest: se solicita al agente que modifique el valor de un cierto OID.

  • Trap: mensaje generado por el agente para informar sobre una determinada situación.

May 12, 2010

Kubuntu 10.04 Lucid Lynx

El Jueves 29 de Abril de 2010 fue liberada la versión 10.04 de Ubuntu/Kubuntu, más conocida como Lucid Lynx.



Se trata de una distribución LTS (Long Term Support), es decir,tiene garantizados tres años de soporte con sus correspondientes actualizaciones de fallos de seguridad y corrección de errores.

Llevo ya más de una semana probando esta nueva versión. No hice una instalación limpia, sino que actualicé directamente desde la anterior versión, Kubuntu 9.10 Karmic Koala, y la verdad es que va como la seda.

Las primeras sensaciones que tienes es que va mucho más ligera que la versión anterior, ya que en el ordenador de mi trabajo para Karmic Koala tenía desactivado los efectos gráficos y ahora para Lucid Lynk los he vuelto a activar, y se aprecia claramente que los movimientos son mucho más suaves.

Echando un vistazo al consumo de los recursos del sistema puede verse que son muy bajos. El ordenador de mi trabajo tiene 1 GB de memoria RAM, y en la imagen que muestro a continuación puede verse que el sistema está empleando alrededor de 900 MB. Pero el dato más importante es que de esos 900 MB, el sistema realmente está utilizando algo menos de 500 MB, ya que como se aprecia en la captura, hay 456 MB cacheados.



Tampoco el sistema me está swapeando, y eso es muy bueno, ya que hace que vaya mucho más rápido (no es lo mismo acceder a disco que a memoria...). Esto último es debido a una recomendación que siempre digo, y que consiste en reducir el valor del parámetro swappiness.

javi@jandres:~$ cat /proc/sys/vm/swappiness
5

Entre las principales novedades que presenta esta versión se encuentra la actualización del kernel a la versión 2.6.32 y de KDE al 4.4.2. También hay que destacar la integración que se ha hecho de Firefox con KDE.



Por último, decir también que se han actualizado la mayoría de las aplicaciones (Amarok 2.3.0, Firefox 3.6.3, K3b 1.91.0, OpenOffice 3.2.0, etc.) así como la incorporación de nuevos plasmoides.


May 3, 2010

Monitorización remota de logs con Zabbix

Otra de las muchas posibilidades que nos ofrece Zabbix de cara a la monitorización remota de una máquina, es la posibilidad de controlar también los logs (o cualquier tipo de fichero de texto) de esta última.

El único requerimiento es tener un agente de Zabbix instalado y funcionando en modo activo (comportamiento por defecto del cliente) en el equipo que se desee monitorizar. En el modo pasivo, el cliente lo único que hace es escuchar las peticiones del servidor. Por lo tanto, si queremos que el agente monitorice un log e informe al servidor cuando haya encontrado alguna determinada cadena de texto, el único requisito consistirá en estar en modo activo.

Para desactivar el modo activo (pasar a modo pasivo), lo único que hay que hacer es añadir la siguiente línea al fichero de configuración del cliente:

[root@server ~]# cat /etc/zabbix/zabbix_agentd.conf
...
DisableActive=1

Otra cosa que también conviene tener en cuenta para que esto funcione correctamente es que el nombre definido en el parámetro Hostname (dentro del fichero de configuración del cliente), debe coincidir con el nombre dado al equipo a la hora de configurarlo desde el frontal web de Zabbix (campo Name de la pantalla CONFIGURATION OF HOSTS).

[root@server ~]# cat /etc/zabbix/zabbix_agentd.conf
...
Hostname=server

A continuación vamos a mostrar un ejemplo de monitorización remota de un fichero: vamos a controlar el archivo /var/log/messages del propio servidor de Zabbix, con el objetivo de que nos envíe las líneas de texto que contengan la palabra "error".

Recordar que tendremos que asegurarnos que el usuario zabbix puede leer ese fichero...

[root@server ~]# ls -l /var/log/messages
-rw----r-- 1 root root 160 abr 22 16:48 /var/log/messages

Lo primero que vamos a hacer es crear un item de tipo Zabbix agent (active), el cual retornará un valor de tipo Log. La frecuencia de muestreo (Update interval) la estableceremos en 30 sg.



A continuación vamos a definir un trigger asociado a este item, el cual se encargará de generar una alarma de severidad alta en caso de recibir una línea de error correspondiente al fichero messages.

Dentro del trigger utilizaremos la función nodata(sec), la cual recibirá como argumento un número entero que se corresponderá con un valor en segundos, y donde devolverá un '1' en caso de no haber recibido ninguna línea monitorizada (en nuestro caso, una línea que contenga la palabra "error") durante los últimos segundos definidos en el parámetro sec, o un '0' en caso contrario.

Por lo tanto, nuestro trigger generará una alarma si durante los últimos 30 últimos segundos le ha llegado alguna línea de error.



Otra posibilidad hubiese consistido en enviar todo el fichero messages desde el cliente al servidor. Para ello tendríamos que haber empleado un item con la siguiente clave: log["/var/log/messages"].

La única diferencia con respecto al item anterior es que ahora no le estamos indicando al cliente de Zabbix que envíe al servidor sólo las líneas que contengan la palabra "error", por lo tanto el cliente enviará todo el contenido del fichero a medida que se vaya escribiendo sobre él.

Para esta segunda posibilidad tendríamos que haber empleado en vez de la función nodata, la función regexp, pasándole como argumento la cadena de texto "error". De esta forma generaríamos una alarma cuando dentro de todo el contenido del fichero enviado, se detectara exclusivamente la palabra "error". La expresión del trigger hubiese quedado de la siguiente forma: {server:log["/var/log/messages","error"].regexp(error)}=1.

Este segundo métodos tiene un inconveniente muy grave: estamos enviando todo el fichero a través de la red, con lo que la estamos sobrecargando mandando información no necesaria.

Además para este segundo caso, tendríamos que seleccionar la opción Normal + Multiple TRUE events dentro del campo Event generation, con el objetivo de permitir que se pudieran lanzar múltiples alarmas para el mismo trigger, ya que por ejemplo se podría generar una alarma, pasar una hora y que no se recibiera ningún tipo de información a través del item, y que al cabo de esa hora volviese a llegar otra cadena de texto que se correspondiera con el error. Para este último caso no se generaría la alarma al tener seleccionada una generación de eventos de tipo Normal.

Para el primer ejemplo nos vale con la opción Normal, ya que aunque se generase una alarma, al cabo de 30 sg desaparecería, con lo que a partir de ese tiempo podría llegar otra alarma de la misma clase (cadena "error").

Y ya por último, decir también que si queremos monitorizar un fichero cuyo nombre varía (por ejemplo un log que rota de nombre), podemos emplear en lugar de la función log, la función logrt, la cual sí que acepta la inclusión de expresiones regulares dentro de su primer argumento (nombre del fichero).

Si tuviéramos por ejemplo un fichero (dentro del directorio /var/log) que rotase de la siguiente forma: file_001.log, file_002.log, ..., la clave del item quedaría de la siguiente forma: logrt["/var/log/file_.*.log","error"].