Archivos de Categoría: ix/ux

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.

 

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.

 

Debian 9 con RAID por software… Y que arranque, y todo

Con lo refinado que está el software libre en general, y el esmero con que está implantado en Debian en particular, es cada vez más raro encontrar, especialmente en una instalación limpia, una situación en que hay que hacer algo siquiera un pelín fuera de guión.

El caso de hoy ha sucedido al instalar en un servidor físico que arranca por BIOS, un RAID 1 por software.

Debian installer, en su versión actual, tiene previsto lo necesario para arrancar con un RAID 1 de discos grandes (y por tanto, GPT), y que además contiene el sistema. Para ello, se necesitan unas pequeñas particiones (1 MB es suficiente) que Debian llama BIOS boot area. Aquí es donde GRUB tiene un sitio para instalar el sector de arranque.

Pues bien, aunque Debian Installer lo ofrece, si estamos particionando manualmente (porque no creemos en la memoria virtual, porque nos gusta usar solo particiones primarias, o porque simplemente somos de la vieja escuela), entonces no acaba el trabajo. Para que el tinglado funcione, hay que hacer lo siguiente.

  1. En todos los discos que participen del RAID, crear al principio de los mismos sendas particiones de 1 MB.
  2. Marcarlas, todas ellas, como BIOS boot area.
  3. Crear el/los RAID oportunos en el resto del disco
  4. Instalar Debian

Si todo va bien hasta ahora, GRUB se ha podido instalar en el primer disco. Pero no hemos acabado:

  1. Rearrancar. Debian arranca con el sector de arranque del primer disco (o el que hayamos elegido en el instalador Y en la BIOS)
  2. Reconfigurar GRUB:
  3. dpkg-reconfigure grub-pc

    Y marcar todos los discos para que Grub, en lo sucesivo, mantenga en todos ellos actualizado el arranque.

Y esto es todo. ¿Qué hemos conseguido? Pequeños detalles: Que si el primer disco es (Ley de Murphy) el que se va al guano, el sistema pueda seguir arrancando. Típico problema que se queda agazapado hasta el momento más inoportuno.

Usando una tarjeta Dell H310 con FreeNAS

Es vox populi que FreeNAS, o cualquier cosa que use ZFS como la versión 5 de Proxmox VE, quiere acceso directo a los discos para que el ZFS los gestione directamente. Es decir, no queremos una tarjeta RAID presentando un único volumen gordo con todos los discos que tiene detrás; solamente queremos que el sistema operativo vea todos y cada uno de los discos.

Para hacer esto, la opción más sencilla es tener una placa base con todos los conectores necesarios. Pero a veces tenemos una cierta cantidad de discos, por ejemplo 12 o 24, conectados a un backplane que, típicamente, cuenta con un par de conectores SFF a partir de los cuales conecta todos los discos.

La Dell H310 es una de bastantes versiones remarcadas de la LSI 9211-8i. Es una tarjeta RAID, pero LSI, en su infinita sabiduría, suministra un firmware que la convierte en una sencilla HBA. Es decir, una tarjeta que se limita a conectar discos y presentarlos de manera visible al sistema operativos. O sea, lo que queremos.

Otra encarnación de la LSI 9211-8i es la popular IBM M1015.

¿Por qué comprar la H310? Por lo de siempre: Por dinero. Van más baratas que las LSI. Además, no hay tantas copias chinas como de las M1015.

Dije que LSI suministra un firmware para convertirla en HBA. Ahora bien, aquí acaban las buenas noticias: El proceso que hay que seguir es algo engorroso pero sobre todo plagado de puñetitas. Así que, ya que me he puesto, he decidido documentarlo.

Hay que decir que la tarjeta tiene un firmware y una BIOS, que son dos piezas separadas. En mi caso, decidí dejarla sin BIOS. Esto no es ningún sacrilegio (la tarjeta vive perfectamente sin ella) y ahorra tiempo en el arranque porque, al no tener BIOS, ya no tiene que echar su meadita en cada arranque del sistema.

Siendo uno de natural paranoico, por otra parte, decidí que solamente iba a descargar el software necesario de sitios de los que me fiara. Tuve que hacer un pequeño salto de fe con fdos.org, más que nada porque es la manera más práctica de generar una ISO de arranque con FreeDOS.

En fin. Vamos a por los ingredientes:

  • Una Debian o cosa similar con xorriso (apt-get install xorriso, sin más)
  • FDOEMCD.builder.zip de fdos.org. Unzip eso, suelta un directorio con el DOSero nombre de FDOEMCD
  • megarec.exe. El único sitio fiable que encontré fue, de una FAQ de Supermicroel FTP de Supermicro. Unzip eso dentro de FDOEMCD/CDROOT. Ya de paso, nos suministra megacli.
  • El firmware IT para la H310. Que, por supuesto, no puede estar en una página de descargas de Dell llamada H310. No, está en la página de los R410, que son uno de los modelos que la montaban. Y ni siquiera se llama H310, sino «6Gbps SAS HBA Firmware Package». En fin, que está aquí y que espero que los de Dell tengan que encontrar su camino por Mongolia con un mapa de carreteras de Libia de 1978. Unzip (es uno de esos exe autoextraíbles que unzip también entiende) dentro de FDOEM/CDROOT también.
  • empty.bin, que es un firmware vacío. Es un fichero de 256 bytes que contiene:
    • 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      *
      0000090 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff
      00000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      *0000100
    • Si te encuentras especialmente paranoico, créalo con un editor hexadecimal.
    • Y si no eres muy paranoico: empty.bin
    • En cualquier caso, también a FDOEM/CDROOT

Ya tenemos todo.

Ahora cogemos y desde FDOEM, y con fe: xorrisofs -o miiso.iso -p "Yo Claudio" -publisher "blog.tecnocratica.net" -b isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table -N -J -r -c boot.catalog -hide boot.catalog -hide-joliet boot.catalog CDROOT

No todas las opciones son estrictamente necesarias, pero así queda más mono. Eso genera miiso.iso.

Bueno, pues arrancamos nuestro servidor con eso (si ese día le toca funcionar al KVM del servidor basado en una versión fosilizada de Java, claro) y ejecutamos:

  • En el directorio de Supermicro, tools:
    • megacli.exe -AdpAllInfo -aAll -page 20
    • Tomar nota de la dirección SAS, para ponérsela más tarde, porque nos la vamos a calzar.
    • megarec.exe -writesbr 0 \empty.bin
    • megarec.exe -cleanflash 0

En este punto, hay que rearrancar. No me preguntes por qué, pero si no, no funciona el invento. Venga, rearranca. Yo espero.

Sigamos:

  • Ahora nos vamos al directorio del firmware de Dell:
    • sas2flsh.exe -o -f 6GBPSAS.fw
    • sas2flsh.exe -o -sasadd <la dirección SAS>

Ya hemos acabado. Llegados a este punto, o tenemos una HBA, o algo con que sujetar la puerta. De nada.

Créditos y enlaces de interés:

  • https://tylermade.net/2017/06/27/how-to-crossflash-perc-h310-to-it-mode-lsi-9211-8i-firmware-hba-for-freenas-unraid/
  • https://forums.freenas.org/index.php?threads/ibm-serveraid-m1015-and-no-lsi-sas-adapters-found.27445/
  • http://www.cgsecurity.org/wiki/Create_a_TestDisk_FreeDos_LiveCD
  • http://blog.asiantuntijakaveri.fi/2013/09/turning-dell-perc-h310-to-dumb-biosless.html
  • https://techmattr.wordpress.com/2016/04/11/updated-sas-hba-crossflashing-or-flashing-to-it-mode-dell-perc-h200-and-h310/
  • https://ciamician.wordpress.com/2015/03/06/flashing-your-dell-perc-h310-to-it-firmware-uefi/

dehydrated y nginx

dehydrated es un cliente ACME escrito en bash.

Resulta extremadamente sencillo de montar y está empaquetado en Debian (desde jessie-backports en adelante), por lo que desplegarlo es trivial. Sin embargo, la documentación, aunque completa, es quizá algo confusa. Especialmente, considerando que lo que quiere hacer la mayor parte de la gente es obtener su certificado y olvidarse del asunto. Pues bien, esto se hace de la siguiente manera:

  1. apt-get install dehydrated
  2. echo «midominio.mitld» > /etc/dehydrated/domains.txt
  3. Configurar el servidor web
  4. Pedir el certificado
  5. Poner un cron que lo renueve periódicamente

Respecto al punto 3, esta es una configuración de ejemplo para nginx. La parte de SSL no funcionará hasta el final del proceso, por lo que hasta entonces no se puede introducir, o nginx no arrancará:

server {
 listen 80;
 server_name midominio.mitld;
 location /.well-known/acme-challenge {
 alias /var/lib/dehydrated/acme-challenges/;
 }
}

server {
 listen 443 ssl default_server;
 server_name midominio.mitld; 
 
 ssl_certificate /var/lib/dehydrated/certs/midominio.mitld/fullchain.pem;
 ssl_certificate_key /var/lib/dehydrated/certs/midominio.mitld/privkey.pem;
}

Esto puede ir en /etc/cron.monthly/renovar-certificado:

#!/bin/dash

/usr/bin/dehydrated -c && /usr/sbin/nginx -s reload

Y ya está. No hay más que ejecutar una vez /usr/bin/dehydrated -c para pedir el certificado, meter la configuración de ssl en nginx, recargar nginx, y listo.

Editado

  • 23 de Agosto de 2017: Mandar una señal reload a nginx: de lo contrario, no leerá el certificado renovado.
  • 28 de Febrero de 2022: Mejor configuración de SSL, eliminando el uso de ssl_trusted_certificate

iTerm 2, o lo que debe ser un terminal

Me llama un compi (que podría escribir estos parrafitos él mismo, pero es tímido) la atención sobre iTerm 2, un proyecto nacido del respetable iTerm, que ha quedado sin mantenimiento durante bastante.
iTerm me ha funcionado bien hasta la actualización a Lion. Entonces apareció un molesto problema consistente en que las ventanas se «encogen» solas, y de cuando en cuando hay que volverlas a ampliar. No un gran inconveniente, pero sumado a la obsoleta y poco funcional búsqueda en el buffer y otros pequeños detalles que podrían estar mejor resueltos, me decidieron a buscar otro programa de terminal.
Lo primero que hice fue arrancar Terminal, el que viene con el OS X. Ha mejorado un tanto desde la última vez que lo probé; ahora permite varias ventanas, tiene una rudimentaria «agenda» de conexiones, es visualmente agradable, y en general, hace lo que tiene que hacer. No busca al vuelo (como iTerm) y no hace nada extraordinario; es una aplicación minimalista, razonable, sin más.
iTerm 2… Empecé a leer la lista de características y a la tercera ya me lo estaba descargando. Lo de tener sesiones en paneles tiene una pinta estupenda, aún no lo he probado; pero, oh, ventura, cómo se nota que los que lo hacen lo usan: ¡Busca al vuelo! ¡Características de Lion! (pantalla completa estilo Lion, para empezar) Y otras cosas que habrá que ir explorando: Copia y pega a la velocidad del estornudo, Growl, usar el ratón de forma nativa en algunas aplicaciones como emacs,… O ideas con una pinta pelotuda para empezar a usar a la de ¡ya!: Histórico de pegar, histórico del terminal («lo tenia en pantalla hace diez minutos, buaaaaa»)…
Echad una mirada, echad: http://www.iterm2.com/#/section/features/
¿He dicho ya que usa los favoritos que hubiera configurados en iTerm?

TermKit

Visto en Slashdot: Un tal Steven Wittens ha concebido una versión siglo XXI del terminal de línea de comandos que todos usamos y, la mayor parte del tiempo, amamos.

Lo cierto es que no tengo mucha esperanza de que llegue muy lejos, porque se olvida de la universalidad de la línea de comandos – mismo motivo por el que todavía en el siglo en que vivimos, todos los hierrecicos de red más o menos serios vienen con un venerable puerto serie que habla caracteres a la astrocuántica velocidad de 9.600 bps; pero tiene «un punto», digamos, da en la diana en varios momentos, y me parece interesantísimo como terminal *ix al menos.

Hasta creo que me lo voy a instalar, mira.