Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Configuración de logs de isc-dhcp-server
172 views
Skip to first unread message
Mauro Antivero
May 14, 2014, 11:20:02 AM5/14/14
to
Estimados, estoy tratando de configurar los logs del servidor DHCP que
por defecto trae Debian (isc-dhcp-server). Hasta ahora he logrado
discriminar los logs para los mensajes de discover y request, pero no he
logrado discrimar el resto, fundamentalmente los acks. Les copio un
fragmento muy breve del archivo de configuraci�n (dhcpd.conf) como para
que vean:
#Offer
if option dhcp-message-type = 1
{
log(info, concat("info: dhcp-cpe-discover:", " MAC-CPE: ",
binary-to-ascii(16, 8, ":", hardware), " MAC-CM: ", binary-to-ascii(16,
8, ":", option agent.remote-id)));
}
#Request
if option dhcp-message-type = 3
{
log(info, concat("info: dhcp-cpe-request:", " MAC-CPE: ",
binary-to-ascii(16, 8, ":", hardware), " MAC-CM: ", binary-to-ascii(16,
8, ":", option agent.remote-id)));
}
#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)));
}
El archivo es mucho m�s largo y tiene muchas m�s condiciones, pero esa
es la idea b�sica. La cuesti�n es que para los ack no veo el mensaje del
tipo "info_ dhcp-cpe-ack", como si el mensaje no existiese, pero si veo
los mensajes que por defecto genera el servidor (DHCPACK on
aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (Lalala) via eee.fff.ggg.hhh).
Alguna idea de que puedo estar pasando por alto u obviando?
Saludos y muchas gracias, Mauro.
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/53738938...@gmail.com
por defecto trae Debian (isc-dhcp-server). Hasta ahora he logrado
discriminar los logs para los mensajes de discover y request, pero no he
logrado discrimar el resto, fundamentalmente los acks. Les copio un
fragmento muy breve del archivo de configuraci�n (dhcpd.conf) como para
que vean:
#Offer
if option dhcp-message-type = 1
{
log(info, concat("info: dhcp-cpe-discover:", " MAC-CPE: ",
binary-to-ascii(16, 8, ":", hardware), " MAC-CM: ", binary-to-ascii(16,
8, ":", option agent.remote-id)));
}
#Request
if option dhcp-message-type = 3
{
log(info, concat("info: dhcp-cpe-request:", " MAC-CPE: ",
binary-to-ascii(16, 8, ":", hardware), " MAC-CM: ", binary-to-ascii(16,
8, ":", option agent.remote-id)));
}
#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)));
}
El archivo es mucho m�s largo y tiene muchas m�s condiciones, pero esa
es la idea b�sica. La cuesti�n es que para los ack no veo el mensaje del
tipo "info_ dhcp-cpe-ack", como si el mensaje no existiese, pero si veo
los mensajes que por defecto genera el servidor (DHCPACK on
aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (Lalala) via eee.fff.ggg.hhh).
Alguna idea de que puedo estar pasando por alto u obviando?
Saludos y muchas gracias, Mauro.
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/53738938...@gmail.com
Camaleón
May 14, 2014, 11:50:02 AM5/14/14
to
El Wed, 14 May 2014 12:18:16 -0300, Mauro Antivero escribió:
> Estimados, estoy tratando de configurar los logs del servidor DHCP que
> por defecto trae Debian (isc-dhcp-server). Hasta ahora he logrado
> discriminar los logs para los mensajes de discover y request, pero no he
> logrado discrimar el resto, fundamentalmente los acks. Les copio un
> fragmento muy breve del archivo de configuración (dhcpd.conf) como para
> Estimados, estoy tratando de configurar los logs del servidor DHCP que
> por defecto trae Debian (isc-dhcp-server). Hasta ahora he logrado
> discriminar los logs para los mensajes de discover y request, pero no he
> logrado discrimar el resto, fundamentalmente los acks. Les copio un
> que vean:
(...)
> #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)));
> }
>
> es la idea básica. La cuestión es que para los ack no veo el mensaje del
> tipo "info_ dhcp-cpe-ack", como si el mensaje no existiese, pero si veo
> los mensajes que por defecto genera el servidor (DHCPACK on
> aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (Lalala) via eee.fff.ggg.hhh).
>
> Alguna idea de que puedo estar pasando por alto u obviando?
Ni idea... pero Google me ha devuelto este hilo, a ver si te da alguna
> los mensajes que por defecto genera el servidor (DHCPACK on
> aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (Lalala) via eee.fff.ggg.hhh).
>
> Alguna idea de que puedo estar pasando por alto u obviando?
pista:
Does "option dhcp-message-type" work?
https://lists.isc.org/pipermail/dhcp-users/2008-July/006818.html
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 14, 2014, 12:20:03 PM5/14/14
to
El 14/05/14 12:48, Camaleón escribió:
entiendo la respuesta, a pesar de que luego quien pregunta dice que lo
ayudó mucho :S
En la respuesta le dicen lo siguiente:
"some folks have been known to use the 'on commit' config feature"
Según pude buscar sirve para ejecutar un script en un determinado
momento (cuando se asigna una IP por ejemplo). No me doy bien una idea
de como esto me puede servir, pero más me gustaría saber porque no sirve
el if tradicional con ese mensaje (ack) y si con otros (discover y offer
por ejemplo).
Sigo buscando. Igual si a alguien se le ocurre algo bienvenido sea.
Saludos, Mauro.
>
> Saludos,
> El Wed, 14 May 2014 12:18:16 -0300, Mauro Antivero escribió:
>
>> Estimados, estoy tratando de configurar los logs del servidor DHCP que
>> por defecto trae Debian (isc-dhcp-server). Hasta ahora he logrado
>> discriminar los logs para los mensajes de discover y request, pero no he
>> logrado discrimar el resto, fundamentalmente los acks. Les copio un
>> fragmento muy breve del archivo de configuración (dhcpd.conf) como para
>> que vean:
> (...)
>
>> #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)));
>> }
>>
>> El archivo es mucho más largo y tiene muchas más condiciones, pero esa
>> es la idea básica. La cuestión es que para los ack no veo el mensaje del
>> tipo "info_ dhcp-cpe-ack", como si el mensaje no existiese, pero si veo
>> los mensajes que por defecto genera el servidor (DHCPACK on
>> aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (Lalala) via eee.fff.ggg.hhh).
>>
>> Alguna idea de que puedo estar pasando por alto u obviando?
> Ni idea... pero Google me ha devuelto este hilo, a ver si te da alguna
> pista:
>
> Does "option dhcp-message-type" work?
> https://lists.isc.org/pipermail/dhcp-users/2008-July/006818.html
Si, lo vi antes de preguntar en esta lista, pero sinceramente no
>
>> Estimados, estoy tratando de configurar los logs del servidor DHCP que
>> por defecto trae Debian (isc-dhcp-server). Hasta ahora he logrado
>> discriminar los logs para los mensajes de discover y request, pero no he
>> logrado discrimar el resto, fundamentalmente los acks. Les copio un
>> fragmento muy breve del archivo de configuración (dhcpd.conf) como para
>> que vean:
> (...)
>
>> #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)));
>> }
>>
>> El archivo es mucho más largo y tiene muchas más condiciones, pero esa
>> es la idea básica. La cuestión es que para los ack no veo el mensaje del
>> tipo "info_ dhcp-cpe-ack", como si el mensaje no existiese, pero si veo
>> los mensajes que por defecto genera el servidor (DHCPACK on
>> aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (Lalala) via eee.fff.ggg.hhh).
>>
>> Alguna idea de que puedo estar pasando por alto u obviando?
> Ni idea... pero Google me ha devuelto este hilo, a ver si te da alguna
> pista:
>
> Does "option dhcp-message-type" work?
> https://lists.isc.org/pipermail/dhcp-users/2008-July/006818.html
entiendo la respuesta, a pesar de que luego quien pregunta dice que lo
ayudó mucho :S
En la respuesta le dicen lo siguiente:
"some folks have been known to use the 'on commit' config feature"
Según pude buscar sirve para ejecutar un script en un determinado
momento (cuando se asigna una IP por ejemplo). No me doy bien una idea
de como esto me puede servir, pero más me gustaría saber porque no sirve
el if tradicional con ese mensaje (ack) y si con otros (discover y offer
por ejemplo).
Sigo buscando. Igual si a alguien se le ocurre algo bienvenido sea.
Saludos, Mauro.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/537395C7...@gmail.com
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 14, 2014, 12:30:02 PM5/14/14
to
El Wed, 14 May 2014 13:11:51 -0300, Mauro Antivero escribió:
> El 14/05/14 12:48, Camaleón escribió:
(...)
> El 14/05/14 12:48, Camaleón escribió:
>>> Alguna idea de que puedo estar pasando por alto u obviando?
>> Ni idea... pero Google me ha devuelto este hilo, a ver si te da alguna
>> pista:
>>
>> Does "option dhcp-message-type" work?
>> https://lists.isc.org/pipermail/dhcp-users/2008-July/006818.html
> Si, lo vi antes de preguntar en esta lista, pero sinceramente no
> entiendo la respuesta, a pesar de que luego quien pregunta dice que lo
> ayudó mucho :S
>
> En la respuesta le dicen lo siguiente:
>
> "some folks have been known to use the 'on commit' config feature"
>
> Según pude buscar sirve para ejecutar un script en un determinado
> momento (cuando se asigna una IP por ejemplo). No me doy bien una idea
> de como esto me puede servir, pero más me gustaría saber porque no sirve
> el if tradicional con ese mensaje (ack) y si con otros (discover y offer
> por ejemplo).
>
> Sigo buscando. Igual si a alguien se le ocurre algo bienvenido sea.
opción "on commit { log(blah, blah, blah) }" en lugar de "if dhcp-message-
type = 5 { log(blah, blah, blah) }" ¿no? :-?
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 14, 2014, 1:20:03 PM5/14/14
to
El 14/05/14 13:22, Camaleón escribió:
estoy logueando (uno define que quiere escribir como línea de log, pero
no sé que es lo que hace que lo que está dentro de "on commit" se
ejecute, en cambio con el if... se entiende claro).
Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
encuentro que es lo que hace exactamente "on commit". Alguna idea?
Saludos y muchas gracias.
Mauro.
>
> Saludos,
> El Wed, 14 May 2014 13:11:51 -0300, Mauro Antivero escribió:
>
>> El 14/05/14 12:48, Camaleón escribió:
> (...)
>
>>>> Alguna idea de que puedo estar pasando por alto u obviando?
>>> Ni idea... pero Google me ha devuelto este hilo, a ver si te da alguna
>>> pista:
>>>
>>> Does "option dhcp-message-type" work?
>>> https://lists.isc.org/pipermail/dhcp-users/2008-July/006818.html
>> Si, lo vi antes de preguntar en esta lista, pero sinceramente no
>> entiendo la respuesta, a pesar de que luego quien pregunta dice que lo
>> ayudó mucho :S
>>
>> En la respuesta le dicen lo siguiente:
>>
>> "some folks have been known to use the 'on commit' config feature"
>>
>> Según pude buscar sirve para ejecutar un script en un determinado
>> momento (cuando se asigna una IP por ejemplo). No me doy bien una idea
>> de como esto me puede servir, pero más me gustaría saber porque no sirve
>> el if tradicional con ese mensaje (ack) y si con otros (discover y offer
>> por ejemplo).
>>
>> Sigo buscando. Igual si a alguien se le ocurre algo bienvenido sea.
> Mmmmm... Pues tal y como lo entiendo lo que le quiere decir es que use la
> opción "on commit { log(blah, blah, blah) }" en lugar de "if dhcp-message-
> type = 5 { log(blah, blah, blah) }" ¿no? :-?
Mmm... Probé y algo hace, osea, la sintaxis es válida, pero ni idea que
>
>> El 14/05/14 12:48, Camaleón escribió:
> (...)
>
>>>> Alguna idea de que puedo estar pasando por alto u obviando?
>>> Ni idea... pero Google me ha devuelto este hilo, a ver si te da alguna
>>> pista:
>>>
>>> Does "option dhcp-message-type" work?
>>> https://lists.isc.org/pipermail/dhcp-users/2008-July/006818.html
>> Si, lo vi antes de preguntar en esta lista, pero sinceramente no
>> entiendo la respuesta, a pesar de que luego quien pregunta dice que lo
>> ayudó mucho :S
>>
>> En la respuesta le dicen lo siguiente:
>>
>> "some folks have been known to use the 'on commit' config feature"
>>
>> Según pude buscar sirve para ejecutar un script en un determinado
>> momento (cuando se asigna una IP por ejemplo). No me doy bien una idea
>> de como esto me puede servir, pero más me gustaría saber porque no sirve
>> el if tradicional con ese mensaje (ack) y si con otros (discover y offer
>> por ejemplo).
>>
>> Sigo buscando. Igual si a alguien se le ocurre algo bienvenido sea.
> Mmmmm... Pues tal y como lo entiendo lo que le quiere decir es que use la
> opción "on commit { log(blah, blah, blah) }" en lugar de "if dhcp-message-
> type = 5 { log(blah, blah, blah) }" ¿no? :-?
estoy logueando (uno define que quiere escribir como línea de log, pero
no sé que es lo que hace que lo que está dentro de "on commit" se
ejecute, en cambio con el if... se entiende claro).
Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
encuentro que es lo que hace exactamente "on commit". Alguna idea?
Saludos y muchas gracias.
Mauro.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5373A55C...@gmail.com
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 14, 2014, 1:50:02 PM5/14/14
to
El Wed, 14 May 2014 14:18:20 -0300, Mauro Antivero escribió:
> El 14/05/14 13:22, Camaleón escribió:
(...)
>>> Sigo buscando. Igual si a alguien se le ocurre algo bienvenido sea.
>> Mmmmm... Pues tal y como lo entiendo lo que le quiere decir es que use
>> la opción "on commit { log(blah, blah, blah) }" en lugar de "if
>> dhcp-message-
>> type = 5 { log(blah, blah, blah) }" ¿no? :-?
> Mmm... Probé y algo hace, osea, la sintaxis es válida, pero ni idea que
> estoy logueando (uno define que quiere escribir como línea de log, pero
> no sé que es lo que hace que lo que está dentro de "on commit" se
> ejecute, en cambio con el if... se entiende claro).
Releyendo el mensaje de la lista de dhcpd, estaba pensando que en tu caso
quizá te bastaría con comentar la instancia que genera el registro "ack",
es decir:
#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)));
# }
Se supone que el contenido de ese bloque se ejecuta cuando se produce un
evento de tipo ACK el cual se registra en el log con la información/datos
que especifica ahí (MAC-CPE, MAC-CM...). Se trataría de decirle que no
registre nada, así en plan brutico O:-)
> Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
> encuentro que es lo que hace exactamente "on commit". Alguna idea?
Sin mirar el manual, se supone que los bloques "on" contienen
instrucciones a ejecutar cuando se produce un evento (commit, release,
expire). "Commit" debe referirse al momento en que se otorga una
dirección IP.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05...@gmail.com
> El 14/05/14 13:22, Camaleón escribió:
(...)
>>> Sigo buscando. Igual si a alguien se le ocurre algo bienvenido sea.
>> Mmmmm... Pues tal y como lo entiendo lo que le quiere decir es que use
>> la opción "on commit { log(blah, blah, blah) }" en lugar de "if
>> dhcp-message-
>> type = 5 { log(blah, blah, blah) }" ¿no? :-?
> Mmm... Probé y algo hace, osea, la sintaxis es válida, pero ni idea que
> estoy logueando (uno define que quiere escribir como línea de log, pero
> no sé que es lo que hace que lo que está dentro de "on commit" se
> ejecute, en cambio con el if... se entiende claro).
quizá te bastaría con comentar la instancia que genera el registro "ack",
es decir:
#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)));
# }
Se supone que el contenido de ese bloque se ejecuta cuando se produce un
evento de tipo ACK el cual se registra en el log con la información/datos
que especifica ahí (MAC-CPE, MAC-CM...). Se trataría de decirle que no
registre nada, así en plan brutico O:-)
> Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
> encuentro que es lo que hace exactamente "on commit". Alguna idea?
instrucciones a ejecutar cuando se produce un evento (commit, release,
expire). "Commit" debe referirse al momento en que se otorga una
dirección IP.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 14, 2014, 2:20:02 PM5/14/14
to
El 14/05/14 14:43, Camaleón escribió:
Excelente, te entiendo. Ahora voy a probar, pero dónde puedo conseguir
documentación sobre tales eventos?
Saludos y muchas gracias.
Mauro.
documentación sobre tales eventos?
Saludos y muchas gracias.
Mauro.
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5373B1C8...@gmail.com
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Cristian Mitchell
May 14, 2014, 6:30:02 PM5/14/14
to
fijate en
/etc/default/isc-dhcp-server
Use this to send dhcp log messages to a different log file (you also
have to hack syslog.conf to complete the redirection).
log-facility local7;
have to hack syslog.conf to complete the redirection).
log-facility local7;
y luego en rsyslog
ahi definis el archivo que deseas
y aca tens mas info
--
MrIX
Linux user number 412793.
http://counter.li.org/
las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,
MrIX
Linux user number 412793.
http://counter.li.org/
las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,
Mauro Antivero
May 15, 2014, 9:00:02 AM5/15/14
to
El 14/05/14 14:43, Camaleón escribió:
y posteriormente loguear de forma personalizada los ACKs!
La pregunta que me queda ahora (no cambio el asunto porque sigue
tratando sonbre la configuración de los logs) es, cómo hago para anular
los mensajes de log que son generados por defecto? Los mismos son de
este tipo:
DHCPREQUEST for aaa.bbb.ccc.ddd from AA:BB:CC:DD:EE:FF via ddd.eee.fff.ggg
DHCPACK on aaa.bbb.ccc.ddd to 00:02:6f:80:09:07 via ddd.eee.fff.ggg
Este tipo de mensajes me gustaría anularlos y que solo queden los logs
personalizados.
Saludos y muchas gracias por la ayuda!
Mauro.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5374B826...@gmail.com
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 15, 2014, 9:10:02 AM5/15/14
to
El Wed, 14 May 2014 15:11:20 -0300, Mauro Antivero escribió:
> El 14/05/14 14:43, Camaleón escribió:
(...)
>>> Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
>>> encuentro que es lo que hace exactamente "on commit". Alguna idea?
>> Sin mirar el manual, se supone que los bloques "on" contienen
>> instrucciones a ejecutar cuando se produce un evento (commit, release,
>> expire). "Commit" debe referirse al momento en que se otorga una
>> dirección IP.
>>
>>
Veamos... en "man 5 dhcpd.conf" tienes un puntero a los eventos (sección
"reference: events) pero como suele pasar en estos casos, las páginas del
manual son exiguas y limitadas, sin ejemplos de uso, posibilidades ni
nada por el estilo por lo que tendrás que tirar de Google (puedes buscar
por "dhcpd.conf events") para obtener más información sobre el uso de los
eventos.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05...@gmail.com
> El 14/05/14 14:43, Camaleón escribió:
(...)
>>> Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
>>> encuentro que es lo que hace exactamente "on commit". Alguna idea?
>> Sin mirar el manual, se supone que los bloques "on" contienen
>> instrucciones a ejecutar cuando se produce un evento (commit, release,
>> expire). "Commit" debe referirse al momento en que se otorga una
>> dirección IP.
>>
>>
> Excelente, te entiendo. Ahora voy a probar, pero dónde puedo conseguir
> documentación sobre tales eventos?
Ahora que tengo un poco más de tiempo te lo puedo buscar.
> documentación sobre tales eventos?
Veamos... en "man 5 dhcpd.conf" tienes un puntero a los eventos (sección
"reference: events) pero como suele pasar en estos casos, las páginas del
manual son exiguas y limitadas, sin ejemplos de uso, posibilidades ni
nada por el estilo por lo que tendrás que tirar de Google (puedes buscar
por "dhcpd.conf events") para obtener más información sobre el uso de los
eventos.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 15, 2014, 9:40:03 AM5/15/14
to
El 15/05/14 10:08, Camaleón escribió:
necesito. Ahí me explica de los 3 tipos de eventos posibles, y que
cuando cada uno de ellos se de uno puede hacer distintas cosas. El tema
es que el servidor, por defecto, sin configurar nada de los logs, genera
logs como los que describí antes.
Estuve viendo los archivos de configuración de mi servidor y en ningún
lado tiene una sentencia "on commit" como para que se genere el log que
yo les describí. Así que sigo sin saber porque o como es que se generan
esas líneas de logs. Me gustaría anularlaras para tener todo definido en
un formato como el que necesito, usando una configuración personalizada
de logs.
Estoy googleando hace un rato y no encuentro nada aún que haga
referencia a los logs por defecto. Seguiré buscando.
Saludos y muchas gracias!
Mauro.
>
> Saludos,
> El Wed, 14 May 2014 15:11:20 -0300, Mauro Antivero escribió:
>
>> El 14/05/14 14:43, Camaleón escribió:
> (...)
>
>>>> Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
>>>> encuentro que es lo que hace exactamente "on commit". Alguna idea?
>>> Sin mirar el manual, se supone que los bloques "on" contienen
>>> instrucciones a ejecutar cuando se produce un evento (commit, release,
>>> expire). "Commit" debe referirse al momento en que se otorga una
>>> dirección IP.
>>>
>>>
>> Excelente, te entiendo. Ahora voy a probar, pero dónde puedo conseguir
>> documentación sobre tales eventos?
> Ahora que tengo un poco más de tiempo te lo puedo buscar.
>
> Veamos... en "man 5 dhcpd.conf" tienes un puntero a los eventos (sección
> "reference: events) pero como suele pasar en estos casos, las páginas del
> manual son exiguas y limitadas, sin ejemplos de uso, posibilidades ni
> nada por el estilo por lo que tendrás que tirar de Google (puedes buscar
> por "dhcpd.conf events") para obtener más información sobre el uso de los
> eventos.
Mmmm... Muchas gracias, pero lo estuve viendo y no he encontrado lo que
>
>> El 14/05/14 14:43, Camaleón escribió:
> (...)
>
>>>> Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
>>>> encuentro que es lo que hace exactamente "on commit". Alguna idea?
>>> Sin mirar el manual, se supone que los bloques "on" contienen
>>> instrucciones a ejecutar cuando se produce un evento (commit, release,
>>> expire). "Commit" debe referirse al momento en que se otorga una
>>> dirección IP.
>>>
>>>
>> Excelente, te entiendo. Ahora voy a probar, pero dónde puedo conseguir
>> documentación sobre tales eventos?
> Ahora que tengo un poco más de tiempo te lo puedo buscar.
>
> Veamos... en "man 5 dhcpd.conf" tienes un puntero a los eventos (sección
> "reference: events) pero como suele pasar en estos casos, las páginas del
> manual son exiguas y limitadas, sin ejemplos de uso, posibilidades ni
> nada por el estilo por lo que tendrás que tirar de Google (puedes buscar
> por "dhcpd.conf events") para obtener más información sobre el uso de los
> eventos.
necesito. Ahí me explica de los 3 tipos de eventos posibles, y que
cuando cada uno de ellos se de uno puede hacer distintas cosas. El tema
es que el servidor, por defecto, sin configurar nada de los logs, genera
logs como los que describí antes.
Estuve viendo los archivos de configuración de mi servidor y en ningún
lado tiene una sentencia "on commit" como para que se genere el log que
yo les describí. Así que sigo sin saber porque o como es que se generan
esas líneas de logs. Me gustaría anularlaras para tener todo definido en
un formato como el que necesito, usando una configuración personalizada
de logs.
Estoy googleando hace un rato y no encuentro nada aún que haga
referencia a los logs por defecto. Seguiré buscando.
Saludos y muchas gracias!
Mauro.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5374C2C...@gmail.com
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 15, 2014, 10:00:02 AM5/15/14
to
El Thu, 15 May 2014 10:36:13 -0300, Mauro Antivero escribió:
> El 15/05/14 10:08, Camaleón escribió:
(...)
> El 15/05/14 10:08, Camaleón escribió:
>> Veamos... en "man 5 dhcpd.conf" tienes un puntero a los eventos
>> (sección "reference: events) pero como suele pasar en estos casos, las
>> páginas del manual son exiguas y limitadas, sin ejemplos de uso,
>> posibilidades ni nada por el estilo por lo que tendrás que tirar de
>> Google (puedes buscar por "dhcpd.conf events") para obtener más
>> información sobre el uso de los eventos.
> Mmmm... Muchas gracias, pero lo estuve viendo y no he encontrado lo que
> necesito. Ahí me explica de los 3 tipos de eventos posibles, y que
> cuando cada uno de ellos se de uno puede hacer distintas cosas. El tema
> es que el servidor, por defecto, sin configurar nada de los logs, genera
> logs como los que describí antes.
cláusulas "if" para que registren esos 3 tipos de eventos, vamos, se lo
estás diciendo tú ¿no?
> Estuve viendo los archivos de configuración de mi servidor y en ningún
> lado tiene una sentencia "on commit" como para que se genere el log que
> yo les describí. Así que sigo sin saber porque o como es que se generan
> esas líneas de logs. Me gustaría anularlaras para tener todo definido en
> un formato como el que necesito, usando una configuración personalizada
> de logs.
Pues ahora mismo ya no sé qué es lo quieres hacer :-), mejor pon un
ejemplo práctico del tipo "el registro de dhcpd pone esto "(a b c d)" y
yo quiero esto "(mi cadena: a b c d)"
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 15, 2014, 10:00:02 AM5/15/14
to
El Thu, 15 May 2014 09:50:46 -0300, Mauro Antivero escribió:
> El 14/05/14 14:43, Camaleón escribió:
(...)
> El 14/05/14 14:43, Camaleón escribió:
(...)
>> Se supone que el contenido de ese bloque se ejecuta cuando se produce
>> un evento de tipo ACK el cual se registra en el log con la
>> información/datos que especifica ahí (MAC-CPE, MAC-CM...). Se trataría
>> de decirle que no registre nada, así en plan brutico O:-)
>>
>>> Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
>>> encuentro que es lo que hace exactamente "on commit". Alguna idea?
>> Sin mirar el manual, se supone que los bloques "on" contienen
>> instrucciones a ejecutar cuando se produce un evento (commit, release,
>> expire). "Commit" debe referirse al momento en que se otorga una
>> dirección IP.
> Bien, confirmo que con "on commit" funciona perfectamente para detectar
> y posteriormente loguear de forma personalizada los ACKs!
Antes de nada, ¿probaste comentando el bloque completo del "if"?
>> un evento de tipo ACK el cual se registra en el log con la
>> información/datos que especifica ahí (MAC-CPE, MAC-CM...). Se trataría
>> de decirle que no registre nada, así en plan brutico O:-)
>>
>>> Me estuve fijando en la man page de dhcp-eval y de dhcpd.conf y no
>>> encuentro que es lo que hace exactamente "on commit". Alguna idea?
>> Sin mirar el manual, se supone que los bloques "on" contienen
>> instrucciones a ejecutar cuando se produce un evento (commit, release,
>> expire). "Commit" debe referirse al momento en que se otorga una
>> dirección IP.
> Bien, confirmo que con "on commit" funciona perfectamente para detectar
> y posteriormente loguear de forma personalizada los ACKs!
> La pregunta que me queda ahora (no cambio el asunto porque sigue
> tratando sonbre la configuración de los logs) es, cómo hago para anular
> los mensajes de log que son generados por defecto? Los mismos son de
> este tipo:
>
> DHCPREQUEST for aaa.bbb.ccc.ddd from AA:BB:CC:DD:EE:FF via
> ddd.eee.fff.ggg DHCPACK on aaa.bbb.ccc.ddd to 00:02:6f:80:09:07 via
> ddd.eee.fff.ggg
>
> Este tipo de mensajes me gustaría anularlos y que solo queden los logs
> personalizados.
tienes documentación sobre la cláusula de los registros.
Prueba seleccionando un nivel de registro que se amenos verboso (en lugar
de "info" prueba con "error" o "fatal") y en cuanto al contenido de los
registros y los parámetros disponibles, no he encontrado documentación
pero los valores son casi auto explicativos ya que lo puedes deducir con
el mensaje que recibes y que pones más arriba ("dhcp-cpe-ack" es el tipo
de mensaje "dhcpack", "MAC-CPE" es la dirección IP del cliente y "MAC-CM"
debe ser su mac y "agent.remote-id" la interfaz de red).
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 15, 2014, 10:10:01 AM5/15/14
to
El 15/05/14 10:58, Camaleón escribió:
Pero es que lo había puesto, solo que a lo mejor entre tanto correo
quedó confuso :S Va de nuevo la aclaración:
Con la configuración por defecto, el servidor DHCP me genera este tipo
de logs:
DHCPREQUEST for aaa.bbb.ccc.ddd from AA:BB:CC:DD:EE:FF (WR720N) via
eee.fff.ggg.hhh
DHCPACK on aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (WR720N) via eee.fff.ggg.hhh
Y con la configuración que yo implementé (con los distintos if y la
sentencia on commit") me genera esto (entre otras cosas):
info: dhcp-cpe-request: IP-CPE: aaa.bbb.ccc.ddd MAC-CPE:
AA:BB:CC:DD:EE:FF MAC-CM: EE:FF:CC:DD:EE:FF
DHCPACK-CPE: IP-CPE: aaa.bbb.ccc.ddd MAC-CPE: AA:BB:CC:DD:EE:FF MAC-CM:
EE:FF:CC:DD:EE:FF
No le presten atención por ahora al texto personalizado (info:,
DHCPACK-CPE, etc), puesto que me falta definir bien como va a quedar (la
cosa es que ya puedo detectar lo que quiero y generar un registro). 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.
Espero se haya entendido bien ahora y perdón si antes quedó medio confuso.
Saludos y gracias!
Mauro.
>
> Saludos,
quedó confuso :S Va de nuevo la aclaración:
Con la configuración por defecto, el servidor DHCP me genera este tipo
de logs:
DHCPREQUEST for aaa.bbb.ccc.ddd from AA:BB:CC:DD:EE:FF (WR720N) via
eee.fff.ggg.hhh
DHCPACK on aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (WR720N) via eee.fff.ggg.hhh
Y con la configuración que yo implementé (con los distintos if y la
sentencia on commit") me genera esto (entre otras cosas):
info: dhcp-cpe-request: IP-CPE: aaa.bbb.ccc.ddd MAC-CPE:
AA:BB:CC:DD:EE:FF MAC-CM: EE:FF:CC:DD:EE:FF
DHCPACK-CPE: IP-CPE: aaa.bbb.ccc.ddd MAC-CPE: AA:BB:CC:DD:EE:FF MAC-CM:
EE:FF:CC:DD:EE:FF
No le presten atención por ahora al texto personalizado (info:,
DHCPACK-CPE, etc), puesto que me falta definir bien como va a quedar (la
cosa es que ya puedo detectar lo que quiero y generar un registro). 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.
Espero se haya entendido bien ahora y perdón si antes quedó medio confuso.
Saludos y gracias!
Mauro.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5374CA2C...@gmail.com
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 15, 2014, 10:30:01 AM5/15/14
to
El 15/05/14 10:49, Camaleón escribió:
Bien, ahí estuve leyendo esa sección, pero eso es para los logs
personalizados que uno crea usando la sentencia "log(...)". Yo lo que
quiero es anular el envío de los logs por defecto.
Aún no encuentro como hacerlo. Se podrá? Me parece raro que no se pueda.
Cuando busco información o bien encuentro lo referido a la condiguración
de la facility o de los logs personalizados con log(...), pero nada de
los logs que por defecto genera.
Voy a revisar nuevamente las man pages, a lo mejor se me escapó algo.
Saludos y gracias.
Mauro.
>
> Saludos,
personalizados que uno crea usando la sentencia "log(...)". Yo lo que
quiero es anular el envío de los logs por defecto.
Aún no encuentro como hacerlo. Se podrá? Me parece raro que no se pueda.
Cuando busco información o bien encuentro lo referido a la condiguración
de la facility o de los logs personalizados con log(...), pero nada de
los logs que por defecto genera.
Voy a revisar nuevamente las man pages, a lo mejor se me escapó algo.
Saludos y gracias.
Mauro.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5374CE5C...@gmail.com
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 15, 2014, 10:30:02 AM5/15/14
to
El Thu, 15 May 2014 11:07:40 -0300, Mauro Antivero escribió:
> El 15/05/14 10:58, Camaleón escribió:
(...)
>> Pues ahora mismo ya no sé qué es lo quieres hacer :-), mejor pon un
>> ejemplo práctico del tipo "el registro de dhcpd pone esto "(a b c d)" y
>> yo quiero esto "(mi cadena: a b c d)"
> Pero es que lo había puesto, solo que a lo mejor entre tanto correo
> quedó confuso :S Va de nuevo la aclaración:
>
> Con la configuración por defecto, el servidor DHCP me genera este tipo
> de logs:
>
> DHCPREQUEST for aaa.bbb.ccc.ddd from AA:BB:CC:DD:EE:FF (WR720N) via
> eee.fff.ggg.hhh DHCPACK on aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (WR720N)
> via eee.fff.ggg.hhh
Vale, eso es lo normal.
> Y con la configuración que yo implementé (con los distintos if y la
> sentencia on commit") me genera esto (entre otras cosas):
>
> info: dhcp-cpe-request: IP-CPE: aaa.bbb.ccc.ddd MAC-CPE:
> AA:BB:CC:DD:EE:FF MAC-CM: EE:FF:CC:DD:EE:FF DHCPACK-CPE: IP-CPE:
> aaa.bbb.ccc.ddd MAC-CPE: AA:BB:CC:DD:EE:FF MAC-CM: EE:FF:CC:DD:EE:FF
Bien. Manda el archivo de configuración que tienes ahora porque supongo
que habrás hecho cambios.
> No le presten atención por ahora al texto personalizado (info:,
> DHCPACK-CPE, etc), puesto que me falta definir bien como va a quedar (la
> cosa es que ya puedo detectar lo que quiero y generar un registro).
Entendido.
> 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 :-)
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05...@gmail.com
> El 15/05/14 10:58, Camaleón escribió:
(...)
>> Pues ahora mismo ya no sé qué es lo quieres hacer :-), mejor pon un
>> ejemplo práctico del tipo "el registro de dhcpd pone esto "(a b c d)" y
>> yo quiero esto "(mi cadena: a b c d)"
> Pero es que lo había puesto, solo que a lo mejor entre tanto correo
> quedó confuso :S Va de nuevo la aclaración:
>
> Con la configuración por defecto, el servidor DHCP me genera este tipo
> de logs:
>
> DHCPREQUEST for aaa.bbb.ccc.ddd from AA:BB:CC:DD:EE:FF (WR720N) via
> eee.fff.ggg.hhh DHCPACK on aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF (WR720N)
> via eee.fff.ggg.hhh
> Y con la configuración que yo implementé (con los distintos if y la
> sentencia on commit") me genera esto (entre otras cosas):
>
> info: dhcp-cpe-request: IP-CPE: aaa.bbb.ccc.ddd MAC-CPE:
> AA:BB:CC:DD:EE:FF MAC-CM: EE:FF:CC:DD:EE:FF DHCPACK-CPE: IP-CPE:
> aaa.bbb.ccc.ddd MAC-CPE: AA:BB:CC:DD:EE:FF MAC-CM: EE:FF:CC:DD:EE:FF
que habrás hecho cambios.
> No le presten atención por ahora al texto personalizado (info:,
> DHCPACK-CPE, etc), puesto que me falta definir bien como va a quedar (la
> cosa es que ya puedo detectar lo que quiero y generar un registro).
> 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.
predeterminados y los personalizados.
> Espero se haya entendido bien ahora y perdón si antes quedó medio
> confuso.
duplicados :-)
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 15, 2014, 11:10:03 AM5/15/14
to
El 15/05/14 11:20, Camaleón escribió:
Bueno, por lo que pude ver hasta ahora no se puede anular los logs que
por defecto envía isc-dhcp-server, 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".
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).
En fin, les estoy muy agradecido por su ayuda.
Saludos, Mauro.
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5374D6EC...@gmail.com
por defecto envía isc-dhcp-server, 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".
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).
En fin, les estoy muy agradecido por su ayuda.
Saludos, Mauro.
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 15, 2014, 11:40:02 AM5/15/14
to
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.
> 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.
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.
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 {
}
Prueba con esto:
if dhcp-message-type = 5 {
}
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 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.
> 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,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05...@gmail.com
> 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 :-)
> Bueno, por lo que pude ver hasta ahora no se puede anular los logs que
> por defecto envía isc-dhcp-server,
hemos forzado que registre los datos al usar el evento "on commit" y cada
vez que se produce el evento, registro al canto.
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.
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)));
}
O algo más simple:
log(info, concat("info: dhcp-cpe-ack:", " MAC-CPE: ",
A ver qué sucede o si notas algún cambio.
> 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".
> 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).
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 15, 2014, 1:50:01 PM5/15/14
to
El 15/05/14 12:34, Camaleón escribió:
Lo limpio un poco y lo subo.
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.
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).
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.
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?
> 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.
>
>> 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.
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é
>> 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.
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
> 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.
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:
> 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)));
> }
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
> 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.
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
>> 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.
>
>> 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,
>> 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.
>
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/5374FDBB...@gmail.com
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 16, 2014, 8:20:02 AM5/16/14
to
A ver, sigue siendo el mismo tema, por eso no pongo otro hilo, pero
ahora lo que quiero capturar son los mensajes del tipo OFFER (DHCP
message type = 2).
La cuestión es que si hago lo siguiente:
if option dhcp-message-type = 2
{
log(info, concat(
"DHCP_OFFER:",
" MAC: ", binary-to-ascii(16, 8, ":", hardware),
" MAC: ", binary-to-ascii(16, 8, ":", option
agent.remote-id)));
}
No funciona, es decir, la sintaxis no me da error pero no obtengo ningún
log del tipo "DHCP_OFFER:". Pero la cuestión es que por defecto el
servidor detecta y loguea estos mensajes de la siguiente manera:
DHCPOFFER on aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF via eee.fff.ggg.hhh
Pero bueno, como ya sabrán quiero (necesito) logs personalizados y por
eso este no me sirve.
Me pregunto si pasará algo similar a lo que pasaba cuando trataba de
detectar los ACK, para los cuales la condición "if option
dhcp-message-type = 5" no servía (aún no entiendo porque) y tenía que
utilizar la sentencia "on commit".
He buscado en Google pero de momento no me aparece nada referido a los
OFFER. Igual, por supuesto que seguiré buscando.
Como siempre, les agradezco mucho por su ayuda.
Saludos, Mauro.
El 14/05/14 12:48, Camaleón escribió:
ahora lo que quiero capturar son los mensajes del tipo OFFER (DHCP
message type = 2).
La cuestión es que si hago lo siguiente:
if option dhcp-message-type = 2
{
log(info, concat(
"DHCP_OFFER:",
" MAC: ", binary-to-ascii(16, 8, ":", hardware),
" MAC: ", binary-to-ascii(16, 8, ":", option
agent.remote-id)));
}
No funciona, es decir, la sintaxis no me da error pero no obtengo ningún
log del tipo "DHCP_OFFER:". Pero la cuestión es que por defecto el
servidor detecta y loguea estos mensajes de la siguiente manera:
DHCPOFFER on aaa.bbb.ccc.ddd to AA:BB:CC:DD:EE:FF via eee.fff.ggg.hhh
Pero bueno, como ya sabrán quiero (necesito) logs personalizados y por
eso este no me sirve.
Me pregunto si pasará algo similar a lo que pasaba cuando trataba de
detectar los ACK, para los cuales la condición "if option
dhcp-message-type = 5" no servía (aún no entiendo porque) y tenía que
utilizar la sentencia "on commit".
He buscado en Google pero de momento no me aparece nada referido a los
OFFER. Igual, por supuesto que seguiré buscando.
Como siempre, les agradezco mucho por su ayuda.
Saludos, Mauro.
El 14/05/14 12:48, Camaleón escribió:
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/53760122...@gmail.com
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 16, 2014, 10:20:01 AM5/16/14
to
El Thu, 15 May 2014 14:47:39 -0300, Mauro Antivero escribió:
> El 15/05/14 12:34, Camaleón escribió:
(...)
>> 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.
Gracias :-)
>> 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?
Para comprobar si mi teoría es correcta. Por el momento lo que sabemos es
que (si hay algo mal me corriges)
1/ De manera predeterminada (sin alterar el archivo de configuración), el
servidor dhcpd registra determinados eventos.
2/ En el manual se definen esos eventos (cadenas de valores fijos) y se
puede interactuar con ellos.
Ahora imagina que eres un servidor dhcp y tu misión es proporcionar la
información de los valores del adaptador de red a tus clientes, registrar
los datos para depuración y llevar la configuración de lo vas haciendo.
Vale, ¿tendría sentido permitirle al administrador personalizar los
registros que generas? Desde mi punto de vista sí ya que otros servicios
también lo permiten (p. ej., los datos que registra Apache2 son
configurables por el usuario).
Y si es posible hacerlo, entiendo que lo lógico es que cuando (y sólo
cuando) el servidor dhcpd genera el tipo de evento buscado (ack,
offer...), se le puedan pasar los parámetros de configuración de qué
datos y en qué formato registrarlo.
Con las dos pruebas de más arriba quiero ver qué sucede haciendo esto,
que podría ser o bien nada (que haga caso omiso) o bien que se altere el
registro de alguna forma. En resumen, sirve sólo para probar si a través
de esta opción se puede dar forma a los datos que registra.
> 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.
(...)
Sí, entiendo que el formato y los datos que registra debe estar definido
en el propio código fuente o en todo caso sea un parámetro configurable
al compilar.
> Lo único que dejé es la configuración de facility local7.
Hum... ahora que mencionas lo de la "facility 7, se me está ocurriendo
una tontuna. ¿Qué pasaría si le dices al sistema que NO registre nada en
"local7" (en /"etc/rsyslog.conf" → local7.none) pero configuras en el
servidor dhcpd la cláusula "on commit(log...)"? La teoría indica que
debería enviarlo al local7 que no registra nada pero...
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05...@gmail.com
> El 15/05/14 12:34, Camaleón escribió:
(...)
>> 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.
>> 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?
que (si hay algo mal me corriges)
1/ De manera predeterminada (sin alterar el archivo de configuración), el
servidor dhcpd registra determinados eventos.
2/ En el manual se definen esos eventos (cadenas de valores fijos) y se
puede interactuar con ellos.
Ahora imagina que eres un servidor dhcp y tu misión es proporcionar la
información de los valores del adaptador de red a tus clientes, registrar
los datos para depuración y llevar la configuración de lo vas haciendo.
Vale, ¿tendría sentido permitirle al administrador personalizar los
registros que generas? Desde mi punto de vista sí ya que otros servicios
también lo permiten (p. ej., los datos que registra Apache2 son
configurables por el usuario).
Y si es posible hacerlo, entiendo que lo lógico es que cuando (y sólo
cuando) el servidor dhcpd genera el tipo de evento buscado (ack,
offer...), se le puedan pasar los parámetros de configuración de qué
datos y en qué formato registrarlo.
Con las dos pruebas de más arriba quiero ver qué sucede haciendo esto,
que podría ser o bien nada (que haga caso omiso) o bien que se altere el
registro de alguna forma. En resumen, sirve sólo para probar si a través
de esta opción se puede dar forma a los datos que registra.
> 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.
Sí, entiendo que el formato y los datos que registra debe estar definido
en el propio código fuente o en todo caso sea un parámetro configurable
al compilar.
> Lo único que dejé es la configuración de facility local7.
una tontuna. ¿Qué pasaría si le dices al sistema que NO registre nada en
"local7" (en /"etc/rsyslog.conf" → local7.none) pero configuras en el
servidor dhcpd la cláusula "on commit(log...)"? La teoría indica que
debería enviarlo al local7 que no registra nada pero...
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 16, 2014, 10:30:01 AM5/16/14
to
El Fri, 16 May 2014 09:14:26 -0300, Mauro Antivero escribió:
> A ver, sigue siendo el mismo tema, por eso no pongo otro hilo, pero
> ahora lo que quiero capturar son los mensajes del tipo OFFER (DHCP
> message type = 2).
>
> La cuestión es que si hago lo siguiente:
>
> if option dhcp-message-type = 2
> {
> log(info, concat(
> "DHCP_OFFER:",
> " MAC: ", binary-to-ascii(16, 8, ":", hardware),
> " MAC: ", binary-to-ascii(16, 8, ":", option
> agent.remote-id)));
> }
>
> No funciona, es decir, la sintaxis no me da error pero no obtengo ningún
> log del tipo "DHCP_OFFER:".
(...)
> A ver, sigue siendo el mismo tema, por eso no pongo otro hilo, pero
> ahora lo que quiero capturar son los mensajes del tipo OFFER (DHCP
> message type = 2).
>
> La cuestión es que si hago lo siguiente:
>
> if option dhcp-message-type = 2
> {
> log(info, concat(
> "DHCP_OFFER:",
> " MAC: ", binary-to-ascii(16, 8, ":", hardware),
> " MAC: ", binary-to-ascii(16, 8, ":", option
> agent.remote-id)));
> }
>
> No funciona, es decir, la sintaxis no me da error pero no obtengo ningún
> log del tipo "DHCP_OFFER:".
Mauro, creo que estamos en la misma situación que con el ACK: estamos
dando por hecho algo que no es o estamos haciendo algo mal, de ahí que te
solicitara el resultado de las dos pruebas anteriores.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mauro Antivero
May 20, 2014, 8:00:02 AM5/20/14
to
El 16/05/14 11:19, Camaleón escribió:
termino de entender que pruebas necesitás que haga. Si me aclarás y
puedo hacerlas (el servidor DHCP no se puede sacar de producción, pero
aún así puedo hacer muchísimas pruebas con él) las hago con gusto.
De momento lo solucioné de una manera muy tonta: Todo lo que es log
personalizado empieza por la cadena "DHCP_" y con eso lo filtro, pero
claro, sigo teniendo logs repetidos en distinto formato (no es grave
pero me gustaría en algún momento corregirlo).
Por último, sigo sin poder detectar los offer. Los mensajes que detecto
hasta ahora son:
Discover: Con la sentencia "if option dhcp-message-type = 1"
Request: Con la sentencia "if option dhcp-message-type = 5"
Ack: Con la sentencia "on commit"
Saludos y gracias!
Mauro.
>
> Saludos,
>
> El Fri, 16 May 2014 09:14:26 -0300, Mauro Antivero escribió:
>
>> A ver, sigue siendo el mismo tema, por eso no pongo otro hilo, pero
>> ahora lo que quiero capturar son los mensajes del tipo OFFER (DHCP
>> message type = 2).
>>
>> La cuestión es que si hago lo siguiente:
>>
>> if option dhcp-message-type = 2
>> {
>> log(info, concat(
>> "DHCP_OFFER:",
>> " MAC: ", binary-to-ascii(16, 8, ":", hardware),
>> " MAC: ", binary-to-ascii(16, 8, ":", option
>> agent.remote-id)));
>> }
>>
>> No funciona, es decir, la sintaxis no me da error pero no obtengo ningún
>> log del tipo "DHCP_OFFER:".
> (...)
>
> Mauro, creo que estamos en la misma situación que con el ACK: estamos
> dando por hecho algo que no es o estamos haciendo algo mal, de ahí que te
> solicitara el resultado de las dos pruebas anteriores.
Disculpá, leí el correo que mencionás (el de las pruebas) pero no
>
>> A ver, sigue siendo el mismo tema, por eso no pongo otro hilo, pero
>> ahora lo que quiero capturar son los mensajes del tipo OFFER (DHCP
>> message type = 2).
>>
>> La cuestión es que si hago lo siguiente:
>>
>> if option dhcp-message-type = 2
>> {
>> log(info, concat(
>> "DHCP_OFFER:",
>> " MAC: ", binary-to-ascii(16, 8, ":", hardware),
>> " MAC: ", binary-to-ascii(16, 8, ":", option
>> agent.remote-id)));
>> }
>>
>> No funciona, es decir, la sintaxis no me da error pero no obtengo ningún
>> log del tipo "DHCP_OFFER:".
> (...)
>
> Mauro, creo que estamos en la misma situación que con el ACK: estamos
> dando por hecho algo que no es o estamos haciendo algo mal, de ahí que te
> solicitara el resultado de las dos pruebas anteriores.
termino de entender que pruebas necesitás que haga. Si me aclarás y
puedo hacerlas (el servidor DHCP no se puede sacar de producción, pero
aún así puedo hacer muchísimas pruebas con él) las hago con gusto.
De momento lo solucioné de una manera muy tonta: Todo lo que es log
personalizado empieza por la cadena "DHCP_" y con eso lo filtro, pero
claro, sigo teniendo logs repetidos en distinto formato (no es grave
pero me gustaría en algún momento corregirlo).
Por último, sigo sin poder detectar los offer. Los mensajes que detecto
hasta ahora son:
Discover: Con la sentencia "if option dhcp-message-type = 1"
Request: Con la sentencia "if option dhcp-message-type = 5"
Ack: Con la sentencia "on commit"
Saludos y gracias!
Mauro.
>
> Saludos,
>
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/537B4302...@gmail.com
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Camaleón
May 20, 2014, 11:20:01 AM5/20/14
to
El Tue, 20 May 2014 08:56:50 -0300, Mauro Antivero escribió:
> El 16/05/14 11:19, Camaleón escribió:
> El 16/05/14 11:19, Camaleón escribió:
(...)
>> Mauro, creo que estamos en la misma situación que con el ACK: estamos
>> dando por hecho algo que no es o estamos haciendo algo mal, de ahí que
>> te solicitara el resultado de las dos pruebas anteriores.
> Disculpá, leí el correo que mencionás (el de las pruebas) pero no
> termino de entender que pruebas necesitás que haga. Si me aclarás y
> puedo hacerlas (el servidor DHCP no se puede sacar de producción, pero
> aún así puedo hacer muchísimas pruebas con él) las hago con gusto.
Las pruebas son las que te explicaba en un mensaje anterior:
>> Mauro, creo que estamos en la misma situación que con el ACK: estamos
>> dando por hecho algo que no es o estamos haciendo algo mal, de ahí que
>> te solicitara el resultado de las dos pruebas anteriores.
> Disculpá, leí el correo que mencionás (el de las pruebas) pero no
> termino de entender que pruebas necesitás que haga. Si me aclarás y
> puedo hacerlas (el servidor DHCP no se puede sacar de producción, pero
> aún así puedo hacer muchísimas pruebas con él) las hago con gusto.
https://lists.debian.org/debian-user-spanish/2014/05/msg00363.html
> De momento lo solucioné de una manera muy tonta: Todo lo que es log
> personalizado empieza por la cadena "DHCP_" y con eso lo filtro, pero
> claro, sigo teniendo logs repetidos en distinto formato (no es grave
> pero me gustaría en algún momento corregirlo).
única en este caso salvo ya que me parece que dhcpd no permite la
configuración personalizada de sus registros (salvo recompilando pero
como bien decías me parece un poco exagerado) :-/
> Por último, sigo sin poder detectar los offer. Los mensajes que detecto
> hasta ahora son:
>
> Discover: Con la sentencia "if option dhcp-message-type = 1"
> Request: Con la sentencia "if option dhcp-message-type = 5"
> Ack: Con la sentencia "on commit"
verboso).
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages