«Modern OS should use virtio-scsi anyways«. Esta cita de Tom, de Proxmox, originalmente en su foro, suena a buena idea. Ya que hemos sustituído una controladora SCSI (SATA para nosotros, los humildes), con su correspondiente disco, por una mera simulación software de la misma y un trocito de un disco más grande, suena correcto que el controlador por el que el virtual pide sus operaciones sea virtual.

Hay varias razones para ello. La más sencilla es que una controladora virtual (una LSI, por ejemplo, que es una de las más populares) no deja de ser un software cuya tarea es interpretar lo que pide el sistema virtualizado, usando unos comandos que se diseñaron pensando en discos que giran y tienen cabezas magnéticas, y convertirlo a lo que el hipervisor ofrece. Esto último, cada vez más, son discos que se parecen mucho más a la memoria RAM que a lo que tenían en mente los que diseñaron el protocolo SCSI para discos. Entonces, podemos librarnos de un montón de trabajo en todos y cada uno de los accesos del virtual al disco si simplemente cogemos lo que el virtual quiere y directamente se lo damos al hipervisor en su lenguaje nativo. Menos uso de recursos, menos código y menos complejo, igual a menos errores. ¿Algún inconveniente?

Claro que sí. La cosa tiene sus inconvenientes. Los aficionados a la retroinformática («mi ERP requiere Windows Server 2003») descubrirán en seguida que los sistemas operativos diseñados hace quince años no llevan controladores para almacenamiento virtualizado. Oh, por supuesto hay solución: No hay más que bajarse la ISO con los últimos controladores, meterla en el CD virtual, e instalar. Si se trata de una máquina que ya existe, solo queda pegar el cambiazo. Ya de paso, podemos meter el controlador de red virtual. Este último mejorará un pelo el rendimiento y uso de recursos de la red, a cambio de… Su propio interface, por supuesto. Ah, ¿que estábamos hablando de una máquina virtual que ya existe? En ese caso, el ejercicio de malabarismo para cambiar uno por otro sin perder la conexión, lo dejo de manos del lector.

Feliz cumpleaños, Víctor.

Si antes lo digo… Hoy he tenido que instalar dehydrated con Apache.

Igual que con nginx, es la sencillez misma; pero no puedo pasar la oportunidad de dejar testimonio de una configuración de ejemplo con Apache, típicamente guardada (en Debian) en /etc/apache2/sites-available/midominio.mitld.conf:

<VirtualHost *:80>
 ServerAdmin webmaster@localhost
 ServerName midominio.mitld
 DocumentRoot /var/www
 <Directory />
  Options FollowSymLinks
  AllowOverride None
 </Directory>
 <Directory /var/www/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 </Directory>

 ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
 <Directory "/usr/lib/cgi-bin">
  AllowOverride None
  Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
  Order allow,deny
  Allow from all
 </Directory>

 ErrorLog ${APACHE_LOG_DIR}/midominio.mitld.errores
 LogLevel warn

 CustomLog ${APACHE_LOG_DIR}/midominio.mitld.accesos combined
 Alias /.well-known/acme-challenge /var/lib/dehydrated/acme-challenges/
 <Directory "/var/lib/dehydrated/acme-challenges">
  Require all granted
 </Directory>
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
 ServerAdmin webmaster@localhost
 ServerName midominio.mitld
 DocumentRoot /var/www
 <Directory />
  Options FollowSymLinks
  AllowOverride None
 </Directory>
 <Directory /var/www/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 </Directory>

 ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
 <Directory "/usr/lib/cgi-bin">
  AllowOverride None
  Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
  Order allow,deny
  Allow from all
 </Directory>

 ErrorLog ${APACHE_LOG_DIR}/midominio.mitld-ssl.errores
 LogLevel warn

 CustomLog ${APACHE_LOG_DIR}/midominio.mitld-ssl.accesos combined

 # SSL Engine Switch:
 # Enable/Disable SSL for this virtual host.
 SSLEngine on

 SSLCertificateFile /var/lib/dehydrated/certs/midominio.mitld/cert.pem
 SSLCertificateKeyFile /var/lib/dehydrated/certs/midominio.mitld/privkey.pem

 <FilesMatch "\.(cgi|shtml|phtml|php)$">
  SSLOptions +StdEnvVars
 </FilesMatch>
 <Directory /usr/lib/cgi-bin>
  SSLOptions +StdEnvVars
 </Directory>
</VirtualHost>
</IfModule>

El resto de la instalación es idéntico a nginx, y también con la salvedad de activar el módulo SSL después de ejecutar dehydrated -c por primera vez y por tanto tener el certificado ya preparado.

En Debian, esto se hace con la sencilla y elegante instrucción

sudo a2enmod ssl

Seguido, si es menester, por

sudo apache2ctl restart

A pasarlo pipa.

Muchos, me atrevo a decir casi todos los que trabajamos en empresas relativamente pequeñas, estamos acostumbrados a que, tarde o temprando, hay que hacer de todo. Sin ir más lejos, hoy he cambiado un interruptor de luz de la oficina. Bien, pues eso es la parte de hardware: ahora, vamos con el software.

Hace poco, me empeñé en automatizar ciertas operaciones relacionadas con dominios que se hacían a mano, con el riesgo de retrasos y errores que ello entraña y que, de hecho, han generado más de un alzar de cejas. Es un affaire en el fondo sencillo, pero hay que hablar con tres APIs de tres proveedores diferentes en tres países distintos, que no siguen una norma común más allá de lo habitual del uso de json y la filosofía REST tan de nuestros días. Ah, y generar un XML.

La primera versión, para probar, la hice en Bash a base de curl. Curl es una herramienta potente, pero el manejo de flujos de programa en Bash recuerda demasiado que el inefable señor Bourne (nada que ver con el señor Burns, aunque suene casi igual), todo lo que necesitaba era una shell para hacer cuatro cosas. Bastante lejos ha llegado.

Total, que inspirado por un programita que me enseñó un compañero, me puse a hacer una siguiente versión en Python, sin haberlo usado en la vida anteriormente, usando la metodología que nuestro desarrollador de referencia llamó SODD: Stack Overflow Driven Development. Pues bien, Python fue un lenguaje sumamente fácil de aprender para hacer algo sencillo. Las cosas salen con facilidad y, a pesar de que no pretendo ser un programador, me resultó fluido hacer un programa de 200 líneas que cumple su cometido.

Me he limitado a las librerías que vienen de serie con una instalación normal en Debian, y aún así, ha sido razonablemente sencillo encontrar lo necesario para manipulación de fechas, POST, GET, un poco de números y cadenas.

Luego decidí aprovechar para aprender Ruby, y porté el programita.

Me sucedieron inmediatamente varias cosas:

1. No entiendo Ruby. Hay cosas que no sé por qué funcionan, y otras que no sé por qué no. Hay partes de la sintaxis que me resultan alienígenas. Esta sensación no la tengo con Python.
2. Hay cosas extrañamente difíciles de hacer. Un POST, por ejemplo. No he encontrado forma de hacerlo si no es con una gema aparte, o con un bloque de código, o con ambas cosas. También enviar correo se me hace algo aparatoso comparado con Python.
3. El programa engordó un 15%, especialmente por los bloques necesarios para los POST.
4. La escritura de xml es mucho más elegante (siempre hablando de las librerías que vienen «de serie»), si bien con una sintaxis algo alienígena, pero elegante y ligera.

Total. Que el programita de los demoniosdominios lo voy a mantener con Python, y le daré otra oportunidad a Ruby cuando tenga que hacer (si llega el caso, que llegará) alguna pequeña aplicación web. Según me ha asegurado el antes aludido, en ese momento las cosas van a favor de Ruby (on Rails). Claro, que también ha dicho que el futuro es Rust… Así que no sé. Estoy por volver a Bash.

SSH es un protocolo estupendo, y OpenSSH es una implementación digna de estudio por su usabilidad y pulcro mantenimiento, lo que le ha llevado a una casi ubicuidad.

Con los años, los cifrados han ido cambiando, aconsejándose unos y otros según avanza la ciencia de la criptografía. Los siguientes son los más habituales, y los primeros tres los que más he usado:

• RSA, el clásico. Aunque desaconsejado por haber sido superado por lo último, sigue siendo la única forma de tener autenticación con clave pública en, sin ir más lejos, los también ubicuos switches Cisco Catalyst, que no conocen otra cosa. No es aconsejable usarlo para nuevas claves salvo en casos como el mencionado si hay otros más modernos.
• DSA, el que pudo ser. Hace bastantes años, DSA prometía mejorar RSA. Sin embargo, los avances en criptografía lo acabaron poniendo en un riesgo mayor que RSA. En los OpenSSH actuales, se desaconseja usar DSA. Incluso Mac OS Sierra lo trae desactivado de serie.
• ECDSA, una nueva esperanza. DSA con curvas elípticas. Teóricamente, un DSA sin los problemas de DSA. En la práctica, también tiene sus «problemillas»: Su seguridad depende de lo bueno que sea el generador local de números aleatorios. Ni mencionar a alguien siquiera medio paranoico.
• Ed25519, el salvador (al menos por ahora). Un algoritmo matemáticamente fuerte, implementable con buen rendimiento, que depende menos del generador local de números aleatorios y, en fin, al que no se le conocen por ahora grietas. En resumen, el que hay que usar si se ha de elegir uno para empezar.

Por cierto. .ssh/authorized_keys2 lleva años desaconsejado, pero aún se ve en servidores por el mundo alante. Trabajando con versiones siquiera medio actuales de SSH, es recomendable mv .ssh/authorized_keys2 .ssh/authorized_keys.

Lo mejor que puede ocurrir con un almacenamiento es que pase desapercibido.
Lo segundo mejor es que sea potente, escalable y demás características deseables.
Un almacenamiento pasa desapercibido cuando no genera problemas, corre lo suficiente y, en general, va como un reloj. FreeNAS lleva haciendo esto ya años.
Para extraer lo máximo de FreeNAS, no solamente en rendimiento sino también, y más importante, en resistencia a fallos, es necesario aprender unas cuantas cosas sobre ZFS. Cómo se organizan los discos en volúmenes. Cuáles son las mejores formas de mejorar el rendimiento y la fiabilidad, dependiendo del hardware de que se disponga; o qué hardware comprar, dependiendo de lo que se quiera hacer.
A fecha de este artículo, estamos convirtiendo todos nuestros almacenamientos basados en sistemas libres de RAID 10 a pilas de RAIDZ-2 de un máximo de 6 discos. Esto da un máximo de almacenamiento exportado (un 15% largo más que RAID10 con solo 6 discos) con un máximo de rendimiento.
Expandir la capacidad de una cabina cambiando los discos por otros de mayor tamaño es relativamente rápido y sencillo, siempre y cuando uno tome la precaución de leer la sección del manual que describe cómo cambiar discos. En algún caso he tenido que ir a la línea de comandos a hacer un zpool replace; nada que quede fuera del alcance de un administrador de sistemas con algunas noches en su haber. Desapercibido.
La flexibilidad, por el hecho de no usar discos con firmware propio, resulta mucho mayor que la de las cabinas «de marca» que mantenemos. Y, aunque estas últimas facilitan algunas operaciones, como el cambio de discos, no se justifica de ninguna de las maneras que cuesten a partir de tres veces más.
Con FreeNAS 9.10, estamos pasando (por recomendación suya) a instalar el sistema en un disco SSD, en lugar de un pincho USB o memoria interna SD. Uno pequeño, de 50 o 100 gigas, es ampliamente suficiente. Como no son muy caros, suelo usar los Samsung 850 Evo de 120. Más espacio libre es más espacio sobre el que repartir las escrituras y por tanto más fiabilidad.
A día de hoy, atesoramos varios años de funcionamiento con FreeNAS. Su fiabilidad ha resultado a la misma altura de las Dell, EMC y compañía. Han pasado igual de desapercibidas. Y han costado de la tercera parte para abajo por bit exportado.

Hay webs inmortales. En tiempos muy remotos, el navegador Netscape venía configurado con sendos botones titulados «What’s new» y «What’s cool». Era una época en que se podían hacer estas cosas.

Sin embargo, con todo el tiempo pasado, siguen existiendo algunos sitios que, de seguir existiendo el segundo de los botones, allí seguirían, año tras año.

Hoy, en uno de esos lugares inmortales, pasé uno de esos ratos riéndome solo (y tomado, por tanto, por loco). Y de todo lo que leí, me resulta muy difícil quedarme con algo, pero si algo mola mucho, es esto: http://www.qdb.us/305607

Pues ya escribiré algo, porque solo lo he usado como diez o quince minutos…