… pues casi que no.
Y no es únicamente por no abrir otro frente más con un script CGI pelado y desantendido, es que el acceso a los registros de los servidores virtuales me plantea problemas que no tenía hasta hace nada.
En la máquina pública de mi empresa tengo varios servidores virtuales con un aplicación Drupal, un catálogo de fotos con Piwigo y varios árboles de documentos e imágenes que servimos al mundo mundial. Hace poco me plantearon la duda de si se estaban viendo o no las páginas y cuántos llegaban allí desde las búsquedas. Como no soy partidario de incluir analíticas de terceros, y tampoco tienen mucha idea de lo que quieren realmente, pensé en utilizar mecanismos pasivos de análisis. A fin de cuentas el servidor web ya está generando un montón de información.
Buscando software en Debian encontré awstats (escrito en Perl) y me pareció que podía dar resultado. Una vez instalado, y antes siquiera de configurarlo, ya me percaté de los problemas que me iba a encontrar en forma de lluvia de mensajes de error. Por lo visto la instalación predeterminada se ejecuta cada media hora y no se le olvida nunca informar a su administrador favorito de todo lo que falta aún por retocar.
Leyendo la documentación del paquete me encontré con otro problema más: el acceso a los registros del servidor web. awstats funciona con el usuario predeterminado para scripts CGI (www-data) y podía elegir entre hacerlo miembro del grupo de administración o hacer que los registros estuviesen directamente a su alcance. La primera opción no me convenció nada. Este usuario está creado precisamente para reducir la gravedad de una intrusión a través del servidor web y la otra … puf, como que tampoco me hacía gracía dar acceso a todo quisque a estos registros; demasiada información con demasiado acceso.
Así que me lo he planteado de otra manera:
- El acceso a las estadísticas va a estar limitado al personal de la empresa, ergo, no es necesario que exista en el servidor de producción.
- El servidor público ya está sobrecargado de trabajo; agradecerá no trabajar más de la cuenta.
- Las estadísticas van a consultarse, como mucho, una vez al día. No es preciso que exista una actualización contínua.
- Traerme los registros del servidor a la intranet elimina todos los inconvenientes de acceso.
- Puedo aprovechar para ordenar el rotado de estos registros e integrar en el proceso el envío de dichos archivos.
Así que me he puesto a ello actuando en dos frentes al mismo tiempo: el servidor de producción y un servidor interno. Para el primero aprovecho que tengo escrito un paquete Debian con ajustes predeterminados para él y en el que voy a situar la configuración de logrotate, indicando que cada vez que se rote se transfieran los archivos al servidor interno. En éste voy a instalar awstats y le dejaré vía libre para que trabaje como más le guste. El acceso vía CGI a las estadísticas se situará en el servidor de administración, con los controles que ya tengo para el personal.
Detalles constructivos
El archivo de rotación de logs que muestro a continuación está situado dentro del directorio debian/ de construcción del paquete. Concretamente como debian/paquete.virtualhosts.logrotate y será instalado bajo /etc/logrotate.d/virtuahosts.
# # Servidores web virtuales # /var/log/virtual/admin.empresa.com/*.log /var/log/virtual/beta.empresa.com/*.log /var/log/virtual/blog.empresa.com/*.log /var/log/virtual/old.empresa.com/*.log /var/log/virtual/static.empresa.com/*.log /var/log/virtual/www.empresa.com/*.log { # Rotación diaria si superan el megabyte y no conservar más de 30 rotate 30 daily size 1M # No comprimir registros nocompress # Notificar al administrador mail admin@empresa.es # Ignorar el archivo si no existe y no hacer nada # si éste está vacío missingok notifempty # Permisos y propiedad del nuevo create 640 root adm # Ejecutar lo siguiente justo al final de procesarlos todos sharedscripts postrotate if [ -x /usr/bin/weblogs2intranet ]; then begin \ weblogs2intranet $* \ fi; \ endscript }
Para verificar la síntaxis del archivo podemos emplear el propio programa de rotación de la siguiente forma:
$ /usr/sbin/logrotate -d debian/paquete.virtualhosts.logrotate
reading config file debian/paquete.virtualhosts.logrotate
Handling 1 logs
rotating pattern: /var/log/virtual/admin.empresa.com/*.log
/var/log/virtual/beta.empresa.com/*.log
/var/log/virtual/blog.empresa.com/*.log
/var/log/virtual/old.empresa.com/*.log
/var/log/virtual/static.empresa.com/*.log
/var/log/virtual/www.empresa.com/*.log
1048576 bytes (30 rotations)
empty log files are not rotated, old logs mailed to admin@empresa.es
not running postrotate script, since no logs were rotated
El script invocado tras el rotado de los registros se limita a utilizar rsync para enviar los cambios al servidor de la intranet. En éste el servicio de sincronización está configurado así:
secrets file = /etc/rsyncd.secrets strict modes = yes hosts allow = xxx.xxx.xxx.xxx
...
[weblogs] path = /srv/backups/weblogs comment = Registros de servidores web read only = no
write only = no
use chroot = yes
transfer logging= yes
uid = www-data gid = www-data auth users = weblogs
La claúsula hosts allow incluye la dirección IP fija del servidor exterior más todas aquellas internas que sean necesarias para el resto de los bloques de configuración. El usuario weblogs, obviamente, se añade al archivo /etc/rsyncd.secrets y el directorio destino debe crearse antes de emplearlo o no funcionará.
Desde el servidor de producción la transmisión de los archivos registro es tan sencilla como invocar al programa rsync (añadido como dependencia al paquete) con los siguientes parámetros:
rsync -a --password-file /etc/empresa/rsync.client \
/var/log/virtual /var/log/apache2 \
weblogs@empresa.net::weblogs
Hay más cosas, pero creo que lo principal está. En otra entrada hablaré de la segunda parte del proceso: el análisis de los registros y la presentación de los resultados.