domingo, 23 de agosto de 2020

SSH y redireccionamiento: Abrir programas gráficos desde SSH estando bajo Screen

Una excelente herramienta para tener múltiples consolas de SSH bajo una misma conexión es "screen". Con ese programa nos ahorramos el tener que iniciar varias sesiones, pudiendo hacer todo desde una única. Esta maravilla de programa la expliqué en otra entrada, les recomiendo darle una vuelta... de verdad es un ahorro de tiempo y recursos 😀

Al conectarnos por SSH agregando la opción de redireccionamiento podemos abrir programas gráficos, es decir, tendremos en nuestro cliente un programa que en realidad se está ejecutando en el servidor, ahorrándonos tener que abrir todo el ambiente gráfico para enfocarnos específicamente en la aplicación ¿genial o no?

Si estamos usando screen, hay que tener en cuenta algunos detalles en la configuración o no veremos nada de la magia 😛

Revisar configuración de redireccionamiento

Estando conectados por SSH es posible hacer redireccionamiento de la parte gráfica, pero esa opción debe estar habilitada en el servidor. 

Revisar la configuración del servidor en "/etc/ssh/ssd_config". Ahí la opción "X11Forwarding" debe estar activa y con "yes". 

X11Forwarding yes

Si estaba desactivada y la activan, no olvidar reiniciar el servicio para que quede funcionando con la nueva configuración.

$ systemctl restart sshd

Conectarse por SSH con redireccionamiento activo

Para ver que todo está bien, conectarse al servidor usando opción -Y y ejecutar algún proceso, dicho programa debiera iniciar su versión gráfica en el cliente que está conectado.

$ ssh -Y -l usuario servidor.com

$ xcalc &

Con lo anterior se nos debería abrir la calculadora en el cliente que está conectado ^^.

Abrir programa gráfico bajo screen

Al iniciar screen generalmente uso las opciones -dR para recuperar la última sesión activa y partir tal cual la última vez.

Si repetimos el proceso de ejecutar algún programa gráfico puede que no nos muestre nada, pero ¿y la magia? ¿qué pasó? 

En algunos casos la variable de ambiente "gráfico" de la sesión de screen puede diferir de la configurada en SSH y como eso no coincide, veremos el programa que ejecutamos como activo en la lista de procesos, pero la parte gráfica estará perdida en el limbo. Para evitar que esto suceda debemos ajustar la variable DISPLAY para que coincida entre la ventana de screen que estemos usando y la sesión de SSH abierta, de esta forma haremos que el redireccionamiento gráfico funcione.

Cerrar screen para estar en la consola de SSH de forma directa, desde ahí ver la configuración de DISPLAY:

$ echo $DISPLAY

localhost:10.0 

En este caso el display apunta a 10, por lo que debemos configurar lo mismo en la ventana de screen que estemos usando. 

$ screen -dR

$ echo $DISPLAY

:0.0

Eso indica que la ventana actual está apuntando a 0 en vez de 10, toca ajustar:

$ export DISPLAY=:10.0

$ echo $DISPLAY

:10.0

$ xcalc &

Y magia... xcalc ahora sí aparece en el cliente, tal como se esperaba 😀

Esto se debe realizar en cada ventana bajo screen que abran, ya que por defecto se abren apuntando a :0.0 👌

sábado, 1 de agosto de 2020

Grub2 UEFI error

Más de una vez me ha tocado reparar grub en computador que tiene varios años, lo que implica haber pasado por varias migraciones. Eso sumado a que se vienen cambios en grub debido a una alerta de seguridad con "secure boot" en EFI (ver enlace más abajo), puede que más de alguno tenga problemas.  Teniendo eso en mente, acá un resumen de los pasos que generalmente ocupo para corregir y así de paso me sirve de ayuda memoria :P.
Luego de actualizaciones o instalaciones, puede que el archivo de configuración quede corrupto o simplemente "invisible" por lo que puede aparecer una ventana básica de grub.
Incluso sin reparar grub, podemos acceder a la partición con Linux de forma directa desde esa consola básica con estos comandos:

set root=(hd0,gpt8)
linux /boot/vmlinuz-4.19.0-10-amd64 root=/dev/sda8
initrd /boot/initrd.img-4.19.0-10-amd64
boot

Tiendiendo sda8 como la partición root, en caso de ser otra la partición se debe cambiar el número por la que corresponda. Lo mismo con las versiones de vmlinuz y initrd (presionando tab aparecerán los archivos disponibles).
Peeeero dado que es poco práctico escribir eso todas las veces, vamos con los pasos de la reparación.
Lo primero es tener un live cd o live usb -que es lo más habitual- e iniciar desde ahí. Idealmente es mejor tener en el live system la misma distro que está instalada, para descartar algún inconveniente.
Suponiendo que la partición EFI es sda6 y la partición root es sda8 los comandos serían:

sudo su -
mount /dev/sda8 /mnt
mount /dev/sda6 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
chroot /mnt /bin/bash

Abrir otra consola y ejecutar:

sudo apt install grub-efi
sudo grub-install --target=x86_64-efi /dev/sda --efi-directory=/mnt/boot/efi --boot-directory=/mnt/boot

Reiniciar el sistema y listo, ya debería partir grub con todas las opciones tal como antes :)

NOTA:
Para tener una idea y resumen de todo lo relacionado con el boot, se puede usar: sudo bootinfoscript.

Referencias:
https://wiki.debian.org/GrubEFIReinstall
https://forums.solydxk.com/viewtopic.php?f=5&t=7649#p71156
https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/

-