Puppet(XI): Reportes

Hasta ahora hemos visto como  configurar y utilizar Puppet, a continuación vamos a ver como obtener información sobre lo que Puppet está haciendo.

Puppet incorpora varias opciones para los reportes. Yo voy a utilizar la opción de generar gráficas con la herramienta RRDTool y luego dejarlas accesibles vía web. Para ello se han instalado los parquetes rrdtool y ruby-RRDtool.

# yum install rrdtool ruby-RRDtool

Una vez hecho esto añadimos al fichero de configuración /etc/puppet/puppet.conf del servidor Puppet las siguientes líneas:

[puppetmasterd]
reports = rrdgraph

Ahora en la configuración de los clientes /etc/sysconfig/puppet añadimos la siguiente opción:

# Activar reportes
PUPPET_EXTRA_OPTS=--report

Este cambio lo hacemos en este fichero y no en /etc/puppuet/puppet.conf para evitar el problema que sucede con el servidor Puppet si a la vez es un cliente como sucede en nuestro caso.

Con estos cambios se nos generan unas gráficas RRD en el directorio /var/lib/puppet/rrd del servidor Puppet. Para poder visualizarlas via web se han añadido las siguientes líneas a la configuración del Apache del servidor Puppet /etc/httpd/conf/httpd.conf):

<Directory "/var/lib/puppet/rrd">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<VirtualHost *:80>
ServerAdmin webmaster@ehu.es
DocumentRoot /var/www/html
ServerName servidorpuppet.ehu.es
ErrorLog logs/error_log
CustomLog logs/access_log combined
Alias /puppet /var/lib/puppet/rrd
</VirtualHost>

Para acceder a ellas simplemente nos hemos de conectar a la siguiente dirección: http://servidorpuppet/puppet

Este mecanismo de reporte es muy limitado. Para mejorar estos reportes existen otras herramientas como Puppet-DashBoard y The Foreman.

PUPPET-DASHBOARD

(http://www.puppetlabs.com/puppet/related-projects/dashboard/)

Herramienta GUI para ver que está haciendo Puppet. Es desarrollado por el mismo equipo que mantiene Puppet. Es una herramienta poco madura, de hecho la versión 1.0 acaba de salir hace pocas semanas.

El resumen de mi primera impresión es el siguiente:

• Documentación prácticamente inexistente
• Va muy lenta (en este caso habría que tener en cuenta que el servidor sobre el que la tenía instalada tenía unos recursos bastante limitados)
• Escasez de opciones de configuración
• Permite visualización de todo en acceso anónimo. Permite el registro de usuarios aunque no he encontrado diferencias entre los usuarios registrados y los anónimos.

Instalación:

# yum install rubygems rubygem-rake ruby-mysql
# rpm -Uvh http://yum.puppetlabs.com/base/puppet-dashboard-1.0.0-4.noarch.rpm

Nos creamos una BBDD en el servidor MySQL. Editamos el fichero /usr/share/puppet-dashboard/config/database.yml (usamos el database.yml.example como ejemplo y hemos de configurar la sección Development)

# cd /usr/share/puppet-dashboard

# rake install

(nos crea las tablas de la BBDD)

# service puppet-dashboard start

(nos lanza el demonio en el puerto 3000)

Nos conectamos a http://servidorpuppet.ehu.es:3000 y ya vemos el reporte de ejemplo.

FOREMAN

(http://theforeman.org)
Otro interfaz para visualizar los reportes de Puppet con mayor funcionalidad. Mi primera impresión ha sido la siguiente:

• Va muy lenta (en este caso habría que tener en cuenta que el servidor sobre el que la tenía instalada tenía unos recursos bastante limitados)
• Más documentación que en Puppet-DashBoard
• Validación contra LDAP (aunque no la he conseguido hacer funcionar)
• Permite enviar reportes por email

Instalación:

# yum install rubygems rubygem-rake rubygem-sqlite3-ruby

Descargar los siguientes paquetes e instalarlos:
http://theforeman.org/repo/el5/noarch/foreman-0.1.4.3.noarch.rpm
http://theforeman.org/repo/el5/noarch/rubygem-rack-1.0.1-1.noarch.rpm

# service foreman restart

Conectarse a http://servidorpuppet.ehu.es:3000

La configuración se hace a través del propio interfaz web o de los ficheros
del directorio /usr/share/foreman/config/.

… Y de momento esto es todo …

DAVID FERNANDEZ ACIN Linux gestión configuración, puppet

Puppet(X): Mejora del rendimiento de Puppet con Mongrel

Al ir añadiendo clientes a nuestro servidor Puppet nos podemos encontrar que de vez en cuando se producen errores en los clientes a la hora de obtener del servidor los ficheros que tienen que ser gestionados.

Entre otras causas esto puede ser debido a que Puppet viene de serie con un servidor web (Webrick) que no está pensado para un gran número de clientes simultáneos. Desde la propia web de Puppet se nos comenta esta situación y vienen instrucciones de como sustituir este servidor web por otro como Mongrel que es capaz de atender más peticiones simultáneas.

En la dirección http://projects.reductivelabs.com/projects/puppet/wiki/Using_Mongrel_On_Enterprise_Linux es donde podemos encontrar la información de como configurar Puppet para usar Mongrel.

Lo que vamos a configurar es 4 instancias del servidor Mongrel y delante de ellas un Apache 2.2 con el mod_proxy_balancer repartiendo las peticiones de los clientes entre estas 4 instancias.

Teniendo configurado el repositorio EPEL, se han seguido los siguientes pasos para la instalación de Puppet con Mongrel:

# yum install rubygem-mongrel  mod_ssl

# service puppetmaster stop

Editamos el fichero /etc/sysconfig/puppetmaster y descomentamos la línea:

PUPPETMASTER_PORTS=(  18140 18141 18142 18143 )

# service puppetmaster  start

Ahora configuramos el Apache y para ello nos creamos un nuevo fichero /etc/httpd/conf.d/puppet.conf con el siguiente contenido:

Listen 8140

<Proxy  balancer://puppetmaster>
 BalancerMember  http://127.0.0.1:18140
 BalancerMember http://127.0.0.1:18141
 BalancerMember http://127.0.0.1:18142
 BalancerMember  http://127.0.0.1:18143
</Proxy>

<VirtualHost  *:8140>
 SSLEngine On
 SSLCipherSuite  SSLv2:-LOW:-EXPORT:RC4+RSA
 SSLCertificateFile  /var/lib/puppet/ssl/certs/puppetserver.pem
 SSLCertificateKeyFile  /var/lib/puppet/ssl/private_keys/puppetserver.pem
 SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
 SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
 SSLVerifyClient optional
 SSLVerifyDepth 1
 SSLOptions +StdEnvVars

 RequestHeader set X-Client-DN  %{SSL_CLIENT_S_DN}e
 RequestHeader set X-Client-Verify  %{SSL_CLIENT_VERIFY}e

 <Location />
 SetHandler balancer-manager
 Order allow,deny
 Allow from all
 </Location>

 ProxyPass /  balancer://puppetmaster/
 ProxyPassReverse /  balancer://puppetmaster/
 ProxyPreserveHost On

 ErrorLog /var/log/httpd/balancer_error_log
 CustomLog  /var/log/httpd/balancer_access_log combined
 CustomLog  /var/log/httpd/balancer_ssl_requests "%t %h %{SSL_PROTOCOL}x  %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>

Si tenemos activado SELinux, hemos de configurarlo para permitir que está infraestructura funcione. Para ello ejecutamos estos dos comandos:

# semanage port -a -t http_port_t -p tcp 8140

# setsebool -P httpd_can_network_connect = 1

Este último comando no se referencia en las instrucciones de la web de Puppet, pero en mi caso ha sido necesario para que Puppet funcionara.

Reiniciamos Apache y ya está:

# service httpd restart

… Continuará …

DAVID FERNANDEZ ACIN Linux gestión configuración, mongrel, puppet

Puppet(IX): Integración con un sistema de control de versiones

Puppet es una herramienta que nos permite gestionar los ficheros de configuración de nuestros equipos. Sin embargo, Puppet no nos proporciona un mecanismo automático para llevar un control de versiones de los ficheros que gestionemos.

Para este tipo de labores los sistemas de control de versiones son herramientas muy interesantes. Por lo tanto, vamos a unir Puppet con Subversion para gestionar mejor nuestros equipos.

Aunque he elegido la herramienta Subversion, debería ser sencillo utilizar otras herramientas de control de versiones como CVS o similares.

En primer lugar nos creamos un repostorio para Puppet en un servidor Subversion. Dentro de este repositorio nos creamos dos carpetas:

• config: aquí se guardará la parte relativa a la configuración de puppet (definición de clientes, ficheros a gestionar,….)
• files: aquí es donde se guardarán los ficheros que luego se enviarán a los clientes.

La carpeta config la sincronizaremos con el directorio /etc/puppet del  servidor Puppet mediante un comando similar al siguiente:

/usr/bin/svn checkout --username $SVNUSER --password $SVNPASSWORD svn://subversionserver/conf-dist/config/puppet/ /etc/puppet/

La carpeta files la sincronizaremos contra el directorio /var/lib/puppet/files/ del servidor Puppet:

/usr/bin/svn checkout --username $SVNUSER --password $SVNPASSWORD  svn://subversionserver/conf-dist/files/ /var/lib/puppet/files/

Es importante que nos aseguremos que los ficheros que sincronicemos quedarán con los permisos adecuados para que el servidor Puppet los pueda leer. En el caso de Red Hat lo más sencillo es que estos comandos de sincronización los ejecutemos con el usuario puppet ya que es el usuario con el que se ejecuta el servidor puppet.

Para que esta sincronización sea automática podemos añadir una tarea al cron del servidor Puppet que ejecute estos comandos. Yo considero que un intervalo de 5 minutos es un tiempo adecuado para la ejecución de esta tarea, aunque he encontrado referencias de gente que lo ejecuta cada minuto. Esta tarea la ejecuto mediante el siguiente script:

[root@subversionserver ~]# cat /usr/local/bin/sync-puppet-svn.sh
#!/bin/bash
SVNUSER="puppet"
SVNPASSWORD="********"
# Comprobamos que el usuario con el que ejecutamos el script sea el deseado
RUNUSER="puppet"
ID=/usr/bin/id
if [[ `$ID -u` -ne `$ID -u $RUNUSER` ]]
then
 echo "No me estoy ejecutando con el usuario $RUNUSER. Debo ejecutarme con ese usuario"
else

 /usr/bin/svn checkout --username $SVNUSER --password $SVNPASSWORD svn://subversionserver/conf-dist/files/ /var/lib/puppet/files/
 /usr/bin/svn checkout --username $SVNUSER --password $SVNPASSWORD svn://subversionserver/conf-dist/config/puppet/ /etc/puppet/
fi

Esta tarea la ejecutamos en el cron añadiendo la siguiente entrada al crontab:

# Sincronizacion ficheros de datos PUPPET
*/5 * * * * /usr/local/bin/sync-puppet-svn.sh >/dev/null 2>&1

… Continuará …

DAVID FERNANDEZ ACIN Linux gestión configuración, puppet

Puppet (VIII): Configuración de los clientes a gestionar (y V)

4. Gestión de paquetes

Entre las capacidades de Puppet se incluye la posibilidad de gestionar los paquetes instalados en los clientes. Desde Puppet podemos instalar paquetes de los repositorios configurados en los clientes. Puppet se encarga de utilizar la herramienta (p.e. yum o up2date)  adecuada para cada cliente. Para gestionar los paquetes usaremos el elemento package.

 package {  "httpd":   
 ensure => installed,
 }

En el ejemplo anterior nos aseguraremos que el paquete httpd sea instalado en nuestros clientes.

5. Cron

Mediante Puppet podemos añadir tareas al cron de nuestros clientes. Podemos gestionar que comando ejecutar, cuando y con qué usuario. Lo haremos mediante el elemento cron.

 cron { tarea-cron:
 hour  => 0,
 minute => 0,
 user => root,
 command => "/usr/local/bin/tarea-cron.sh",
 }

En la primera línea “tarea-cron” metemos un texto descriptivo que nos servirá para identificar la tarea en los ficheros de cron. Con los parámetros hour, minute, month,  monthday, weekday especificaremos el momento de ejecución de la tarea. user nos permitirá indicar el usuario con el que se ejecutará la tarea y command indica el comando para ejecutar la tarea (si queremos redirigir la salida, lo haremos en el propio comando). Puppet añadirá una línea al crontab del usuario (/var/spool/cron/user).

… Continuará …

DAVID FERNANDEZ ACIN Linux gestión configuración, puppet

Puppet(VII): Configuración de los clientes a gestionar (IV)

Con la herramienta Puppet se instala la utilidad facter que es capaz de obtener información sobre el cliente. Este utilidad si la ejecutamos desde la línea de comando nos devuelve información sobre nuestro equipo:

# facter
architecture => x86_64
...
operatingsystem => RedHat
operatingsystemrelease => 5.5
...
swapfree => 4.00 GB
swapsize => 4.00 GB
timezone => CEST
uniqueid => 007f0100
uptime => 7 days
uptime_days => 7
uptime_hours => 180
uptime_seconds => 650871
virtual => physical

La información que genera facter la tenemos disponible en Puppet en la forma de variables que podemos consultar y utilizar para aplicar configuración según los valores de estas variables. Por ejemplo, la última línea devuelta por facter ha sido “operatingsystemrelease => 5.5″, esto implica que en Puppet tendremos una variable operatingsystemrelease con valor “5.5”. Esta variable nos permitirá distinguir la versión de nuestro sistema operativo. Esto puede ser muy útil en casos donde un fichero de configuración dependa de la versión del sistema operativo y no de la función del servidor (por ejemplo el servicio ntpd).

A continuación vamos a ver un ejemplo de como aplicar un fichero de configuración en función de la versión del sistema operativo. Para ello usaremos el elemento class de Puppet. El elemento class permite agrupar la definición de otros elementos (file, service,…) que luego serán incorporados en la definición de nodos mediante la directiva include.

# Configuración NTPD

class ntpdrh4 {
    file { "/etc/ntp.conf":
        owner => "root",
        group => "root",
        mode => 644,
        source => "puppet:///redhat4/etc/ntp.conf",
        notify => Service["ntpd"],
    }
}

class ntpdrh5 {
    file { "/etc/ntp.conf":
        owner => "root",
        group => "root",
        mode => 644,
        source => "puppet:///redhat5/etc/ntp.conf",
        notify => Service["ntpd"],
    }
}

class ntpd {
    service { "ntpd":
        enable => "true",
        ensure => "running",
        hasrestart => "true",
        hasstatus => "true",
    }
    if (operatingsystemrelease < 5) {
        include ntpdrh4
    }
    if (operatingsystemrelease >= 5) {
        include ntpdrh5
    }       
}

… Continuará …

DAVID FERNANDEZ ACIN Linux gestión configuración, puppet

Puppet(VI): Configuración de los clientes a gestionar (III)

En la sección anterior vimos como gestionar ficheros y directorios de nuestros clientes. En esta vamos a ver como gestionar otros elementos.

3. Servicios

Mediante Puppet podemos gestionar servicios. Podemos hacer que estén configurados para arrancar de forma automática con el servidor, asegurarnos que estén en ejecución y reiniciarlos cuando se cambia uno de sus ficheros de configuración.

Para gestionar servicios tenemos el elemento service. Un ejemplo de utilización de este elemento es la siguiente:

service { "miservicio":
 pattern => "nombreservicio",
 ensure => "running",
 start => "/etc/init.d/scriptmiservicio start",
 stop => "/etc/init.d/scriptmiservicio stop",
 hasstatus => "true",
 hasrestart => "true",
 }

El parámetro pattern lo utilizaremos en el caso de que el nombre del servicio no coincida con el proceso en ejecución correspondiente. Puppet lo utilizará para determinar si el servicio está en ejecución en caso de que el servicio no soporte la opción status.

El parámetro ensure verifica que el servicio se encuentra en ejecución. Si no lo estuviera lo intenta arrancar.

El parámetro enable sirve para garantizar que el servicio arrancará con el servidor.

Los parámetros start y stop los definiremos en el caso de que el servicio no utilice un script de arranque con el mismo nombre que el servicio.

Los parámetros hasstatus y hasrestart le indican a Puppet si el script de arranque del servicio soporta las opciones de status (en caso de no soportar esta opción Puppet determinará si el proceso está en ejecución revisando la tabla de procesos) y restart (si esta opción no está disponible, Puppet ejecutará un stop y start para reiniciar el servicio.

Además de controlar servicios, una de las opciones más interesantes de Puppet es su capacidad para reiniciar un servicio si cambia la configuración del mismo. Para ello en los elementos ficheros añadiremos el parámetro notify.

file { “/etc/configmiservicio”:

source => “puppet://servidorpuppet/carpetagrupo/etc/configmiservicio”,
owner => “user”,
group => “group”,
mode => 644,
notify => Service[“miservicio”],
}

… Continuará …

DAVID FERNANDEZ ACIN Linux gestión configuración, puppet

Puppet(V): Configuración de los clientes a gestionar (II)

En la entrada anterior empezamos a ver como definir nuestros clientes en Puppet. Una vez hecho, ahora nos toca definir los elementos que queremos gestionar.

1. Ficheros

El primer elemento que vamos a gestionar es un fichero. Mediante este elemento vamos a poder modificar el contenido de un fichero, sus permisos, su propietario,…

Para gestionar los ficheros usaremos el elemento file. Un ejemplo de la utilización de este elemento es la siguiente:

file { "/etc/mifichero":
 source =>  "puppet://servidorpuppet/carpetagrupo/etc/mifichero",
 owner =>  "root",
 group => "root",
 mode => 700,
 }

La directiva source nos permite especificar la ubicación desde la que obtendremos el fichero.

• servidorpuppet es el nombre del servidor puppet del que obtener el fichero. En caso de no especificarse se considera que es el mismo que el servidor del que se ha obtenido la configuración.
• carpetagrupo es el repositorio dentro del servidor del que obtendremos el fichero. Estos repositorios se definen en el fichero fileserver.conf del servidor Puppet.

Las directivas owner, group y mode nos permiten definir el propietario, grupo y permisos a asignar al fichero. Por ejemplo, podríamos utilizar estas directivas para asegurarnos que determinado fichero tiene los permisos que deseamos aunque algún otro proceso o usuario los haya cambiado.

2. Directorios

Una extensión del elemento fichero nos permite gestionar un directorio y todos los ficheros contenidos en él.

file { "/etc/midirectorio":
 source =>  "puppet:///carpetagrupo/etc/midirectorio",
 owner =>  "root",
 group => "root",
 recurse => "true",
 purge => "true",
 force => "true",
 }

Para gestionar un directorio en lugar de un fichero individual, simplemente añadiremos la directiva recurse con valor true. Además también es interesante usar las directivas purge (hace que se borren en el destino todos los ficheros que se hayan borrado del origen) y force (hace que se borren los directorios que si no quedarían vacíos).

… Continuará …

DAVID FERNANDEZ ACIN Linux gestión configuración, puppet

Puppet(IV): Configuración de los clientes a gestionar

Una vez que se ha visto como hacer la instalación del servidor y del cliente Puppet llega el momento de ver como gestionar los clientes. Esta configuración se guardará dentro del directorio /etc/pupppet/manifests del servidor Puppet. Dentro de este directorio tendremos un fichero site.pp que será el fichero inicialmente leído por Puppet.

Inclusión de ficheros de configuración adicionales

Dentro del fichero site.pp podemos añadir la directiva import para permitir incluir otros ficheros de configuración. En esta directiva podemos especificar el nombre completo del fichero o un * para que se incluyan todos los ficheros de un directorio (estos ficheros tienen que tener extensión .pp)

import "nodes.pp"
import "classes/*"

Esta directiva nos permite dividir nuestra configuración en varios ficheros, lo que es muy útil en caso de tener que gestionar varios clientes.

Definición de nodos

Los primeros elementos que definiremos serán los nodos. Con los nodos nos podemos referir a servidores concretos:

node "micliente.midominio.com" {}

o a grupos de servidores:

node grupoclientes1 {}

Una característica muy importante de Puppet es la herencia. Esta característica nos permite que un nodo incorpore dentro de él reglas definidas en otro nodo. La herencia la definiremos de la siguiente forma:

node "micliente.midominio.com" inherits grupoclientes1 {}

De momento, Puppet no soporta la herencia múltiple.

Por último podemos definir un nodo especial default que se aplicará a todos los clientes para los que no se haya definido un nodo más concreto.

node default {}

… Continuará …

DAVID FERNANDEZ ACIN Linux gestión configuración, puppet

Puppet(III): Instalación del cliente

La instalación del cliente la hacemos instalando los paquetes puppet y ruby-rdoc (no existe para RH4) del repositorio EPEL:

# yum install puppet ruby-rdoc (RH5)
# up2date –i puppet (RH4)

Una vez instalado ejecutamos:

#  puppetd -o --server=puppetserver.midominio.com

Con este comando nos conectamos al servidor, le hacemos una petición y finalizamos la ejecución. Ahora en el fichero /var/log/messages del servidor deberíamos ver una línea del estilo:

puppetmasterd[6729]:  *******.midominio.com has a waiting certificate request

Puppet se comunica mediante conexiones SSL con certificados de cliente. Para que la conexión funcione es necesario que la CA que incorpora el servidor de Puppet firme el certificado emitido por el  cliente. Para hacer esto ejecutamos los siguientes comandos:

# puppetca --list
# puppetca --sign *******.midominio.com

Una vez hecho esto, volvemos a ejecutar en el cliente el comando anterior y ya nos debería hacer la sincronización inicial:

#  puppetd -o --server=puppetserver.midominio.com

Para que el servidor se conecte automáticamente a nuestro servidor Puppet modificamos el fichero /etc/sysconfig/puppet y configuramos la variable PUPPET_SERVER.

PUPPET_SERVER=puppetserver.midominio.com

Ahora ya podemos proceder a activar el servicio con:

# chkconfig puppet  on

Para arrancarlo tenemos el siguiente comando:

# service puppet start

… continuará…

DAVID FERNANDEZ ACIN Linux gestión configuración, puppet, ruby

Puppet (I): Introducción

Puppet es un sistema open source para automatizar las tareas administrativas de servidores Unix. Nos permite gestionarlos de forma remota y en el caso de tener que administrar múltiples servidores permite mantener una configuración uniforme de los mismos de forma sencilla.

Entre otras cosas desde Puppet podemos:

• Distribuir ficheros de configuración almacenados en un repositorio centralizado
• Instalar paquetes de software en los servidores
• Gestionar servicios (arrancarlos, pararlos, reiniciarlos,…)
• Gestionar el cron
• …

Puppet está escrito en Ruby y está disponible para sistemas operativos tipo Unix, aunque parece que el soporte para Windows estará disponible a lo largo de este año.

No es la única herramienta de este estilo. Existen varias alternativas (CFEngine, Spacewalk,…), pero desde mi punto de vista es una herramienta con la que es posible obtener resultados de forma rápida y eso en mi caso era un factor muy importante.

En mi caso me he centrado en la administración de sistemas Red Hat Linux 4 y 5 ya que son los sistemas que administro.

… continuará …

DAVID FERNANDEZ ACIN Linux gestión configuración, puppet, ruby