Algo de Linux: enero 2017

martes, 31 de enero de 2017

Modificado purge-old-kernels para permitir eliminar kernels antiguos en Proxmox

He modificado el script purge-old-kernels para permitir la eliminación de kernels también en Proxmox.

Podéis instalarlo en vuestro servidor de una forma muy sencilla:
# wget --no-check-certificate -O /usr/local/sbin/purge-old-kernels https://github.com/algodelinux/purge-old-kernels/raw/master/purge-old-kernels
# chmod 755 /usr/local/sbin/purge-old-kernels
Una vez instalado, no tenéis más que ejecutarlo sin parámetros para eliminar todos los kernels salvo los dos más recientes:
# purge-old-kernels
O podéis especificar el número de kernels a conservar:
# purge-old-kernels --keep 3
Aquí podéis ver el código completo:
Publicado por primera vez en http://enavas.blogspot.com.es

Error "/run/lvm/lvmetad.socket: connect failed: No existe el fichero o el directorio" en Debian Jessie

En alguna ocasión me ha surgido este error en mi servidor Debian Jessie con LVM al ejecutar cualquier comando lvm:
/run/lvm/lvmetad.socket: connect failed: No existe el fichero o el directorio
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
Para solucionarlo, he habilitado lvm2-lvmetad.socket e iniciado lvm2-lvmetad.service:
systemctl enable lvm2-lvmetad.socket
systemctl start lvm2-lvmetad.service
Publicado por primera vez en http://enavas.blogspot.com.es

Instalar kernels y headers en Proxmox

En Linux, lo habitual es que el nombre del paquete que instala un determinado kernel tenga la siguiente forma: linux-image-{version}. Y, del mismo modo, el nombre del paquete que instala las cabeceras del núcleo tenga la siguiente estructura: linux-headers-{version}.

Sin embargo, en Proxmox:

  • El nombre del paquete que instala el núcleo tiene la siguiente forma: pve-kernel-{version}.
  • El nombre del paquete que instala las cabeceras tiene la siguiente: pve-headers-{version}

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

Instalar LAMP en máquinas controladas mediante pkgsync

En nuestros centros utilizamos pkgsync para mantener una uniformidad en el software instalado tanto en clientes como en servidores. La última versión de pkgsync mantenida por mí disponible a día de hoy es la 1.37.

Para instalar LAMP (Apache + PHP + Mysql) en máquinas controladas mediante pkgsync, lo más sencillo es crear un fichero en el directorio /etc/pkgsync/musthave.d cuyo contenido será la lista de paquetes necesarios.
/etc/pkgsync/musthave.d/lamp
apache2
libapache2-mod-php5
mysql-client
mysql-common
mysql-server
php5
php5-cgi
php5-cli
php5-common
php5-ldap
php5-mysql
php-pear
De este modo, pkgsync se encargará de instalar automáticamente todos los paquetes que necesitamos. Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 30 de enero de 2017

pfSense: Permitir/denegar acceso por MAC al portal cautivo

Es posible utilizar un filtrado MAC para permitir o denegar el acceso de un equipo al portal cautivo, o incluso permitirle el acceso limitando su consumo de ancho de banda desde el apartado MACs de la configuración del portal cautivo:


Si utilizáis este tipo de filtrado, es conveniente que recordéis que debéis dejar desmarcada la casilla que desactiva el filtrado MAC (Disable MAC filtering). De este modo, cuando un usuario se conecta, en el apartado de status del portal cautivo, se mostrará la MAC que utiliza para conectarse, dato que podéis usar para bloquear su acceso con esa MAC concreta:

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

sábado, 28 de enero de 2017

Instalar OpenMediaVault "Erasmus" en Debian Jessie

Instalar OpenMediaVault en Debian Jessie es realmente sencillo:

Primero.- Añadimos el repositorio:
# echo "deb http://packages.openmediavault.org/public erasmus main" > /etc/apt/sources.list.d/openmediavault.list
Segundo.- Actualizamos los índices de los repositorios:
# apt-get update
Tercero.- Agregamos la clave del repositorio:
# apt-get install --allow-unantenticated openmediavault-keyring
Cuarto.- Instalamos OpenMediaVault:
# apt-get install openmediavault
Quinto.- Por último, iniciamos la herramienta de configuración:
# omv-initsystem
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 27 de enero de 2017

Configurar impresora Canon LBP3360 en Ubuntu 14.04

Para configurar la impresora Canon LBP3360, que, por cierto, me está dando bastantes quebraderos de cabeza en Ubuntu 14.04, después de muchas pruebas con distintos drivers, he utilizado el driver UFR II/UFR II LT Printer Driver for Linux V3.30.

Aún así, después de instalar el driver, ha seguido dando problemas si la configuraba vía usb, por el puerto usb del equipo, por el puerto usb de la propia impresora, o por lo que sea...

Para descartar, la he configurado como impresora de red y parece que, al menos de momento, está funcionando sin problemas.
Publicado por primera vez en http://enavas.blogspot.com.es

Realizar un backup automático de la configuración del firewall pfSense

pfSense realiza un backup automático de la configuración del firewall en el directorio /cf/conf/backup/ cada vez que se realiza un cambio en dicha configuración. Sabiendo ésto, podemos crear un script e implantarlo en nuestro servidor de backup para que periódicamente realice una copia de los archivos de backup del firewall mediante cron.

Para ello, primero creamos una regla en el firewall que nos permita el acceso ssh desde la interfaz WAN, si nuestro servidor de backup se encuentra en la intranet del centro, como es mi caso.

Segundo, establecemos una relación de confianza entre el servidor de backup y el firewall, copiando la clave pública del usuario con el que vamos a realizar el backup.

Tercero, creamos un script en nuestro servidor de backup como el siguiente:
#!/bin/bash
#
# /usr/local/sbin/backupfirewallconfig
# Este script hace backup de las configuraciones del firewall pfsense vía rsync
# Esteban M. Navas Martín
# 27/01/2017

# Creamos el directorio de backup, si no existe
[ -d /var/ies_backups/firewall/backup ] || mkdir -p /var/ies_backups/firewall/backup

# Copiamos los ficheros de backup del firewall en el servidor de backup
scp -r firewall:/cf/conf/backup/* /var/ies_backups/firewall/backup/

echo "Backup firewall:/cf/conf/backup/* en /var/ies_backups/firewall/backup/ finalizado." | logger -s -t $0
Por último, también en nuestro servidor de backup, añadimos una entrada a cron que realice la copia de seguridad con la periodicidad que queramos. Por ejemplo:
# Hacer backup de la configuración del firewall todos los domingos
0 2     * * 7   root    /usr/local/sbin/backupfirewallconfig
Publicado por primera vez en http://enavas.blogspot.com.es

Copiar la clave pública de un usuario de nuestra máquina pasarela para conectarnos al firewall vía ssh sin contraseña

Hay un post del año 2009 donde explicaba cómo generar una clave pública y otra privada para crear una relación de confianza y poder conectarnos a máquinas de forma remota sin tener que introducir la password del usuario al realizar una conexión mediante ssh. 

Siguiendo las instrucciones del post, veréis que es muy fácil copiar la clave pública de un usuario de nuestra máquina pasarela (en este ejemplo, root) al firewall:
root@pasarela ~ # ssh-copy-id -i /root/.ssh/id_rsa.pub.pasarela root@firewall
root@firewall's password: 
Now try logging into the machine, with "ssh 'root@firewall'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.
Publicado por primera vez en http://enavas.blogspot.com.es

Crear una regla en pfSense para permitir el acceso vía ssh al propio servidor desde la interfaz WAN

La interfaz WAN de mi servidor pfSense lo conecta a la intranet del centro, de manera que los equipos de infolab quedan separados en una VLAN y los equipos que se conectan vía wifi en otra.

Por comodidad, para poder conectarnos directamente al firewall vía ssh desde la intranet del centro, no tenemos más que crear una nueva regla en la interfaz WAN:

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

jueves, 26 de enero de 2017

Recibir un aviso de un bot de Telegram cuando se realice una conexión ssh a nuestros servidores

Por seguridad, sería conveniente controlar qué conexiones ssh se realizan a nuestros servidores, de manera que recibamos un aviso cuando alguien realice la conexión. Este aviso podríamos realizarlo vía email, simplemente teniendo configurado un servicio postfix, ssmtp, etc..., o mediante Telegram.

Los que me conocéis ya sabéis lo mucho que me gusta Telegram por la potencia y las posibilidades que nos ofrece frente a otras opciones de mensajería como Whatsapp... 

Una muy importante es que puedo tener el cliente de Telegram instalado en varios dispositivos (smartphone, tablet, ordenador) o incluso usar la versión web que me va a permitir usar Telegram en equipos donde no lo tenga instalado;  y recibir avisos en todos los dispositivos. 

Otra característica importantísima es la posibilidad de usar bots, con lo que podemos ampliar la funcionalidad de Telegram. 

Una tercera, pero no por ello menos importante, es que podemos utilizar la API de Telegram para implementar scripts o aplicaciones que nos permitan recibir notificaciones en nuestros servidores o incluso controlarlos mediante un bot.

En este post vamos a utilizar un script llamado ssh-telegram.sh publicado por matriphe en GitHub, para vigilar las conexiones ssh que se realizan a nuestros servidores.

Si echáis un vistazo al script, veréis que lo he modificado ligeramente:
/etc/profile.d/ssh-telegram.sh
# save it as /etc/profile.d/ssh-telegram.sh
# use jq to parse JSON from ipinfo.io
# install jq from repositories on Ubuntu or Debian
# or get jq from here http://stedolan.github.io/jq/

USERID="<user_id>"
KEY="<bot_token>"

TIMEOUT="10"
URL="https://api.telegram.org/bot$KEY/sendMessage"
DATE_EXEC="$(date "+%d %b %Y %H:%M")"
TMPFILE=/tmp/ipinfo-"$(date +"%Y%m%d-%H%M")".txt

if [ -n "$SSH_CLIENT" ]; then
        IP=$(echo $SSH_CLIENT | awk '{print $1}')
        PORT=$(echo $SSH_CLIENT | awk '{print $3}')
        HOSTNAME=$(hostname -f)
        IPADDR=$(hostname -I | awk '{print $1}')

        curl http://ipinfo.io/$IP -s -o $TMPFILE
        CITY=$(jq -r '.city' < $TMPFILE)
        REGION=$(jq -r '.region' < $TMPFILE)
        COUNTRY=$(jq -r '.country' < $TMPFILE)
        ORG=$(jq -r '.org' < $TMPFILE)

        if [ "$CITY" != null ] && [ "$REGION" != null ] && [ "$COUNTRY" != null ] && [ "$ORG" != null ]; then
           TEXT="$DATE_EXEC: ${USER} logged in to $HOSTNAME ($IPADDR) from $IP - $ORG - $CITY, $REGION, $COUNTRY on port $
        else
           TEXT="$DATE_EXEC: ${USER} logged in to $HOSTNAME ($IPADDR) from $IP on port $PORT"
        fi
        curl -s --max-time $TIMEOUT -d "chat_id=$USERID&disable_web_page_preview=1&text=$TEXT" $URL > /dev/null
        rm $TMPFILE
fi
Este script hace uso del comando jq para parsear el fichero JSON obtenido de ipinfo.io que nos proporciona información acerca de la IP desde la que se realiza la conexión, si es pública. Así que, lo primero que debemos hacer es instalar jq. En Debian o Ubuntu, es muy fácil porque el paquete se encuentra en los repositorios:

# apt-get install jq
El siguiente paso será copiar el script ssh-telegram.sh en el directorio /etc/profile.d:
# cp ssh-telegram.sh /etc/profile.d/
Una vez copiado, modificaremos los valores USERID y KEY en el script de manera que:
Y eso es todo. A partir de ese momento, recibiremos un mensaje de Telegram cada vez que un usuario realice una conexión ssh a nuestros servidores.
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 24 de enero de 2017

@botfather: Crear bots para Telegram

Por decirlo de algún modo, un bot es un asistente virtual que nos permite recibir un servicio (bot), en ocasiones, conversando con el usuario (chatbot). Estos bots pueden ser muy útiles, por ejemplo, para dar soporte técnico o realizar búsquedas.

@botfather es un chatbot que nos va a permitir crear nuestros propios bots.

En este post vamos a ver lo sencillo que es crear un bot con  @botfather:

Primero.- Utilizando la herramienta de búsqueda de Telegram en nuestro móvil o de Telegram Desktop en nuestro ordenador, buscamos el bot y pulsamos sobre él para iniciar una conversación:

Lo primero que hará @botfather será mostrarnos ayuda acerca de la API del Bot y de cómo controlarlo.

Segundo.- Para crear un bot, enviamos el mensaje: /newbot:


Botfather nos pedirá que elijamos un nombre para nuestro bot.

Tercero.- Escribimos un nombre. Es obligatorio que termine en bot o _bot. Si ese nombre estuviera ya registrado, nos pedirá que introduzcamos otro. Una vez introducido un nombre válido y que no haya sido registrado aún, nos devolverá un token que podremos usar para interactuar con nuestro bot:


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

Chocolatey: Listar paquetes que pueden ser actualizados

A partir de la versión 0.9.9.6+ de Chocolatey, podemos obtener un listado de paquetes actualizables utilizando el comando outdated de Chocolatey:

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

@myidbot: Un bot de Telegram para obtener nuestro user ID

Como bien dice el título del post, @myidbot es un bot de Telegram con el que podemos obtener nuestro user ID:

Tan sólo tenemos que escribir el comando /getid para obtener nuestro Telegram ID.
Y si es un grupo, podemos utilizar /getgroupid para obtener el ID de grupo.
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 23 de enero de 2017

Evitar que desaparezca el puntero del ratón en Xubuntu 14.04 con gráficas Intel

En algunos equipos con Xubuntu 14.04 con gráficas intel desaparece el puntero del ratón al suspender el sistema y al reanudar no vuelve a mostrarse. Parece que este error es bastante común en diferentes versiones de Ubuntu y se debe al método de aceleración usado por defecto con las gráficas intel. 

Después de probar varias cosas, lo que ha funcionado ha sido crear un fichero de configuración en el directorio /usr/share/X11/xorg.conf.d en el que especifiquemos que se utilice el método de aceleración gráfica "uxa":

  /usr/share/X11/xorg.conf.d/20-intel.conf
Section "Device"
        Identifier "Intel Graphics"
        Driver "i915"

        Option "AccelMethod" "uxa"
EndSection
He experimentado estos problemas en equipos con el driver i915, pero, por lo que parece, también sucede con el driver intel.
Publicado por primera vez en http://enavas.blogspot.com.es

GUERRILLAMAIL.COM: Utiliza emails temporales para enviar y recibir

GUERRILLAMAIL.COM es un servicio que nos proporciona direcciones de e-mail desechables que expiran tras un período de 60 minutos. 


Es decir, que durante 60 minutos vamos a poder enviar y recibir correos electrónicos, incluso con archivos adjuntos mediante un e-mail temporal.

Este servicio puede ser verdaderamente útil cuando necesitemos contactar por correo electrónico y no queramos proporcionar nuestra dirección de e-mail real. O cuando queramos enviarnos a nuestro propio correo algún tipo de información, evitando tener que loguearnos.
Publicado por primera vez en http://enavas.blogspot.com.es

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"
[main]
server=puppetinstituto2
pluginsync=true
autoflush=true
ca_server=puppetinstituto
Si os fijáis en el fichero de configuración, estoy indicando al cliente que el servidor del que debe obtener las actualizaciones es: puppetinstituto2. Y la autoridad de certificación es el servidor puppetinstituto. Ésto es así porque tengo dos servidores puppet y tan sólo uno de ellos es la autoridad de certificación.

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 10d -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

cleanpuppetnodes: Limpiar información de facts, node y certificados de nodos puppet en el puppetmaster

El script cleanpuppetnodes sirve para eliminar información de facts, node y certificados de nodos puppet en el puppetmaster.

Podéis instalarlo en vuestro servidor de una forma muy sencilla:
# wget --no-check-certificate -O /usr/local/sbin/cleanpuppetnodes https://github.com/algodelinux/cleanpuppetnodes/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
Aquí podéis ver el código completo: Publicado por primera vez en http://enavas.blogspot.com.es

puppetlast: Muestra la última conexión de los nodos puppet en el puppetmaster

He reescrito puppetlast en bash para adaptarlo a mis necesidades. Ahora muestra 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:

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

miércoles, 11 de enero de 2017

Habilitar acceso seguro a la interfaz de Monit

El acceso a la interfaz de monit se hace vía http. Si queremos habilitar un acceso seguro a la interfaz de monit, haremos lo siguiente:

Editamos el fichero /etc/monit/monitrc y añadimos las siguientes líneas justo a configuración de la que dice: set httpd port 2812 and:
SSL ENABLE
PEMFILE /etc/ssl/certs/monit.pem
El bloque de configuración nos quedará más o menos así:
set httpd port 2812 and
    SSL ENABLE
    PEMFILE /etc/ssl/certs/monit.pem
    allow localhost        # allow localhost to connect to the server and
    allow 192.168.0.10     # allow 192.168.0.10 to connect to the server and
    allow admin:monadmin   # require user 'admin' with password 'monadmin'
Por supuesto, debéis modificar las reglas allow para permitir el acceso desde un determinado equipo de vuestra red y las credenciales de acceso.

Una vez hecho ésto, crearemos el certificado en la ubicación que hemos definido: /etc/ssl/certs/monit.pem
cd /etc/ssl/certs
openssl req -new -x509 -days 365 -nodes -config /etc/puppet/modules/puppet-monit/files/monit.cnf -out /etc/ssl/certs/monit.pem -keyout /etc/ssl/certs/monit.pem
openssl gendh 512 >> /etc/ssl/certs/monit.pem
openssl x509 -subject -dates -fingerprint -noout -in /etc/ssl/certs/monit.pem
chmod 700 /etc/ssl/certs/monit.pem
La plantilla para la creación del certificado yo la tengo almacenada en una tarea puppet que configura monit. Con el parámetro -config estamos indicando donde se encuentra dicha plantilla: -config /etc/puppet/modules/puppet-monit/files/monit.cnf No olvidéis cambiarlo por la ubicación donde tengáis almacenado el archivo. Una vez hecho ésto, ya podemos acceder vía https a la interfaz de monit: https://servidor
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 10 de enero de 2017

reinstall_nwfermi_module: Script para instalar el módulo nwfermi tras actualizar el kernel

Como no soy capaz de dedicar el suficiente tiempo para investigar por qué deja de funcionar el módulo nwfermi de las SmartBoard SB480 tras actualizar el kernel, lo que tengo es un script que me permite reinstalarlo:
#!/bin/bash

PKGVER=`dpkg-query -W -f='${Version}' nwfermi | awk -F "-" '{print $1}'`
PKGVER=${PKGVER#*:}

echo "Removing all DKMS Modules"
dkms remove -m nwfermi -v $PKGVER --all -q > /dev/null
echo "Done."
echo "Adding Module to DKMS build system"
echo "driver version= $PKGVER"
dkms add -m nwfermi -v $PKGVER > /dev/null
echo "Doing initial module build"
dkms build -m nwfermi -v $PKGVER > /dev/null
echo "Installing initial module"
dkms install -m nwfermi -v $PKGVER > /dev/null
echo "Done."
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 9 de enero de 2017

Imagen iso con Clonezilla + DRBL + Rescatux para montar en pendrive/disco duro USB

Como ya comenté en un post anterior, para no tener que gestionar dos menús de opciones (uno para syslinux y otro para grub) he creado una ISO con Clonezilla, DRBL y Rescatux que utiliza tan sólo GRUB. 

Si observáis el contenido del dispositivo, veréis que, en la raiz del mismo, hay un directorio /boot donde instalamos GRUB. Este directorio /boot contiene un subdirectorio grub con los archivos de GRUB y un fichero de configuración grub.cfg (/boot/grub/grub.cfg). Este fichero de configuración contiene una línea que indica a grub que cargue el fichero de configuración /EFI/boot/grub.cfg:
configfile /EFI/boot/grub.cfg

/boot/grub/grub.cfg -> /EFI/boot/grub.cfg
Por tanto, cuando queramos añadir, modificar o borrar entradas de menú, tan sólo tendremos que modificar el fichero /EFI/boot/grub.cfg.


Como podéis observar en la imagen anterior, he dejado en el menú principal una entrada por defecto para Clonezilla, otra para DRBL y otra para Rescatux.

Por otro lado, he creado submenús con diferentes opciones agrupadas de Clonezilla, DRBL y Rescatux. De este modo, el menú no es demasiado extenso y se encuentra un poco más organizado.

También he añadido un submenú que permite instalar xubuntu trusty amd64 e i386 desde la iso. 

Y, por último, una opción para reiniciar el equipo y otra para apagarlo directamente.

En su día, monté la iso con Clonezilla, DRBL y Boot Repair Disk, pero me pareció mucho más interesante reemplazar esta última herramienta por Rescatux que incorpora Boot Repair Disk y nos proporciona utilidades adicionales para realizar diferentes tareas de recuperación y reparación:
  • Solucionar problemas de GRUB
  • Restablecer contraseñas de Windows 
  • Restablecer contraseñas de usuario de Linux 
  • Chequear y reparar archivos de sistema 
  • Restaurar el MBR de Windows
  • Getionar particiones con GParted
  • Recuperar archivos eliminados con Photorec 
  • Regenerar el archivo sudoers
Al igual que ya comenté en su día, monto clonezilla y drbl en el mismo dispositivo por una razón muy sencilla: Habitualmente uso clonezilla para crear y restaurar imágenes con entradas de menú directas o inicio sesión en un terminal de clonezilla para hacer algún diagnóstico, o cualquier modificación, pero, además, cuando tengo que clonar de forma masiva, utilizo DRBL para restaurar imágenes en modo multicast.

Los ajustes que llevan tanto clonezilla como DRBL son los mismos que en versiones anteriores:
  • El filesystem.squashfs de DRBL se aloja en el directorio live y el filesystem.squashfs de Clonezilla se encuentra ubicado en el directorio live-clonezilla. De este modo, es posible tener ambas herramientas en el mismo dispositivo.
  • Se establece por defecto el idioma español tanto para la interfaz como para el teclado. Con ésto evitamos tener que seleccionar el idioma en el asistente de clonación cada vez que lo usemos.
  • Se fija como directorio de imágenes el /home/partimag del dispositivo para ambas herramientas y se monta en modo lectura/escritura con el fin de que se use tanto para salvar/restaurar imágenes desde ambas herramientas.
Una vez que lo montéis en vuestro disco duro/pendrive USB, podéis editar las entradas y adaptarlas a vuestras necesidades. He dejado algunas opciones de restauración de imágenes que uso en mi disco de herramientas para que sirvan de ejemplo y podáis modificarlas a vuestro gusto.

Para montar la ISO en el pendrive podéis usar tuxboot.

A continuación tenéis dos enlaces alternativos para descargar la ISO:
En la imagen se puede ver que hay un submenú para iniciar Android Remix OS. Eso es porque he realizado la captura de imagen de mi HDD externo donde también lo tengo montado. No he añadido Remix OS a la ISO. Sin embargo, sí he dejado comentadas las entradas del menú por si alguien quiere "descomentarlas" para añadir Remix OS a su disco duro.
Publicado por primera vez en http://enavas.blogspot.com.es