Cómo monté mi servidor - El entorno para chroot

Dentro del directorio /f tenía que crear una estructura de directorios y archivos propia de un sistema UNIX para que se ejecutara el servidor web y los programa CGIs. El chroot lo que hace es convertir en raíz (/) el directorio especificado, por lo que si, dentro de la jaula, el usuario root te hace un rm -rf /, sólo te habrá borrado el directorio de chroot.

Lo primero que pensé es que ya habría mini-distribuciones de Linux preparadas para esto que contengan los programas necesarios: bash, ls, gcc, perl, ... Seguro que hay, pero no busqué mucho y decidí hacerlo a mano. Descubrí que es muy fácil si se usan las herramientas apropiadas. Esta captura de pantalla deja claro el proceso ('captura' en modo texto aquí):

Y así con cada programa, tienes que copiar las librerías que necesita (ya sabes, man ldd si no sabes qué hace).

Opciones de thttpd

Lo bueno de elegir un servidor sencillo es que pude revisar todo el código fuente y leerme y entender por completo el manual de uso. Sabiendo manejar el programa entero, no tuve ningún problema.

thttpd no necesita archivo de configuración; todas las opciones se pasan como parámetros. Por eso me hice un script que hacía lo siguiente:

Explicación:

• -p 80: es el 'por defecto', pero sólo para asegurarme. Mi intención era que thttpd no se ejecutara como root sinó como un usuario normal, y por tanto pensaba usar un puerto no privilegiado (ej. 8000) y hacer NAT desde el router, pero como para el chroot hace falta ser root (luego baja de privilegios), acabéusando el 80.
• -d /f: directorio al que entra al ejecutar el programa
• -r: hacer chroot en el directorio del programa (o sea, el /f de la opción anterior)
• -u webo: usuario al que cambiar después de hacer las cosas que requieren ser root. Es importante no ser root dentro del chroot, porque entonces es 'fácil' salir mandando unas señales.
• -dd web: directorio al que entra después de haber hecho el chroot. O sea, que las webs están en /f/web
• -c "blablabla": archivos que deben ejecutarse en vez de mostrarse, o sea CGIs. Además han de ser ejecutables (+x). Tengo que poner cada nombre de host (aunque la web sea la misma) por la diferencia que se hace con lo del virtual hosting: quizás alguien quiera que desde miweb.com vayan los CGIs pero desde www.miweb.com no. Nota que el * lo traduce el bash a los nombres de archivo que hay en ese momento en cada directorio, por lo que si luego añades nuevos CGIs hay que reiniciar el servidor dándole la nueva lista.
  
• -l /f/log/este_mes: dónde añadir los logs (lo explico luego)
• -v: hacer virtual hosting. En /f/web no habrá una web con su index.html, sinó directorios, cada uno llamado con un nombre de host (ej. www.miweb.com) y con su index.html y familia dentro.

El proceso se arranca como demonio; para hacer pruebas va bien el -D que lo deja en primer plano.

Logs

Me hice este script que rota y archiva los logs, muy sencillo. Está en /etc/cron.monthly

#!/bin/sh
# Rotar logs. EJECUTAR EL PRIMER DÍA DE CADA MES

Si no sabías lo que era rotar logs, pues ya lo sabes (es descartar el más viejo para que quepa uno nuevo; sólo tengo 12 posiciones). La última línea reinicia el servidor web o, en caso de que no esté activo, lo inicia.

También podía haber usado herramientas automáticas que lo hacen, como logrotate. Pero mi script es más sencillo porque tiene sólo lo que yo quiero.

Un watchdog para el servidor web

Puede que, por alguna razón rara, el proceso thttpd muera y me quede sin servidor. Por eso me hice un 'watchdog', o 'perro guardián', que comprueba periódicamente si está activo y si no lo está lo inicia. Al principio se ejecutaba cada día porque no encontré un /etc/cron.hourly (lo mímino era daily)... pura vagancia. Luego le añadí 05 *    * * *   root    /root/wdogweb al /etc/crontab para ejecutarlo cada hora a los 05 minutos.

El script es realmente sencillo y muy bonito:

Me han comentado que hay utilidades como daemontools que se encargan de arrancar y vigilar servicios, pero ahora que ya he aprendido a usar cron creo que no me hace falta otro programa para hacer lo mismo. No digo que no sea útil; al contrario, va muy bien por si tienes muchos servidores.