¿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