Arreglando detallitos: el blog, actualizaciones y estadísticas web

9 septiembre 2014

Hoy, entre otras cosas, me propongo reparar tres aspectos de la administración del sistema que no funcionan: la vista del blog de desarrollo desde la intranet, el usuario especial actualizador con el que pongo al día los sistemas y desatascar el analizador de registros del servidor web de venexma.es (y otros) que se hace un lío con registros antiguos.

Navegación interna por el blog de desarrollo

Tan sencillo como activar las reglas de reescritura de direcciones en el archivo htaccess correspondiente. En mi caso, y creo que es norma en Debian, este archivo se sitúa en /etc/wordpress/.htaccess, como enlace procedente de /usr/share/wordpress/.htaccess.

La estrofa es la siguiente:

[apache]

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

[/apache]

Usuario especial para actualizar máquinas

En todos los sistemas existe un usuario específico para actualizarlas en remoto y en bloque. Se llama actualizador, tiene la misma contraseña en todas las máquinas (es lo más cómodo, no lo más seguro) y accede desde un punto central (sigfrido) a cada una empleando una clave pública.

Hasta ahora no lo he automatizado por pura pereza, pero cada vez que cambio los componentes de una máquina la conexión se pierde y es necesario volver a hacer lo mismo.

Escribo una pequeña lista de cosas que hacer para poner en marcha una máquina como nodo del mecanismo de actualizaciones remotas:

  1. Instalar el paquete apt-dater-host.
  2. Activar configuración de sudo en el archivo /etc/sudoers.d/apt-dater-host.
  3. Crear un usuario llamado actualizador dentro del grupo adm y con la contraseña habitual registrada en https://admin.venexma.net/passwords.
  4. Accedemos al servidor central (sigfrido) con el usuario actualizador y desde allí copiamos la clave pública en la máquina que estamos configurando. Empleamos para ello ssh-copy-id sin darle más indicaciones que el destino.
  5. Testear ésto último entrando vía ssh a la máquina en configuración desde el servidor. Y cuidado porque es posible que ni así se consiga dado que la dirección IP, la identificación de la máquina o combinaciones de ambas hayan cambiado y sea necesario retocar el archivo ~/.ssh/known_hosts del usuario actualizador en sigfrido.

Martes, 9 de Septiembre

Obviamente ayer no me dio tiempo a completar lo que me proponía, así que esta mañana he tenido trabajo pendiente.

Registros de acceso al servidor web no válidos

Todo el mecanismo de creación de estadísticas web (y disponible aquí) tenía un fallo que impedía que funcionase y, de paso, me inundaba el buzón con mensajes de error. Resulta que los registros generados por el servidor web en venexma.es deben estar en un formato concreto. Si no es así awstats no puede realizar su trabajo y aborta todo el proceso.

La solución ha consistido en efectuar un filtrado previo de los registros para aceptar únicamente aquellos que tienen el formato adecuado. Dado que la configuración de awstats es flexible he creado un programa (incluído en el paquete venexma-sigfrido) que se encarga de este trabajo y de llamar a la herramienta correspondiente.

La configuración de cada dominio para las estadísiticas incluye una línea como la que sigue:

[ini]

LogFile=»/usr/bin/weblog2awstats dominio | »

[/ini]

reemplazando dominio por aquél que queremos procesar (static.venexma.com,venexma.com,…).

 

 

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *