Este post surge particularmente por un problema que tuve recientemente en una Lan donde el unico acceso a internet esta reglado por un Firewall GNU/Linux que a su vez  tiene un servidor web Apache2 corriendo algunos aplicativos internos hacia la Lan, donde, por su lado,  muchas estaciones de trabajo de usuarios cuentan con un sistema operativo MS Windows con instalaciones del Antivirus Eset Nod 32.

El problema, según lo que he podido observar,  radica en que algunas estaciones con dicho antivirus, al no poder acceder a internet , debido probablemente a  alguna politica de firewall ,  suelen tratar de (al parecer) obtener sus updates del servidor con apache2. Digo esto debido a la inmensa cantidad de lineas de Logs que se generan en los archivos de logs access.log y error.log, ubicados en las siguientes rutas:

/var/log/apache2/access.log

/var/log/apache2/error.log

Tal es la cantidad de lineas generadas que los archivos han llegado a crecer en un  promedio aproximado de 1 giga por hora en el caso de access.log y un poco menos en error.log, calculo que la varianza en el crecimiento de este archivo dependerá de la cantidad de terminales con dicho antivirus que colapsen con alguna regla firewall que evite su acceso hacia el server contra el que se actualicen.

En access.log la linea que genera el crecimiento desmesurado del archivo es como la siguiente, lo que al parecer es un intento de actualización vía protocolo http.

10.20.30.5 – – [01/Jun/2010:12:06:39 -0300] “GET http://um10.eset.com/eset_upd/update.ver HTTP/1.1” 404 391 “-” “ESS Update (Windows; U; 32bit; VDB 6651; BPC 3.0.621.0; OS: 5.1.2600 SP 3.0 NT; CH 1.1; LNG 1033; x32c; UPD AUTOSELECT; APP eav”
10.20.30.6 – – [01/Jun/2010:12:09:20 -0300] “GET http://um10.eset.com/eset_eval/update.ver HTTP/1.1” 404 392 “-” “ESS Update (Windows; U; 32bit; VDB 7210; BPC 3.
0.621.0; OS: 5.1.2600 SP 3.0 NT; CH 1.1; LNG 1033; x32c; UPD AUTOSELECT; APP eav”
En el error.log observe una reiteracion de esta linea:
[Thu Jun 01 13:06:39 2010] [error] [client 10.20.30.5] File does not exist: /var/www/eset_upd
Lo cual parece una respuesta correcta por parte de Apache2 al no encontrar la ruta que solicita Eset en el servidor.
Si bien en algún momento pensé en que una de las soluciones posibles seria reducir el lapso de rotado de los archivos de logs, esto, de acuerdo al grado de crecimiento observado tanto en access.log como en error.log, implicaría un rotado por hora para evitar el crecimiento alocado en el tamaño de los archivos a fin de evitar que llenen la partición /var  y también para agilizar su lectura.
Escogiendo que loguear en Apache 2
Para este caso preferi husmear un poco mas en la documentación de Apache2 y me di con el parámetro de configuración SetEnvIf, que me permite definir variables de ambiente basadas en patrones de matching en una solicitud web, dicho patrón puede estar dado por una expresión regular que identifique una porcion de una URL, un tipo de petición o vía algún  otro campo de busqueda,  para luego asignárselo a una variable. Durante la definición del archivo de access.log  se debe referenciar dicha variable con un negador para que dichos patrones sean excluidos del proceso de logging de acceso.
Tal es asi que en mi caso modifique /etc/apache2/sites-enabled/sistema-interno, que es el archivo base de definicion de los sistemas web internos. y añadi entre los tags de virtualhost, las siguientes lineas:
SetEnvIf Request_URI “eset_upd” nologuear
SetEnvIf Request_URI “eset_eval” nologuear
Estas lineas estan antes de las definiciones de los archivos de logs de acceso y de errores, que normalmente vienen por defecto con los siguientes valores:
CustomLog /var/log/apache2/access.log combined
ErrorLog /var/log/apache2/error.log
En las definiciones de SetEnvIf se analizan las URL(URI) que contengan las cadenas “eset_upd” y “eset_eval” y se asignan a la variable nologuear.
Luego. modificamos la definicion del archivo de logs de accesos, el cual normalmente es una linea similar a esta:
CustomLog /var/log/apache2/access.log combined
y la dejamos como la siguiente:
CustomLog /var/log/apache2/access.log combined  env=!nologuear
Esta es la linea magica que nos permite excluir de nuestro archivo de logs de accesos cualquier patron concordante con las cadenas que especificamos mediante SetEnvIf  en la variable nologuear.
Ahora si estas pensando que con esto se termino todo, aun me faltaba evitar que siguiese creciendo el archivo error.log.
Aunque con los parametros anteriores evitamos que el logging de acceso de Eset quede registrado, eso no implica que apache2 deje de  registar en el archivo error.log los mensajes de la ruta no encontrada.
Para esto me simplifique un poco la vida y modifique la el nivel de debug del ErrorLog , con el parametro LogLevel.
Modifique el parámetro LogLevel que venia por default al parecer cambiándolo del siguiente valor:
LogLevel warn
a la siguiente linea
LogLevel crit
No creo que sea la solucion mas adecuada, pero si fue la que funciono:). Créanme cuando digo que pense que me iba a dar con la misma versatilidad del parámetro CustomLog respecto a la definición de  parámetros a excluir del Log, pero no fue posible, no lo encontré en la documentación de Apache2.
Finalmente para que los cambios efectuados surgan efecto debemos reiniciar el servicios Apache2:
En Debian o derivados:
# /etc/init.d/apache2 restart