Renombrar volumen Docker

El cliente docker tiene un conjunto de opciones destinadas a administrar volúmenes (docker volume), pero ninguna de ellas permite renombrar un volumen existente.

Me puse a investigar cómo hacerlo y me fui a ver el filesystem y a buscar la carpeta que representa el volumen y hacer el cambio allí, pero cuando investigaba para no dañar la configuración me encontré con esta solución que me pareció muy filosofía docker, inclusive es lo que se hace para copiar un disco en una nueva unidad:

docker volume create --name <nuevo_volumen>
docker run --rm -it -v <viejo_volumen>:/from -v <nuevo_volumen>:/to alpine ash -c "cd /from ; cp -av . /to"
docker volume rm <viejo_volumen>

En definitiva se trata de crear un nuevo volumen, lanzar un contenedor que monta el volumen viejo y el volumen nuevo y copia los datos de uno a otro, y finalizar borrando el viejo volumen. Simple, seguro, y elegante.

La idea no es mía, la obtuve de este issue de Github, donde incluso alguien propone un script:

$ docker-rename-vol viejo-volumen nuevo-volumen

#/bin/bash
docker volume create --name $2
docker run --rm -it -v $1:/from -v $2:/to alpine ash -c "cd /from ; cp -av . /to"
[ $? -eq 0 ] && docker volume rm $1

Y ahora, está aquí mi blog para tenerlo presente.

Tamaño máximo de adjuntos en correos

El tamaño máximo de adjuntos en un correo varía de servicio en servicio.

Esto nos afecta, pues nuestro servicio puede tener un tamaño establecido que es mayor que el tamaño del servicio de destino y, si mis ajuntos son mayores, el correo no será ni acpetado ni entregado al destinatario. Mientras que correos que envío a cuentas en mi mismo servicio son entregados sin problema.

Por supuesto, es posible configurar un servidor de correo para soportar tamaños mayores a los indicados, pero hay que tener en cuenta que cuando se envíe un correo será el servicio de destino el que aplicará sus límites, antes de aceptar el correo, para entregar en la casilla del destinatario.

Esta es una lista de los tamaños de ajuntos soportado por distintos servicios:

Servicios internacionales:

Servicios nacionales (Uruguay):

Otros límites a un correo:

Hay que recordar también que los distintos servicios tienen límites aplicados a otras características de los correos electrónicos, que también puden afectar si mi correo llegará a destino.

  • Número máximo de direcciones de destinto (To:)
  • Tamaño máximo de mensaje (adjunto + cuerpo + cabezales)
  • Espacio máximo de casilla destino (esto puede afectar si el destinatario no vacía su casilla para alojar el correo que recibe)
  • Cantidad de correos que se aceptan recibir de un mismo dominio (por día)

Estos límites han creado un «estándar» que se observa desde hace muchos años y al que todos más o menos nos adaptamos, pero cada tanto alguien tiene requisitos por sobre estos límites y se encontrará que su correo no llega a destino.

Cuando su correo no llegue a destino por tamaño del adjunto, debe buscar la ayuda de otros servicio, como ser file.io, donde el adjunto viaja por un medio y el correo, con un enlace para recuperar el adjunto, llega al destinatario de manera normal.

Remover dominio de certificado Let’s Encrypt

Tengo un sitio que responde por varios dominios y, a su vez, con y sin www, por lo que el certificado let’s encrypt tiene un Nombre Común y varios Nombres Alternativos.

$ certbot-auto certificates
  Certificate Name: cert.com
    Serial Number: 40d6f1a43875cf95b5eeb284c2902060d8e
    Key Type: RSA
    Domains: cert.com dom.com test.us play.cert.com win.cert.com www.cert.com www.dom.com www.test.us
    Expiry Date: 2021-04-04 15:33:09+00:00 (VALID: 79 days)
    Certificate Path: /etc/letsencrypt/live/cert.com/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/cert.com/privkey.pem

resulta que de este certificado se había cancelado, borrado, eliminado el sitio win.cert.com por lo que necesitabamos bajarlo del DNS también. Si no modificamos el certificado, la próxima renovación automática de Let’s Encrypt produciría un error al no poder validar la existencia del sitio.

El procedimiento para eliminar un dominio es borrar el certificado en primer lugar:

$ certbot-auto delete --cert-name cert.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
The following certificate(s) are selected for deletion:

  * cert.com

Are you sure you want to delete the above certificate(s)?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
(Y)es/(N)o: (Y)es/(N)o: (Y)es/(N)o: (Y)es/(N)o: (Y)es/(N)o: 

Al borrar el certificado no se afecta el servidor web que está corriendo, mientras el servidor no sea reiniciado.

Y se puede volver a tramitar un certificado, ahora con la lista de dominios excluyendo el que se quiere elimintar:

$ certbot-auto certonly -d cert.com -d cert.com -d dom.com \
  -d test.us -d play.cert.com -d www.cert.com -d www.dom.com \
  -d www.test.us

How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
1: Nginx Web Server plugin (nginx) [Misconfigured]
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Select the appropriate number [1-3] then [enter] (press 'c' to cancel): 2
Plugins selected: Authenticator standalone, Installer None
Requesting a certificate for cert.com and 6 more domains

Espero le sea útil a alguien más.

corona-stats.online

Un API para obtener los datos de la pandemia del Coronavirus COVID-19 se puede acceder para consultas en el sitio

https://corona-status.online

Algunas de las consultas:

$ curl -s https://corona-stats.online/UY?format=json | jq
[
  {
    "country": "Uruguay",
    "province": "",
    "countryCode": "UY",
    "confirmed": 94,
    "recovered": 0,
    "deaths": 0,
    "confirmedByDay": [
      0,
      0,
      0,
      4,
      4,
      8,
      29,
      50,
      79,
      94
    ],

Y por terminal se pueden conseguir unos resultados interesantes, como muestran estas capturas:

Si deseas colaborar, el proyecto se puede forkear a partir de este repositorio

https://github.com/sagarkarira/coronavirus-tracker-cli

Gracias a este twit tuve noticia de esta iniciativa:

https://twitter.com/radhios/status/1241374172674220034

Vagrant: Ignoring gem because its extensions are not built.

Comenzando cursos actualicé a la última version de vagrant y comencé a tener un error en las gemas de ruby instaladas:

$ vagrant version
Ignoring nokogiri-1.10.5 because its extensions are not built.  Try: gem pristine nokogiri --version 1.10.5
Ignoring ovirt-engine-sdk-4.3.0 because its extensions are not built.  Try: gem pristine ovirt-engine-sdk --version 4.3.0
Installed Version: 2.2.7
Latest Version: 2.2.7

You're running an up-to-date version of Vagrant!

Si bien todo el funcionamiento de vagrant que probé no tenía problemas, el error aparecía previo a la ejecución de cada comando vagrant.

Las sugerencias sugeridas de correccion de ejecutar gem no funcionaron tuve unos errores de permisos.

Revisando documentación vi que el error podría estar en el código de los plugins de vagrant (que agregan funcionalidad) y ejecuté el comando para borrarlos y reinstalarlos:

$ vagrant plugin expunge --reinstall

This command permanently deletes all currently installed user plugins. It
should only be used when a repair command is unable to properly fix the
system.

Continue? [N]: y

All user installed plugins have been removed from this Vagrant environment!

Vagrant will now attempt to reinstall user plugins that were removed.
Installing the 'vagrant-aws' plugin. This can take a few minutes...
Fetching: iniparse-1.5.0.gem (100%)
Fetching: xmlrpc-0.3.0.gem (100%)
Fetching: formatador-0.2.5.gem (100%)
[...]
Fetching: faraday_middleware-0.14.0.gem (100%)
Fetching: vultr-0.4.3.gem (100%)
Fetching: vagrant-vultr-0.1.2.gem (100%)
Installed the plugin 'vagrant-aws (0.7.2)'!
Installing the 'vagrant-cachier' plugin. This can take a few minutes...
Installed the plugin 'vagrant-cachier (1.2.1)'!
Installing the 'vagrant-scp' plugin. This can take a few minutes...
Installed the plugin 'vagrant-scp (0.5.7)'!
Installing the 'vagrant-vultr' plugin. This can take a few minutes...
Installed the plugin 'vagrant-vultr (0.1.2)'!

La reinstalación como se puede ver, descargó nuevamente las gemas y las compiló junto con el plugin actualizado. Esto solucionó el problema definitivamente:

$ vagrant version
Installed Version: 2.2.7
Latest Version: 2.2.7

You're running an up-to-date version of Vagrant!

Espero esta información sea de utilidad pues me llevó un rato interesante llegar a la solución.

Docker tags

Buscar una imágen en docker es fácil con el comando docker search, pero luego que encuentras la imágen localizar las etiquetas disponibles ya no está al alcance del comando rápido… se requiere un consultar la respuesta json de una URL del registry.

Agregando este bloque de función al .bashrc

es posible tener un comando docker_tags que recibe por parámetro la imágen que se va a buscar y devuelve la lista de etiquetas disponibles:

$ docker_tags alpine
"20190707"
"20190809"
"20190925"
"3"
"3.10"
"3.10.1"
"3.10.2"
"3.8.4"
"edge"
"latest"

Si encuentras una mejora a esto, agradezco lo compartas en los comentarios.

exito ok

whois para nuevos TLDs

Los nuevos TLDs como guru, americanfamily, showtime y muchos otros son un desafío para el comando whois con cierta antigüedad, ya que no los pueden resolver y muestra el error:

No whois server is known for this kind of object.

La solución es configurar un archivo /etc/whois.conf con las referencias a los nuevos TLDs y los servidores whois que los resuelven.

Este gist es un archivo /etc/whois.conf pronto para pegar y tener resuelto el problema para la siguiente consulta whois que se haga con los nuevos TLDs.

Sobre escribir variables al invocar el shell script

Todos utilizamos variables de tipo constantes en nuestros shell scripts, que en principio no son modificables pues están en el código, un ejemplo simple:

#!/bin/bash
HOLA="Hola, soy el script"
echo $HOLA

así en cada ejecución de este script se mostrará el contenido de la variable HOLA:

$ ./hola
hola soy el script
$

Pero al definir/crear la variable podemos hacerlo con un contenido por defecto, que se usa en caso que la variable no tenga otro valor, mediante esta sintaxis de definición:

HOLA=${HOLA:-"Hola, soy el script"}

de esta forma HOLA tomará el valor que ya traiga o, en caso de ser nula, asignará el string indicado luego del :-

Esta sintaxis para la definición de las variables en nuestros script permite que se le pueda cambiar el valor al invocar el script, así:

$ HOLA="Hola, soy el shell" ./hola
Hola, soy el shell
$

También esta sintaxis de valor por defecto de las variables puede ser asignado directamente al invocarlas, utilizando una sintaxis equivalente:

#!/bin/bash
echo ${HOLA:-"Hola, soy el script"}

lo que simplifica el script, aunque puede distribuir los valores de las variables a lo largo y ancho del código así que a usarlo con cuidado.

Obviamente es algo muy documentado y explicado, aquí unos ejemplos:

Rocket Chat super rápido con Vagrant

Rocket Chat es un excelente sistema corporativo de chat completamente software libre (clientes y servidores), con todo el glamour de un sistema de chat moderno (canales, integración, componentes embebitos, chatbots, etc. etc.)

En este Vagrantfile es posible levantarlo de forma tan simple como escribir vagrant up

[pastacode lang=»ruby» path_id=»aX3qrbgr» highlight=»» lines=»» provider=»pastebin»/]

Publicar la llave pública SSH

Los principales repositorios (Gitlab y Github) exponen las llaves públicas SSH de sus usuarios de forma que están accesibles para descarga:

https://(gitlab|github).com/<usuario>.keys

Es la URL de donde se obtienen, y aquí las mías:

La ventaja es tener un sitio disponible donde está nuestra clave (y la de nuestros colegas) para usar en automatismos como esta task de Ansible:

- name: Enable pilasguru root access
  authorized_key:
    user: root
    state: present
    key: https://gitlab.com/pilasguru.keys
    validate_certs: False