Para controlar el acceso con mi usuario (victor) a este blog he integrado la herramienta Latch sin prácticamente ningún problema.
Ahora puedo, desde el móvil,. monitorizar y controlar el acceso a este sitio 🙂
Para controlar el acceso con mi usuario (victor) a este blog he integrado la herramienta Latch sin prácticamente ningún problema.
Ahora puedo, desde el móvil,. monitorizar y controlar el acceso a este sitio 🙂
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.
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]
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:
Obviamente ayer no me dio tiempo a completar lo que me proponía, así que esta mañana he tenido trabajo pendiente.
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,…).