¿Cómo manejar varias PC con un sólo teclado y mouse?

No es infrecuente encontrarnos con técnicos que necesitan manejar varias computadoras en su escritorio.

Por ejemplo puede que tenga en una instalado un Sistema Operativo Linux para realizar actividades de monitoreo, y un equipo adicional separado para testear una determinada aplicación.

Puede que tenga dos máquinas: una realizar sus actividades personales (banca, correo electrónico, chats, juegos, VPN personal para conectarse a herramientas o sistemas de uso personal, sistema de manejo de claves personal, etc); y en la otra máquina realizar sus actividades laborales (programación, acceso a sistemas confidenciales, conexión a la VPN de la empresa que no es compatible con la VPN personal que tengo en la otra máquina, chat propio de la empresa, sistema de manejo de claves de la empresa, etc), de esta forma tiene aislados las aplicaciones en dos sistemas completamente diferentes.

En fin, puede existir una variedad de razones por las que una persona tenga que manejar varias computadoras. Y se vuelve molesto el tener que mantener en la misma mesa dos teclados y dos mouse (si es que maneja dos computadoras). Tener que mover todo el cuerpo para alcanzar el teclado de la izquierda para responder a un mensaje que le llegó por telegram, volver al teclado de la derecha para seguir programando, regresar al teclado de la izquierda para imprimir una tarea para los hijos, etc.

input-leap

Bueno, es posible usar una herramienta llamada input-leap, la que es un fork de barrier.

Esta herramienta nos permite manejar varias computadoras, con tan solo un mouse y un teclado. Esta herramienta simplemente permite extender el mouse entre las dos computadoras, si mueves el mouse hacia la computadora de la izquierda, el teclado y mouse trabajarán en la computadora de la izquierda. Si mueves el mouse al extremo derecho de la máquina izquierda, este se cambiará a la máquina de la derecha y en ese momento el teclado y mouse trabajarán en la máquina de la derecha.

De esta forma, simplemente desplazamos el mouse hacia un extremo de un monitor, y el mouse “mágicamente” pasará a moverse en el otro monitor y el teclado funcionará en esa máquina.

Imagínate que tengas el siguiente escenario:

Laptop de la izquierda, con un monitor adicional a la izquierda de ella.

Laptop de la derecha, con un monitor adicional a la derecha de ella.

Tienes entonces 4 monitores, los 2 de la laptop de la izquierda y los dos de la laptop de la derecha.

La laptop de la derecha le llamaremos el Servidor, la máster. Esta es la que tiene el teclado y mouse externo en mi ejemplo, y bueno, también seguramente tendrá el teclado y mouse incorporados de la laptop.

La laptop de la izquierda le llamaremos el cliente, la esclava. Esta puede tener su propio teclado y mouse en la laptop, que siempre seguirán funcionando pero solamente para ella, no para la máster.

Configurando input-leap en el servidor

Instalamos el input-leap:

sudo dnf install input-leap

Al arrancarlo, podemos mostrar la ventana principal (Click derecho -> Show). Notar que en mi caso pueden aparecer referencias a barrier que es el nombre anterior. input-leap es compatible con versiones de barrier.

En la pantalla principal vamos a presionar el botón que dice “Configure Server…”

Nos mostrará la siguiente ventana:

Es en esta ventana donde vamos a definir dónde va mi servidor (en mi caso es el que tengo en azul) y dónde va el cliente (el que está a la izq del servidor). Para ello podré arrastrar el iconito de monitor que aparece arriba a la derecha.

El servidor ubicará, reconocerá al cliente por su nombre. En mi caso el cliente se llama “lactoc.local”. Anoten ese nombre que ya lo verán en la próxima sección.

Luego vamos al TAB “Advanced server settings”:

En este TAB podemos hacer varios cambios interesantes. Sobre todo te comento que actualmente hay un bug en el input-leap que el servidor deja de responder repentinamente. Esto encontré que es cuando la opción “Enable clipboard sharing” está activada, por lo que en mi caso siempre deshabilito esa opción.

Clipboard sharing lo que hace es permitir que lo que uno copie en el cliente, pueda ser pegado en el servidor, y viceversa! Es un feature muy bueno, pero incluso hasta por seguridad mejor no tenerlo, para evitar por error pegar algún texto de uno en el otro que no se deba (contraseñas por ejemplo).

Yo le tengo marcada la opción “Switch after waiting” 50ms. En este caso lo que hace es que el mouse no se va a desplazar suave, mágicamente, de un equipo al otro sino que “tropezará” durante 50 milisegundos, antes de cambiarse de equipo. Nada del otro mundo, me da igual tener esa opción desactivada o activada, no cambia el rumbo de mi vida.

Bounce on double tap: No la uso, pero impide que te desplaces a la otra pantalla excepto que golpees con el mouse el borde de la pantalla dos veces seguido. Esto puede ser útil cuando trabajas con ventanas muy al borde, a veces sucede que recuestas el mouse a un borde antes de dar click (que lo pegas al borde), si input-leap ve que llegaste al borde, te pasa automáticamente al otro equipo. Con este “doble golpe” evitas que se pase automáticamente. Yo NO lo uso. Pero es cuestión de gustos.

Una vez guardamos estas configuraciones, podemos ir al menú de la pantalla principal, opción “settings” donde podemos escoger si minimizar la aplicación, si ocultarla al arrancar y/o si quieremos arrancarla al iniciar la sesión gráfica. En mi caso tengo las 3 marcadas. También sugiero cerciorarse que “Enable SSL” esté activado, para que la comunicación viaje cifrada entre un equipo y el otro.

Si tienes el firewal activado en el servidor, es importante que abras el puerto 24800/TCP, de lo contrario el cliente no se podrá conectar a él!

Configurando input-leap en el cliente

Instalamos el input-leap

sudo dnf install input-leap

Al arrancarlo, podemos mostrar la ventana principal de input-leap (noten que en mi caso me sigue saliendo el nombre anterior “barrier”, input-leap es compatible con clientes barrier.

En este caso solamente debemos configurar la IP del servidor (Server IP). En mi caso el servidor que configuramos anteriormente tiene la IP 192.168.1.80. Luego de esto podríamos presionar en el botón de Start, pero no lo hagas todavía, veamos algunas cosas más.

Si deseas mayor seguridad en la comunicación, sugiero que conectes ambas computadoras a través de un cable LAN y en “Server IP” pongas la IP de la LAN del servidor. A veces si comunicamos al cliente y al servidor por WiFi, puedes notar demoras en la comunicación, quizá porque el WiFi está muy lejos, o saturado, etc. De ser este tu caso te sugiero conectar a ambos equipos por la LAN para que no hayan demoras.

Previamente a iniciar (Si ya iniciaste no hay problema, dale en “Stop”), sugiero revisar las opciones del menú, específicamente las de propiedades (Settings):

  • Screen name: Es cómo se va a identificar el cliente ante el servidor. Es importante que el servidor sepa cómo se llama el cliente ya que en base a su nombre es que logra ubicarlo en la posición correcta (a la izq, a la derecha, arriba, etc).
  • Claro que puedes escoger minimizar la aplicación, minimizarla al arrancar, y arrancar InputLeap al iniciar. Sugiero verificar que la comunicación sea por SSL (Enable SSL).
  • No te olvides que el cliente se conectará al puerto 24800/TCP del servidor. Así que cerciórate que en el firewall del servidor tengas abierto el puerto 24800/TCP sino el cliente no se podrá conectar a él.

Otros detalles

input-leap no solamente funciona entre equipos Linux, también funciona con equipos Windows y MacOS. De hecho un equipo puede ser, por ejemplo, Linux y el otro Windows. Yo personalmente no lo ha probado, pero sí es multiplataforma.

Seguramente se pueden conectar más de 2 computadoras. Yo no lo he probado, pero es un buen ejercicio, quizá una a la derecha, otra a la izquierda y una tercera encima de la de la máquina de la derecha. No sé, opciones hay muchas.

Espero hayas disfrutado este post y que me comentes qué tal te fue.

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.

Programar TV RIVIERA para Decodificador DirecTV LH02

Tengo un amigo con un TV Riviera que instaló el decoficador DirecTV llamado LH02. Es un decodificador pequeñito de color negro, el control remoto es de color blanco y tiene un botón amarillo en medio

En la etiqueda de abajo del decodificador dice: LH02-O-303.

Esta es una imagen del control remoto:

El código que me funcionó de mi TV Riviera fue el 13134.

Para programarlo hacemos lo siguiente:

  • Presionas a la vez SELECT+MUTE y esperas unos segundos hasta que el LED que está entre ON y OFF parpadee dos veces. Ahi le sueltas a ambos botones.
  • Ingresas el código: 13134 (no hay apuro, le ingresas normalmente)
  • Apuntando al TV Riviera, que tienes encendido, presionas el botón OFF

El TV debe apagarse luego de un momento.

Ya, eso es todo, ya tenemos configurado nuestro TV. Ahi puedes encenderle presionando ON, subir/bajar el volumen, etc.

Esto funciona para mi TV a la fecha de hoy, Noviembre del 2022.

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!

Código de TV Riviera

En Ecuador es una marca muy popular un tipo de televisor marca Riviera.

Tengo un RIVIERA RLED-DSG32CHE3000 de unos pocos años atrás, y quise configurar el control remoto del Google TV (el nuevo Chromecast) que resulta que no le detecta automáticamente. Lo mismo me sucedió con Amazon FireTV

Luego de mil trabajos encontré que este TV Riviera DSG32CHE3000 usa el código de TV tipo Toshiba.

En este caso, el resto de la configuración fue muy sencilla, desde el control remoto Google Chromecast con Google TV le configuré un dispositivo tipo TV TOSHIBA y en pocos segundos pude realizar las dos acciones que más necesitaba que es que a través del control de Google TV se pueda apagar/encender el TV y subir/bajar el audio.

Running RS-HFIQ Under Linux (Raspberry PI4)

I have been running RS-HFIQ under raspbian and also under ubuntu Linux on a Raspberry Pi3 and currently under Raspberry Pi4. This is a very raw explanation on how to make it work RS-HFIQ under linux so I can use it as a guide in case I found myself having to reinstall it.

Here is my current Hardware:

As you can see I’m running it in Ubuntu 20.04 LTS on a 4GB RAM RPI 64bits (aarch64). But I have also ran it under raspbian 32bits (for raspi 3) as well as under Fedora Linux

The Input and output is being made via a StarTech USB sound card (recommended by the author of RS-HFIQ). Exactly like this one https://www.startech.com/en-us/cards-adapters/icusbaudio2d

The winning hand here is to be able to install quisk as well as wsjt-x and make them both work together.

How I connected the RS-HFIQ to the USB sound card? Well I followed the diagram in this link: https://sites.google.com/site/rshfiqtransceiver/rs-hfiq-technical-information-site/faq-and-troubleshooting?authuser=0

Here is a picture of how to connect it: IQ OUT RX to MIC, and IQ IN RX to the headphones.

On the raspberry pi4 I installed ubuntu 20.04 LTS from here. You may install the latest DESKTOP version found here. If you install the SERVER it will come up in text mode only, so you will have to install the graphical packages. If you are unexperienced, you better install the DESKTOP version.

Here is my LXDE desktop for my Ubuntu 20.04 in my raspi4

Of course you will notice there are several tasks already running (WSJT-X and QUISK). We will work on that, later,

I then proceed to install quisk, from the quisk website itself: https://james.ahlstrom.name/quisk/

I simply readed the whole page, and then proceeded to install quisk. https://james.ahlstrom.name/quisk/docs.html#Installation (look for the python3 install method in Linux, not the python2).

I’m pretty sure there was some package missing in the instructions but it was quite simple to find out and install it. Sorry, I can’t recall right now.

I tried then to start quisk by typing “quisk” in the linux terminal. It started, now you must configure it

  • Click on “Radios” TAB, then chose to add name the new radio and name it, for example: RS-HFIQ”

A new TAB with the chosen name will appear to the Right (See the TAB *RS-HFIQ* in my case. Ok, click that TAB.

Now download hardware_usbserial.py from here https://github.com/dl1ksv/rshfiq take note of where you downloaded it. In my case I simply downloaded to /home/ubuntu/ as my username is “ubuntu”. So the full path is /home/ubuntu/hardware_usbserial.py

Adapt, change the option “Hardware file path” under *RS-HFIQ* TAB to fit the place where you downloaded the file, in my case /home/ubuntu/hardware_usbserial.py

Now click on the “Sound” TAB and try to match exactly the options shown in the following image. Notice that, maybe the alsa hw:X,0 may change, in my case it is hw:2,0 but in your case X may be, for example, 1 (hw:1,0).

Under remote, match the “Remote” TAB options to the ones shown in the following screen capture:

I did not recall having changed anything else. Just clicked the buttons to configure the mode to DGT-USB, the BW to 3200 and the start option to “Config” in the main window. Oh, and AGC as I can see now.

One important thing to mention here: If you notice an error (in red characters) saying “Stream error: pulse Monitor of QuiskDigitalInput”, that usually means that quisk was started before the QuiskDigitalInput virtual sound card was created. Simply close Quisk and open it again.

Here you will notice the red messages:

Here is quisk after you close it and reopen it, as you may see, the error message have dissapeared:

I then install wsjt-x:

sudo apt-get update && sudo apt-get install wsjtx

In my case I compiled the latest version (currently 2.4.0) but using the stock version from ubuntu should be ok.

After installing wsjtx, open it and compare/adjust the settings:

Under radio settings, try to configure it like this:

Under “Audio” configure it like this:

The rest of the settings tab is up to you to customize them

After configuring it, you will be able to change bands, click on tune, receive stations, and also make calls.

I recall there was an issue with earlier versions of RS-HFIQ and a firmware upgrade must be done in order for digimodes to properly work. This issue is outside the scope of this article, just bear in mind that you must be using version 3.2 or newer. In case you have a version <3.2, check the instructions for upgrading here: https://sites.google.com/site/rshfiqtransceiver/rs-hfiq-technical-information-site/arduino-sketch?authuser=0

Not enough power? You will probably want to check the audio output values. I set them to 100% using pulseaudio

Member of SKCC#7163T