viernes, 21 de mayo de 2010

Instalación de Puppet y configuración de un servidor maestro y un cliente en Ubuntu Server 10.04 LTS

Puppet es un automatizador de tareas de configuración de sistemas Unix, GNU\Linux, BSD, MacOS... que todavía no soporta Ms Windows. Tiene arquitectura cliente-servidor y se basa en ruby.

http://projects.puppetlabs.com/

Vamos a ver como instalar Puppet en un Ubuntu Server.

Prerrequisitos

Al estar basado en Ruby necesitamos instalar tanto Ruby como las librerías necesarias.

$ sudo aptitude install ruby libruby libopenssl-ruby libxmlrpc-ruby facter rdoc

Esto instalará la versión 1.8.7 de ruby.

Instalaremos Facter que es una aplicación ruby multiplataforma que sirve para recopilar sucesos o propiedades de otro sistema, como la dirección IP, la versión del Sistema Operativo, MACs, claves SSH... Version 1.5.6 (en Debian habría que instalar lsb-release también)

Rdoc sirve para que aplicaciones como facter muestren ayuda al poner "facter --help", por ejemplo. Si no lo instalamos no habrá ayuda de facter o puppet.

Estos prerrequisitos deben instalarse en todos los nodos que vayamos a usar, tanto en el nodo maestro que tendrá el servidor Puppet como en los nodos clientes que solo tendrán el cliente de Puppet.

Instalación de Puppet

Una vez instalados los prerrequisitos instalamos Puppet. Yo estoy instalando, hasta ahora, en el nodo que hará de Puppet server, pero también instalaré en este servidor el Puppet client para que se auto configure. Como usaré vim, también instalo el plugin para colorear la sintaxis de los manifiestos de puppet.

$ sudo aptitude install puppet vim-puppet puppetmaster
$ id puppet
uid=104(puppet) gid=112(puppet) grupos=112(puppet)

Con id vemos si el grupo y usuario de puppet se han creado correctamente.

Configuración del maestro

Para iniciar el daemon de servidor de Puppet, puppetmasterd, debemos tener un manifiesto (manifest). Un manifiesto contiene las directivas de configuración de un nodo (un ordenador con puppet) Es un simple archivo de texto.

El manifiesto central requerido por Puppet se llama, por defecto, /etc/puppet/manifests/site.pp. Para arrancar puppetmasterd debe existir este manifiesto central. No existe por defecto así que hay que crearlo. En Ubuntu Server 10.04 LTS, el manifiesto central no existe pero el servicio puppetmasterd se arranca por defecto correctamente al instalarlo, en otros sistemas puede dar error al iniciar puppetmasterd ya que falta.

$ touch /tmp/archivodeprueba
$ ls -lah /tmp/archivodeprueba 
-rw-r--r-- 1 administrador administrador 0 2010-05-21 11:46 /tmp/archivodeprueba

$ sudo vim /etc/puppet/manifests/site.pp

# Manifiesto Central de Puppet

# Prueba de cambio de permisos de un fichero
# llamado archivodeprueba en /tmp
# Nos aseguramos de que exista (ensure), si no se creará
# cambiamos el propietario, el grupo y los permisos
# Hemos usado el recurso file dentro de una clase
# llamada nombreclaseprueba que hemos creado.

class nombreclaseprueba {
        file { "/tmp/archivodeprueba":
                ensure => present,
                owner => "root",
                group => "games",
                mode => 777
        }
}

# Nodos donde se va a ejecutar la clase. El propio servidor
# y un cliente portatil con fedora

node ubults00 {
        include nombreclaseprueba
}

node portfed {
        include nombreclaseprueba
}

Hemos creado un archivo de prueba y hemos editado site.pp. El nodo servidor es ubults00. Por supuesto hay más recursos para manejar otras cosas a parte de archivos (file) como servicios o paquetes, entre otros, es decir, hay diferentes "tipos" de recurso.

Los recursos tiene un título (en este caso "/tmp/archivodeprueba" y unos atributos que podemos usar (owner, group... entre otros para el tipo de recurso file) Estos recursos podemos agruparlos en "colecciones" que se llaman clases. Por ejemplo, podríamos crear una clase llamada servidor_web y agrupar dentro todos los tipos de recurso necesarios para configurar un servidor web en un nodo.

Lo normal es crear un manifiesto por nodo y no meter todo en site.pp. Pero esto es para probar.

$ sudo service postmaster restart
 * Restarting puppet configuration management tool master server                   [ OK ]

Esto reiniciará el demonio postmasterd. Usa upstart pero también se puede hacer con /etc/init.d/postmaster. Escucha por defecto en el puerto 8140.

$ netstat -tna
Conexiones activas de Internet (servidores y establecidos)
Protocolo Recv-Q Send-Q Dirección Local Dirección Externa Estado      
tcp        0      0 0.0.0.0:8140            0.0.0.0:*               ESCUCHAR
...

Configuración del cliente ubuntu, válido para el propio servidor

Una vez instalados los prerrequisitos y puppet (no puppetmaster, solo en el servidor) veremos que no se inicia por defecto el cliente puppetd. Esto es porque debemos activarlo configurando lo siguiente.

$ sudo vim /etc/default/puppet

# Para poder iniciar el daemon del cliente puppet lo ponemos a yes.
START=yes

# Opciones del daemon cliente
# Hemos puesto el nombre dns completo que aparece en /etc/hosts
DAEMON_OPTS="--server ubults00.dominio"

$ sudo service puppet start
* Starting puppet configuration management tool                       [ OK ]

Este daemon busca nuevas configuraciones en el servidor cada 30 minutos por defecto. Podemos arrancar el daemon en modo "no daemonizado" para probar y que no quede residente. Lo paramos con CTRL+C. La opción waitforcert le dice que chequee cada 45 segundos para ver si se se devuelve un certificado firmado. Con el siguiente comando podemos ver lo que hace.

$ sudo service puppet stop
$ sudo puppetd --verbose --server ubults00.dominio --no-daemonize --waitforcert 45 --debug

El cliente lo estamos usando desde el propio nodo servidor. El servidor puppet tiene su propia CA que se creo en la instalación automáticamente. Cuando el cliente se conecta a un servidor se usa un certificado para autenticar al cliente. Este certificado se ha creado y firmado automáticamente en /var/lib/puppet/ssl/certs/ubults00.dominio.pem para el propio servidor, por tanto, ahora debería haberse creado el archivo de prueba con los permisos adecuados.

$ ls -lah /tmp/archivodeprueba 
-rwxrwxrwx 1 root games 0 2010-05-21 14:19 /tmp/archivodeprueba

Y efectivamente, ahí esta.

Si lo hacemos desde otro nodo cliente. Primero debemos firmar el certificado en el servidor para que podamos conectar (--waitforcert [segundos]). También hay una opción que podemos poner en el archivo de configuración de puppet para que firme los certificados de forma automática (autosign=false)

Cliente en Fedora "Constantine"

Suponemos que hemos instalado puppet, ruby, etc. (no puppetmaster). Y queremos conectar a puppetmaster en ubults00.dominio (por defecto, los clientes se conectan a un servidor llamado "puppet" de forma automática, no es el caso)

Editamos el fichero del cliente puppet y en la sección para el demonio cliente [puppetd] añadimos la directiva server.

# vim /etc/puppet/puppet.conf

[puppetd]
    # Añadimos un servidor puppet para este cliente
    server = ubults00.dominio

Reiniciamos el cliente puppet en fedora y al iniciarse, en ubults00 (la otra máquina con el servidor puppet) debería haberse creado una solicitud de certificado. Para verlo, en ubults00

$ sudo puppet --list
portfed.dominio
ubults00.dominio

Debemos firmar el certificado de fedora.

$ sudo puppetca --sign portfed.dominio
portfed.dominio
notice: Signed certificate request for portfed.dominio
notice: Removing file Puppet::SSL::CertificateRequest portfed.dominio at '/var/lib/puppet/ssl/ca/requests/portfed.dominio.pem'

Vemos que se ha creado el certificado firmado.

Volvemos a fedora, reiniciamos el cliente puppet y después de un tiempo

# ls -lah /tmp/archivodeprueba 
-rwxrwxrwx. 1 root games 0 may 21 15:40 /tmp/archivodeprueba

Aquí lo tenemos :-)

NOTA: Para revocar un certificado en el servidor

$ sudo puppetca --revoke portfed.dominio

Para eliminar un certificado y que se vuelva a crear en la siguiente conexión

$ sudo puppetca --clean portfed.domino
Related Posts with Thumbnails