fail2ban en Debian 12 bookworm: Mola… Si te sabes este truquito

fail2ban es un invento estupendo, independientemente de lo bien que creamos que un servidor está protegido del mundanal ruido.

En los tiempos que corren, pensar que una red es «segura» porque está detrás de un cortafuegos es equivalente a apuntar con un arma de fuego cargada a los genitales y hacer lo posible por tener un ataque de hipo.

Así las cosas, una de las formas más sencillas y eficaces de mejorar la seguridad de nuestro servidor, es instalar fail2ban. Siempre ha sido uno de esos servicios de instalar y olvidar, especialmente en Debian, donde simplemente:

sudo apt-get install fail2ban

era lo que había que hacer para tener al menos el ssh con este extra de seguridad.

Pero eso se acabó… Brevemente, en Debian 12 bookworm. ¿Por qué? Bueno, pues tras rebuscar un rato, porque no se acaba de llevar del todo bien con systemd (con la iglesia hemos topado):

Aug 22 09:25:26 nuevadb fail2ban-server[350]: 2023-08-22 09:25:26,534 fail2ban [350]: ERROR Failed during configuration: Have not found any log file for sshd jail
Aug 22 09:25:26 nuevadb fail2ban-server[350]: 2023-08-22 09:25:26,542 fail2ban [350]: ERROR Async configuration of server failed
Aug 22 09:25:26 nuevadb systemd[1]: fail2ban.service: Main process exited, code=exited, status=255/EXCEPTION
Aug 22 09:25:26 nuevadb systemd[1]: fail2ban.service: Failed with result 'exit-code'.

En el caso que nos ocupa, el problema es que fail2ban para funcionar con systemd, vaya por $dios, necesita una librería que no tiene como dependencia.

Así que todos nuestros problemas mejorarán ostensiblemente simplemente:

alfredo@nuevadb:~$ sudo apt install python3-systemd

Seguido de un nuevo (probablemente esté en el history unas cuantas veces ya en este punto)

alfredo@nuevadb:~$ sudo systemctl start fail2ban

Pero la vida nunca es tan sencilla, ¿verdad?

En Bookworm, por defecto no hay syslog (qepd), y sshd larga sus miserias a systemd. Pero por algún motivo, fail2ban sigue creyendo en syslog; así que hay que convencerle de otra cosa. Por ejemplo:

alfredo@nuevadb:~$ sudo emacs /etc/fail2ban/jail.d/defaults-debian.conf

Y añadir la línea

backend = systemd

Ahora sí ya hemos terminado y podemos ooootra vez arrancar, ya con éxito, fail2ban.

Debian mola, salvo cuando te hacen una de estas. En fin. Hasta más ver.

Seguimiento de este problema en el github de fail2ban

ModSecurity en Debian Bookworm

Hace unos años, escribí un artículo comentando la forma de instalar ModSecurity con nginx en Buster. Desde entonces, hemos tenido una pandemia, visto salir Debian 11, 12 y (en el momento de escribir esto) casi la 13, una larga guerra en Europa y varias elecciones.

Esta es una actualización para Bookworm, con dos posibilidades: La larga y la corta.

En general, todo lo comentado en el artículo para Buster sigue estando vigente. Solo hay algunas cosillas:

El kit básico para compilar nginx se instala de aquesta manera.

Nginx:

sudo apt install nginx wget git gcc

Librerías:

sudo apt install libmodsecurity-dev libpcre3-dev libssl-dev libzlib-dev zlib1g-dev libxslt-dev libgd-dev libgeoip-dev libperl-dev

Traerse el código fuente de nginx:

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

El módulo:

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

Configurar:

cd nginx-1.22.1

./configure --with-cc-opt='-g -O2 -ffile-prefix-map=/build/nginx-AoTv4W/nginx-1.22.1=. -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=stderr --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-compat --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_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_secure_link_module --with-http_sub_module --with-mail_ssl_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-stream_realip_module --with-http_geoip_module=dynamic --with-http_image_filter_module=dynamic --with-http_perl_module=dynamic --with-http_xslt_module=dynamic --with-mail=dynamic --with-stream=dynamic --with-stream_geoip_module=dynamic --add-dynamic-module=../ModSecurity-nginx --with-pcr

Compilar:

make

Y mover a su sitio, y hemos terminado.

Claro que, ya que estamos en bookworm, podemos usar el módulo precompilado que aparece por primera vez en esta versión… Y ahorrarnos todo el sarao:

sudo apt install libnginx-mod-http-modsecurity

Las ciencias adelantan que es una barbaridad, ¿eh?.

PostgreSQL en Debian: Actualizar el cluster

PostgreSQL es uno de esos servidores que imponen. Frente a la asequibilidad friqui de MySQL, perdón, MariaDB, PostgreSQL tiene un aire de señor trajeado con cara de pocas bromas. Pero funciona muy bien, que es lo que importa; y el empaquetado en Debian es, como de costumbre, impecable.

Una de las cosas que distinguen a PostgreSQL es que se toma muy en serio eso de las versiones. Tanto que es posible tener varias corriendo a la vez en un servidor sin más que instalarlas con su nombre (postgresql-13, por ejemplo) y ponerle un puerto a cada una en su fichero/directorio de configuración (/etc/postgres/13/main/postgresql.conf, por seguir con el mismo ejemplo).

Actualizar entre versiones puede hacerse a mano, claro. Pero hay una herramienta que viene con el servidor que lo hace todo, y generalmente bien: pg_upgrade.

¿Y cómo se usa pg_upgrade? Como es habitual, la documentación es extensa y explicativa, pero no cuenta el caso de uso más habitual para actualizar en cinco minutos. Que se resuelve de esta manera que sigue a continuación:

1. Parar los servidores:

sudo systemctl stop postgresql

2. Ejecutar la migración con pg_upgrade:

sudo su - postgres 
postgres@servidorimportantequetecagas:~$ /usr/lib/postgresql/versionnueva/bin/pg_upgrade -b /usr/lib/postgresql/versionantigua/bin -B /usr/lib/postgresql/versionnueva/bin -d /var/lib/postgresql/versionantigua/main -D /var/lib/postgresql/versionnueva/main -o ' -c config_file=/etc/postgresql/versionantigua/main/postgresql.conf' -O ' -c config_file=/etc/postgresql/versionnueva/main/postgresql.conf'

Se puede añadir -c al final, para que no haga la migración sino que se limite a ver si todo parece preparado.

3. Cambiar el puerto

Editar la configuración de los servidores, típicamente en /etc/postgresql/versionantigua/main/postgresql.conf y /etc/postgresql/versionnueva/main/postgresql.conf, y poner el puerto deseado en el nuevo, para que las aplicaciones conecten al cluster nuevo.

4. Hacer limpieza:

alfredo@servidorimportantequetecagas:~$ sudo dpkg --purge postgresql-versionantigua postgresql-client-versionantigua

5. Arrancar los servidores:

sudo systemctl start postgresql

Listo. Este sencillo procedimiento, funciona con casi cualquier pareja de versiones de PostgreSQL desde allá por la 9, hasta la actual.

Ya no hace falta la copia de seguridad recién sacada. Porque hay una copia de seguridad recién sacada… ¿Verdad?

NFS en Debian: Molaba el siglo pasado

NFS es uno de esos protocolos que, a la chita callando, ahí sigue. Ciertamente, su interoperabilidad no es la de la familia SMB que Samba resolvió hace años, tras grandes esfuerzos que, sin duda, en ningún caso se dedicaron a su página web. Y en los tiempos que vivimos, en que el espacio tiene un coste tan ridículo, replicar datos al vuelo es tan barato y eficaz, y accederlos por protocolos más «web» es tan fácil, NFS se ha quedado con cuatro parcelitas de uso. Pero son sus cuatro parcelitas, y en ellas no hay nada mejor. Por ejemplo, si un servidor ha de acceder a los archivos de otro, especialmente si está cerquita, y posiblemente también modificarlos, de una manera interactiva y sin grandes complicaciones.

La implantación de NFS en Debian hereda costumbres de tiempos remotos. La página man de nfsd fue modificada por última vez en 2014, y es de las más modernas. No es de extrañar que lo que rodea a nfs, recuerde tiempos de redes confiables, en que lo más peligroso era el entusiasmo de un estudiante descubriendo el mundo de mover bits de un lado para otro.

NFS en Debian, por defecto, escucha en todos los interfaces de red que pilla. Que, como caso general, está bien; pero si lo que pretendemos es que dos servidores que son accesibles públicamente se hablen por una discreta red trasera, y sin exponer al público la posibilidad de buscarle las cosquillas, parecería que nuestro único recurso es poner delante un cortafuegos (unas reglas de nftables, por ejemplo).

Ah, pero la venerable página de nfsd dice que el servicio acepta -H seguida de una IP para escuchar. Guay, ¿y cómo se hace eso a la Debian?

Pues al menos hasta Debian 11, nfs se configura poniendo valores en los tradicionales ficheros de variables de /etc/default. Simple y efectivo. En el caso del servidor nfs, la apropiada es /etc/default/nfs-kernel-server. Ahora bien, ¿cuál es la variable?

Pues una que no está:

RPCNFSDOPTS="-H <IP>"

Por algún motivo, la variable, que es RPCNFSDOPTS, no está. Normalmente, todas las variables que tienen algo que ver con un fichero de variables de /etc/defaults están presentes, aunque estén vacías, y tienen algún comentario que explica su función.

Encontré en Server Fault a otro pobre y desamparado administrador de sistemas preguntándose cómo es posible que no hubiera forma de hacer esto, así que por lo que me costaba, lo dejé documentado para la posteridad.

Así en resumen, el fichero /etc/default/nfs-kernel-server, con RPCNFSDOPTS y todo lo demás, lo lee /usr/lib/systemd/scripts/nfs-utils_env.sh. Este incluye el valor de RPCNFSDOPTS en RPCNFSDARGS y manda esta y otras variables a /run/sysconfig/nfs-utils; de ahí lo lee el fichero unit de arranque de nfsd, /lib/systemd/system/nfs-server.service, y al arrancar /usr/sbin/rpc.nfsd, le pasa como parámetro el contenido de RPCNFSDARGS. Y el arzobispo de Constantinopla… Bueno, que me desvío.

Hacer que un servicio escuche solamente donde necesita, si es que tal cosa es posible, es la primera línea de defensa; anterior, incluso, al cortafuegos. Al fin y al cabo, si no hay posibilidad de comunicación, no hay posibilidad de intrusión. Y como rpc.nfsd lo permite, me he permitido sugerir a Debian que documente el uso de RPCNFSDOPTS en /etc/default/nfs-kernel-server.

Actualizado el día siguiente a la publicación de este artículo lo siguiente. Siempre tan abnegados, respondieron a mi sugerencia superando mis expectativas:

Since version 1:2.6.1-1 /etc/nfs.conf settings can be done, or in
dropins in /etc/nfs.conf.d/ so closing this bug with that version.
Starting there you can set the host= and other parameters in the
configuration file in the [nfsd] stanza.

Salvatore Bonaccorso, mantenedor de nfs-kernel-server

Bookworm tiene ya la versión 1:2.6.2-1+b1. Así que quien no pueda vivir sin esto, que corra esa versión, que en el momento de escribir esto, es la testing. Con la variable puesta como he descrito, por ahora, es suficiente; solo hay que acordarse de volver sobre este asunto cuando se empiece a instalar nfs en bookworm.

Broadcom BCM57800: Mola, salvo cuando se la pega

El chip BCM57800 es uno de los que, en el kernel de Linux, van gestionados por el controlador bnx2x. También es el que lleva una de las tarjetas rNDC de Dell para los r630 más populares, con 2 SFP+ y 2 «cobres» de 1G.

Estas tarjetas con BCM57[0-9][0-9][0-9]* «Everest» son uno de esos productos con una historia meandrosa. Los chips fueron diseñados por Broadcom, que los anunció en Diciembre de 2010, y en poco tiempo usados por Brocade en varios productos. En 2014, QLogic compró a Brocade el negocio de Fibre Channel y adaptadores de red, incluyendo tarjetas que usaban estos chips, cuyo controlador pasó a mantener como atestigua el .h del bnx2x. En Junio de 2016, QLogic fue adquirida por Cavium, que a su vez fue adquirida por Marvell. Por su parte, Brocade fue comprada por Broadcom en 2016. Las tarjetas con chips BCM57 eran de Cavium cuando Dell los empezó a utilizar, y de hecho algunos documentos técnicos en la web de Dell llevan la marca de Cavium.

Toda esta historia implica curiosidades como que en el código fuente, el copyright de Broadcom es anterior al de Qlogic.

Con toda esta florida historia de adquisiciones y pases, no es de extrañar que el bnx2x y sus hermanos hayan pasado por tantas manos que la calidad, al final, se haya resentido. Y esto es lo que parece haber ocurrido para que en algunas versiones, cuando reciben un poco de caña (digamos, una migración masiva de contenedores en un cluster de Proxmox), la red se caiga con todo el equipo:

May 30 20:35:20 hv149 kernel: [ 1272.998710] RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000006
May 30 20:35:20 hv149 kernel: [ 1273.021980] call_timer_fn+0x32/0x130
May 30 20:35:20 hv149 kernel: [ 1273.052021] RDX: 0000012862241f85 RSI: 0000000037a6f674 RDI: 0000000000000000
May 30 20:35:20 hv149 kernel: [ 1273.075905] ---[ end trace 179564100f322278 ]---
May 30 20:35:20 hv149 kernel: [ 1273.099027] bnx2x: [bnx2x_panic_dump:1021(eno1)] indexes (0x0 0xe97e 0x0 0x0 0x0 0x186d 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
May 30 20:35:20 hv149 kernel: [ 1273.158754] INDEX[6] flags (0x3) timeout (0xc)
May 30 20:35:20 hv149 kernel: [ 1273.218986] bnx2x: [bnx2x_panic_dump:1015(eno1)] run indexes (0x7d14 0x0)
May 30 20:35:20 hv149 kernel: [ 1273.334124] bnx2x: [bnx2x_panic_dump:1004(eno1)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
May 30 20:35:20 hv149 kernel: [ 1273.365957] bnx2x: [bnx2x_panic_dump:1004(eno1)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
May 30 20:35:20 hv149 kernel: [ 1273.374863] SM[1] __flags (0x0) igu_sb_id (0x9) igu_seg_id(0x0) time_to_expire (0x4ad6f466) timer_value(0xff)
May 30 20:35:20 hv149 kernel: [ 1273.377750] INDEX[1] flags (0x2) timeout (0x6)
May 30 20:35:20 hv149 kernel: [ 1273.440571] bnx2x: [bnx2x_mc_assert:736(eno1)]XSTORM_ASSERT_INDEX 0x12 = 0x0002ef76 0x00000000 0x0400000d 0x000200

El caso es que esto no le hace mucha gracia a los contenedores ni, en cascada, a los cientos de servicios que hay en ellos corriendo; por lo que parece conveniente investigar un poco el problema.

El bnx2x sigue recibiendo un activo mantenimiento, y no pasa un mes sin que reciba una actualización. El comportamiento problemático ha sido observado en los kernel 5.4.78 (Noviembre de 2020) y 5.4.189 (Abril de 2022). Pero la rama 5.4, incluso en este último kernel, a pesar de su reciente factura, sigue llevando una versión de bnx2x fechada en 2014, y bnx2x ha recibido importantes actualizaciones en todas las versiones principales desde entonces. De hecho, ha dejado de tener su propio número de versión; su código fuente está en github, en el repo del bueno de Linus, desde hace más de diez años; si bien parece que le ha costado una temporada de su tortuosa historia armonizarse completamente.

Pero a día de hoy, las actualizaciones van siendo cada vez más tranquilas y de mantenimiento progresivo. En la rama 5.15, que en el momento de escribir este artículo es la más actual de mantenimiento «longterm», ha recibido actualizaciones en media docena de versiones. De todas, solamente llama la atención que en la 5.15.38, «While handling PCI errors (AER flow) driver tries to disable NAPI [napi_disable()] after NAPI is deleted [__netif_napi_del()] which causes unexpected system hang/crash.» Que es una bonita forma de decir que vaya, que fíjate, que el sistema entero se la puede pegar en cualquier momento; pero solamente después de que ya haya habido un error de PCI, es decir, que es un caso bastante raro. Todo lo demás son cosas del estilo de «Fix unused-function warning«, reorganizaciones, limpieza y usar las características más modernas del kernel.

TL;DR: No es de esperar que esto se la pegue tras actualizar a Proxmox 7.2, que lleva el kernel 5.15.35. Siguiente problema.

ConnectX4 LX: Molan, hasta que se atascan

nVidia (nacida Mellanox) dice en sus notas de actualización de firmware que es un «rare case». Pero a todos nos mira un tuerto de vez en cuando, y ese día no fue de extrañar que un Dell r630 dejara de ver sus dos puertos SFP28 (en la tarjeta rNDC, pero esto es irrelevante; es PCIe, al fin y al cabo).

En lugar de los SFP28, nos gratificó con un arranque bastante lento y un críptico error en syslog:

mlx5_core 0000:01:00.0: mlx5_function_setup:995:(pid 252450): Firmware over 120000 MS in pre-initializing state, aborting
mlx5_core 0000:01:00.0: probe_one:1484:(pid 252450): mlx5_init_one failed with error code -16

Los dispositivos, en consecuencia, no aparecieron en el sistema operativo, convirtiendo este servidor en un nada práctico pisapapeles.

¿Y qué es lo que pasaba? Una bonita tarde de domingo escarbando (con el dueño del servidor cerca de un desfibrilador), reveló esta perla en las notas de versión del firmware:

- Fixed a rare case where the the device hanged while running the sw reset flow under heavy stress and with many open resources.

Bueno, no era mucho, pero tras haber rearrancado mil veces el servidor y hasta haberlo apagado y encendido, no quedaba mucho más que pudiera ser. Bien fuera este caso o un primo hermano, suele merecer la pena actualizar el firmware de los diferentes subsistemas: El mantenimiento de firmware suele consistir casi siempre en correcciones de errores, siendo la introducción de errores nuevos relativamente infrecuente.

Con Dell hemos topado

En general, Dell hace las cosas bastante bien y el Open Manage Enterprise, que permite actualizar firmwares sin dolor y masivamente, por sus muchos defectos, es una herramienta de lo más útil. Si el servidor en cuestión está integrado, claro. Lo cual no era este caso porque es un servidor de un cliente; y, para añadir insulto a la ofensa, ni la iDRAC, ni el lifecycle controller local veían posible actualizar el firmware. Decían que ese dispositivo no está en el sistema. Lo sabrán ellos.

Total.

  • Descargar las herramientas de gestión de firmware de nVidia;
  • Descargar el firmware de Dell para la tarjeta en cuestión;
  • Desempaquetar el firmware del putrefacto .EXE que suministra Dell (unzip es suficiente).
  • Averiguar gracias a lspci -vv cuál de los tres firmwares sin más explicación es el correcto para la tarjeta rNDC (lspci da el nombre de la pieza, que forma parte del nombre del archivo de uno de los tres .bin que el paquete de Dell incluye en payload/). Como para unas prisas:
# lspci -vv | grep PN
        [PN] Part number: 0R887V
        [PN] Part number: 0R887V
# ls networkfirmware900n0/payload/ | grep 0R887V
fw-ConnectX4Lx-rel-14_31_1014-0R887V-UEFI-14.24.13-FlexBoot-3.6.403.bin
  • Quemar
# flint -d 01:00.0 -i networkfirmware900n0/payload/fw-ConnectX4Lx-rel-14_31_1014-0R887V-UEFI-14.24.13-FlexBoot-3.6.403.bin b
  • Rearrancar el firmware
# mlxfwreset -d 01:00.0 reset

Y listo, a funcionar. Rearrancamos y actualizamos todo, ya que estamos, hacemos un bonito artículo por si alguien se ve en las mismas, y nos acabamos el café.

Nexus: Molan, hasta que se convierten en ladrillos al actualizarlos

Era un día normal para un venerable y fiable Nexus 3000, concretamente un 3064 que corría NX-OS 6.0(2)U6(6) tras una pequeña actualización sin novedad y sin hacer más que conmutar paquetes a nivel 2.

Había llegado para él el día de actualizar. Se había decidido que iba a empezar a terminar vLANes, es decir, a nivel 3; lo cual requiere ponerle direcciones IP públicas, y las versiones 6 tienen algunos feos fallos de seguridad. Por supuesto que a base de ACLs y/o cortafuegos es posible aislar lo bastante las IPs públicas de un gateway. Pero ya hace muchos años que Rommel popularizó la defensa en profundidad, y en redes es más que aplicable lo que tanto sufrimiento costó entender a los militares.

El concienzudo proceso de actualización de los Nexus requiere, en este momento, pasar por varias versiones intermedias partiendo de la 6 hasta llegar a la deseada, la 9.3.8 en el día de actos. Así que, armados con la paciencia nacida de la experiencia, mandamos la 7.0.3.I7.9. Runtime checks, boot variables, configuration copy y todo lo habitual hasta llegar a

Finishing the upgrade, switch will reboot in 10 seconds.

Fue lo último que dijo.

Mosqueados tras un ratito, consola en ristre, desenchufado de la corriente y vuelto a enchufar, nos informa por la consola:

(c) Copyright 2011, Cisco Systems.
N3000 BIOS v.4.5.0, Thu 11/09/2017, 05:38 PM

Y nada más. Ni boot loader, ni pulse Del… Nada.

Colgado.

Vaya, qué inconveniente.

Así que vamos a ver qué se hace en estos casos. Buscando por Internet no encontré nada de nada, así que escribí en los foros de Cisco. Las respuestas no pudieron ser más descorazonadoras: Una vez se aseguraron de que lo habitual no iba a funcionar, solo quedó como posibilidad abrir un caso con el TAC de Cisco y probablemente cambiarlo.

Pero estos switches ya otoñales no suelen tener un SmartNet activo, y Cisco ya no hace caso de nadie sin ello. Así que, mientras uno buscaba (con poco éxito) si aún se venden SmartNets para este modelo, el otro fue a desmontar el equipo, convencidos de que la cosa iba para largo. Tal vez, razonamos, haya alguna forma de fulminar la memoria flash y obligarle a irse al boot loader; o de hacerle arrancar de alguna manera.

Foto del módulo eUSB
Módulo eUSB fabricado por Viking Technology

Pues sí. Y más fácil que lo que nos temíamos.

El almacenamiento en estos equipos es una memoria flash USB. Es una versión un poco especial de USB, pensada para entornos industriales y para montarse de placa a placa, pero es USB al fin y al cabo. Está sujeta con un tornillo a la placa base y lleva un conector estilo DB9 miniaturizado (tal vez un Hirose DF9).

Bueno, pensó alguien. ¿Y si arranco el equipo sin la flash?

Dicho y hecho:

Press ctrl L to go to loader prompt in 2 secs

loader>

¡Tenemos boot loader! Desde aquí, ya todo es un paseo: Con el boot loader, se le puede arrancar por tftp o por un pincho USB. Esto último, con el equipo sin red fuera de la mesa, parece lo más inmediato…

loader> boot usb1:nxos.7.0.3.I7.9.bin

Pero, parafraseando al androide chungo de Blade Runner, el dios de la mecánica no se había terminado de ciscar en nosotros aún, y al equipo en cuestión no le daba la gana de arrancar desde el puerto USB.

Vaya.

Lo siguiente.

¿Y si, dado que se puede desmontar este módulo, probamos con el de otro equipo parecido?

Dicho y hecho, en menos de lo que se tarda en leerlo estábamos quitando los aproximadamente 150.000 tornillos Phillips del 1 de una aleación similar a la plastilina que sujetan la tapa del segundo equipo y cambiando su módulo al enfermito.

Y arrancó. Sin más. Bueno, es lo que esperábamos, ¿no?

Lo que no esperábamos es que el módulo del switch enfermo… Hiciera arrancar al «donante». Pero había que rendirse a la evidencia, evidencia presentada en nuestro terminal con un lacónico

%ASCII-CFG-2-CONF_CONTROL: System ready

Pofale.

Desde aquí, actualizar con mucho cuidadito nuevamente y a correr.

Mola la informática. Aunque a veces… Felix qui potuit rerum cognoscere causas. Aunque, en el caso que nos ocupa, nada más actualizar y en el siguiente arranque, pasó casi desapercibido un mensaje que decía algo así como: «Vaya, el firmware eUSB necesita actualizarse. Voy para allá… Hecho, sigamos con lo nuestro».

Vaya.

megacli: Mola, relativamente

Megacli sirve para todo, y no hay nada en un chip RAID de LSI/Avago/Comesellamenhoy que no pueda configurar. Esas son las buenas noticias.

Las regulares… Pues son chips complicadillos y por tanto la línea de comandos de megacli, tiene su complejidad. Incluso antes de que a alguien se le ocurrieran esas graciosas abreviaturas.

El ejercicio de hoy era sacar unos discos de una venerable 2108 de un Supermicro otoñal, y meterlos en un Dell r620 con su H310.

Al meterlos, hacen blip-blip y todo parece ir bien, pero… No aparecen por ninguna parte en /dev/pordondesemire.

Megacli sí los ve, o mejor dicho, su primo megaclisas-status: Unconfigured(good). No parece mala señal.

Bueno, pues solo hay que cambiarlos a JBOD para poder dárselos a Ceph, ZFS o a cualquier otra cosa con o sin Z, ¿no?.

No…

megacli -PDMakeJBOD -PhysDrv[32:6] -aALL
Adapter: 0: Failed to change PD state at EnclId-32 SlotId-6.

Vaya. Que no se puede. Aguanta y tira.

¿Y por qué no se puede? Je. Porque vienen con la meadit… Quiero decir, con la firma del RAID precedente. Podrían tener el detalle de decirlo, pero vaya, no, no lo tienen. Bueno.

¿Y tiene solución? Claro. La artesanal, que es meter el disco en alguna parte que no sepa nada de RAIDs y ciscarse la firma, por ejemplo con un dd; o la megacli, que ya que estamos…

root@lab.tecnocratica ~ # megacli -CfgForeign -Scan -a0

There are 1 foreign configuration(s) on controller 0.

Pues al carajo con ella, ¿no?

root@lab.tecnocratica ~ # megacli -CfgForeign -Clear -a0

Foreign configuration 0 is cleared on controller 0.

Pues a la carga de nuevo:

root@lab.tecnocratica ~ # megacli -PDMakeJBOD -PhysDrv[32:6] -a0

Adapter: 0: EnclId-32 SlotId-6 state changed to JBOD.

Pues como siempre, tras un rato de rompimiento de cabeza, eso era todo. La verdad es que estaría bien que si alguien busca por «controladora perc o raid de dell o de supermicro o de quien carajo sea no ve discos que vienen de otra controladora» encontrase esta receta, que le haría ahorrar algo de tiempo. Se intentará…

ix0: Unsupported SFP+ module detected!

Ya el año pasado, me tocó lidiar con la estúpida decisión de Intel de que sus chips de 10G no funcionan con los SFP que no entran en la corta lista de los que tienen probados.

La historia se repite, y esta vez ha sido un venerable FreeNAS 11.1 en un nuevo armario y con nuevos y flamantes cables AOC el que lleva el controlador de Intel que ha decidido, vaya hombre, que los AOC no son lo bastante flamantes; que si eso, que compre otros.

Uno no tiene tiempo ni ganas de dejarse llevar por las veleidades de una empresa que tiene gente trabajando en puestos que llevan a la vez la palabra technical y la palabra marketing (pobrecicos).

Usando la clásica técnica de poner en un buscador el mensaje de error que sale en dmesg y que da título a este artículo, en seguida se llega a algún ticket del redmine de IXsystems / FreeNAS; no en vano es uno de los mayores distribuidores de FreeBSD del momento.

El caso es que, como suele suceder, las cosas no pueden ser tan fáciles.

¿Es cierto que añadir a /boot/loader.conf las palabras mágicas:

hw.ix.unsupported_sfp=1

resuelve el problema? Si.

Pero no es menos cierto que en la versión 11.1, no. Vamos, lo ignora completamente en la versión que va en el kernel de la 11.1.

Así que, usando la clásica y probada por la experiencia técnica de la huida hacia delante, me bajé la ISO de la última estable de FreeNAS y le hice una actualización in situ. Las actualizaciones de FreeNAS son una gozada, si bien hacerlas sobre uno de esos KVM viejos de Supermicro no son la mejor experiencia del mundo. Pero en una máquina virtual Windows bien añeja (de Windows 7 para atrás) funcionan, así que no me voy a quejar demasiado. Total, hace años que por estas cosillas dejé de comprar Supermicro y pasé a comprar Dell.

Una vez hecha la actualización, arrancado el sistema nuevo, ya todo…

…Una mierda. Resulta que la actualización instala su propio /boot/loader.conf. Bueno, no pasa nada: Otra vez KVM basado en Java y volver a añadir hw.ix.unsupported_sfp=1 al final del ficherito.

Y esta vez sí, por fin, quejándose como un abuelo hablando de política en el bar del pueblo, por fin levantó los puertos de 10G. Y el resto, como se suele decir… Es historia.

Los switches HP 7900 y sus rutas inactivas

No molan mucho, la verdad.

Los HP 7900 y sus compañeros de gama pelo arriba, pelo abajo, corren Comware. Comware es un sistema operativo que HP compró en el paquete de 3Com en 2010. Había sido diseñado por H3C, en la que 3Com participaba junto con Huawei y de la que compró a su socio su parte en 2007. Esto es el motivo por el que los switches HP y los Huawei hablan el mismo idioma.

Recientemente, nos encontramos un caso en que se había instalado un par de switches HP7900 en cluster para un proveedor de servicios de alojamiento, perdón, de cloud. En seguida se hizo evidente que una de las primeras necesidades, desde un punto de vista de diseño de red, era una frontera nueva: Los HP solamente tienen memoria para 32.768 rutas aprendidas por BGP, mas alguna (unas pocas) «extra». En el momento de escribir este artículo, la Tabla va por encima de las 800.000, y subiendo. Evidentemente, no podían hacer ni un atisbo de balanceo de tráfico, y olvidémonos de puntos neutros o cualquier otro refinamiento.

Lo interesante que observé en Comware es que, cuando se le acaba la memoria para rutas, no tira la sesión de BGP que le ha llenado la memoria, como hacen los Cisco (y con ello agravando el problema); simplemente, está llena, pues está llena: Ya no se instalan más rutas.

Pero no se instalan, no se instalan: Si con la memoria llena se añade una IP a un interface, ese interface no funciona a nivel 3 porque no tiene memoria ni para la ruta conectada.

¿Solución que le daban localmente a este problema? Reiniciar el bicho. ¿Por qué si se reinicia ya funciona el nuevo interface? Fácil: Las conectadas llegan antes a la tabla que las aprendidas por BGP, que han de esperar a que la sesión se establezca. Pero claro: Toda la red sin conectividad ninguna mientras dura el rearranque. Ole.

En fin. Una pareja de Mikrotiks resolvió muy lindamente una frontera nueva. A día de hoy, la propuesta de Mikrotik no es una panacea: Seguimos esperando una implantación de BGP mejor, y sería deseable que la estabilidad mejorase un pelo. Pero funcionan en general bastante bien, conmutan tráfico como campeones, tienen IPFix (algo casi imprescindible en nuestros días), y el precio es imbatible.