miércoles, 25 de diciembre de 2019

nginx: [emerg] SSL error: key values mismatch



Solucionar error "key values mismatch" al recargar la configuración en NGINX.



Cuando instalemos un nuevo certificado SSL en NGINX, puede que nos encontremos con el siguiente error al ejecutar nginx -s reload (comando que carga los cambios efectuados en los archivos .conf):

nginx: [emerg] SSL_CTX_use_PrivateKey("/etc/ssl/name.key") failed (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch)

Este error se pude deber a 2 causas:


Causa 1:
Las claves pública/privada no coinciden



Esta causa se da cuando estamos enlazando una clave pública (crt) y una clave privada (key) que no coinciden. Es un problema común cuando hay varias partes involucradas en la instalación de un certificado SSL (la persona que genera el CSR, la que efectúa el pago del certificado, la que lo instala en NGINX...). En el tramo final del proceso, puede darse que la persona encargada de instalar los archivos acabe recibiendo un key y un crt que no hagan match.

Para solucionar este problema, deberemos buscar la key que sí combine con el crt, o en última instancia, volver a generar un nuevo crt en la entidad certificadora donde compramos el certificado SSL originalmente, en caso de que no encontremos el key y el crt que hagan match.

Para quien le interese, ya mostré cómo comprobar el match entre clave pública y clave privada de un certificado SSL mediante el comando openssl en una entrada anterior.


Causa 2:
Orden incorrecto en la concatenación de certificados



Otro de los causantes de este error es el orden de concatenacion de los certificados.

Al especificar un archivo crt en NGINX, no basta con especificar el dominio.com.crt como archivo en el apartado ssl_certificate, sino que debemos unificar el crt del dominio con los certificados intermedios y el certificado de nuestra entidad certificadora.

Este orden de unificación o concatenación debe ser el siguiente:

tu_dominio.crt) -> intermediario_1.crt -> intermediario_2.crt -> root_ca.crt

Para juntar todos los certificados en un solo archivo, podemos usar el siguiente comando:

HOST# cat tu_dominio.crt gd_bundle.crt >> dominio.chained.crt

Una vez concatenados los certificados, ya podemos usar el archivo resultante en el apartado ssl_certificate de NGINX para el dominio que queramos configurar.
0

miércoles, 18 de diciembre de 2019

Añadir discos a un Linux que corra sobre VMWare



Cómo añadir un disco a un sistema Linux que corre sobre VMWare sin reiniciar la máquina.



Con la llegada de los entornos virtuales llegaron nuevos desafíos, como por ejemplo, cómo añadir un disco a una máquina virtual encendida y hacer que esta lo detecte sin tener que reiniciar la máquina.

Para añadr un disco a una máquina virtual Linux que corra sobre VMware, lo primero que debemos hacer es añadir un disco a dicha máquina desde el hipervisor.

Al añadir un disco en caliente, Linux no se dará cuenta de que se le ha conectado nuevo hardware hasta que se lo indiquemos. Para ello, debemos usar sysfs para decirle al kernel que rescanee los buses (o channels, en terminología SCSI) con el fin de que el sistema operativo pueda ver el nuevo disco.


Método manual



Con el comando lsscsi, listamos todos los dispositivos SCSi detectados por el sistema:

HOST# lsscsi [1:0:0:0] cd/dvd NECVMWar VMware IDE CDR10 1.00 /dev/sr0 [2:0:0:0] disk VMware, VMware Virtual S 1.0 /dev/sda

Entre corchetes, encontraremos 4 números representados como [ <H> <C> <T> <L> ]

- <H> es el host adapter
- <C> es el channel (bus) en el host adapter.
- <T> es el target ID.
- <L> es el Logical Unit Number.

A continuación, buscaremos a qué host adapter está conectado el disco que acabamos de añadir:

HOST# grep mpt /sys/class/scsi_host/host?/proc_name /sys/class/scsi_host/host2/proc_name:mptspi

Con el comando anterior, hemos visto que el disco está conectado al host2. Ahora le diremos al kernel que reescanee todos los controladores de ese host adapter:

HOST# echo "- - -" > /sys/class/scsi_host/host2/scan

Los tres valores "- – -" representan:

- Channel (bus)
- SCSI target ID
- LUN

Los guiones son comodines que significan "reescanea todo".

Después del escaneo, comprobamos que el sistema operativo ya ve el disco:

HOST# lsscsi [1:0:0:0] cd/dvd NECVMWar VMware IDE CDR10 1.00 /dev/sr0 [2:0:0:0] disk VMware, VMware Virtual S 1.0 /dev/sda [2:0:1:0] disk VMware, VMware Virtual S 1.0 /dev/sdb


Alternativa: rescan-scsi-bus.sh



Alternativamente, podemos reescanear los adaptadores SCSI con el comando rescan-scsi-bus.sh del paquete sg3_utils. Este script hace todo el proceso anterior automáticamente:

HOST# rescan-scsi-bus.sh -a

Alguna gente es crítica con este script, quejándose de que a veces falla. Personalmente, debo decir que siempre que lo he usado me ha funcionado la mar de bien.


Fuentes:

http://systemadmin.es/2017/06/hacer-un-rescan-de-discos-iscsi
https://ssh.guru/adding-and-removing-disks-from-linux-guest/
https://blog.fpmurphy.com/2017/05/adding-and-removing-disks-from-vmware-rhel7-guests...
0

miércoles, 11 de diciembre de 2019

Incrementar tamaño de un volumen EBS en Linux



Cómo aumentar el tamaño de un volumen EBS en una instancia EC2 Linux en AWS.



A continuación, mostraré cómo subir el tamaño de un disco o volumen de una instancia Linux alojada en Amazon Web Services y cómo ver el nuevo tamaño en el sistema operativo.

Para este ejemplo, el disco a ampliar será un disco de 60 GB llamado "xvdf" montado en la partición /mnt. La ampliación se hará en caliente, sin parar la máquina ni desmontar el punto de montaje.

admin@ip-10-250-4-93:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 80G 0 disk └─xvda1 202:1 0 80G 0 part / xvdf 202:80 0 60G 0 disk /mnt

Para ampliar el disco, debemos ir a la consola web de AWS y buscar la opción "Volumes". Una vez dentro, seleccionamos el disco a subir de tamaño e incrementamos su Size:



Una vez modificado el tamaño del disco, nos conectamos por SSH a la instancia y lanzamos el comando lsblk. Tras unos instantes - y sin hacer nada más en la terminal - deberíamos ver el nuevo tamaño del disco en pantalla (vemos que el disco xvdf tiene ahora un tamaño de 70 GB):

admin@ip-10-250-4-93:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 80G 0 disk └─xvda1 202:1 0 80G 0 part / xvdf 202:80 0 70G 0 disk /mnt

Aun viendo que el tamaño del disco es 70 GB, el punto de montaje /mnt aún no ve el nuevo espacio:

admin@ip-10-250-4-93:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 7.9G 0 7.9G 0% /dev tmpfs 1.6G 12M 1.6G 1% /run /dev/xvda1 79G 1.1G 75G 2% / tmpfs 7.9G 0 7.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup tmpfs 1.6G 0 1.6G 0% /run/user/1000 /dev/xvdf 59G 53M 56G 1% /mnt

Para que /mnt vea los 70 GB, usaremos el comando resize2fs para extender el filesystem en caliente:

admin@ip-10-250-4-93:~$ sudo resize2fs /dev/xvdf resize2fs 1.43.4 (31-Jan-2017) Filesystem at /dev/xvdf is mounted on /mnt; on-line resizing required old_desc_blocks = 8, new_desc_blocks = 9 The filesystem on /dev/xvdf is now 18350080 (4k) blocks long.

Volvemos a ejecutar un df y ya vemos el tamaño correcto:

admin@ip-10-250-4-93:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 7.9G 0 7.9G 0% /dev tmpfs 1.6G 12M 1.6G 1% /run /dev/xvda1 79G 1.1G 75G 2% / tmpfs 7.9G 0 7.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup tmpfs 1.6G 0 1.6G 0% /run/user/1000 /dev/xvdf 69G 52M 66G 1% /mnt

A partir de este momento, ya podemos usar el nuevo espacio asignado.
0

miércoles, 4 de diciembre de 2019

Cron: ejecutar script el primer lunes de cada mes



Cómo hacer que un script se ejecute el primer lunes de cada mes en Linux.



Los que conozcáis cron sabréis que es una utilidad que sirve para ejecutar scripts (o comandos) de forma recurrente en entornos Linux. Cron permite elegir el minuto, hora, dia, mes y día de la semana en que ejecutar un script automáticamente.


Ejecutar script el día 1 de cada mes



Siguiendo lo mencionado anteriormente, para hacer que un script se ejecute automáticamente el dia 1 de cada mes a las 2:00 de la madrugada, debemos usar la siguiente sintaxis en crontab:

0 2 1 * * /ruta/script.sh


Ejecutar script el primer lunes de cada mes



Puede que nos interese ejecutar un script, ya no el día 1 de cada mes, sino el primer lunes de cada mes, de modo que al entrar a la oficina a las 8:00h podamos actuar dependiendo del resultado generado por el script. Y que sea crítico que se ejecute el lunes porque sí o sí estaremos a la mañana siguiente en el trabajo, cosa que no pasaría si el día 1 de ese mes fuese sábado (por ejemplo).

NOTA: sí, puede que haya lunes que sean festivos...

La forma en la que está diseñado cron no contempla este tipo de planificación, pero eso no significa que no se pueda llevar a cabo. Para conseguir que un script se ejecute el primer lunes de cada mes a las 2:00h (por ejemplo), podemos usar la siguiente parametrización en crontab:

0 2 1-7 * * [ "$(date '+\%u')" = "1" ] && /ruta/script.sh

Lo que estamos haciendo es ejecutar un script y luego otro. Recordemos que, en bash, el operando && indica "si se cumple la condición anterior, ejecuta el comando siguiente". Es decir, si el día de la semana equivale a 1 (lunes), ejecuta el script.

En el primer script, vemos cómo se escapa el caracter % con el uso de comillas simples y \. Esto es necesario, puesto que si no se escapa el caracter, el comando no se ejecuta en cron. Sin más.


Número vs Nombre



Se podría usar [ "$(date '+\%a')" = "Mon" ] para comprobar si el día es lunes, pero entonces el script solo funcionaría en sistemas con el locale inglés. Si nuestro sistema estuviera en español, necesitaríamos compararlo con "lun", si estuviera en francés, con "lundi", etc.

Para evitar problemas con el idioma del sistema operativo, considero que es mejor usar el número del día (%u) en vez de usar el nombre del día (%a), ya que los números son universales, cosa que nos permitirá pasar esta entrada cron de un sistema a otro sin importar los locales.


Alternativa



De forma alternativa, se podría ejecutar el script cada lunes y dentro del script en sí comprobar si ese lunes es el primero del mes actual. Si es el primer lunes, seguir con la ejecución, y sino, ejecutar un simple "exit" para salir del script. Pero considero que esta opción gasta más tiempo de procesador.


Conclusión



Aunque cron no esté diseñado explícitamente para permitirnos ejecutar un script el primer dia X de cada mes, hemos visto cómo podemos llevar a cabo esta tarea usando simples comandos de bash.
3