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.

Intentado resolver problemas de desconexión del sistema ambilight, gracias a un comentario de alguien en algún foro que hablaba sobre su necesidad de bajar el tamaño de las muestras de la capturadora para que el puerto USB 2.0 no se saturase, descubrí que mi caso era algo similar, la única diferencia es que mi información, a pesar de muy inferior, viajaba por Wifi, un medio muy problemático.

Así que, leyendo el post de Korbin Brown, descubrí que, a pesar de tener el punto de acceso al lado de la Raspberry PI, el cable LAN solucionó el problema por completo.

Con «iwconfig wlan0» detecté que la velocidad que alcanzaba era de 1Mb/s, totalmente insuficiente para transmitir los datos necesarios a Hyperion.

Progressive Web Apps es una manera de «convertir» páginas web en aplicaciones o que al menos parezcan que son independientes del navegador, cuando realmente lo están ejecutando por debajo. En Firefox tenemos dicha posibilidad utilizando un addon de Filip Štamcar.

Existen dos problemas con los que me he encontrado y que me han impedido utilizarlo:

• Cuando se utiliza una versión snap de Firefox o similar. Algo que en Ubuntu o distribuciones derivadas podremos resolver instalando la versión no snap o invirtiendo un poco de tiempo.
• Cuando recibimos un mensaje «unexpected error» ante cualquier intento de configuración del addon, que no es otra cosa que una señal de que la comunicación con entre el navegador y la aplicación nativa está restringida, normalmente por apparmor. Para resolverlo sólo tenemos que hacer lo siguiente:

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

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

Al actualizar algunos contenedores LXC en los que mantenía algún despliegue con Docker he acabado encontrando este tipo de error:

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running hook #0: error running hook: exit status 1, stdout: , stderr: failed to add interface veth52242e7 to sandbox: error setting interface «veth52242e7» IPv6 to <nil>: failed to configure ipv6: failed to disable IPv6 on container’s interface eth0, set env var DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE=1 to ignore this error: unknown
Error: failed to start containers: 89fze5ea9d64

Debido a que en LXC el sistema de ficheros es de sólo lectura en «/proc/sys/net» se necesita aplicar una variable de entorno en la sección «Service» del fichero que inicia Docker «/etc/systemd/system/multi-user.target.wants/docker.service»:

[Service]
Environment=»DOCKER_ALLOW_IPV6_ON_IPV4_INTERFACE=1″

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.

ACTUALIZACIÓN

Tres posibles soluciones a este problema en openSUSE Tumbleweed:

• Ejecutar lo siguiente:
  • sudo systemctl stop virtlxcd
  • sudo virtlxcd -f /etc/libvirt/virtlxcd.conf -d
• Cambiar el fichero «/etc/systemd/system.conf.d/80-defaults.conf» para que tenga lo siguiente:
  • [Manager]
    DefaultMemoryAccounting=yes
• Realizar la isntalación de cockpit con podman:

zypper install patterns-microos-cockpit cockpit cockpit-bridge cockpit-kdump cockpit-machines cockpit-networkmanager cockpit-packagekit cockpit-pcp cockpit-podman cockpit-storaged cockpit-system cockpit-ws

systemctl enable –now cockpit.socket
systemctl restart cockpit.socket

Acceder a https://ip:9090 y clicar en «Limited access» para obtener permisos de administración. En la sección de «Podman containers» no saldrá un mensaje para que habilitemos los servicios de podamn, el cual aceptaremos y ya está.

En las instancias de servidor de Oracle Cloud, cuando despliegas alguna de sus imágenes, tienen preconfiguradas una serie de reglas en el cortafuegos que impiden la comunicación a los servicios más básicos como HTTP/HTTPS.

Puede llegar a ser realmente confuso porque, antes de averiguar que en una instalación limpia ya hay reglas de cortafuegos, hemos tenido que abrir puertos y configurar la red en el panel de control de Oracle. Así que podemos dejar el cortafuegos totalmente abierto y gestionar la entrada/salida desde el panel de control.

Con estos comando quitaríamos las reglas:

iptables -I INPUT -j ACCEPT

iptables-save > /etc/iptables/rules.v4

O si sólo queremos abrir ciertos puertos:

iptables -I INPUT 6 -m state –state NEW -p tcp –dport 80 -j ACCEPT sudo netfilter-persistent save

netfilter-persistent save

Para más información, hay un hilo de reddit donde se discute el tema.

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

En esta ocasión es un Intel N95 de 15W y 4 núcleos equipado con 8GB de DDR4, que me costó algo menos de 223€ en Amazon.

Lo primero que me sorprendió cuando lo abrí es que llevase un módulo de memoria Crucial de 3200Mhz que no deja de ser una marca reconocida. A parte incorpora un disipador bastante mejor que el que he visto en otros equipos de similares características, lo que lo hace mantener un temperatura bastante razonable de unos 40º con carga ligera, muy por debajo de los 60º del NiPoGi.

Lleva una tarjeta de red Realtek RTL8111 con velocidades de 800Mbits/seg, de lo más rápido que he visto en este tipo de equipos. El M.2 es de tipo NVME con una velocidad de casi 600MB/seg. de la marca Maxio.

El procesador se comporta estupendamente para tareas multimedia con su soporte por hardware del códec AV1.

En este caso se trata de un miniPC con el Intel N95 de 15W y 4 núcleos equipado con 16GB de DDR4, que me costó un poco menos de 240€ en Amazon y que acabó siendo devuelto.

El procesador da soporte por hardware a la decodificación del códec AV1 pero la construcción no parece permitirle una buena circulación de aire, permaneciendo fácilmente por encima de 60º sin casi carga. Parece que lleva la misma solución térmica que el N5105 que es de 10W cuando el N95 es de 15W. Esto se resumía en un constante ruido de ventilador y, de ser usado por periodos largos de tiempo, en throttling.

La tarjeta de red es una Realtek que alcanza velocidades ligeramente por encima de 750Mbits/seg lejos del Gigabit.

El disco M.2 es de tipo SATA, un Kowin E2000 de 512GB con velocidades de 500MB/seg. Incorpora un módulo de memoria RAM SODIMM DDR4 de 16GB de 2667Mhz.

Lo acabé devolviendo porque las temperaturas eran altas y, sobretodo, porque emitía un zumbido eléctrico muy molesto cuando estaba apagado pero conectado a la corriente.