Cristian Vicente

Tras actualizar el software de OpenSuse Tumbleweed me he encontrado con el siguiente error al intentar iniciar los contenedores LXC:

libvirtError: error interno: No se pudo encontrar montaje de controlador de memoria cgroups

Supongo que debe estar relacionado con la actualización de software LXC más que con el kernel, porque volver a la versión anterior no lo resolvía. Sin embargo, lo que sí lo resolvía era añadir los siguientes parámetros en el inicio del kernel:

cgroup_enable=memory systemd.unified_cgroup_hierarchy=0

Y se puede comprobar cómo cambia el resultado al ejecutar este comando antes y después:

cat /proc/cgroups | column -t

mount | grep cgroup

Supuestamente, el tenerlo activado nos permite controlar y limitar el acceso a los recursos de la máquina host por parte de los guest, con lo que no entiendo si está hecho a posta porque han habido cambios que ya no necesitan estos parámetros y lo implementan de otra forma o es un simple fallo en la última versión.

Dejando atrás la limitación del sistema operativo que traía de fabrica para intentar sobrepasar el límite del sistema de ficheros ext2 y lograr hacer un RAID 0 con dos discos duros de 20TB he llegado a la conclusión de que no se puede.

Se puede formar un RAID 0 sin mayores inconvenientes instalado las herramientas disponibles en OpenWRT y utilizando este comando como en cualquier sistema Linux:

mdadm –create –verbose /dev/md0 –level=0 –raid-devices=2 /dev/sda /dev/sdb

Pero a la hora de darle formato a ese raid es cuando empiezan los problemas. Con ext4, en el proceso de inicialización del journaling, directamente se para con un error, algo que se puede saltar para que finalice el proceso y con XFS no hay inconvenientes. Pero a la hora de montar la unidad /dev/md0, en ambos, salta un error diciendo que el fichero es demasiado grande («file to large»). Intuyo que todo está relacionado con el hecho de utilizar un sistema operativo de 32bit por culpa de una CPU que no soporta instrucciones de 64bit.

Curiosamente, podemos formatear y montar el raid si utilizamos el sistema de ficheros exFAT, pero cuando empiezas a copiar ficheros en él empieza a dar errores y tiempos de espera muy largos, algo que lo hace inusable.

Supongo que este ZyXEL se quedará con dos discos de 8TB como máximo.

Hace 8 años compré por un precio más que razonable un NAS de 2 bahías de Zyxel que me permitió hacer bastantes más cosas de las oficiales gracias a repositorios de la comunidad. Pero todo tiene un límite, concretamente en lo que se refiere a su compatibilidad con discos duros de gran capacidad. Resulta que el sistema de archivos que utiliza es ext2, el cual permite un tamaño de volumen máximo de 16TiB, algo que me impedía hacer uso de dos discos duros de 20TB. Frustrado por ello busqué alternativas y encontré la posibilidad de instalar OpenWRT reescribiendo la NAND, lo cuál me permitía hacer uso de ext3 entre otras muchas cosas.

Para llevar a cabo la operación, me enfrenté con documentación incompleta desde el punto de vista de alguien que no lo había hecho nunca. Se hablaba de utilizar una conexión serie USB, de poner comandos en un terminal, hacer uso de un pendrive antiguo y de soldar cosas. Al final fue relativamente sencillo, sin soldar ni comprar nada adicional porque ya tenía en mi posesión una Raspberry Pi 2 para hacer el trabajo de conector serie USB.

Importante

El proceso puede dejar inservible el dispositivo NAS e incluso la Raspberry Pi si confundís algún cable. Así que cada uno es responsable de lo que hace.

Obtención de la MAC

Durante el proceso habrá que configurar la MAC del NAS a mano, con lo que antes de empezar sería buena idea obtenerlo.

Sacar la placa base

Para sacar la placa base hay que extraer las bahías de los discos duros, sacar un par de tornillos de la base, deslizar una parte de la carcasa sobre la otra y seguir desatornillando un poco más, nada difícil ni nada clicks. Hay un vídeo muy ilustrativo de los primeros pasos:

Conectar la Raspberry Pi

Teniendo en cuenta de que en mi caso estaba usando una Rasperry Pi 2 B y que sun GPIO difiere de otros modelos, la conexión me quedó así:

En caso de utilizar un adaptador USB serie, la conexión sería como esta:

Preparando un pendrive

Parece ser que esto es algo que da bastantes problemas, donde algunas personas han tenido que recurrir a pendrive antiguos anteriores al 2.0, pero yo me he arreglado con un Sandisk de 16GB que tenía por ahí. Lo tendremos que formatear en FAT32 y depositaremos en él dos ficheros:

• Los ficheros de u-boot en su versión 18.06.0 porque las más recientes parecen tener un bug que afecta al arranque con USB.
• El firmware de OpenWRT (la más reciente, a día de hoy la versión 22.03.5).

Colocaremos el pendrive en la placa base del NAS, procurando que sea uno de los puertos traseros 2.0.

Preparando la Raspeberry Pi

Arrancamos la Raspberry Pi (en mi caso llevaba una Hyperbian), nos logueamos y, utilizando el comando «raspi-config», dentro de «Interface options» -> «Serial Port», desactivamos el puerto serie para el login shell y activamos el puerto serie por hardware. Reiniciamos las Raspberry Pi y ya la tenemos lista.

Flasheando

Le damos corriente al NAS a través de su adaptador habitual y lo encendemos desde su botón. Desde la Raspberry Pi descargamos el u-boot y le damos una orden con él a través del USB serie que hemos montado con los cables:

wget https://archive.openwrt.org/releases/18.06.0/targets/kirkwood/generic/u-boot-nsa325/u-boot.kwb

kwboot -p -t -b u-boot.kwb -o 5 -B 115200 /dev/ttyAMA0

Nos pedirá que reiniciemos el dispositivo NAS de Zyxel, con lo que le quitaremos la corriente y se la volveremos a dar. Nos mostrará el progreso de flasheo y cuando haya terminado cargará una especie de shell interactiva en la cual tendremos que dar algunas órdenes.

usb reset
fatload usb 0 0x1000000 u-boot.kwb
nand erase 0x0 0x100000
nand write 0x1000000 0x00000 0x100000
reset

Seguiremos configurando algunas variables de entorno:

setenv mtdparts ‘mtdparts=orion_nand:0x00c0000(uboot),0x80000(uboot_env),0x7ec0000(ubi)’
setenv bootcmd ‘run setenv bootargs; ubi part ubi; ubi read 0x800000 kernel; bootm 0x800000’
saveenv
reset

Le configuraremos la MAC que tenía:

setenv ethaddr AB:CD:EF:00:00:00
saveenv

Flashearemos el fichero «openwrt-22.03.5-kirkwood-zyxel_nsa325-squashfs-factory.bin» que habíamos descargado:

usb reset
fatload usb 0 0x2000000 openwrt-22.03.5-kirkwood-zyxel_nsa325-squashfs-factory.bin
nand erase.part ubi
nand write 0x2000000 ubi 0x600000

Una vez finalizado podremos reiniciarlo con el siguiente comando:

reset

El sistema arrancará y ya tendremos disponible desde el navegador una interfaz web para configurarlo.

Fuentes:

Documentación de OpenWRT

Apuntes de Panticz.de

Estaba observando que el arranque en Opensuse estaba tardando más de lo usual y utilizando los comandos:

systemd-analyze blame

systemd-analyze plot > /tmp/plot.svg

Detecté que el culpable residia en «postfix.service» principalmente. Se resolvía cambiando el fichero de configuración «/etc/postfix/main.cf» y cambiando el siguiente el valor de configuración:

inet_protocols = ipv4

Después de esto, el servicio «NetworkManager-wait-online» era el que estaba entorpeciendo el arranque. Como no tenía ninguna entrada en fstab que dependiese de la interfaz de red, apliqué los siguientes comandos:

systemctl disable NetworkManager-wait-online.service

systemctl mask NetworkManager-wait-online.service

Finalmente el sistema ahora es capaz de arrancar en poco más de 2 segundos.

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

Cada vez existen menos aplicaciones dedicadas de escritorio y más servicios webs que suplen las necesidades de los usuarios. Las webapps vienen a fusionar ambos mundos: convierten los servicios web en aplicaciones aparentemente independiente del navegador. Por debajo lo que hacen es utilizar el motor de un navegador (en nuestro caso Firefox) para mostrar las distintas webs que necesitamos usar a modo de aplicaciones clásicas.

Se necesitan instalar dos piezas de software que trabajan en conjunto:

• PWAs For Firefox: se encarga de hacer el trabajo pesado. Suele estar disponible empaquetado en rpm, deb y msi para distintas plataformas.
• Addon para Firefox: una extensión que se instala en el navegador y que nos permitirá ir agregando las páginas webs que deseemos.

Una vez instalado el primero, instalaremos la runtime con el siguiente comando:

firefoxpwa runtime install

Ahora sólo tendremos que abrir la página web desde Firefox de, por ejemplo, nuestro Airsonic local, pulsar sobre la extensión y, seguidamente, darle a «Install current site».

Para comprobar qué tal ha ido bastará utilizar este comando:

firefoxpwa profile list

Nos mostrará algo similar a lo siguiente:

========================= Default ==========================
Description: Default profile for all sites
ID: 00000000000000000000000000

Sites:
– airsonic: http://10.18.1.19:8080/ (01G3MWVNVOPZZD4N6Y4C6ZHAAG)

Y para ejecutar nuestra webapp sólo tendremos que escribir el siguiente comando:

firefoxpwa site launch 01G3MWVNVOPZZD4N6Y4C6ZHAAG

Sólo nos faltaría hacer un acceso directo acorde con su icono y ya tendríamos algo similar a una aplicación clásica.

OpenSuse Tumbleweed es un distribución Linux de filosofía rolling-release mientras que le versión Leap es del tipo clásico. Si queremos pasar de una a otra deberemos realizar un cambio de repositorios y después actualizar desde ellos.

Primeramente realizamos una copia de seguridad de los repositorios que estamos utilizando actualmente:

mkdir /etc/zypp/repos.d/old
mv /etc/zypp/repos.d/*.repo /etc/zypp/repos.d/old

Añadimos los nuevos:

zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/oss repo-oss

zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/non-oss repo-non-oss

zypper ar -f -c http://download.opensuse.org/update/tumbleweed/ repo-update

zypper ar -f -c http://download.opensuse.org/tumbleweed/repo/debug repo-debug

zypper ar -f -d -c http://download.opensuse.org/tumbleweed/repo/src-oss repo-src-oss

zypper ar -f -d -c http://download.opensuse.org/tumbleweed/repo/src-non-oss repo-src-non-oss

Comprobaremos que todo está correcto con el comando «zypper lr -u» y luego actualizaremos con el comando «zypper dup».

Si todo ha ido bien, sólo tendremos que reiniciar el equipo para aplicar los cambios.

Si queremos visualizar de forma remota por SSH el tráfico que está gestionando uno de nuestros servidores podemos hacer uso de «bmon«. Suele estar disponible en la mayoría de repositorios oficiales y tiene el siguiente aspecto:

Si estamos trabajando con Libvirt y deseamos realizar una actualización de sistemas de forma prácticamente desatendida, este es un script que puede resultar cómodo:

#!/bin/bash

## Recoge el nombre de los contenedores y elimina la primera línea y la última
lxc_names=»$(virsh -d 0 -c lxc:/// list –name | tail -n +2 | head -n -1)»

update_lxc_machines(){
local lxc=»$1″
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq update
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq -y upgrade
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq -y clean
virsh -c lxc:/// lxc-enter-namespace «$lxc» –noseclabel /bin/apt -qq -y autoclean
}

for lxc_name in $lxc_names
do
update_lxc_machines «$lxc_name»
done

He tomado como referencia este otro script y lo he modificado a mis necesidades.

En aquellos casos en los que sospechamos de zonas de memoria RAM que no funcionan correctamente y que se producen en equipos con funciones de servidor en los que un reinicio para utilizar Memtest86+ nos supone un problema podemos optar por «memtester».

Con el comando «free» podemos averiguar cuánta memoria tiene nuestro equipo utilizada y cuánta libre. Sabiendo esto lanzamos nuestra nueva herramienta indicándole cuánta memoria tiene que reservar para testearla y cuántas pasadas debe realizar:

memtester 20131 2

En el caso anterior le estaríamos diciendo que comprobase algo más de 19GB y que hiciese dos pasadas. En caso de que encontrase errores veríamos mensajes como el siguiente:

FAILURE: 0x7f40f12dd82264da != 0x7f40f52dd82264da at offset 0x22fa2d27.