Re: Configuración de logs de isc-dhcp-server
El 15/05/14 12:34, Camaleón escribió:
El Thu, 15 May 2014 12:02:04 -0300, Mauro Antivero escribió:
El 15/05/14 11:20, Camaleón escribió:
(...)
Lo que quiero hacer es que los dos mensajes por defecto (los primeros
dos que puse, los que dicen DHCPREQUEST y DHCPACK) no se generen,
puesto que en si la información está repetido con los que yo genero.
Ah, vale, entonces lo que buscas ahora es *no duplicar* los mensajes
predeterminados y los personalizados.
Espero se haya entendido bien ahora y perdón si antes quedó medio
confuso.
Ahora sí, es que no recordaba que hubieras comentado nada sobre
mensajes duplicados :-)
Se te ha olvidado adjuntar el archivo de configuración.
Si, perdón, está lleno de comentarios y líneas viejas que fui probando.
Lo limpio un poco y lo subo.
Bueno, por lo que pude ver hasta ahora no se puede anular los logs que
por defecto envía isc-dhcp-server,
Estaba pensando por qué duplica los registros y claro, debe ser porque
hemos forzado que registre los datos al usar el evento "on commit" y cada
vez que se produce el evento, registro al canto.
Exacto. Según parece registra por defecto los REQUEST y los ACK (y no sé
si algún otro caso más, pero esos dos son los que más se repiten), yo lo
que hice fue volver a registrarlos pero para tener una sintaxis
personalizada.
Es decir, no estamos dando forma a los registros predeterminados sino que
estamos ejecutando la misma acción en paralelo y con el formato que
queremos pero claro, hay duplicidad.
Exacto! El tema es como hacer para que la acción por defecto no se
ejecute (cosa que me parece al fin y al cabo que no se puede, quizás con
una opción de compilación, pero sinceramente no me pienso meter con eso).
Volvamos al inicio... quitando cualquier cláusula "on commit" que tengas
habilitada, en lugar de esto que tenías al principio (y que no te
funcionaba):
#Ack
if option dhcp-message-type = 5 {
log(info, concat("info: dhcp-cpe-ack:", " MAC-CPE: ",
binary-to-ascii(16, 8, ":", hardware), " MAC-CM: ",
binary-to-ascii(16, 8, ":", option agent.remote-id)));
}
Prueba con esto:
if dhcp-message-type = 5 {
log(info, concat("info: dhcp-cpe-ack:", " MAC-CPE: ",
binary-to-ascii(16, 8, ":", hardware), " MAC-CM: ",
binary-to-ascii(16, 8, ":", option agent.remote-id)));
}
Mmm... Perdón, pero no entiendo. Para qué probar esto? Una aclaración:
Todo lo que es el manejo de logs lo tengo en un archivo separado el cual
luego incluyo en dhcpd.conf con una sentencia include. Ya probé no
incluirlo (osea anular todas las configuraciones adicionales de logs) y
si bien los logs personalizados desaparecen (menos mal no?) los logs por
defecto siguen estando, así que no es cosa del archivo de configuración,
o al menos no algo que yo haya escrito.
Lo único que dejé es la configuración de facility local7.
O algo más simple:
log(info, concat("info: dhcp-cpe-ack:", " MAC-CPE: ",
binary-to-ascii(16, 8, ":", hardware)));
A ver qué sucede o si notas algún cambio.
Lo puedo probar por supuesto, pero disculpá, no entiendo para que. Esto
sería para lograr un log personalizado ante un ACK, y esto ya lo he
logrado con on commit. No me mal interpretes por favor, lo pruebo, pero
me aclararías cual es el fin de esta prueba?
lo que si se me ocurrió algo, pero no creo que lo implemente porque a
mi humilde entender me parece inapropiado:
La idea sería configurar syslog para que solamente loguee mensajes del
tipo err por ejemplo y luego utilizar esta prioridad en la sentencia
log, de manera que quede del tipo "log(err, ....)". De esta forma solo
se enviarían los logs personalizados (y los propios que se generen del
tipo err, pero como les decía me parece una "chanchada".
Seguirías duplicando los registros, aunque en menor cantidad.
Es verdad, y además, era una chanchada! :P
Voy a buscar un ratito más, si no encuentro nada lo que hago es
configurar un filtro en rsyslog para que detecte y guarde solo los logs
personalizados. Esto es relativamente sencillo (creo) y lo podría haber
hecho en un principio, pero por prolijidad quería que no se envíen logs
innecesarios para que luego sean descartados (especialmente porque son
muuuuuuuuchos los logs de este tipo).
Okay, ya contarás.
Saludos,
Saludos y muchas gracias, Mauro.
Reply to: