Algo de Linux

viernes, 20 de enero de 2017

Instalar puppet agent en Windows

En el post anterior, comentaba que tengo un puppetmaster replicado en el servidor HP Proliant secundario. Este puppetmaster está modificado para realizar la actualización tanto de clientes puppet linux como windows, lo que me permite actualizar, en general, cualquier máquina Linux del centro, y, en particular los Windows de los Infolab.

Como también he comentado en alguna ocasión, en los equipos Windows utilizo Chocolatey para mantener actualizado software de propósito general como Firefox, Google Chrome, 7-zip, Libreoffice, Gimp, etc... 

Así que, utilizando Chocolatey es realmente sencillo instalar y configurar el cliente puppet en Windows:
C:\Windows\System32> choco install -y puppet -version 3.4.3 -installArgs '"PUPPET_MASTER_SERVER=puppetinstituto2 PUPPET_CA_SERVER=puppetinstituto"'
Como podéis, observar, estoy indicando a chocolatey que quiero instalar concretamente la versión 3.4.3 del cliente puppet, es decir, la misma que tenemos en los clientes Ubuntu.

Pero, además, le estoy diciendo que el servidor puppet para este cliente es puppetinstituto2 (PUPPET_MASTER_SERVER=puppetinstituto2), es decir, mi servidor secundario; y que la autoridad de certificación es puppetinstituto (PUPPET_CA_SERVER=puppetinstituto); que es mi servidor principal.

Una vez instalado, podemos echar un vistazo al archivo de configuración para comprobar que el fichero puppet.conf ha sido configurado correctamente:

C:\Windows\System32> notepad "C:\ProgramData\PuppetLabs\puppet\etc\puppet.conf"

Y, por último, podemos ejecutar puppet agent en modo de prueba para testear que funciona correctamente:
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 19 de enero de 2017

Sincronizar los módulos del puppetmaster servidor con el puppetmaster ldap

Como ya he comentado en alguna ocasión, cuento con dos servidores HP Proliant. Ambos prestan los mismos servicios esenciales: DHCP, DNS, LDAP, NTP, GATEWAY, aunque se diferencian en otros. Por ejemplo, uno de ellos aloja el mirror de Debian Wheezy y el otro el de Ubuntu Trusty. Para distinguirlos, seguí llamando servidor a uno de ellos y ldap al otro. 

El puppetmaster se encuentra implementado en el servidor servidor. Ahora bien, para aprovechar los recursos, en un momento dado me pareció interesante montar un puppetmaster secundario en el servidor ldap, de manera que la autoridad de certificación sea sólo servidor.

Si a ésto le añado la sincronización de los módulos puppet junto el fichero que contiene la clase especifica-xubuntu-linex-2015.pp,  puedo contar con dos servidores que me van a permitir realizar un reparto de la carga:


Para sincronizar los módulos tan sólo necesito utilizar un simple script que se ejecuta desde el cron del puppetmaster principal:

/usr/local/sbin/sinc_puppet_modules
#!/bin/bash

SERVIDOR='ldap'

rsync -av /etc/puppet/manifests/classes/xubuntu/especifica-xubuntu-linex-2015.pp root@$SERVIDOR:/etc/puppet/manifests/classes/xubuntu/especifica-xubuntu-linex-2015.pp 
rsync -av /etc/puppet/modules/ root@$SERVIDOR:/etc/puppet/modules/
rsync -av /etc/puppet/modulesSec/ root@$SERVIDOR:/etc/puppet/modulesSec/

Es cierto que se podría realizar un balanceo de carga entre ambos servidores, pero el puppetmaster servidor no lo controlamos los administradores en exclusiva, así que no me lo planteo. En lugar de eso, puedo configurar determinados clientes para que se actualicen con un servidor y determinados clientes para que se actualicen con el otro. Por ejemplo, el sistema operativo Windows de los Infolab o los equipos workstation.

También es posible ejecutar el puppet agent de forma manual para que el cliente se actualice con un servidor:
# puppet agent --onetime --no-daemonize --server=puppetinstituto
O con el otro:
# puppet agent --onetime --no-daemonize --server=puppetinstituto2
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 17 de enero de 2017

Retornar un valor desde una función bash

Bash nos permite utilizar funciones que, al finalizar, devuelven el valor de estado de salida ($?), que será cero en caso de que la ejecución sea correcta y cualquier otro valor en caso de error.

El método que más utilizo (sobre todo porque me resulta bastante claro) cuando quiero devolver un valor en una función bash es el de sustitución de comandos. La sustitución de comandos en bash hace uso del operador $().

Como ejemplo, podemos ver la función calculatetime que utilicé en el script puppetlast:
function calculatetime {

  local ARGUMENTO=$1
  local NUMERO=${ARGUMENTO%%[dhms]}
  local LETRA=${ARGUMENTO:${#NUMERO}}
  local VALOR=$1

  if [ $LETRA = "d" ]; then
     VALOR=$((NUMERO*60*60*24))
  elif [ $LETRA = "h" ]; then
     VALOR=$((NUMERO*60*60))
  elif [ $LETRA = "m" ]; then
     VALOR=$((NUMERO*60))
  elif [ $LETRA = "s" ]; then
     VALOR=$((NUMERO))
  fi
  echo $VALOR
}

Mediante este método, hacemos que el resultado de la función se muestre en STDOUT.

Al emplear la sustitución de comandos, conseguiremos almacenar el resultado en una variable:
MIN=$(calculatetime $2)
Publicado por primera vez en http://enavas.blogspot.com.es

Regular Expressions CheatSheet

Y ya que hablamos de expresiones regulares, además de un servicio para testearlas, es interesante disponer de una buena Cheat Sheet. Para Bash, os recomiendo la siguiente:
Publicado por primera vez en http://enavas.blogspot.com.es

regexraptor.net: Chequea tus expresiones regulares bash online

Para los que trabajamos habitualmente con expresiones regulares en Bash, es importante comprobar que nos proporcionan el resultado que queremos antes de utilizarlas en nuestros scripts.

Para chequear una expresión regular en Bash, podéis utilizar el siguiente servicio online:
http://regexraptor.net/
Publicado por primera vez en http://enavas.blogspot.com.es

Actualizado puppetlast para permitir seleccionar un rango de tiempo en el que mostrar la información de nodos

Como ya comenté en un post anterior, reescribí puppetlast en bash para adaptarlo a mis necesidades. y que mostrara en pantalla tres datos:
  • El tiempo transcurrido desde que se actualizó el nodo.
  • El nombre con el que se genera el certificado (ya sea el uuid o el fqdn).
  • El fqdn del host. 
Se muestra en color verde la información de aquellos nodos que se actualizaron en segundos o minutos, en color rojo aquellos que se actualizaron en horas y en rojo más intenso aquellos cuya última actualización se realizó hace días:


He realizado una modificación que permite filtrar el listado de nodos por tiempo máximo y/o mínimo de actualización:


La sintaxis es sencilla:
puppetlast [-m|--min time] [-M|--max time]

Opciones:
  • -m|--min: Nos permite indicar un tiempo mínimo de actualización.
  • -M|--max: Nos permite indicar un tiempo máximo de actualización.
  • time es una combinación de números+letra donde:
    • letra debe ser un valor de entre los siguientes: [dhms]:
      • d: días
      • h: horas
      • m: minutos
      • s: segundos
Ejemplos:
    puppetlast
    puppetlast -m 1h
    puppetlast -M 2d
    puppetlast -M 1h -m 2d
    puppetlast -M 19h -m 1m

Podéis instalarlo fácilmente en vuestro servidor con tan sólo ejecutar los siguientes comandos:
# wget --no-check-certificate -O /usr/local/sbin/puppetlast https://github.com/algodelinux/puppetlast/raw/master/puppetlast
# chmod 755 /usr/local/sbin/puppetlast
Aquí podéis ver el código completo: Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 13 de enero de 2017

Modificado cleanpuppetnodes para limpiar también información antigua de nodos en el puppetmaster

Como ya os comenté en un post anterior, el script cleanpuppetnodes sirve para eliminar información de facts, node y certificados de nodos puppet en el puppetmaster.

Para facilitar la tarea de actualizar nodos mediante puppet, a partir de una cierta versión del script sinc_puppet, comencé a usar un uuid en lugar del fqdn del host. Con este cambio, evitamos los problemas de sincronización de máquinas con el mismo nombre de host.

A partir de ese momento, el propio script sinc_puppet se encarga de generar  los uuid en el propio cliente. Con esta nueva forma de trabajar, es posible que en el puppetmaster tengamos información antigua de nodos con diferente uuid. Así que, he modificado el script para limpiar esta información obsoleta también.

Aquí podéis ver el código completo:
Podéis instalarlo en vuestro servidor de una forma muy sencilla:
# wget --no-check-certificate -O /usr/local/sbin/cleanpuppetnodes https://github.com/algodelinux/puppetlast/raw/master/cleanpuppetnodes
# chmod 755 /usr/local/sbin/cleanpuppetnodes
Una vez instalado, no tenéis más que ejecutarlo sin parámetros para eliminar información de nodos con una antigüedad predefinida en el script (60 días):
# cleanpuppetnodes
O podéis especificar la antiguedad en días como parámetro:
# cleanpuppetnodes 30
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 12 de enero de 2017

Reinstalar el módulo nwfermi usando tmux-cssh

En un post anterior, vimos cómo podemos ejecutar un mismo comando a la vez en un conjunto de máquinas haciendo uso de la herramienta tmux-cssh.

En este post, tan sólo vamos a ver un ejemplo de cómo he usado tmux-cssh para reinstalar el módulo nwfermi en los equipos que tienen instalada una SmartBoard SB480:

Primero me conecto a una máquina que tenga establecida una relación de confianza con los equipos en los que quiero actualizar el driver y ejecuto el comando tmux-cssh:


Como podéis observar en la captura anterior, al comando tmux-cssh le estoy pasando como parámetro el resultado de mostrar el contenido del archivo /etc/dsh/group/smartboard. Este archivo contiene una línea por máquina con el nombre de la máquina (En este caso, las máquinas que tienen instalada una pizarra SmartBoard SB480).

Al ejecutar el comando, tmux-cssh se conectará a todas las máquinas listadas en el fichero que se encuentren encendidas:


Una vez conectado, lo único que tengo que hacer es escribir el comando que deseamos ejecutar: En este caso: reinstall_nwfermi_module


Como podréis observar, se escribe el comando en todos los terminales a  la vez. Cuando terminemos de escribirlo, pulsamos "Enter" y se ejecutará en todos a la vez:


Publicado por primera vez en http://enavas.blogspot.com.es

GIT CHEATSHEET

Aquí tenemos una excelente cheatsheet sobre git:
Publicado por primera vez en http://enavas.blogspot.com.es

Paquete pkgsync 1.37

En la versión 1.37 de pkgsync he introducido dos nuevas opciones:
  • LAUNCHPAD_GETKEYS="yes":  Trata de obtener claves de repositorios mediante launchpad-getkeys si launchpad-getkeys se encuentra instalado.
  • LAUNCHPAD_GETKEYS="no": no tratar de obtener claves mediante launchpad-getkeys
Si queréis utilizar esta opción, debéis instalar el paquete launchpad-getkeys que se encuentra en los repositorios de Ubuntu.

La segunda opción nos permite definir un tiempo máximo de espera a que dpkg o apt hayan terminado antes de realizar pkgsync. Este parámetro sirve para evitar evitar que pkgsync quede bloqueado por un fallo de dpkg o apt que se hubiera producido con anterioridad a la ejecución de pkgsync.

Este ajuste puede definirse en segundos (30 o 30s), minutos (10m), horas (6h) o días (2d).
  • TIMEOUT_FOR_DPKG_OR_APT="3m": Esperar un tiempo máximo de 3 minutos (valor por defecto)
Aquí podéis ver el fichero de configuración de pkgsync: /etc/default/pkgsync
# Defaults for pkgsync
#
# See /usr/share/doc/pkgsync/README.Debian for information about options
# of managing pkgsync.

# Ignorar ficheros de configuración musthave, mayhave o maynothave
IGNORE_MUSTHAVE="no"
IGNORE_MAYHAVE="no"
IGNORE_MAYNOTHAVE="no"

# Activar o desactivar pkgsync:
#  ENABLE="yes": activa pkgsync (opción por defecto)
#  ENABLE="no" : desactiva pkgsync
#  Si no existe la variable ENABLE o no tiene valor, es equivalente al valor 'yes'.
ENABLE="yes"

# Eliminar kernels antiguos (por defecto deja los dos últimos)
# PURGE_OLD_KERNELS="no": no elimina kernels antiguos (opción por defecto)
# PURGE_OLD_KERNELS="yes": elimina kernels antiguos
PURGE_OLD_KERNELS="no"

# Eliminar dependencias de paquetes desinstalados, purgar paquetes desinstalados y limpiar la cache
# CLEAN="no": no hacer limpieza (opción por defecto)
# CLEAN="yes": hacer limpieza
CLEAN="no"

# Eliminar librerías huérfanas
# REMOVE_ORPHAN_LIBS="no": no eliminar librerías huérfanas (opción por defecto)
# REMOVE_ORPHAN_LIBS="yes": eliminar librerías huérfanas
REMOVE_ORPHAN_LIBS="no"

# Iniciar sinc_puppet antes de lanzar pkgsync para garantizar que los ficheros de pkgsync 
# se encuentren actualizados
# LAUNCH_SINC_PUPPET="no": no iniciar sinc_puppet antes de hacer pkgsync
# LAUNCH_SINC_PUPPET="yes": iniciar sinc_puppet antes de hacer pkgsync (opción por defecto)
LAUNCH_SINC_PUPPET="yes"

# Apagar automáticamente el equipo después de ejecutar pkgsync en el intervalo especificado
# AUTOMATIC_SHUTDOWN_BETWEEN="22:00-07:00"
AUTOMATIC_SHUTDOWN_BETWEEN=""

# Obtener claves de repositorios mediante launchpad-getkeys si launchpad-getkeys se encuentra
# instalado
# LAUNCHPAD_GETKEYS="no": no tratar de obtener claves mediante launchpad-getkeys
# LAUNCHPAD_GETKEYS="yes": tratar de obtener claves mediante launchpad-getkeys (opción por defecto)
LAUNCHPAD_GETKEYS="yes"

# Definimos un tiempo máximo de espera a que dpkg o apt hayan terminado antes de realizar pkgsync
# Este parámetro sirve para evitar evitar que pkgsync quede bloqueado por un fallo anterior de dpkg o apt
# Este ajuste puede definirse en segundos (30 o 30s), minutos (10m), horas (6h) o días (2d).
# TIMEOUT_FOR_DPKG_OR_APT="3m": Esperar un tiempo máximo de 3 minutos (valor por defecto)
TIMEOUT_FOR_DPKG_OR_APT="3m"

Aquí podéis ver el código completo de pkgsync:

Publicado por primera vez en http://enavas.blogspot.com.es