Author Archives: alfredo

MacOS: Mola, salvo cuando se le va la pinza creando Preboots

Lo malo de solo tener un culo es que hay que aceptarlo como es, y el mío es inquieto. Vamos, que a media lectura de la página de Apple sobre las bondades de Catalina, ya mi culo estaba firmando que recaerá sobre mí y mi descendencia hasta la octava generación el karma por correr betas, y que bla bla bla aceptaryaleche.

Pero las cosas a veces van y otras veces se arrastran, y en mi caso el arrastre por todos los motores de búsqueda conocidos por el hombre empezó con un misterioso mensaje de error: Could not create a preboot volume for APFS install.

Por la Internet alante se encuentra todo tipo de recetas para salir de esa. Para variar, ninguna me funcionó. Pero salí de esa. ¿Cómo?

Observé que mi directorio /Volumes contenía una cantidad enfermiza de directorios cuyo objetivo en la vida, aparentemente, es montar el volumen Preboot:

alfredo@Alfredobot-274 /Volumes> ls
InstallESD    Preboot 18  Preboot 29  Preboot 4   Preboot 50  Preboot 61  Preboot 72  Preboot 83  Preboot 94
Macintosh HD    Preboot 19  Preboot 3   Preboot 40  Preboot 51  Preboot 62  Preboot 73  Preboot 84  Preboot 95
Preboot        Preboot 2   Preboot 30  Preboot 41  Preboot 52  Preboot 63  Preboot 74  Preboot 85  Preboot 96
Preboot 1    Preboot 20  Preboot 31  Preboot 42  Preboot 53  Preboot 64  Preboot 75  Preboot 86  Preboot 97
Preboot 10    Preboot 21  Preboot 32  Preboot 43  Preboot 54  Preboot 65  Preboot 76  Preboot 87  Preboot 98
Preboot 11    Preboot 22  Preboot 33  Preboot 44  Preboot 55  Preboot 66  Preboot 77  Preboot 88  Preboot 99
Preboot 12    Preboot 23  Preboot 34  Preboot 45  Preboot 56  Preboot 67  Preboot 78  Preboot 89
Preboot 13    Preboot 24  Preboot 35  Preboot 46  Preboot 57  Preboot 68  Preboot 79  Preboot 9
Preboot 14    Preboot 25  Preboot 36  Preboot 47  Preboot 58  Preboot 69  Preboot 8   Preboot 90
Preboot 15    Preboot 26  Preboot 37  Preboot 48  Preboot 59  Preboot 7   Preboot 80  Preboot 91
Preboot 16    Preboot 27  Preboot 38  Preboot 49  Preboot 6   Preboot 70  Preboot 81  Preboot 92
Preboot 17    Preboot 28  Preboot 39  Preboot 5   Preboot 60  Preboot 71  Preboot 82  Preboot 93

Y observé, en particular, que había hasta el Preboot 99. Ni uno más, ni uno menos. Así que, cabezazo a cabezazo contra la mesa, acabé por formular la hipótesis de que lo que el programa de instalación quería no era otra cosa que crear un punto de montaje nuevo para el Preboot. Aparentemente, si ya existe /Volumes/Preboot, intenta /Volumes/Preboot 1, y si no /Volumes/Preboot 2, etc… Hasta /Volumes/Preboot 99, y ahí lo deja por imposible. Pero, ¿acaso dice «Unable to create /Volumes/Preboot directory» o algo así clarificador? Noooo, esto lo ha hecho uno que viene de Microsoft, y lo que dice, que al traducirlo despista más todavía, es lo que se ve en el título.

Total. Que me los cargué todos, excepto el primero y el último, por si acaso. Innecesaria precaución: Tras instalar Catalina, no quedó ni uno. Y Catalina funciona, al menos lo bastante como para contarlo.

Ansible y autenticación mysql

Trabajando con una Debian o Ubuntu por defecto, la autenticación para el usuario root de MySQL/MariaDB está tan lejos como anteponer sudo a lo que sea que queramos hacer desde el shell.

Esto es, obviamente, enormemente práctico. ¿Queremos crear una base de datos? sudo mysql. ¿Examinar una base de datos? sudo mysqldump basedepatos. Etcétera. Sin necesidad de recordar ninguna clave o mantener una insegura.

Al pasar alguna de estas actividades a Ansible, sin embargo, tenemos todas las papeletas de encontrarnos de morros con esto:

fatal: [mizervio]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, \"Access denied for user 'root'@'localhost'\")"}

¿Esto qué es? Bueno, pues que la magia de la que hablaba al principio es posible simplemente porque usamos el socket de autenticación… Y eso lo podemos hacer porque somos root. Este es el socket de autenticación de una Debian 10:

srwxrwxrwx 1 mysql mysql    0 sep  9 18:39 /run/mysqld/mysqld.sock

Pero Ansible no usa el socket de autenticación. A no ser que se lo digamos explícitamente. Por qué han elegido este comportamiento, en lugar de ser consistentes con la línea de comandos, probablemente tiene que ver con pensar en ello demasiado o demasiado poco, pero no seré yo quien arrample contra unos tipos a los que, la verdad, estoy más que agradecido por haber creado esta máquina de ahorrar tiempo y dolores de cabeza.

Además, la solución es fácil. Se coge la receta uno, y se añade en la tarea en que se llame a mysql_db:

login_unix_socket: /run/mysqld/mysqld.sock

Listo, resuelto todo. De nada.

ixgbe failed to load because an unsupported SFP+ or QSFP module type was detected

En la más pura y molesta tradición de Cisco, ahora el controlador que lleva el kernel (para valores de «ahora» cercanos a 4.19) para los chips de red de Intel (disculpad la palabrota), solamente quiere usar SFPs que hayan probado anteriormente.

Si tienes un SFP de «su» marca, todo va bien. Si no es de «su» marca, ya puede ser el mejor del mercado, que el controlador decide que a la mierda:

ixgbe 0000:01:00.0: failed to load because an unsupported SFP+ or QSFP module type was detected.

Señor, dame paciencia que para mala leche ya tenemos a Linus.

Total. Que, si nos pasa eso, tenemos dos posibles soluciones:

  • La buena, que es decirle al controlador que se verifique al que lo programó:

echo "options ixgbe allow_unsupported_sfp=1" > /etc/modprobe.d/ixgbe.conf

Si nuestro kernel lleva el controlador de marras compilado dentro, tendremos que pasarlo por la línea de comandos del kernel. Prosaicamente, añadir donde toque (/etc/default/grub, /etc/grub.d/ o lo que tenga nuestra distro) ixgbe.allow_unsupported_sfp=1.

Y con eso, y si acaso el juicioso uso de rmmod ixgbe ; insmod ixgbe, estaremos de nuevo en marcha, como si no se les hubiera ocurrido… Bueno, no sigo, que me enciendo.

ModSecurity con Nginx en Buster

Tras pasarlo regular para poner a marchar un Nginx como proxy inverso con ModSecurity, he pensado que sería buena idea volcar en alguna parte mis notas para ahorrar quebraderos de cabeza a otros sufridos informáticos.

Buster lleva la librería ModSecurity 3 ya empaquetada. No hay más que instalarla con apt.

Lo que da un poco de problema es compilar el módulo de nginx. Esto, por ahora, hay que hacerlo a mano.

Primero, instalar nginx con apt.

Luego, bajar el fuente de la versión exacta. En el momento de escribir esto:

dpkg -l nginx
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-==========================================
ii nginx 1.14.2-2 all small, powerful, scalable web/proxy server

Por tanto:

wget -O - http://nginx.org/download/nginx-1.14.2.tar.gz | tar xzf -

También necesitamos el conector de ModSecurity con nginx:

git clone https://github.com/SpiderLabs/ModSecurity-nginx.git

Ahora, ojo a esto. Aparte de build-essential, hacen falta otras cosas. La más enrevesada es libpcre3-dev. Sin esto, no compila el módulo de nginx. Pero es que además hay que configurar el conector para que la use. Es decir, ya en el directorio del fuente de nginx (nginx-1.14.2 en este caso):

./configure --with-compat --add-dynamic-module=../ModSecurity-nginx --without-http_rewrite_module --without-http_gzip_module --with-pcre

Hecho esto, ya no hay más que hacer make.

Otra cosa que despista un poco es dónde pone Debian las cosas. El módulo compilado lo podemos encontrar en objs/ngx_http_modsecurity_module.so y casi cualquier guía que encontremos por ahí dice de ponerlo en /etc/nginx/modules. Pero nop, eso no es el estilo Debian. Para hacerlo al estilo Debian, hay que soltarlo en /usr/lib/nginx/modules/ y seguidamente crear la configuración que lo carga. Verbigracia:

echo "load_module modules/ngx_http_modsecurity_module.so;" > /tmp/mod-security.conf && sudo mv /tmp/mod-security.conf /etc/nginx/modules-available/

cd /etc/nginx/modules-enabled/

sudo ln -s ../modules-available/mod-security.conf 50-mod-security.conf

sudo service nginx restart

Y nuestros esfuerzos se verán recompensados con un:

nginx: [emerg] module "/usr/share/nginx/modules/ngx_http_modsecurity_module.so" is not binary compatible in /etc/nginx/modules-enabled/50-mod-security.conf:1

Mierda.

Total. Que vamos a ver cómo está construído el nginx del paquete Debian:

nginx -V

Esto suelta el chorizo que en su día le pasaron al nginx al compilarlo para empaquetarlo. Y nos dice que:

configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-sWHVb6/nginx-1.14.2=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-auth-pam --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-dav-ext --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-echo --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-upstream-fair --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-subs-filter

Vale

Pues nada, paciencia y vamos a ver.

make clean

./configure --add-dynamic-module=../ModSecurity-nginx --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-sWHVb6/nginx-1.14.2=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module

make

sudo cp objs/ngx_http_modsecurity_module.so /usr/lib/nginx/modules/ngx_http_modsecurity_module.so

sudo service nginx start

Los otros –add-dynamic-module se pueden omitir. Y ya estamos listos.

Configurar un proxy inverso con ModSecurity es otra historia y debe ser contada en otra ocasión.

Debian live a medida

En Github se pueden encontrar excelentes instrucciones para instalar una Debian Stretch con ZFS en la raíz. ZFS no está disponible directa y cómodamente en el instalador de Debian porque las licencias de Linux y de ZFS no son compatibles, por lo que es necesario <suspiro>hacerlo a mano</suspiro>.

En fin. La forma más normal, como se puede leer, es arrancar con una Debian «live» y seguidamente hacer un montón de cosas a mano. Esto es muy instructivo, pero cuando a uno le esperan una pila de hipervisores, que pesan más que uno y hasta algunos opinan que valen más, en todos los cuales hay que instalar una ZFS en raíz… Es de recibo buscar un método algo más automático.

El primer paso es automatizar un poquejo las acciones con un script en bash. Esto es bastante agradecido ya; no hay más que copiar y pegar, y la instalación se hace sola (más o menos).

Pero arrancar con una Debian Live tiene sus cosillas, como que hay que instalar una tonelada de software todas y cada una de las veces. Entre otras cosas, el zfs va en dkms y depende de un montón de cosas.

Así que, redondeando, decidí hacerme una Debian Live a medida. Esto no es tan difícil, especialmente si alguien lo ha hecho antes y ha vivido para documentarlo, como por ejemplo ha hecho Will Haley con este excelente artículo. Partiendo del mismo, he hecho unas pocas adaptaciones y esto es lo que me funciona, para hacer una ISO de Debian Stretch (live) especialmente para instalar Debian con ZFS en raíz, utilizando una Debian Stretch.

En el artículo de Will Haley también explica cómo generar un pincho USB. Pero como la ISO me soluciona la papeleta (porque uso iDRAC, IPMIs, iLOs y otras cosas que comienzan con i), aquí me he quedado.

La cosa empieza instalando en la Debian en que vayamos a trabajar lo necesario:

sudo apt install debootstrap squashfs-tools xorriso grub-pc-bin grub-efi-amd64-bin mtools

Nos creamos un directorio (voy a usar el mismo nombre que Will Haley para no liarnos) y algunos subdirectorios que usaremos más adelante:

mkdir -p LIVE_BOOT/{scratch,image/live}

Nos montamos una Debian básica en ese directorio:

sudo debootstrap --arch=amd64 --variant=minbase stretch LIVE_BOOT/chroot http://deb.debian.org/debian/

En lugar de http://deb.debian.org/debian, podemos usar nuestro mirror favorito si tenemos uno. Igualmente, la arquitectura puede ser i386 o lo que necesitemos.

Nos vamos al chroot:

sudo chroot LIVE_BOOT/chroot

Elegimos un nombre para nuestra Debian «viva» y lo ponemos:

echo "viva" > /etc/hostname
echo "127.0.1.1 viva" >> /etc/hosts

Le instalamos un kernel y lo necesario para el arranque:

apt install --no-install-recommends linux-image-amd64 live-boot systemd-sysv

Añadimos a la masa los paquetes que queramos tener disponibles. Varios de los siguientes son prácticamente una necesidad para poder tener red y esas cosillas:

sudo apt install curl openssh-client openssh-server iproute2 iputils-ping less sudo emacs-nox

Y si queremos usar esta imagen para instalar un ZFS en raíz, podemos ir metiendo algunos paquetes que necesitaremos. Desafortunadamente, zfs-dkms no se puede compilar en un chroot (ni idea de por qué), pero al menos se puede dejar instalado:

sudo apt install debootstrap gdisk dpkg-dev linux-headers-amd64
sudo apt install zfs-dkms

Limpiamos:

sudo apt clean

Creamos un usuario si nos apetece y le damos sudo. O bien simplemente ponemos una clave a root:

sudo useradd -m -s /bin/bash debian
sudo passwd debian
sudo passwd root
sudo visudo

Y nos salimos del chroot

exit

Ya tenemos nuestro entorno listo; ahora hacemos con él un sistema de ficheros:

sudo mksquashfs LIVE_BOOT/chroot LIVE_BOOT/image/live/filesystem.squashfs -e boot

Copiamos el kernel y el sistema de ficheros al directorio donde guardamos lo que irá en la imagen:

sudo cp LIVE_BOOT/chroot/boot/vmlinuz-* LIVE_BOOT/image/vmlinuz
sudo cp LIVE_BOOT/chroot/boot/initrd.img-* LIVE_BOOT/image/initrd

Ahora vamos a crear la configuración de GrUB. El comando search lo que hace es buscar un sistema de ficheros que contenga el fichero /DEBIAN_CUSTOM que vamos a crear seguidamente. Lo podríamos haber llamado /Susana o cualquier otra cosa. El caso es que el sistema de ficheros que pesque con ese fichero creado es el que va a llamar raíz:

cat <<'EOF' > LIVE_BOOT/scratch/grub.cfg
search --set=root --file /DEBIAN_CUSTOM
insmod all_video
set default="0"
set timeout=5
menuentry "Debian Live" {
linux /vmlinuz boot=live quiet nomodeset
initrd /initrd
}
EOF

Creamos el fichero prometido en su sitio:

touch LIVE_BOOT/image/DEBIAN_CUSTOM

Creamos la imagen UEFI con GrUB:

sudo grub-mkstandalone --format=x86_64-efi --output=LIVE_BOOT/scratch/bootx64.efi --locales="" --fonts="" "boot/grub/grub.cfg=LIVE_BOOT/scratch/grub.cfg"

Creamos la imagen de arranque UEFI, de 16 bits de toda la vida (al menos de la vida del PC):

cd LIVE_BOOT/scratch
dd if=/dev/zero of=efiboot.img bs=1M count=10
mkfs.vfat efiboot.img
mmd -i efiboot.img efi efi/boot
mcopy -i efiboot.img ./bootx64.efi ::efi/boot/
cd ../..

Y una imagen de arranque para BIOS:

sudo grub-mkstandalone --format=i386-pc --output=LIVE_BOOT/scratch/core.img --install-modules="linux normal iso9660 biosdisk memdisk search tar ls" --modules="linux normal iso9660 biosdisk search" --locales="" --fonts=""  "boot/grub/grub.cfg=LIVE_BOOT/scratch/grub.cfg"

Concatenamos la imagen de arranque de CD con el sistema de ficheros que hemos creado:

cat /usr/lib/grub/i386-pc/cdboot.img LIVE_BOOT/scratch/core.img > /tmp/bios.img
sudo mv /tmp/bios.img LIVE_BOOT/scratch/bios.img

Y por fin, crear la ISO:

sudo xorriso -as mkisofs -iso-level 3 -full-iso9660-filenames -volid "DEBIAN_CUSTOM" -eltorito-boot boot/grub/bios.img -no-emul-boot         -boot-load-size 4 -boot-info-table --eltorito-catalog boot/grub/boot.cat --grub2-boot-info --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img -eltorito-alt-boot -e EFI/efiboot.img -no-emul-boot -append_partition 2 0xef ${HOME}/LIVE_BOOT/scratch/efiboot.img     -output "${HOME}/LIVE_BOOT/debian-custom.iso" -graft-points         "${HOME}/LIVE_BOOT/image"  /boot/grub/bios.img=$HOME/LIVE_BOOT/scratch/bios.img  /EFI/efiboot.img=$HOME/LIVE_BOOT/scratch/efiboot.img

Listo para usar. A pasarlo pipa.

Los ventiladores de los Mikrotik CCR1036

El sol lucía a mediados de Agosto en la calle cuando, en el CPD, un CCR dijo que uno de sus ventiladores había dejado de girar.

El ventilador en cuestión pertenecía a un Mikrotik CCR 1036 (si, uno de esos a los que ya a estas alturas he hecho mil perrerías, como meterles doble fuente o cambiar condensadores de estabilización de los chips Ethernet).

Algo fastidiado, porque este tipo de equipos generalmente es un tanto complicado desmontarlos estando en producción, me puse a investigar.

Por un lado, encontré un documento PDF titulado «TroubleShooting for CCR1036/CCR1016«. No estoy seguro de su autoría; los metadatos dicen que fue creado con la aplicación Draw de OpenOffice 3.4.1 el 6 de Diciembre de 2013, pero no tienen nada en el campo de autor. En él, se dice que si el ventilador no va, se verifique el transistor Q133. Q133 es un transistor SMD minúsculo, por lo que empecé a rezar a Santa Tecla para que lo roto fuera el ventilador, y no Q133.

Total, que cogí un ejemplar del taller y me miré los ventiladores. Los fabrica Chiefly Choice, su modelo CC 4028B12M. En el momento de escribir este artículo, aquí está su hoja de características. En resumen, es un ventilador de rodamientos de bolas, de 40x40x28 mm; a cambio de 190 mA a 12V, gira a 7000 rpm, moviendo casi 13 CFM (368 l/m), emitiendo un ruido de 33 dBA. O eso dice el fabricante.

En Digi-Key encontré casi 100 posibles sustitutos, muchos de ellos con ventaja. Y ya tenía el dedo en la lista de la compra, cuando el router dijo que el otro ventilador se había parado.

Dos ventiladores de los dos que tiene el chisme parados dan para acojonar al más pintado, porque ya sabemos lo que sigue a continuación: La temperatura empieza a subir rápidamente, y el trasto empieza a rearrancar, lo cual lo enfría un poco, pero en seguida se vuelve a calentar y así se queda, en un bucle sin fin de autodestrucción.

Pero sucedía algo extraño. La temperatura no subía. El trasto seguía clavado en sus 50 grados en placa (60 en el procesador) y diciendo que tenía todos sus ventiladores parados.

Más moscas que las que hay en un laboratorio de teleportación, nos acercamos al centro de datos a meter una brida por la parte trasera del chisme, y… ¡Ñiooooook! Aquello estaba girando, como siempre desde que se enchufó la última vez y se empezó a calentar.

Parece improbable que los dos sensores hayan fallado a la vez, por lo que me inclino a pensar en un fallo de RouterOS. Que he buscado, pero no encontrado; así que lo actualizaremos y ya veremos lo que nos depara el futuro.

Para la posteridad, aquí queda este testimonio de que (a) los CCR1036, al menos una vez, indicaron que estaban sin ventilación no siendo cierto; y (b) las características y referencia de los ventiladores, y posibles sustitutos.

La consola

Desde que Microsoft hiciera su famoso salvapantallas de las tuberías para los Windows NT, en la época de las pantallas de tubos de rayos, ha llovido como para aguar el whisky de todas generaciones que quedan hasta que se nos meriende el sol.

En nuestros tiempos de servidores lindamente apilados en armarios en centros de datos, y sobre todo, de servidores virtuales, los protectores de pantalla en los servidores cumplen las siguientes funciones:

  • Estorbar cuando queremos ver la consola
  • Tener corriendo software innecesario, por lo que son superficie atacable
  • Consumir recursos

Sin embargo, curiosamente, casi todos los proveedores de sistemas operativos (distribuciones GNU/Linux, Windows, etc) parecen seguir encantados con los salvapantallas. En mi estimadísima Debian, se sigue instalando por defecto console-setup, un paquete que solamente es útil si se corre X; y el kernel sigue viniendo por defecto con salvapantallas para la consola.
Como todo esto me parece un derroche, tengo por hábito (ansible mediante o a mano, según) especificar en la línea de opciones del kernel lo siguiente:

consoleblank=0 gfxpayload=text nomodeset nofb

La forma más cómoda de hacerlo es dpkg-reconfigure grub-pc.

Con esto, lo que hacemos es quitar de en medio el framebuffer y dejar la consola en riguroso texto de 80×25 que, aunque no queda mono para hacer una serie de televisión, es lo que normalmente se necesita; y quitamos de en medio el que la pantalla (que no existe) se quede en blanco para «protegerla». Al abrir la consola virtual de este servidor, veremos en seguida lo que está contando (si es que se cuenta algo), y evitamos la habitual incómoda minucia de mandarle una tecla para que lo haga.

 

BFD: Mola, a no ser que a alguien se le ocurra que mola demasiado

BFD (RFC 5880 y ss) es un protocolo independiente del enlace para detectar rápidamente fallos en los mismos. La teoría de funcionamiento es similar a la de un «hello» como los que se usan en OSPF, BGP, etc: Ambos lados esperan recibir periódicamente paquetes BFD del otro y, de no recibirlos, suponen fallecido el enlace y hacen lo que sea que resulte apropiado.

Además del protocolo base, RFC 5881 define BFD sobre IPv4 e IPv6, y RFC 5882 define algunos casos de uso y detalles para implementarlo.

La cosa no está nada mal pensada, excepto por el hecho de que no está definido en ninguna parte si BFD, en los equipos e interfaces que lo pueden llevar, debe estar activado salvo configuración en contra, o no.

Cisco, en su prudente sabiduría, implementa BFD. Si se quiere utilizar, hay que activarlo explícitamente. Algo muy de agradecer, a diferencia de la florida historia del mal parido «Smart Install». Que de smart, la verdad, tiene bien poco.

Mikrotik, por su parte, quizá pensando que esto de BFD mola, lo activa por defecto… Pero ojo, lo hace en los interfaces en que se configura OSPF. Aguanta y tira. O sea, que uno todo confiado añade un interface para hablar OSPF con un Cisco, y comprueba sorprendido cómo la adyacencia se cae y reestablece cada pocos minutos. Carallo, ¿y eso?

Pues BFD. Como el Mikrotik lo activa por defecto en los puertos que hablan OSPF, asume que el otro lado también va a tenerlo activado. Ah, que el otro lado es un Cisco y no… Pues nada, cada minuto el BFD decide que el enlace se ha caído, y por tanto lo sensato es volver a negociar.

BFD está bien, pero en un enlace Ethernet a giga o superior, con todas sus garantías, no parece que añada mucho y no deja de ser un servicio que puede tener problemas. Así que, en general, opto por

/routing/ospf/interface set use-bfd=no numbers=x

Y como se decía antes: Muerto el perro, se acabó la rabia.

Mikrotik y el puerto 2000

A veces, uno tiene la sensación de ser el último en enterarse.
Así me ha sucedido con el peculiar uso, por parte de Mikrotik, del puerto 2000 (que IANA asignó al protocolo SCCP de Cisco en el ya lejano año 2003).
Ellos lo usan para una herramienta llamada bandwidth-server, cuya utilidad en este mundo es probar el ancho de banda de una red conectada a un Mikrotik. Y lo mejor de todo: Está disponible tanto por TCP, como por UDP.
¿Soy el último en pensar que esto es una mala idea, dicho con toda la diplomacia de que soy capaz?
En fin. A lo que voy:
/tool bandwidth-server set enabled=no
Y se acabó el problema. Problema que no debería existir, para empezar a hablar.
Así que voy a añadir esta línea a mi receta de Ansible para Mikrotiks, junto con deshabilitar la pila de servicios que vienen por defecto habilitados.

Mac OS X no se deja actualizar

Sucede en las peores familias: Uno se apunta a las betas de Mac OS X en un momento de locura y desenfreno. Prueba antes que nadie, un tanto kamikazemente, cosas como APFS. Y un buen día, encuentra que no hay cosas aparentemente tan guays que justifiquen seguir corriendo betas. Así que saca el ordenador de las betas. Fácil, ¿no?.

Pues no.

Por algún motivo que no he llegado a comprender del todo, desde que saqué mi ordenador de las betas de Apple no actualiza bien. App Store avisa de que hay una actualización, la descarga, rearranca, hace como que la instala… Y al volver al escritorio, está la que estaba antes.

Mientras encuentro el tiempo (léase «ganas») de investigar el motivo último de este comportamiento, he encontrado una forma de instalar las actualizaciones a mano. Es poco trabajo, pero me ha costado un poco reunir la información, así que aquí queda.

Lo primero es hacernos con el «Combo update» en la página de descargas de Apple. Cuando acaba de salir una versión nueva, suele ser lo primero que sale.

Segundo, arrancar el Mac en modo recuperación (Cmd-R mientras hace clonnnng). Este es un modo mínimo que corre separadamente del sistema operativo principal, y por tanto no se ve afectado por las veleidades de éste.

Tercero, ya con el Mac arrancado en modo recuperación, tirar de la Utilidad de Discos y montar:

  1. Nuestro volumen principal. Sale en la barra lateral, no hay más que marcarlo y puchar el botón «Montar». Habrá que poner la clave si es encriptado.
  2. La imagen de disco de la actualización: Archivo, Abrir imagen de disco, buscarla y listo.

Armados con todo esto, ya podemos burguesamente abrir un terminal y, con la línea de comandos:

installer -pkg combo.pkg -target nuestrodisco

Por ejemplo:

installer -pkg /Volumes/macOS\ High\ Sierra\ 10.13.4\ Update/macOSUpdCombo10.13.4.pkg -target /Volumes/Macintosh\ HD

Y cuando diga que está listo:

reboot

Y el universo volverá a estar en equilibrio… Hasta la próxima.