CheckUpdatesRedHat4

Viernes, 21 de enero de 2011

Chequeo automático de actualizaciones pendientes en Red Hat 4

Al tener que administrar varios servidores linux Red Hat, me pareció interesante disponer de un sistema que me avisará mediante correo electrónico de las actualizaciones pendientes de instalar en los diferentes servidores para que no haya ninguno que se quede demasiado desactualizado.

En Red Hat 5 esto se puede hacer mediante el servicio yum-updatesd que viene incluido, pero para Red Hat 4 no he encontrada algo parecido. Por eso me he creado un script personalizado para hacer este trabajo. Este script además de avisar por e-mail, también descarga los paquetes para que la próxima vez que se haga la actualización esta sea más rápida. El script en cuestión es el siguiente:

#!/bin/bash

AVISADOS="root@midominio.es"
HOSTNAME=`hostname`
TMPDIR=/tmp
# Esperamos un tiempo aleatorio para que todos los servidores
# no ataquen a la RHN a la vez
sleep `expr $RANDOM % 300`
TMPFILE=`mktemp -p $TMPDIR checkup2date.XXXXXX`
TMPFILE2=`mktemp -p $TMPDIR checkup2date.XXXXXX`
# Obtenemos la lista de paquetes pendientes
/usr/bin/up2date -l > $TMPFILE
# Descargamos los paquetes para facilitar la instalacion posterior
/usr/bin/up2date -u -d -f  > /dev/null 2>&1
# Procesamos la lista de pendientes
ESTADO=0
CONT=0
while read linea
do
   if [[ `echo $linea | grep "^Name"` ]]
   then
      ESTADO=1
   elif [[ `echo $linea | grep "^--*$"` ]]
   then
      continue
   elif [[ $ESTADO -eq 1 && -z $linea ]]
   then
      ESTADO=0
   elif [[ $ESTADO -ne 0 ]]
   then
      echo $linea | awk -F" " '{printf "     %-50s %s-%s\n",$1,$2,$3}' >> $TMPFILE2
      CONT=`expr $CONT + 1`
   fi
done < $TMPFILE
# Generamos el mensaje de correo segun el num. de paquetes pendientes
case "$CONT" in
 0)
   SUBJECT="$HOSTNAME: no updates available"
   echo "Hi," > $TMPFILE
   echo "This is the automatic update system on $HOSTNAME" >> $TMPFILE
   echo >> $TMPFILE
   echo "There is no package updates available." >> $TMPFILE
   echo >> $TMPFILE
   echo "Thank You," >> $TMPFILE
   echo "Your Computer" >> $TMPFILE
   ;;
 1)
   SUBJECT="$HOSTNAME: 1 update available"
   echo "Hi," > $TMPFILE
   echo "This is the automatic update system on $HOSTNAME" >> $TMPFILE
   echo >> $TMPFILE
   echo "There is 1 package update available. Please run the system updater." >> $TMPFILE
   echo  >> $TMPFILE
   echo "Package available for update: " >> $TMPFILE
   echo  >> $TMPFILE
   cat $TMPFILE2 >> $TMPFILE
   echo >> $TMPFILE
   echo "Thank You," >> $TMPFILE
   echo "Your Computer" >> $TMPFILE
   ;;
 *)
   SUBJECT="$HOSTNAME: $CONT updates available"
   echo "Hi," > $TMPFILE
   echo "This is the automatic update system on $HOSTNAME" >> $TMPFILE
   echo >> $TMPFILE
   echo "There are $CONT package updates available. Please run the system updater." >> $TMPFILE
   echo  >> $TMPFILE
   echo "Packages available for update: " >> $TMPFILE
   echo  >> $TMPFILE
   cat $TMPFILE2 >> $TMPFILE
   echo >> $TMPFILE
   echo "Thank You," >> $TMPFILE
   echo "Your Computer" >> $TMPFILE
   ;;
esac
# Enviamos el correo
cat $TMPFILE |mail -s "$SUBJECT" $AVISADOS
# Borrado temporales
rm -f $TMPFILE $TMPFILE2

Linux ,

AmpliarVolumenLVM

Jueves, 20 de enero de 2011

Ampliación de una partición sobre LVM

Para ampliar un volumen LVM desde la línea de comandos haríamos lo siguiente:

En primer lugar necesitamos obtener el nombre del volumen lógico de la partición a ampliar

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root 3.8G  2.9G  770M  80% /
/dev/mapper/VolGroup00-home 1.5G  1.4G  1.9M 100% /home
/dev/mapper/VolGroup00-tmp 485M   11M  449M   3% /tmp
/dev/mapper/VolGroup00-var 1.9G  1.1G  753M  60% /var
/dev/sda1              99M   25M   70M  27% /boot
tmpfs                1002M     0 1002M   0% /dev/shm

Ahora necesitamos conocer el nombre del volume group donde esta creado nuestra partición.

# lvdisplay /dev/mapper/VolGroup00-home
--- Logical volume ---
 LV Name                /dev/VolGroup00/home
 VG Name                VolGroup00
 LV UUID                pzBSAL-dvH9-2hv5-sfnM-YGES-3pWC-JGk9mq
 LV Write Access        read/write
 LV Status              available
 # open                 1
 LV Size                2.49 GB
 Current LE             637
 Segments               3
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           253:1

Ahora hemos de comprobar que hay espacio disponible para la ampliación. Si no fuera así deberíamos dar más espacio a esto volume group.

 # vgdisplay VolGroup00
--- Volume group ---
 VG Name               VolGroup00
 System ID
 Format                lvm2
 Metadata Areas        3
 Metadata Sequence No  12
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                4
 Open LV               4
 Max PV                0
 Cur PV                3
 Act PV                3
 VG Size               19.39 GB
 PE Size               4.00 MB
 Total PE              4964
 Alloc PE / Size       2262 / 8.84 GB
 Free  PE / Size       2702 / 10.55 GB
 VG UUID               zqOdUf-3Y0b-78Gv-RUzO-8Ji3-ujpa-I0DaXw

Como tenemos espacio libre podemos ampliar la partición. Lo hacemos con el comando (en el ejemplo la ampliamos en 1 GB):

# lvresize -L +1GB /dev/mapper/VolGroup00-home
Extending logical volume home to 2.49 GB
Logical volume home successfully resized

Ahora tenemos que extender el sistema de ficheros. Lo hacemos con el comando resize2fs:

# resize2fs -p /dev/mapper/VolGroup00-home
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/mapper/VolGroup00-home is mounted on /home; on-line resizing required
Performing an on-line resize of /dev/mapper/VolGroup00-home to 2609152 (1k) blocks.
The filesystem on /dev/mapper/VolGroup00-home is now 2609152 blocks long.

Los dos comandos anteriores los podríamos ejecutar con uno solo si añadimos el flag -r al comando lvresize. El comando quedaría como sigue:

# lvresize -r -L +1GB /dev/mapper/VolGroup00-home

Ahora ya podemos ver el resultado:

#  df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root 3.8G  2.9G  770M  80% /
/dev/mapper/VolGroup00-home 2.5G  1.4G  943M  60% /home
/dev/mapper/VolGroup00-tmp 485M   11M  449M   3% /tmp
/dev/mapper/VolGroup00-var 1.9G  1.1G  753M  60% /var
/dev/sda1              99M   25M   70M  27% /boot
tmpfs                1002M     0 1002M   0% /dev/shm

Si en lugar de querer ampliar la partición en una cantidad determinada, lo que quisieramos es aprovechar todo el espacio disponible en el volumen podríamos usar el siguiente comando:

# lvresize -r -l +100%FREE /dev/mapper/VolGroup00-home

Linux

CreacionRepositorioYUM

Miércoles, 10 de noviembre de 2010

Creación de un repositorio YUM para Red Hat 4 y 5

En este documento pretendo explicar una forma rápida y sencilla de crearnos nuestro propio repositorio de paquetes RPM. El acceso al repositorio será vía web.

Crearemos un repositorio distinto por cada versión de SO (4 y/o 5) y arquitectura (32 bits y/o 64 bits). Los repositorios para Red Hat 4 serán accesibles mediante la herramienta up2date y los de Red Hat 5 mediante yum.

Para crear los repositorios necesitamos instalarnos las herramientas:

  • createrepo: es la encargada de generar los repositorios para YUM
  • repoview: genera unas páginas HTML indice con el contenido del repositorio. Estas páginas se generan dentro de una carpeta repoview y nos permite navegar por los paquetes del repositorio y obtener información sobre ellos.
  • yum-arch: esta herramienta la necesitamos para Red Hat 4 para generar unos ficheros .hdr que usa up2date.

Dado que el repositorio va a ser accesible vía web, también necesitamos un servidor web, en este caso yo voy a utilizar el servidor Apache.

Los repositorios se van a crear en un servidor con Red Hat 5 con el repositorio EPEL configurado (en este repositorio están disponibles las herramientas mencionadas con anterioridad).

La instalación de estas herramientas la hacemos con el siguiente comando:

yum install createrepo repoview yum-arch

A continuación nos creamos los directorios que albergarán el repositorio. Estos directorios deberán ser accesibles vía web.  Crearemos un directorio por cada repositorio.

Una vez creados los directorios hemos de copiar dentro de ellos los diferentes paquetes RPM que queremos dejar disponibles en el repositorio.

Nota:  Si tenemos activado SELinux, hemos de revisar el contexto de los ficheros *.rpm copiados, ya que por defecto se les asigna uno que los deja inaccesibles para el Apache.

Una vez copiados los RPMs que nos interesen y cada vez que se haga una modificación ejecutaremos los siguientes comandos para generar/actualizar el repositorio:

createrepo -d $dir
repoview $dir

siendo $dir el directorio del repositorio.

Además, en el caso de actualizar los repositorios de Red Hat 4 también ejecutaremos:

yum-arch $directorio

Al ejecutar esta herramienta obtenemos un aviso de que esta deprecated, pero es la forma que he encontrado para crear el repositorio en Red Hat 4.

Configuración del repositorio en los clientes

El activar el repositorio en los clientes depende de si vamos a usar Red Hat 4 (up2date) o Red Hat 5 (yum).

Red Hat 4 (up2date)

Nos hemos de crear un fichero /etc/yum.repos.d/myRepo.repo con el siguiente aspecto:

[myRepo]
name=myRepo Repository for Enterprise Linux 4 - $basearch
baseurl=http://$urlrepositorio
enabled=1
gpgcheck=0

Además hemos de dar de alta el repositorio en la configuración de los sources de up2date (/etc/sysconfig/rhn/sources) añadiendo las siguientes líneas al fichero mencionado con anterioridad:

#BEGIN myRepo
yum myRepo http://$urlrepositorio
#END myRepo

Con esto ya está dado de alta el repositorio en nuestro cliente.

Nuestro repositorio no tiene activado el uso de GPG. En caso de querer utilizar paquetes firmados con GPG hay que hacer más cosas, pero eso se escapa de los objetivos de esta documentación. Para poder utilizar este repositorio no firmado  es necesario pasar el parámetro –nosig al up2date para que no compruebe la firma GPG. Se podriá desactivar esta comprobación de forma global para todos los repositorios RPM, pero esto puede ser demasiado radical.

Red Hat 5 (Yum)

Nos hemos de crear un fichero /etc/yum.repos.d/myRepo.repo con el siguiente aspecto:

[myRepo]
name=myRepo Repository for Enterprise Linux 5 - $basearch
baseurl=http://$urlrepositorio
enabled=1
gpgcheck=0

A semejanza del repositorio EPEL (y supongo que otros) se podría crear un paquete RPM que se encargara de configurar el nuevo repositorio en nuestros clientes.

Linux , , , ,

Cambio idioma por defecto en Red Hat 5

Viernes, 10 de septiembre de 2010

Para cambiar el idioma por defecto en un equipo con Red Hat Enterprise Linux 5 podemos usar el comando:

# system-config-language

Este comando que funciona tanto en módo gráfico como texto nos permite seleccionar el idioma que queramos.

Linux ,

puppet11

Martes, 27 de julio de 2010

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 …

Linux ,

puppet10

Miércoles, 21 de julio de 2010

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á …

Linux , ,

puppet9

Miércoles, 14 de julio de 2010

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á …

Linux ,

puppet8

Jueves, 8 de julio de 2010

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, monthmonthday, 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á …

Linux ,

windows7telnet

Jueves, 8 de julio de 2010

Cliente telnet en Windows 7

Al utilizar Windows 7, una de las cosas que he echado en falta es el cliente telnet para poder verificar que algunos servicios remotos están operativos.

Al intentar ejecutarlo Windows, respondía con un:

"telnet" no se reconoce como un comando interno o externo,
programa o archivo por lotes ejecutable.

El motivo de esto es que en la instalación por defecto no se instala este cliente. Para instalarlo procedemos de la siguiente forma:

Panel de control –> Programas –> Programas y características –> Activar o desactivar las características de Windows

En el listado que nos aparece seleccionamos la opción Cliente Telnet.

Windows ,

puppet7

Martes, 6 de julio de 2010

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á …

Linux ,