Cristian Vicente

El instalador de Ubuntu no trata los volúmenes cifrados con mucho cariño, salvo que los crees en la propia instalación del sistema operativo. Por ese motivo, cuando tengamos uno previo de otra instalación y no queramos formatearlo, simplemente lo configuraremos a posteriori.

Primero nos cercioraremos de que podemos montarlo:

apt install cryptsetup

cryptsetup luksOpen /dev/nvme0n1p4 homecifrado

mount /dev/mapper/homecifrado /mnt

Si todo funciona correctamente y podemos acceder a los contenidos en /mnt pasaremos a hacerlo más permanente editando el fichero «/etc/crypttab» con este contenido:

homecifrado /dev/nvme0n1p4 none luks

Y en fichero «/etc/fstab»:

/dev/mapper/homecifrado /home xfs defaults 0 2

Reiniciar y listo, nos preguntará la contraseña durante el arranque.

Debido a cómo interactúan los snaps con el sistema, todo aquel Firefox que esté instalado de dicha forma no permite el funcionamiento de PWA. Para subsanar el inconveniente tendremos que desinstalar Firefox de la siguiente forma:

sudo snap remove firefox

Añadimos un repositorio donde tengamos disponible la versión clásica de Firefox y le damos prioridad para que se instale desde ahí:

sudo add-apt-repository ppa:mozillateam/ppa

cat << EOF | sudo tee /etc/apt/preferences.d/firefox
Package: firefox*
Pin: origin ppa.launchpadcontent.net
Pin-Priority: 600
EOF

sudo apt -y install firefox

También necesitaremos eliminarlo de la supervisión de AppArmor (el primer comando nos permitirá saber si realmente está afectado por ello o no):

sudo aa-status

sudo ln -s /etc/apparmor.d/usr.bin.firefox /etc/apparmor.d/disable

sudo apparmor_parser -R /etc/apparmor.d/usr.bin.firefox

Hace unos meses moví todas las máquinas virtuales de Proxmox a Ubuntu 18.04 LTS y todo iba bien hasta que decidir actualizar a Ubuntu 20.04 LTS. Resulta que esta última versión incluye el kernel 5.4 que trae consigo una serie de modificaciones más restrictivas con respecto al acceso de zonas de memoria reservadas y que afectas a las agrupaciones IOMMU mal hechas por parte de algunas BIOS. El error que saltaba era similar al siguiente:

failed to setup container for group 28: memory listener initialization failed: Region mach-virt.ram: vfio_dma_map(0x563169753c80, 0x40000000, 0x100000000, 0x7fb2a3e00000) = -22 (Invalid argument)

Hice diversas modificaciones sobre el kernel para intentar evitar la restricción del mapeo de memoria sin ningún éxito. Probé a actualizar al kernel 5.8 de la rama de desarrollo de Ubuntu para acabar teniendo el mismo problema. La única solución era volver a Ubuntu 18.04 o directamente probar una distribución que trabajase con el kernel 5.3 que era el último que se sabía que funcionaba de forma permisiva en ese aspecto. Por tanto terminé con OpenSuse 15.2.

Todo ello me llevo a cuestionarme si el hardware (HP Gen8) que estaba intentando hacer funcionar merecía la pena tanto tiempo invertido o simplemente comprar otro equipo mejor preparado. Tras visitar numerosas webs me encontré con que la información relativa a las agrupaciones IOMMU no se ofrecen por parte de los fabricantes de placa base y que, futuras actualizaciones de la BIOS podían afectarlas. Lo que parece ser más orientativo es que las placas base más caras suelen ser mejores en ese aspecto y que para plataformas AMD hay que llevar cuidado con las actualizaciones de AGESA. Con lo que al final supone una lotería y voy a estirar el kernel 5.3 todo lo que pueda, a ver si en un futuro se publica algún método para seguir usando este hardware.

Partiendo del hecho de que una Ubuntu Server carece de interfaz gráfica tal cual la conocemos habitualmente, a la hora de instalar un Kodi y que sea lo único que aparezca se hace algo laborioso.

Instalaremos Kodi con lo siguiente:

add-apt-repository ppa:team-xbmc/ppa
apt install kodi

En caso de tener una tarjeta gráfica de Nvidia, instalaremos su driver propietario:

apt install ubuntu-drivers-common
ubuntu-drivers devices
ubuntu-drivers autoinstall

Observando los diferentes escritorios a los que podemos optar, yo elegí Lubuntu por su ligereza:

tasksel –list-task
tasksel install lubuntu-core
service lightdm start

Con lo anterior ya deberíamos tener una interfaz gráfica donde hacer login que hará que arranque Kodi nada más entrar. Para no necesitar introducir la contraseña podemos hacer que entre automáticamente creando un fichero «/etc/lightdm/lightdm.conf.d/50-myconfig.conf» que incluya lo siguiente:

[Seat:*]
autologin-user=nombre_de_usuario
autologin-user-timeout=0

Sin embargo, nos encontraremos con problemas para hacer passthrough de sonido a través del HDMI de la gráfica. Tendremos que crear un script que se inicie con la sesión que recoja estos comandos:

echo autospawn = no > $HOME/.config/pulse/client.conf
pulseaudio –kill > /dev/null 2>&1

Cada vez que entramos por ssh a una máquina con Ubuntu 18.04 recibimos un mensaje a modo de bienvenida con información acerca de actualizaciones pendientes entre otras cosas. Para personalizarlo un poco me he basado en una entrada del blog de The Geek Stuff.

Básicamente he creado un fichero nuevo con el comando «nano /etc/update-motd.d/99-custom» y he agregado la siguiente información dentro:

#!/bin/sh
printf ‘\n%s\t%s\t%s\n’ «==========» «ESPACIO LIBRE» «==========»
/bin/df -h | grep «sd\|md»

printf ‘\n%s\t%s\t%s\n’ «==========» «ESTADO DEL RAID» «==========»
/bin/cat /proc/mdstat

Con esto, cada vez que accedo al servidor obtengo información sobre el espacio libre de los dispositivos que quiero y el estado del RAID.

Debido al hardware específico (HP Miniserver Gen8) que tengo y que para poder resolver los problemas de su BIOS con la paravirtualización se necesita aplicar un parche en el kernel que me dejó de funcionar en Proxmox en la última actualización, pues decir librarme de la comodidad de Proxmox en busca de algo más flexible.

Quería una distribución con software relativamente actualizado y documentado en el que me sintiese cómodo. Opté por una Ubuntu 18.04 para servidores que, aunque no está entre mis favoritas para el uso cotidiano, es bastante cómoda para funciones de servidor.

Software de virtualización

Después de la instalación básica necesitaba una serie de herramientas para virtualizar máquinas:

apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils

adduser `id -un` libvirt

Preparación previa del hardware

Hice que no cargase ningún driver de la gráfica a la que tenía pensada hacerle passthrough :

echo blacklist nouveau > /etc/modprobe.d/blacklist-nvidia-nouveau.conf

echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf

echo blacklist snd_hda_intel > /etc/modprobe.d/blacklist-nvidia-nouveau.conf

Con el comando «lpsci -nn» encontré los datos de la gráfica que me interesaban:

07:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1)
07:00.1 Audio device [0403]: NVIDIA Corporation GP107GL High Definition Audio Controller [10de:0fb9] (rev a1)

Y edité el fichero de configuración de Grub «/etc/default/grub»:

GRUB_CMDLINE_LINUX=»intel_iommu=on vfio_pci.ids=10de:1c82,10de:0fb9″

Para terminar de curarme en salud, creé el fichero «/etc/modprobe.d/vfio_pci.conf»:

options vfio_pci ids=10de:1c82,10de:0fb9

Y edité el de «/etc/initramfs-tools/modules»:

vfio
vfio_iommu_type1
vfio_virqfd
options vfio_pci ids=10de:1c82,10de:0fb9
vfio_pci ids=10de:1c82,10de:0fb9
vfio_pci

¿Excesivo? Puede ser. Quizás sobrase con sólo haber editado el fichero de Grub, pero se llega a un punto en el cual has dado tantas vueltas sobre lo mismo que no te fías con hacer lo mínimo indispensable.

Finalmente toca rehacer el arranque con los siguientes comandos:

update-grub
update-initramfs -u

Compilación del kernel

Editamos las fuentes de apt para poder descargar el fuente del software «/etc/apt/sources.list»:

deb-src http://es.archive.ubuntu.com/ubuntu/ bionic main restricted

deb-src http://es.archive.ubuntu.com/ubuntu/ bionic-updates main restricted

Descargamos el software necesario:

apt update

apt-get build-dep linux linux-image-$(uname -r) git fakeroot dkms default-jdk

Es posible que nos topemos con el siguiente error:

la descarga se realiza de forma desprotegida como superusuario, ya que al archivo «linux-signed_4.15.0-91.92.dsc» el usuario «_apt» no pudo acceder. – pkgAcquire::Run

Para solventarlo nos basta con hacer lo siguiente:

chown _apt /var/lib/update-notifier/package-data-downloads/partial/

Dentro de la carpeta «/usr/src/» descargaremos los fuentes del kernel de Ubuntu Bionic:

git clone git://kernel.ubuntu.com/ubuntu/ubuntu-bionic.git

Editaremos el fichero «/usr/src/ubuntu-bionic/drivers/iommu/intel-iommu.c» donde pone:

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor.\n»);
return -EPERM;
}

Pondremos lo siguiente:

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device is ineligible for IOMMU domain attach due to platform RMRR requirement. PARCHEADO.\n»);
}

En este paso, si tratamos de compilar el kernel nos encontraremos con un error relacionado con el script «ubuntu-bionic/debian/scripts/retpoline-check» y que tuve que modificar de este código:

count=$( diff -u «$prev» «$curr» | grep ‘^+[^+]’ | wc -l )
if [ «$count» != 0 ]; then
rc=1

A este otro:

count=$( diff -u «$prev» «$curr» | grep ‘^+[^+]’ | wc -l )
if [ «$count» != 0 ]; then
rc=0

Sé que está relacionado con las mitigaciones sobre las CPU de Intel pero no es algo que en esta máquina me importase mucho.

Desde el directorio de «/usr/src/ubuntu-bionic» lancé la compilación que duró un periodo de tiempo considerable:

fakeroot debian/rules clean

fakeroot debian/rules binary

De dicho proceso se generaron una serie de paquetes .deb que instalé:

dpkg -i *.deb

Una vez instalado el kernel modificado, ahora sólo necesitaba que el equipo siempre arrancase con él, con lo que había que realizar algunos cambios en el cargador de arranque. Para saber qué modificaciones tenía que aplicar lancé el siguiente comando:

sed -nre «/submenu|menuentry/s/(.? )'([^’]+)’.*/\1 \2/p» < /boot/grub/grub.cfg

Me devolvió el listado visual de Grub que tenía que tener en cuenta:

menuentry Ubuntu
submenu Opciones avanzadas para Ubuntu
menuentry Ubuntu, con Linux 4.15.0-91-generic
menuentry Ubuntu, con Linux 4.15.0-91-generic (recovery mode)
menuentry Ubuntu, con Linux 4.15.0-88-lowlatency
menuentry Ubuntu, con Linux 4.15.0-88-lowlatency (recovery mode)
menuentry Ubuntu, con Linux 4.15.0-88-generic
menuentry Ubuntu, con Linux 4.15.0-88-generic (recovery mode)
menuentry Ubuntu, con Linux 4.15.0-76-generic
menuentry Ubuntu, con Linux 4.15.0-76-generic (recovery mode)

Entonces edité el fichero «/etc/default/grub» acorde:

GRUB_DEFAULT=»Opciones avanzadas para Ubuntu>Ubuntu, con Linux 4.15.0-88-generic«

Y además bloquee la posibilidad de que sufriese cambios a través de alguna actualización del gestor de paquetes y regeneré la configuración de Grub:

apt-mark hold 4.15.0-88-generic

update-grub

Si en un futuro queremos actualizar el kernel, para desbloquear el que tenemos modificado bastará con lanzar el comando «apt-mark unhold 4.15.0-88-generic».

Tras un reinicio del equipo y con el comando «dmesg | grep -i vfio» deberíamos poder ver lo siguiente:

[230727.140577] vfio-pci 0000:07:00.1: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. PARCHEADO.
[230727.730169] vfio_ecap_init: 0000:07:00.0 hiding ecap 0x19@0x900

Configuración del puente de red

Para que las máquinas virtuales puedan tener acceso directo a nuestra y así poder hacer uso de los recursos que en ella se encuentran hay que configurar un puente de red. Modificaremos el fichero «/etc/netplan/01-netcfg.yaml»:

network:
version: 2
renderer: networkd

ethernets:
eno2:
dhcp4: false
dhcp6: false

bridges:
br0:
interfaces: [eno2]
addresses: [192.168.1.10/24]
gateway4: 192.168.1.1
mtu: 1500
nameservers:
addresses: [192.168.1.1]
parameters:
stp: true
forward-delay: 4
dhcp4: no
dhcp6: no

El dispositivo «eno2» sería nuestra tarjeta de red con conectividad y «br0» sería al puente hacia nuestras máquinas virtuales. Hay que tener en cuenta que yo he preferido establecer una IP fija para mi tarjeta con conectividad física pero se podría haber dejado con DHCP.

Gestión web del servidor

Para poder gestionar de manera fácil el servidor a través de un entorno web, he optado por hacer uso de Cockpit, el cual se puede instalar de la siguiente forma:

apt install cockpit cockpit-machines cockpit-docker cockpit-system cockpit-packagekit

Ahora podremos gestionar el servidor desde http://127.0.0.1:9090

Gestión de las máquinas virtuales

Si bien se pueden gestionar las máquinas virtuales de Cockpit de manera fácil, el interfaz es algo limitado con respecto a lo que podía hacer con Proxmox. Pero esto es fácilmente solucionable si las gestionamos desde Virtual Machine Manager, un software que puede estar instalado en nuestro sobremesa o portátil y que permite gestionar tanto las máquinas virtuales en local como remotas.

En Ubuntu

Editamos el fichero que exista dentro de «/etc/netplan/», que en nuestro caso es «10-lxc.yaml» y lo dejamos de la siguiente forma:

network:

version: 2

ethernets:

eth0:

dhcp4: false

addresses: [192.168.1.10/24]

gateway4: 192.168.1.1

nameservers:

addresses: [8.8.8.8, 8.8.4.4]

Hay que tener en cuenta que no se debe tabular, sino utilizar espacios y que, en nuestro caso, el dispositivo de red es el denominado «eth0».

Tras la configuración sólo tenemos que ejecutar el siguiente comando:

netplan apply

En Debian

Necesitaremos modificar el fichero «/etc/network/interfaces» de la siguiente forma:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug ens3

auto ens3
iface ens3 inet static
address 192.168.1.10
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

Modificaremos el fichero «/etc/resolv.conf» para que tenga las DNS que necesitemos:

nameserver 8.8.8.8
nameserver 192.168.1.1

Reiniciaremos el servicio de red con el siguiente comando:

systemctl restart networking.service

Para comprobar que tenemos la IP correctamente asignada podemos recurrir a este comando:

ip -4 addr

Let’s Encrypt nos facilita tener un certificado SSL de forma gratuita e ISPConfig nos automatiza el proceso marcando un par de checks, pero puede que haya problemas si utilizamos una Ubuntu 16.04 (Xenial): cuando marcamos los checks para activar el SSL y Let’s Encrypt en el dominio deseado, no se quedan permanentes, se desactivan como si el proceso no se hubiese llevado a cabo.

Todo esto se debe a que necesitamos actualizar el proceso de automatización de solicitud de certificados de seguridad. Nos es suficiente con realizar estas acciones para instalar Certbot:

apt-get update
apt-get install software-properties-common
add-apt-repository ppa:certbot/certbot
apt-get update
apt-get install python-certbot-apache

Una vez realizado los pasos anteriores, podremos acudir de nuevo a ISPConfig y marcar los checks.