Category Archives: Linux

Conexión de OpenVPN reiniciándose frecuentemente

OpenVPN es uno de los servidores de VPN más populares en nuestro mundo de Linux. En mi caso lo vengo utilizando hace unos 15 años, quizá más.

El día de ayer un cliente amigo (dueño de una PYME) me contactó que las conexiones hacia el servidor de VPN que le instalé hace varios años en su empresa le había comenzado a fallar. Lo que reportaba era que cada pocos minutos, a veces un minuto, a veces un poquito más, la conexión se le cerraba y tenía que volver a reconectarse.

Me llamó mucho la atención pues es un servidor que la verdad no toco, entro infrecuentemente al servidor, poquitas veces al año. Es un servidor puramente dedicado a OpenVPN, no realizan ninguna actividad en él. El servidor simplemente está ahi atendiendo las poquitas conexiones de VPN que maneja.

Es una persona muy proactiva y me envió el log de su cliente de VPN, copio aquí la parte más relevante:

Mon Jan 15 18:36:43 2024 us=578145 Initialization Sequence Completed
Mon Jan 15 18:36:43 2024 us=578145 MANAGEMENT: >STATE:1705361803,CONNECTED,SUCCE
SS,10.8.0.42,1.2.3.4,1194,,
Mon Jan 15 18:40:43 2024 us=841400 [server] Inactivity timeout (--ping-restart),
restarting
Mon Jan 15 18:40:43 2024 us=842159 TCP/UDP: Closing socket
Mon Jan 15 18:40:43 2024 us=842662 SIGUSR1[soft,ping-restart] received, process restarting
Mon Jan 15 18:40:43 2024 us=842662 MANAGEMENT: >STATE:1705362043,RECONNECTING,ping-restart,,,,,
Mon Jan 15 18:40:43 2024 us=842662 Restart pause, 5 second(s)

Encontré muchos comentarios en Internet con posibles soluciones, desde que los algoritmos de cifrado, hasta algo que me interesó mucho y era que el ping del cliente no coincidía con el ping del servidor, o que se debía usar keepalived. En verdad tiene muchas razones.

Pero hay una razón más, que me parece importante, y es que este problema también sale cuando hay una diferencia de hora entre el OpenVPN cliente y el OpenVPN servidor. Incluso si la diferencia de hora es pequeña (en el orden de segundos). Esto puede suceder.

Y me pareció la explicación más lógica porque es un equipo al que no se le hacen mayores cambios. La configuración que se usa es la misma durante varios años, por lo que si fuera un problema de configuración, hubiera sucedido ya hace mucho tiempo.

Alternativas de mitigación

Una propuesta de mitigación que encontré es configurar al servidor para que renegocie el canal (reneg-sec) en un periodo de tiempo más extendido. Por ejemplo, para que se renegocie el canal cada 8 horas. Así al menos la conexión, una vez negociada, duraría quizá 8 horas.

Por defecto el parámetro reneg-sec está en una hora, por lo que la sesión se renegocia cada una hora si esta no está definida.

El problema con reneg-sec es que debe ajustarse tanto en el cliente como en el servidor, ya que OpenVPN usará el menor valor definido en ambos extremos. Por ejemplo, podemos poner reneg-sec 86400 (un día) en el servidor, pero si tenemos reneg-sec 7200 (2 horas) en el cliente, entonces la renegociación ocurrirá cada 2 horas, el valor menor.

Imagínate si tuvieras decenas de clientes en diferentes partes del país, o en diferentes países, cómo cambiarías el reneg-sec en ellos?

Además, como indicaba la persona que proponía el cambio es que esto realmente es una mitigación porque no resuelve el problema, sino que lo dilata para que ocurra una vez cada 8 horas.

Solución propuesta

Y un problema adicional: mi amigo no tiene el parámetro reneg-sec configurado ni en clientes ni en servidor. Por lo tanto el periodo de renegociación es el valor por defecto de 3600 segundos. Y no sé si recuerdan que mencioné que realmente él no podía casi ni navegar, el OpenVPN se le desconectaba cada pocos minutos (1 o 2 minutos).

Entonces noto que la hora del servidor estaba desplazada, estaba adelantada más de 7 segundos respecto a la hora oficial.

Instalé y activé el servicio de NTPd en el servidor y una vez que el servidor tuvo la hora correcta, el problema ya no ocurrió más!

Lo más probable es que este servidor no se había apagado en varios años, pero, en vista de los apagones que han estado sucediendo en el país, posiblemente le pusieron un UPS que no está entregando una frecuencia estable, quizá no está a 60hz y al servidor lentamente la hora se le ha ido corriendo. Esta es mi opinión, puede ser por muchas razones más, pero creo que está relacionada con el problema energético ya que esto le comenzó a suceder recientemente luego de muchos años trabajando normalmente.

Conclusiones

Es importante tener este posible problema en cuenta. En este caso el problema estaba en el servidor. Pero debemos también pensar que puede ocurrir en uno de los clientes. En este último caso el problema se manifestaría solamente en un cliente.

Sugerimos que se instale y mantenga activo un servicio de tiempo (NTPd o Chrony) en nuestros servidores, todos, ya que como podemos ver, el mantener la hora correcta en nuestros servidores es fundamental por muchas razones.

Add LUKS partition to Orange PI 5b

Yesterday I got a brand new Orange PI 5b, and installed Ubuntu 22.04 in it. Everything went smoothly. My Orange Pi 5b has 16GB RAM, 256GB MMC Disk, 8 CPU. And yes, it runs quite fast.

I guess these instructions can work for other versions of Orange PI, but this was tested for Orange Pi 5b

I plan to use it for my travel desktop, with a 14-inch LED HDMI flat screen, keyboard, and mouse.

I’m used to and can not live without having my data encrypted. So in case it is lost or stolen, my information will remain confidential.

But the recommended steps to install Ubuntu in my Orange PI 5b do not include a way to encrypt the /home filesystem

When installed, it simply splits the disk into two partitions:

  • /dev/mmcblk0p1, 512MB, where the kernel and initrd image resides, and
  • /dev/mmcblk0p2, where the / filesystem is, using the rest of the disk

I prefer not to encrypt the / filesystem, for several reasons like, it is costly, hardware-wise, having to encrypt/decrypt every time we read or write any file in the system. So I prefer only to encrypt the /home dir.

Download Ubuntu-22.04 for Orange PI 5b from

https://github.com/Joshua-Riek/ubuntu-rockchip/releases
Specifically, the one named “ubuntu-22.04.3-preinstalled-desktop-arm64-orangepi-5b.img.xz”

There is no current way to install Ubuntu directly to the MMC disk, so we use two stages:

  • using another Linux workstation we copy the image to a microSD
  • Then we boot our Orange PI 5b from that SD
  • Using the provided scripts, we install, we transfer the contents of the SD to the MMC disk.
  • Finally, we power off the Orange PI 5b, remove the SD card, and we can start our Ubuntu from the MMC disk.

1- Copy Ubuntu to the SD

Do this from a Linux desktop computer, I guess it could be done in Windows or Mac as well using their tools to copy images to SD cards:

fdisk -l <- find where your SD card is. In my case, it is on /dev/sdX
xz -dc ubuntu-22.04.3-preinstalled-desktop-arm64-orangepi-5b.img.xz|sudo dd of=/dev/sdX

extract the SD card from your Linux desktop

2- Boot from SD

Insert the SD card into your Orange PI 5b and start it.

It won’t be long until it is booted, a small configuration wizard is shown, and you are in.

3- Install Ubuntu into your MMC.

My MMC is on /dev/mmcblk0, you can find it by using:

fdisk -l 

and look for the MMC disk (checking the disk size for example)

This will install Ubuntu to your MMC, it may take some minutes, depending on the speed of your SD card, etc.

sudo u-boot-install-mtd /dev/mmcblk0
sudo ubuntu-rockchip-install /dev/mmcblk0

We will then install gparted, and reduce /dev/mmcblk0p2 to, for example, 25GB, leaving the rest of the disk free, and unused.

apt update
apt install gparted
gparted /dev/mmcblk0
Inside gparted, reduce /dev/mmcblk0p2 to approx 25GB

4- Create the luks partition

We can then create a new partition /dev/mtdblock0p3, create it with luks, open the luks, and format the luks mapped device:

fdisk /dev/mmcblk0 <- Create /dev/mtdblock0p3
cryptsetup luksFormat --pbkdf-memory 512000 /dev/mmcblk0p3
cryptsetup luksOpen /dev/mmcblk0p3 homefs
mkfs.ext4 /dev/mapper/homefs

NOTE: If you lose your luks password your info is lost, and there is no way to recover it easily.

chrooting into the MMC disk

Now, we will mount everything under /mnt/chroot

mkdir /mnt/chroot
mount /dev/mmcblk0p2 /mnt/chroot
mount /dev/mmcblk0p1 /mnt/chroot/boot
mount /dev/mapper/homefs /mnt/chroot/home
mount -t proc none /mnt/chroot/proc/
mount -t sysfs none /mnt/chroot/sys/
mount -o bind /dev /mnt/chroot/dev/
mount -o bind /dev/pts /mnt/chroot/dev/pts/

We copy the contents of /home into /mnt/chroot/home, there should not be too much info, just the skel of the user you just created when it was installed above.

rsync -avPH /home/* /mnt/chroot/home/

Configuring luks

Now we take note of the luks partition (/dev/mtdblock0p3) UUID as we will need it when defining the luks partition in the next steps:

blkid

/dev/mmcblk0p3: UUID="571c8ca6-4332-4fda-a856-52d8dd0d6a92"

We then chroot into /mnt/chroot

LANG=C chroot /mnt/chroot/

And edit /etc/crypttab adding just one line, notice the UUID is the one we found above!

homefs UUID="571c8ca6-4332-4fda-a856-52d8dd0d6a92" none luks,initramfs,discard

In /etc/fstab we add a new line requesting our system to mount the mapped filesystem (the one created when luks is opened) in /home:

/dev/mapper/homefs /home ext4 discard,errors=remount-ro 0 0

We are about to finish! We have not to indicate the system that, on boot, it should request for the luks password to decrypt the disk when booting:

echo "CRYPTSETUP=y" >> /etc/cryptsetup-initramfs/conf-hook

We then create, and update our initramfs to include the new devices/modules (dm-crypt) needed when initially booting.

update-initramfs -u

Sites consulted

I used the following sites as a guide to creating this document. They were mostly for Debian and for using luks for/in Ubuntu. And created my steps to reach my goal: to encrypt /home partition in Ubuntu 22.04 for Orange Pi 5b.

https://github.com/Joshua-Riek/ubuntu-rockchip/discussions/435
https://habet.dev/blog/raspberry-pi-encrypted-boot-with-ssh/
https://askubuntu.com/questions/1287837/luks-disk-encryption-on-raspberry-pi-4-and-ubuntu-desktop-20-10
https://gist.github.com/cpainchaud/bac37abd5e3274c33f143c85c94dbed1

Migrando una VM desde OpenVZ a KVM

Este post es muy interesante, relacionado con respaldos con rsync, manejo de máquinas virtuales, paquetes de Linux, manejo de la red.

En este post vemos una breve introducción a OpenVZ y KVM para entrar de lleno al proceso de migración de un sistema de virtualización al otro.

OpenVZ es un sistema de virtualización de Sistema Operativo muy popular, similar a LXC que permite a un sistema operativo Linux correr múltiples instancias a las cuales popularmente se les conoce como VPS.

Este tipo de virtualización basada en sistema operativo tiene la característica de que todas las máquinas virtuales que en ella corren, lo hacen usando el mismo único kernel que el hospedero tiene.

Tiene algunas desventajas, entre ellas que, ante un fallo en el kernel, todas las VPS se verían afectadas y que si un cliente necesita una versión diferente del kernel esto no será posible.

Ahora, tiene cosas buenas como el hecho de que es más rápido el funcionamiento del kernel ya que todas usan el mismo kernel y además que la memoria que no usa un VPS será aprovechada por otro VPS.

¿Por qué migrar desde OpenVZ?

Ocurren ocasiones en que es necesario migrar una VPS en OpenVZ hacia un sistema con full virtualización; por ejemplo porque se necesita utilizar las características de aislamiento típicas de un sistema full virtualizado como KVM, por ejemplo porque se requiere un kernel específico.

O porque nuestro proveedor de VPS va a dejar de ofrecernos el servicio,

Otra razón, la más común, es que necesitamos un manejo más certero de recursos como RAM, necesitamos que la RAM que adquirimos para nuestra VPS nos esté garantizada para nuestra máquina virtual, esto debido a que muchos proveedores de OpenVZ hacen lo que se llama “overselling” que es ofrecer a los clientes recursos que no se tienen realmente. Por ejemplo, tienen un servidor con 128GB de RAM y venden a sus clientes 10 máquinas virtuales de 24GB cada una. Si multiplicamos 10*24G=240G, que es mucho mayor que los 128GB que tienen. Esto es posible ya que OpenVZ permite utilizar la memoria que un cliente no usa, puede que un ciente de sus 24GB de RAM “comprados”, realmente use 8GB, y el resto lo tenga libre y solamente lo use en picos en ciertas horas del día. Esto permite al proveedor aprovechar esos 16GB para que en el mismo servidor corran otras máquinas de otros clientes.

Esto usualmente no causa problemas ya que usualmente no todas las máquinas usan toda la memoria todo el tiempo, es posible que una máquina use toda la memoria ahora, pero dentro de 5 minutos ya use solamente el 20% de esta, y entonces otra máquina comience a usar toda la RAM pero luego de 15 minutos ya use solamente el 15%. Como podemos ver, se tiene la esperanza de que la memoria se pueda ir compartiendo: una vez se usa para un grupo de clientes, pero luego para otro, etc.

El problema radica en que si en un determinado momento varios clientes, por diversas razones, comienzan a utilizar toda la memoria que reservaron, el servidor se quedará sin memoria. Existen técnicas como el uso de la SWAP, pero eventualmente se agota además de ser lenta.

Debe tenerse mucho cuidado con los proveedores de VPS ya que muchos, en el afán de ganar dinero, sobrevenden bastante agresivamente sus servidores. Siempre es saludable pensar que si un VPS es muy muy barato para las características que ofrecen, es síntoma de que se está sobrevendiendo agresivamente (mucho).

Lo contrario ocurre con proveedores que ofrecen virtualización completa (full virtualization) basada en KVM, Xen, VMWare. Los sistemas de full virtualización sí permiten la sobreventa de ciertos recursos (usando KSM para la RAM por ejemplo). Pero típicamente cuando vemos nombres como KVM, Xen o VMWare, esto significa que los recursos que vamos a contratar estarán disponibles para nuestra VM.

¿Qué problema tenemos al migrar desde OpenVZ?

El problema principal al migrar desde OpenVZ es que sus VPS no tienen el paquete “kernel” instalado entonces, aunque logremos convertir su disco duro (que está en formato ploop) hacia, digamos, qcow2, este no arrancará en nuestro KVM pues no existe un kernel para arrancar.

Esto no es un defecto, es una característica de OpenVZ, recordemos que las VPS no contienen un kernel propio sino que usan el kernel del hospedero. Pero las máquinas virtuales full virtualizadas sí necesitan tener su kernel cada una.

Procedimiento para migrar

El procedimiento en sentido general es bien sencillo, pero lleva una serie de pasos que debemos seguir con mucho cuidado.

Digamos que tenemos una VPS en OpenVZ que por comodidad llamaré “Servidor anterior” y tendremos una VM en KVM hacia la que queremos migrar el servidor anterior. A esta VM le llamaré “Servidor nuevo”. Anota esto en algún ugar.

Los siguientes pasos en algunos casos pueden ser realizados en diferente orden, o de forma paralela. Pero bueno, sigamos en esta orden:

Servidor anterior:

  • Ahorra espacio, borra todo lo que puedas borrar para agilitar la transferencia. Mientras más contenidos tengas, más tiempo demorará la transferencia.
  • Si es posible, disminuye el tamaño de los logs:
journalctl --vacuum-size=10M
  • Actualiza el sistema operativo y reinicia la máquina para validar que todo funcione luego de actualizar. Es importante actualizar ya que es muy útil que ambos servidores, el anterior y el nuevo, estén en la misma versión, y la forma de garantizar esto es que ambos estén actualizados.
  • Es importante reinciar ya que no queremos culpar a la migración por algo que falla desde antes. Ocurre que hay ocasiones en que luego de reiniciar no arranca algún servicio y es porque no estaba activado por defecto. En fin, es importante estar seguros que el servidor anterior funciona correctamente!
yum -y update && yum clean all && reboot
  • Anotemos la versión de Linux que corremos, pues esa misma versión debemos instalar en el nuevo servidor.
cat /etc/centos-release
AlmaLinux release 8.9 (Midnight Oncilla)

En este caso, es un AlmaLinux versión 8.

El release (.9) lo logramos en ambos servidores haciendo yum update. Es importante manteer la misma versión y release ya que ahorraremos tiempo al copiar archivos y a que algunos archivos que no existen en el servidor viejo (el kernel por ejemplo) los tendremos en el nuevo, todo con la misma misma versión.

Servidor nuevo:

  • Instalaremos la misma versión que en el server viejo. En mi ejemplo será AlmaLinux 8.
  • Instalo el paquete rsync. Este es el comando que usaremos para sincronizar por lo que debe existir en ambos servidores:
yum -y install rsync
  • Una vez instalado, le procedo a actualizar, con esto le llevaré al mismo release del servidor viejo que ya teníamos actualizado.
cat /etc/redhat-release; yum -y update &&  reboot
AlmaLinux release 8.9 (Midnight Oncilla)

Como podemos ver, tenemos la misma versión y release (8.9) que el servidor anterior. He reiniciado para estar seguro que el servidor arranca con el nuevo kernel, y que arranca correctamente.

Una vez más, reiniciamos para diferenciar si un futuro problema que tengamos con el reinicio, sea por la copia de los archivos y no de la actualización.

Copiamos los contenidos del archivo de configuración de red.

cat /etc/syscofig/network-scripts/ifcfg-eth0

En mi caso mi archivo se llama ifcfg-eth0, en tu caso puede variar. Es importante anotar los contenidos de la configuración de la red ya que al sincronizar los archivos en el siguiente paso, el rsync borrará los archivos que no existan en el servidor viejo, y este es uno de ellos.

Servidor viejo:

Regresamos ahora al servidor viejo, vamos a copiar los contenidos del viejo al nuevo. Vamos a instalar rsync, apagar mysqld; o mariadb, o postgresql, el que tengas.

Apagaremos el servidor de mysql para que no queden transacciones inconsistentes. Al finalizar la transferencia le volvemos a encender. Aquí ves la importancia de haber borrado cualquier archivo o contenido que ya no uses, como te mencioné al inicio, esto es para que la transferencia no demore mucho ya que la BD estará apagada durante todo este tiempo.

yum -y install rsync
systemctl stop mysqld (o mariadb, o postgresql)
rsync --exclude=/etc/fstab --exclude=/boot --exclude=/proc --exclude=/lib/modules/ --exclude=/etc/udev --exclude=/lib/udev --exclude=/sys -e ssh --delete --numeric-ids -avpogtStlHz / root@IPDELSERVERNUEVO:/
systemctl start mysqld

Este proceso tomará tanto tiempo como contenidos tengas que transferir del servidor viejo a la IP del servidor nuevo. Y de la velocidad de la red. Puede tomar algunos minutos, o algunas horas, toca esperar.

Tip!

Hay ocasiones en que no queremos tener la BD apagada tanto tiempo, esto es lo que yo hago!:

  • Sincronizo con rsync, sin apagar la BD
  • Cuando la sincronía acabe, luego de varios minutos, horas o días: apago la BD en ambos servidores, viejo y nuevo, y vuelvo a sincronizar.
  • Como ya los contenidos estaban previamente sincronizados, el rsync solamente sincronizará los archivos que hayan cambiado, que serán infinitamente menos que la sincronía inicia.

Servidor nuevo:

Ya estamos finalizando! Ahora vamos a hacer unas tareas finales, que son las más importantes:

Borramos la configuracion de red del openvz ya que no nos sirve en el servidor nuevo. Y copiemos la configuraciónde ifcfg-eth0 que guardamos en los pasos anteriores. Al hacer rsync, este archivo fue borrado ya que no existe en el origen:

cd /etc/sysconfig/networ-scripts
rm ifcfg-venet*
vi ifcfg-eth0  (aqui copio los contenidos que guardé antes)

Reiniciamos el servidor nuevo para ver que arranque correctamente:

reboot

A mi siempre me arranca correctamente. La red me funciona, todo ok.

Procedo como paso final a instalar el paquete kernel. Este último paso es confuso para algunas personas porque, cómo es posible que el sistema ya arranque si no tiene el paquete kernel?

Lo que sucede es que el archivo del kernel sí existe, está, existe gracias a que instalamos la máquina nueva virtual con la misma versión y release. Estos archivos no fueron borrados porque al hacer rsync hicimos dos exclude importantes: el exclude de /boot y el exclude en /lib/modules que es donde se guardan el kernel y sus módulos.

El problema radica en que la BD de rpm /var/lib/rpm sí fue sobreescrita cuando se hizo el rsync, y recuerden que el viejo sistema no contiene el paquete kernel ya que OpenVZ no necesita este paquete. Es por eso que tenemos el kernel instalado, pero no tenemos el paquete en la BD.

Si no hacemos este último paso, el sistema funcionará maravillosamente, pero a la hora de actualizar los paquetes, al no existir evidencia en la BD de paquetes del kernel, no lo actualizará posiblemente. Por esto hagamos:

yum install kernel

Y para validar que nada haya cambiado, reiniciamos:

reboot

Resumen

Como podemos ver, el proceso es bastante sencillo, he tomado mi tiempo en describirlo completamente para que se comprenda el por qué de cada paso, pero si nos fijamos bien, son pocos pasos, quizá unos 15.

Una forma de reducir el tamaño de un qcow2 para respaldar

El sistema de virtualización por excelencia en Linux es KVM (libvirt). Las máquinas virtuales en KVM usualmente almacenan su disco en formato QCOW2.

QCOW2 utiliza, en principio, solamente el espacio que requiere, digamos que tenemos un disco QCOW2 de 50GB de tamaño, sin embargo esto no significa que el archivo .QCOW2 utilizará 50GB en disco desde un inicio. Sino que utilizará lo que se va realmente almacenando, digamos que estamos utilizando 8GB de este disco, entonces QCOW2 utilizará aproximadamente 8GB de los 50GB del disco.

A medida que pasa el tiempo, el sistema operativo irá realizando escrituras en diversas partes del disco, creando archivos, actualizándolos, y también eliminándolos. Esto irá provocando que el espacio realmente utilizado vaya difiriendo del espacio utilizado por el archivo de disco de QCOW2. Pasado un tiempo, digamos que nuestro sistema operativo está ocupando 12GB, sin embargo el tamaño del disco del QCOW2 puede ser de, por ejemplo, 29GB.

A veces nos topamos conque queremos dar de baja ya a una máquina virtual, no le usaremos más (o al menos durante mucho tiempo) . Y queremos guardar un respaldo de ella. Tomemos el ejemplo anterior: definitivamente sería mejor almacenar solamente el espacio utilizado (12GB) que no los 29GB que actualmente tiene el QCOW2. Nos ahorramos 17GB de espacio.

Aunque existen muchas técnicas para reducir el tamaño del QCOW2, hoy experimenté con una de ellas que consiste en utilizar el comando virt-sparsify.

virt-sparsify es un binario parte del paquete guestfs-tools, por lo que debemos verificar que este paquete esté instalado. Para CentOS podemos ejecutar:

sudo yum install guestfs-tools

virt-sparsify en principio fue concebido como un comando que llena de 0 los espacios declarados como vacíos en un disco. Al llenarse de 0, puede aprovecharse esos 0 para comprimir todo ese espacio conteniendo la misma información. De esta forma logramos librarnos de contenidos escritos en disco que ya no nos son de valor (porque ya fueron declarados como borrados).

Para ellos utilizamos:

[root@backups respaldos]# virt-sparsify mivm.qcow2 --compress mivm-new.qcow2

Lo que hará será leer los contenidos de la VM ‘mivm.qcow2’ y los escribirá hacia la salida ‘mivm-new.qcow2’, comprimiendo sus contenidos.

En mi caso fallaba al iniciar indicándome que no había espacio en TMPDIR, pues TMPDIR por defecto es /tmp/, lo que hice fue, antes de volverlo a ejecutar cambié el contenido de la variable TMPDIR hacia /respaldos/tmp ya que en la partición donde está /respaldos/ yo sí tenía espacio suficiente:

mkdir /respaldos/tmp
export TMPDIR=/respaldos/tmp

y volví a repetir la operación. Ten en cuenta que tengo un disco duro con varios TB disponibles montado en /respaldos/, es por eso que opero con /respaldos/

El proceso puede tomar tiempo, incluso horas, depende del disco duro, y al finalizar podemos probar que mivm-new.qcow2 pueda ser leído

guestmount -a mivm-new.qcow2 -i /mnt
ls /mnt
umount /mnt

Si efectivamente podemos leer los contenidos, entonces ya con tranquilidad podemos borrar el qcow2 original (mivm.qcow2 en mi caso).

Por último: ¿qué hace guestmount? Es un comando muy interesante y que merece su propio post aparte. guestmount es un comando que te permite “abrir”, montar, un disco qcow2 y poder ver sus contenidos. En este caso lo utilicé para simplemente validar que el disco duro se podía acceder y ver sus contenidos (lo monté en /mnt), pero sirve para mucho más, por ejemplo un cliente al que no le arranca la red, puedes apagar la máquina (guestmount y virt-sparsify deben utilizarse con la VM apagada!), y puedes montar el disco y corregir cualquier falla en la configuración de la red que el usuario necesite, y entonces desmontar el disco montado con guestmount y volver a arrancar la VM.

Compiling FLRig for raspbian/Ubuntu

  • Download the source code http://www.w1hkj.com/files/flrig/
  • untar the source code
  • cd flrig*/
  • sudo apt-get install checkinstall libxft-dev fltk1.3
  • ./configure
  • make -j4
  • sudo checkinstall

That’s it!

Agregar HP Laserjet m175A en debian buster

  1. Instalar cupsd
    1. sudo apt install cups cups-client cups-filters cups-ipp-utils
  2. Configurar cupsd para que escuche desde 0.0.0.0
    1. cupsctl –remote-admin –remote-any –share-printers
  3. Instalar drivers para pixma
    1. apt -y install hp-ppd hplip
  4. Acceder a cupsd desde el browser: https://laip:631
  5. Agregar nueva impresora
  6. Buscar en la lista de drivers HP y la versión de pixma que tengamos
    1. buscar lentamente hp laserjet color pro m175a, está desordenado. La m176n me funciona bien, pues no me apareció la m175a

Agregar canon pixma g2100 en debian buster

  1. Instalar cupsd
    1. sudo apt install cups cups-client cups-filters cups-ipp-utils
  2. Configurar cupsd para que escuche desde 0.0.0.0
    1. cupsctl –remote-admin –remote-any –share-printers
  3. Instalar drivers para pixma
    1. sudo apt install printer-driver-gutenprint
  4. Acceder a cupsd desde el browser: https://laip:631
  5. Agregar nueva impresora
  6. Buscar en la lista de drivers CANON y la versión de pixma que tengamos

docker de joomla con letsencrypt

Hace unos meses publicamos cómo echar a andar joomla con ssl vía letsencrypt. En el archivo adjunto a este post pueden encontrar al docker-compose.yml que creamos en este video. El archivo adjunto está comprimido con .gz para que los filtros de este sitio me permitan subirlo.

Nuestro docker no resuelve DNS

hoy mientras instalaba un nuevo docker en CentOS-8 me topé por segunda ocasión que el contenedor no resolvía nombres de domino.

Cuando intentaba realizar alguna operación dentro del contenedor que requería resolver un nombre me devolvía error de que no podía resolver.

Por ejemplo, el contenedor era de CentOS, y cuando intentaba instalar un paquete (yum install….) me devolvía:

Cannot find a valid baseurl for repo: base/7/x86_64

Pero, puede ocurrir con cualquier otro comando (apt, dnf, ping, wget, curl, etc).

Para validar que efectivamente era un problema de mi servidor y no del contenedor en específico probé un docker muy sencillo “busybox” que tiene el conocido comando ping:

docker run --rm busybox ping -c 1 8.8.8.8
...
64 bytes from 8.8.8.8: seq=0 ttl=116 time=18.972 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss

Como se puede ver, hace perfectamente ping desde un contenedor hacia 8.8.8.8

Ahora probaré lo mismo pero con un nombre, para que se vea obligado a resolver

docker run --rm busybox ping -c 1 www.google.com
ping: bad address 'www.google.com'

¡Efectivamente falla! no puede resolver una dirección.

Esto se debe a que en el firewall de nuestro CentOS-8 no se están permitiendo la resolución de nombres. Agrego la interfaz docker0 a la lista de interfaces confiables:

sudo firewall-cmd --permanent --zone=trusted --add-interface=docker0
sudo firewall-cmd --reload

Y ahora pruebo:

docker run --rm busybox ping -c 1 www.google.com
PING www.google.com (172.217.170.4): 56 data bytes
64 bytes from 172.217.170.4: seq=0 ttl=116 time=18.897 ms
--- www.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 18.897/18.897/18.897 ms

Trabajó al 100% luego de esto!

Compiling WSJT-X for armbian

This small tutorial will show you how to build and install wsjt-x for your ARMBIAN. In my case I have an OrangePI PC board and armbian buster desktop. But this tuto should work for any other board. It should also work for any other Linux and architecture. E.g.: raspios, debian, ubuntu, etc.

I followed this tutorial for Linux Mint:

http://kb4lhp.blogspot.com/2018/12/recipe-for-building-and-installing-new.html

Lets start by installing some requirements:

sudo apt-get install build-essential checkinstall texinfo gfortran libfftw3-dev qt5-default qttools5-dev qttools5-dev-tools libqt5svg5-dev qtmultimedia5-dev asciidoctor libqt5serialport5-dev libqt5multimedia5 docbook-xsl xsltproc libxml2-utils dpkg cmake libusb-dev libusb-1.0 libudev-dev

Then download the latest tgz from https://physics.princeton.edu/pulsar/K1JT/wsjtx.html ex;

wget https://physics.princeton.edu/pulsar/K1JT/wsjtx-2.2.2.tgz 

Lets extract the contents of this package and cd into the directory:

tar zxf wsjtx-2.2.2.tgz
cd wsjtx-2.2.2

And then, lets configure and build wsjtx:

cmake -DWSJT_SKIP_MANPAGES=ON -DWSJT_GENERATE_DOCS=OFF .
cmake --build .

This process will take time depending on how fast is your CPU. After it finished, we will invoke the next command in order for it to build the .deb package. Pay attention you will have to modify option number 10:

sudo checkinstall

This package will be built according to these values: 

0 -  Maintainer: [ [email protected] ]
1 -  Summary: [ WSJT-X version 2.2.2 compiled by HC6PE ]
2 -  Name:    [ wsjtx ]
3 -  Version: [ 2.2.2 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ checkinstall ]
7 -  Architecture: [ armhf ]
8 -  Source location: [ wsjtx-2.2.2 ]
9 -  Alternate source location: [  ]
10 - Requires: [ libqt5multimedia5 ]
11 - Provides: [ wsjtx ]
12 - Conflicts: [  ]
13 - Replaces: [  ]
Enter a number to change any of them or press ENTER to continue: 

in here you enter “10” and add “libqt5multimedia5” (without the quotes). Then just continue and it will build the .deb:


Done. The new package has been installed and saved to
/home/radio/wsjtx-2.2.2/wsjtx_2.2.2-1_armhf.deb

Lets install it!

radio@pisdr:~$ sudo dpkg -i ~/wsjtx-2.2.2/wsjtx_2.2.2-1_armhf.deb
(Reading database … 112570 files and directories currently installed.)
Preparing to unpack …/wsjtx_2.2.2-1_armhf.deb …
Unpacking wsjtx (2.2.2-1) over (2.2.2-1) …
Setting up wsjtx (2.2.2-1) …
Processing triggers for man-db (2.7.5-1) …

And… it works! Check the version, in my case it is 2.2.2, the same I compiled and installed.