Como Mola Todo

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.