Openstack CLI y autocompletar en bash

Hace ya tiempo que utilizo el comando integrado openstack para vincularme con nubes en Openstack de distintos proveedores y siempre extrañe que en algunas distribuciones de GNU/Linux no estuviera disponible el autocompletar en Bash.

El comando openstack ofrece el parámetro complete que genera el script para que bash-completion lo cargue y quede funcional.

Ejecutar como usuario con permiso sudo:

$ openstack complete | sudo  tee /etc/bash_completion.d/osc.bash_completion > /dev/null

o también como root:

# openstack complete > /etc/bash_completion.d/osc.bash_completion

El parámetro complete implementado en el comando openstack utiliza el framework cliff – Command Line Interface Formulation Framework para obtener la salida del script de bash-completion.

Cambiando vencimiento llave GPG

Las llaves GPG que me identifican les coloco un vencimiento anual.

Mi llave pública GPG en keybase

entonces cada año en esta época debo proceder a renovar la llave, que lo que hago es correrle un año para adelante el vencimiento y vovler a sincronizar con los keyservers.

Este es el proceso total que ejecuto:

Buscar mi llame en mi llavero:

$ gpg --list-keys Rodolfo
pub   rsa2048 2014-09-07 [SC] [caduca: 2017-09-14]
      FCE66FC5849DA0F6E30DD1FCA33C4E6423B5BE7B
uid           [  absoluta ] Rodolfo Pilas <rodolfo@>
uid           [  absoluta ] Rodolfo Pilas <rodolfo@>
uid           [  absoluta ] Rodolfo Pilas <rpilas@>
uid           [  absoluta ] [jpeg image of size 4579]
uid           [  absoluta ] [jpeg image of size 13611]
sub   rsa2048 2014-09-07 [E] [caduca: 2017-09-14]

Editar la llave:

$ gpg --edit-key FCE66FC5849DA0F6E30DD1FCA33C4E6423B5BE7B

Clave secreta disponible.

sec  rsa2048/A33C4E6423B5BE7B
     creado: 2014-09-07  caduca: 2017-09-14  uso: SC
     confianza: absoluta      validez: absoluta
ssb  rsa2048/65841C4E15CF2ADC
     creado: 2014-09-07  caduca: 2017-09-14  uso: E
[  absoluta ] (1). Rodolfo Pilas <rodolfo@>
[  absoluta ] (2)  Rodolfo Pilas <rodolfo@>
[  absoluta ] (3)  Rodolfo Pilas <rpilas@>
[  absoluta ] (4)  [jpeg image of size 4579]
[  absoluta ] (5)  [jpeg image of size 13611]

Está editando la key 0 o sea la que se identifica como A33C4E6423B5BE7B

gpg> expire
Cambiando caducidad de clave primaria.
Por favor, especifique el per'iodo de validez de la clave.
         0 = la clave nunca caduca
      <n>  = la clave caduca en n d'ias
      <n>w = la clave caduca en n semanas
      <n>m = la clave caduca en n meses
      <n>y = la clave caduca en n a~nos
?Validez de la clave (0)? 1y
La clave caduca Tue Sep 11 17:26:48 2018 -03
?Es correcto? (s/n) s

sec  rsa2048/A33C4E6423B5BE7B
     creado: 2014-09-07  caduca: 2018-09-11  uso: SC
     confianza: absoluta      validez: absoluta
ssb  rsa2048/65841C4E15CF2ADC
     creado: 2014-09-07  caduca: 2017-09-14  uso: E
[  absoluta ] (1). Rodolfo Pilas <rodolfo@>
[  absoluta ] (2)  Rodolfo Pilas <rodolfo@>
[  absoluta ] (3)  Rodolfo Pilas <rpilas@>
[  absoluta ] (4)  [jpeg image of size 4579]
[  absoluta ] (5)  [jpeg image of size 13611]

Ya quedo cambiada la caducidad de la llave primaria, ahora la secundaria 65841C4E15CF2ADC:

gpg> key 1

sec  rsa2048/A33C4E6423B5BE7B
     creado: 2014-09-07  caduca: 2018-09-11  uso: SC
     confianza: absoluta      validez: absoluta
ssb* rsa2048/65841C4E15CF2ADC
     creado: 2014-09-07  caduca: 2017-09-14  uso: E
[  absoluta ] (1). Rodolfo Pilas <rodolfo@>
[  absoluta ] (2)  Rodolfo Pilas <rodolfo@>
[  absoluta ] (3)  Rodolfo Pilas <rpilas@>
[  absoluta ] (4)  [jpeg image of size 4579]
[  absoluta ] (5)  [jpeg image of size 13611]

gpg> expire
Cambiando fecha de caducidad de subclave.
Por favor, especifique el per'iodo de validez de la clave.
         0 = la clave nunca caduca
      <n>  = la clave caduca en n d'ias
      <n>w = la clave caduca en n semanas
      <n>m = la clave caduca en n meses
      <n>y = la clave caduca en n a~nos
?Validez de la clave (0)? 1y
La clave caduca Tue Sep 11 17:27:37 2018 -03
?Es correcto? (s/n) s

sec  rsa2048/A33C4E6423B5BE7B
     creado: 2014-09-07  caduca: 2018-09-11  uso: SC
     confianza: absoluta      validez: absoluta
ssb* rsa2048/65841C4E15CF2ADC
     creado: 2014-09-07  caduca: 2018-09-11  uso: E
[  absoluta ] (1). Rodolfo Pilas <rodolfo@>
[  absoluta ] (2)  Rodolfo Pilas <rodolfo@>
[  absoluta ] (3)  Rodolfo Pilas <rpilas@>
[  absoluta ] (4)  [jpeg image of size 4579]
[  absoluta ] (5)  [jpeg image of size 13611]

Guardar la llave editada y salir de gpg

gpg> save

Subir la llave al keyserver, para que los cambios se repliquen

$ gpg --keyserver pgp.mit.edu --send-keys FCE66FC5849DA0F6E30DD1FCA33C4E6423B5BE7B
gpg: enviando clave A33C4E6423B5BE7B a hkp://pgp.mit.edu

Y aprovechar a actualizar todas las demas llaves de mi llavero, pero eso ya es otra tarea.

LXC en Debian con Ansible

Desde antes del 2013 vengo insitiendo con las ventajas de los containers en Linux, ya que permiten un rápido despliegue de muchos sistemas Linux corriendo en forma independiente.

En 2014 había hecho experiencias para tener con una máquina virtual de DigitalOcean muchos contenedores Linux instalados y prestando servicios y en 2016 tuve la oportunidad de compartir en forma práctica con la comunidad de Paysandú un ejemplo de uso de contenedores.

Hace unos meses atrás armé un perfil de vagrant (Vagrantfile) que permite levantar una máquina virtual con Debian e instalar (aprovisionar) un servidor de contenedores LXC, y un primer contenedor de pruebas.

Este artículo tiene por objetivo, compartir esa configuración, para que la pueda usar quién desee.

Repositorio: debian-lxc-ansible

El aprovisionamiento se realiza mediante Ansible, por lo que es fácil de parametrizar y adaptar.

Una vez levantado el primer contenedor (que ya queda en el aprovisionamiento inicial, luego de correr vagrant up) es muy fácil levantar más contenedores con los comandos normales.

También, en el directorio /vagrant/utils se entregan scripts (requieren revisión y adaptación a la instalación particular) que sirven cómo muestra de cómo levantar containers para producción:

a) Levantar un container con sitio web funcional

/vagrant/utils/create-container.sh name

b) Borrar el container creado con el script anterior

/vagrant/utils/destroy-container.sh name

c) Crear una página web para ver el status de los containers a través de web en el servidor lxc

/vagrant/utils/status.sh

Toda esta instalación, obviamente puede ser modificada y mejorada. Si desean compartir sus mejoras conmigo lo pueden hacer a través de Merge Request.

Carguemos las pilas

Creo que he llegado a una nueva marca sin publicaciones en el blog desde abril pasado.

Una de las razónes es Deployando.Me el podcast de tecnología para sysadmin y devops que trato de mantener en forma períodica ¿ya lo escucharon?

Otra de las razones son nuevos proyectos laborales, viajes al exterior para distintas tareas profesionales y un montón de etcéteras que puedo encontrar, pues razones hay muchas pero…

el que no publica soy yo, y no es porque falte material o falte qué compartir.

Entonces, va este artículo como auto-compromiso de seguir publicando.

Actualización y los 4 millones de archivos

Un tiempo atrás actualicé un sistema Debian en forma rutinaria y hace un par de días comenzó a producir problemas extraños en las aplicaciones: desde pérdida de sesión al editar páginas web, errores para escribir en las bases de datos, hasta problemas de permisos en los archivos temporales.

El problema resultó ser la temida y oscura: tabla de inodos llena.

# df -i
Filesystem      Inodes    IUsed           IFree IUse% Mounted on
/dev/sda1       5120000 5120000     0        100%   /

Entonces, a salir a buscar dónde estaban los millones de archivos que ocupaban todos los inodos:

# find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n
...
3945231  /var/lib/php5/

y resulta que en ese directorio se mantenían unos casi cuatro millones de archivos llamados como sess_dn5m6oc4fcpfo0c95pq1se4rp0.

Aparte de iniciar un proceso de borrado masivo:

# cd /var/lib/php5
# find . -name "sess_*" -print | xargs rm -v

Inicié la búsqueda de las causas de fondo para evitar que el problema se vuelva a repetir en el futuro.

En Debian/Ubuntu el encargado de mantener los archivos de sesiones que se generan en /var/lib/php5 es el script

# cat /etc/cron.d/php5
# /etc/cron.d/php5: crontab fragment for php5
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)

que como se puede ver, utiliza la salida de la ejecución de /usr/lib/php5/maxlifetime para determinar el tiempo de mantenimiento de los archivos de sesión de php.

El problema se generó en la ejecución de /usr/lib/php5/maxlifetime que producía el error de al ejecutar por la presencia de la directiva safe_mode en el archivo php.ini:

#  grep safe_mode /etc/php5/apache2/php.ini
safe_mode = On

en razón de que:

42 | WARNING | INI directive ‘safe_mode’ is deprecated from PHP 5.3 and forbidden from PHP 5.4.

Así la actualización a PHP 5.4 hizo que el archivo /usr/lib/php5/maxlifetime dejara de devolver un valor para devolver un error. Entonces el proceso de limpieza, dejó de limpiar y se juntaron cuatro millones de archivos que llenaron la tabla de inodos.

Solución permanente: comentar safe_mode = On en el archivo php.ini.

La caída de GitLab

Tal vez no conoces Gitlab, tal vez su caída de servicio no te afectó. Yo soy de los que tengo bastantes cosas en GitLab y su caída me llegó en un momento inoportuno; por suerte no perdí datos ni sufrí problemas irremediables.

Del problema rescato el cómo Gitlab llega a esa situación tan crítica y cómo fue el proceso de volverlo a poner online. Lo considero una experiencia invaluable para que todos los que estamos de alguna forma involucrados en mantenimiento de sistemas ya que podemos ver, en la experiencia ajena, qué enseñanza tomar para nosotros mismos.

Comparto un video de Freddy Vega titulado Consejos para DevOps en situaciones de crisis | La caída de GitLab con una explicación clara de todo el evento de Gitlab:

Y, por supuesto, que sigo teniendo mis repositorios en Gitlab y estoy más entusiasmado que nunca con su servicio y, desde esta humilde página, agradezco todo el esfuerzo y la impronta puesta en la solución.

La magia de lo mágico: el correo electrónico

He manifestado muchas veces que el correo electrónico es la herramienta más abusada de Internet y a su vez una de las más viejas que se mantiene casi incambiada (casi como fue creada hace más de 40 años), y la gente acostumbrada a una especie de chat por e-mail suele perder noción de su funcionamiento básico, asignándole funcionalidades mágicas y, haciendo reclamos de magia cuando algo no funciona como espera.

Recientemente una empresa de servicios de correo electrónico empezó a clasificar el correo que envia uno de mis clientes como SPAM cuando lo entrega en la casilla de los destinatarios. Los remitentes (mis clientes) comenzaron a reclamarme por esta situación, frente a la que estoy virtualmente atado de manos, una de mis respuestas fue:

Si  mandas una carta por el Correo Uruguayo 
a un amigo en Bélgica y el cartero belga 
deja la carta en el hall del edificio en lugar 
de la buzonera del departamento (donde tu 
amigo revisa todos los dias).

¿Crees que el Correo Uruguayo puede hacer 
algo para que el cartero belga deje la carta 
donde la debería poner al entregarla?

Si llevamos el análisis del e-mail al equivalente del sistema de correo postal, solucionaríamos muy rápido muchos problemas.

¿te ha pasado que te piden hacer magia con el e-mail?

¿tienes alguna experiencia semejante para compartir?