Re: dhcp-proxy con dnsmasq
El 2023-01-20 a las 14:28 +0100, trujo escribió: > El jue, 19-01-2023 a las 20:38 +0100, Camaleón escribió: > > El 2023-01-19 a las 13:49 +0100, trujo escribió: > > > > > Estoy intentando ponerlo en marcha (con debian estable). > > > la red en la que esta recibe ipes desde un relay situado en el > > > conmutador. > > > Si en el servidor DHCP pongo la opción 66 (next-server) parece > > > funcionar, si no no funciona. > > > no deberia dar este parametro el proxy-dhcp. > > > mi configuración: > > > port=0 > > > log-dhcp > > > dhcp-no-override > > > enable-tftp > > > dhcp-range=192.168.53.21,proxy > > > dhcp-boot=terminales/bootcode.bin,192.168.53.4,192.168.53.4 > > > interface=red-pxe > > > dhcp-option=66,"192.168.53.4" > > > > > > Si desactivo el dhcp-relay no funciona en absoluto, ¿no deberia > > > funcionar?, ¿donde se le dice cual es el servidor al que debe > > > pedirle > > > la ip? > > > > Hum... así a bote pronto el único valor que no veo definido en la > > configuración es el directorio raíz del servidor TFTP («tftp-root»), > > pero no sé hasta qué punto puede afectar al tener definida la opción > > de > > next-server, no he trabajado nunca con dnsmasq :-? > > > > Echa un vistazo a la wiki de Archlinux que siempre explican de forma > > didáctica cómo configurar cada uno de los servicios que admite > > dnsmasq: > > > > https://wiki.archlinux.org/title/dnsmasq > > > > En cualquier caso, revisa el registro de dnsmaq para ver qué hace > > exactamente el demonio y por qué falla en cada caso (p. ej., cuando > > defines la opción «66» y cuando no). > > > > > Se me olvido copiarlo, pero el problema no es ese el problema, es que > no funciona. > Lo monto en consola para poder depurarlo: > # dnsmasq -d -C /etc/dnsmasq.d/ipxe > dnsmasq: started, version 2.85 DNS disabled > dnsmasq: opciones de compilación: IPv6 GNU-getopt DBus no-UBus i18n > IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC > loop-detect inotify dumpfile > dnsmasq-dhcp: DHCP, proxy on subnet 192.168.53.1 > dnsmasq-dhcp: DHCP, sockets bound exclusively to interface red-pxe > dnsmasq-tftp: TFTP root está /srv/tftp/terminales > dnsmasq-dhcp: 2554010389 available DHCP subnet: > 192.168.53.1/255.255.255.0 > dnsmasq-dhcp: 2554010389 vendor class: PXEClient:Arch:0:UNDI:002001 Si se queda ahí, quizá lo que falle es la carga del PXE, que no lo detecte correctamente y tengas que forzar de alguna manera que lo reconozca para poder iniciar los clientes ligeros. PXE : dnsmasq dhcp proxy not answering [SOLVED] https://bbs.archlinux.org/viewtopic.php?id=254774 Que es básicamente lo que recomienda el artículo de la wiki de Archlinux (apartado de configuración para el servidor PXE). > No llega a arrabcar, si añado en el servidor de DHCP principal, es que > lo que no quiero hacer la opción 66 > En el cliente se ve: > IP-Config: Complete: > device=eth0, hwaddr:xx:xx:xx:xx:xx:xx, ipaddr=192.168.53.13, > mask=255.255.255.0,gw=192.168.53.1 > host=192.168.53.13, domain=ea.ea.ea.ea.ea, nis-domain=(none) > boorserver=0.0.0.0, rootserver=0.0.0.0, rootpath= > nameserver0=8.8.8.8, nameserver1=xxx.xxx.xxx > > > Es decir toma los datos dados por el DHCP principal, > Si desactivo el dhcp-relay del conmutador y hago que dnsmasq actue como > relay añadiendo la linea: > dhcp-relay=192.168.53.4,10.xxx.xxx.xxx > > > # dnsmasq -d -C /etc/dnsmasq.d/ipxe > dnsmasq: started, version 2.85 DNS disabled > dnsmasq: opciones de compilación: IPv6 GNU-getopt DBus no-UBus i18n > IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC > loop-detect inotify dumpfile > dnsmasq-dhcp: DHCP, proxy on subnet 192.168.53.1 > dnsmasq-dhcp: DHCP relay from 192.168.53.4 to 10.xxx.xxx.xxx > dnsmasq-tftp: TFTP root está /srv/tftp/terminales > > Pero el resto es igual, es decir el relay funciona pero el proxy no. > La pagina de Arch que me has dicho ya la habia mirado antes y no aporta > nada, solo que mire en el fichero "/var/lib/misc/dnsmasq.leases" para > ver los arrendamiento, pero ese fichero esta vacío. > > Lo único que no controlo bien es la linea: > dhcp-range=192.168.53.1,proxy > He probado a poner el GW (1), el servidor (192.168.53.4) o una de las > direcciones arrendadas (13), pero el resultado es siempre el mismo, no > funciona ¿De qué tipo de clientes ligeros se trata? Quizá requieran algún tipo de parámetro o configuración concreto, de ahí que forzando la opción 66 se cargue el bootloader y los clientes detecten sin problemas el servidor dnsmasq. Saludos, -- Camaleón
Re: dhcp-proxy con dnsmasq
El jue, 19-01-2023 a las 20:38 +0100, Camaleón escribió: > El 2023-01-19 a las 13:49 +0100, trujo escribió: > > > Estoy intentando ponerlo en marcha (con debian estable). > > la red en la que esta recibe ipes desde un relay situado en el > > conmutador. > > Si en el servidor DHCP pongo la opción 66 (next-server) parece > > funcionar, si no no funciona. > > no deberia dar este parametro el proxy-dhcp. > > mi configuración: > > port=0 > > log-dhcp > > dhcp-no-override > > enable-tftp > > dhcp-range=192.168.53.21,proxy > > dhcp-boot=terminales/bootcode.bin,192.168.53.4,192.168.53.4 > > interface=red-pxe > > dhcp-option=66,"192.168.53.4" > > > > Si desactivo el dhcp-relay no funciona en absoluto, ¿no deberia > > funcionar?, ¿donde se le dice cual es el servidor al que debe > > pedirle > > la ip? > > Hum... así a bote pronto el único valor que no veo definido en la > configuración es el directorio raíz del servidor TFTP («tftp-root»), > pero no sé hasta qué punto puede afectar al tener definida la opción > de > next-server, no he trabajado nunca con dnsmasq :-? > > Echa un vistazo a la wiki de Archlinux que siempre explican de forma > didáctica cómo configurar cada uno de los servicios que admite > dnsmasq: > > https://wiki.archlinux.org/title/dnsmasq > > En cualquier caso, revisa el registro de dnsmaq para ver qué hace > exactamente el demonio y por qué falla en cada caso (p. ej., cuando > defines la opción «66» y cuando no). > > Saludos, > Se me olvido copiarlo, pero el problema no es ese el problema, es que no funciona. Lo monto en consola para poder depurarlo: # dnsmasq -d -C /etc/dnsmasq.d/ipxe dnsmasq: started, version 2.85 DNS disabled dnsmasq: opciones de compilación: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile dnsmasq-dhcp: DHCP, proxy on subnet 192.168.53.1 dnsmasq-dhcp: DHCP, sockets bound exclusively to interface red-pxe dnsmasq-tftp: TFTP root está /srv/tftp/terminales dnsmasq-dhcp: 2554010389 available DHCP subnet: 192.168.53.1/255.255.255.0 dnsmasq-dhcp: 2554010389 vendor class: PXEClient:Arch:0:UNDI:002001 No llega a arrabcar, si añado en el servidor de DHCP principal, es que lo que no quiero hacer la opción 66 En el cliente se ve: IP-Config: Complete: device=eth0, hwaddr:xx:xx:xx:xx:xx:xx, ipaddr=192.168.53.13, mask=255.255.255.0,gw=192.168.53.1 host=192.168.53.13, domain=ea.ea.ea.ea.ea, nis-domain=(none) boorserver=0.0.0.0, rootserver=0.0.0.0, rootpath= nameserver0=8.8.8.8, nameserver1=xxx.xxx.xxx Es decir toma los datos dados por el DHCP principal, Si desactivo el dhcp-relay del conmutador y hago que dnsmasq actue como relay añadiendo la linea: dhcp-relay=192.168.53.4,10.xxx.xxx.xxx # dnsmasq -d -C /etc/dnsmasq.d/ipxe dnsmasq: started, version 2.85 DNS disabled dnsmasq: opciones de compilación: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile dnsmasq-dhcp: DHCP, proxy on subnet 192.168.53.1 dnsmasq-dhcp: DHCP relay from 192.168.53.4 to 10.xxx.xxx.xxx dnsmasq-tftp: TFTP root está /srv/tftp/terminales Pero el resto es igual, es decir el relay funciona pero el proxy no. La pagina de Arch que me has dicho ya la habia mirado antes y no aporta nada, solo que mire en el fichero "/var/lib/misc/dnsmasq.leases" para ver los arrendamiento, pero ese fichero esta vacío. Lo único que no controlo bien es la linea: dhcp-range=192.168.53.1,proxy He probado a poner el GW (1), el servidor (192.168.53.4) o una de las direcciones arrendadas (13), pero el resultado es siempre el mismo, no funciona
dhcp-proxy con dnsmasq
Estoy intentando ponerlo en marcha (con debian estable). la red en la que esta recibe ipes desde un relay situado en el conmutador. Si en el servidor DHCP pongo la opción 66 (next-server) parece funcionar, si no no funciona. no deberia dar este parametro el proxy-dhcp. mi configuración: port=0 log-dhcp dhcp-no-override enable-tftp dhcp-range=192.168.53.21,proxy dhcp-boot=terminales/bootcode.bin,192.168.53.4,192.168.53.4 interface=red-pxe dhcp-option=66,"192.168.53.4" Si desactivo el dhcp-relay no funciona en absoluto, ¿no deberia funcionar?, ¿donde se le dice cual es el servidor al que debe pedirle la ip?
RE: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...]
Hola, Con el kernel 5.10.0-16 tuve varios problemas. Lo instalé Debian 11 en 3 Hp Proliant DL3810 G7 con 64ram, en uno me dió problemas luego de una actu del kernel... Hice mvarias pruebas y no se solucionaba hasta que opté por bajar e instalar 5.16.0-0.bpo.3-amd64, por ahora no tengo problemas y los que tenía se solucionaron. Sldos, Marcelo.- -Mensaje original- De: JavierDebian [mailto:javier.debian.bb...@gmail.com] Enviado el: lunes, 22 de agosto de 2022 18:06 Para: debian-user-spanish@lists.debian.org Asunto: Re: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...] El 19/8/22 a las 03:45, Camaleón escribió: > El 2022-08-18 a las 21:59 -0300, JavierDebian escribió: > >> Buenas noches. >> >> Me ha pasado algo extraño. >> Debian 11 "bullseye" con kernel 5.10.0-16-amd64. >> Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. >> Computadora que funciona desde hace 6 años con configuración de red >> por DHCP automática, configurado "a mano" por interfaces. >> resolvconf corriendo como demonio. >> >> Hace un par de días, se puso remolona para tomar dirección IP. >> Reiniciado el enrutador y el equipo un par de veces, lo achaqué a >> problemas del enrutador o del servicio provisto por mi ISP, un CISCO >> Technicolor DPC3848VE DOCSIS 3.0, empresa Flow/Personal/Fibertel Argentina. > > El problema de tener el servidor de DHCP en equipos restringidos > (routers, switches o dispositivos integrados) es que apenas permiten > depurar los errores en caso de presentarse problemas. > >> Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. >> Cambié cable de conexión, sin éxito. >> "¿Será la placa de red?" >> Arranqué Windows desde otra partición; conexión impecable, no es ni >> el cable ni la placa ni el enrutador. >> Arranco un SystemRescueCD, y toma la dirección sin problemas. >> Vuelvo a Debian, no toma dirección IP. >> Levanto una máquina VirtualBox en Debian que corre un Win7 con la red >> en modo puente... toma la dirección sin inconvenientes >> >> Configuro la red en forma manual, con IP fija y todo a mano >> Funciona sin inconvenientes. >> >> Vuelvo atrás, a configurar por DHCP automático; no funciona, pero >> sólo en Debian 11. >> Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún >> problema, aún siendo "stable"; sigue sin funcionar. >> >> Ahora estoy en modo IP estático, funcionando sin problemas... salvo >> que no puedo volver a DHCP dinámico, porque no funciona. >> >> Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL >> SISTEMA HAGA COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. >> >> Seguiré investigando. >> >> Si a alguno le pasó algo así, escucho sugerencias. > > Yo probaría lo siguiente: > > 1. Fuerza la renovación de la IP, a ver si el Cisco le asigna otra > nueva y se puede configurar el adaptador de red sin problemas. > > Dependiendo de qué cliente dhcp uses (hoy en día me pierdo con tantas > opciones: systemd, dhclient, network-manager...) tendrás que hacer una > cosa u otra para renovar los datos del adaptador: > > Linux Force DHCP Client (dhclient) to Renew IP Address > https://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address > / > > 2. A modo de prueba, y si te resulta posible, configura otro servidor > o sistema (router/switch) como servidor DHCP (desconecta el Cisco de > la red para evitar conflictos) a ver si el Debian 11 puede > configurarse preguntando a otro servidor. > > 3. Revisa los registros para ver qué puede estar fallando (syslog, > journalctl) o intenta configurar el adpatador de red desde línea de > órdenes (con dhclient -v...) para ver si tienes más información del > problema, recibes un timeout, etc... > > Saludos, > Tomando en cuenta las indicaciones de Camaleón, procedí a: 1 - Eliminar resolvconf, avahi-autoipd, isc-dhcp-client-ddns e isc-dhcp-client. O sea, todo lo que tenga que ver con manejos automágicos de redes, excepto systemd, por supuesto... (network-manager está prohibido en mi sistema). 2 - Reinstalar resolvconf e isc-dhcp-client. 3 - Reconfigurar nuevamente /etc/interfaces para dirección IP por DHCP. 4 - Reiniciar el equipo. Mágicamente, funciona. Ayer pasó lo mismo en otra máquina que tiene mi hija en su habitación; empezó a no resolver IP. Y ayer, justamente, fue "día de actualización de la PC de la niña". Me huelo a alguna actualización o instalación de algo (?) que desbarató algo otro (?). Gracias. JAP
Re: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...]
El lun, 22 ago 2022 a la(s) 16:22, Yoel Villarreal (yoe...@nauta.cu) escribió: > > Quizás no fue algo "roto". Quizás fue que no leímos el changelog. El top posting no es lindo Y yo tampoco leí el change log. ¿Qué dice que cambió? Saludos, Antonio Galicia Eram quod es, eris quod sum --
Re: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...]
El 22 de agosto de 2022 5:06:57 p. m. JavierDebian escribió: El 19/8/22 a las 03:45, Camaleón escribió: El 2022-08-18 a las 21:59 -0300, JavierDebian escribió: Buenas noches. Me ha pasado algo extraño. Debian 11 "bullseye" con kernel 5.10.0-16-amd64. Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. Computadora que funciona desde hace 6 años con configuración de red por DHCP automática, configurado "a mano" por interfaces. resolvconf corriendo como demonio. Hace un par de días, se puso remolona para tomar dirección IP. Reiniciado el enrutador y el equipo un par de veces, lo achaqué a problemas del enrutador o del servicio provisto por mi ISP, un CISCO Technicolor DPC3848VE DOCSIS 3.0, empresa Flow/Personal/Fibertel Argentina. El problema de tener el servidor de DHCP en equipos restringidos (routers, switches o dispositivos integrados) es que apenas permiten depurar los errores en caso de presentarse problemas. Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. Cambié cable de conexión, sin éxito. "¿Será la placa de red?" Arranqué Windows desde otra partición; conexión impecable, no es ni el cable ni la placa ni el enrutador. Arranco un SystemRescueCD, y toma la dirección sin problemas. Vuelvo a Debian, no toma dirección IP. Levanto una máquina VirtualBox en Debian que corre un Win7 con la red en modo puente... toma la dirección sin inconvenientes Configuro la red en forma manual, con IP fija y todo a mano Funciona sin inconvenientes. Vuelvo atrás, a configurar por DHCP automático; no funciona, pero sólo en Debian 11. Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún problema, aún siendo "stable"; sigue sin funcionar. Ahora estoy en modo IP estático, funcionando sin problemas... salvo que no puedo volver a DHCP dinámico, porque no funciona. Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL SISTEMA HAGA COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. Seguiré investigando. Si a alguno le pasó algo así, escucho sugerencias. Yo probaría lo siguiente: 1. Fuerza la renovación de la IP, a ver si el Cisco le asigna otra nueva y se puede configurar el adaptador de red sin problemas. Dependiendo de qué cliente dhcp uses (hoy en día me pierdo con tantas opciones: systemd, dhclient, network-manager...) tendrás que hacer una cosa u otra para renovar los datos del adaptador: Linux Force DHCP Client (dhclient) to Renew IP Address https://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address/ 2. A modo de prueba, y si te resulta posible, configura otro servidor o sistema (router/switch) como servidor DHCP (desconecta el Cisco de la red para evitar conflictos) a ver si el Debian 11 puede configurarse preguntando a otro servidor. 3. Revisa los registros para ver qué puede estar fallando (syslog, journalctl) o intenta configurar el adpatador de red desde línea de órdenes (con dhclient -v...) para ver si tienes más información del problema, recibes un timeout, etc... Saludos, Tomando en cuenta las indicaciones de Camaleón, procedí a: 1 - Eliminar resolvconf, avahi-autoipd, isc-dhcp-client-ddns e isc-dhcp-client. O sea, todo lo que tenga que ver con manejos automágicos de redes, excepto systemd, por supuesto... (network-manager está prohibido en mi sistema). 2 - Reinstalar resolvconf e isc-dhcp-client. 3 - Reconfigurar nuevamente /etc/interfaces para dirección IP por DHCP. 4 - Reiniciar el equipo. Mágicamente, funciona. Ayer pasó lo mismo en otra máquina que tiene mi hija en su habitación; empezó a no resolver IP. Y ayer, justamente, fue "día de actualización de la PC de la niña". Me huelo a alguna actualización o instalación de algo (?) que desbarató algo otro (?). Gracias. JAP Quizás no fue algo "roto". Quizás fue que no leímos el changelog. Enviado con Aqua Mail para Android https://www.aqua-mail.com
Re: IP por DHCP dejó de funcionar en Debian "bullseye" [RESUELTO - Por ahora...]
El 19/8/22 a las 03:45, Camaleón escribió: El 2022-08-18 a las 21:59 -0300, JavierDebian escribió: Buenas noches. Me ha pasado algo extraño. Debian 11 "bullseye" con kernel 5.10.0-16-amd64. Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. Computadora que funciona desde hace 6 años con configuración de red por DHCP automática, configurado "a mano" por interfaces. resolvconf corriendo como demonio. Hace un par de días, se puso remolona para tomar dirección IP. Reiniciado el enrutador y el equipo un par de veces, lo achaqué a problemas del enrutador o del servicio provisto por mi ISP, un CISCO Technicolor DPC3848VE DOCSIS 3.0, empresa Flow/Personal/Fibertel Argentina. El problema de tener el servidor de DHCP en equipos restringidos (routers, switches o dispositivos integrados) es que apenas permiten depurar los errores en caso de presentarse problemas. Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. Cambié cable de conexión, sin éxito. "¿Será la placa de red?" Arranqué Windows desde otra partición; conexión impecable, no es ni el cable ni la placa ni el enrutador. Arranco un SystemRescueCD, y toma la dirección sin problemas. Vuelvo a Debian, no toma dirección IP. Levanto una máquina VirtualBox en Debian que corre un Win7 con la red en modo puente... toma la dirección sin inconvenientes Configuro la red en forma manual, con IP fija y todo a mano Funciona sin inconvenientes. Vuelvo atrás, a configurar por DHCP automático; no funciona, pero sólo en Debian 11. Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún problema, aún siendo "stable"; sigue sin funcionar. Ahora estoy en modo IP estático, funcionando sin problemas... salvo que no puedo volver a DHCP dinámico, porque no funciona. Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL SISTEMA HAGA COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. Seguiré investigando. Si a alguno le pasó algo así, escucho sugerencias. Yo probaría lo siguiente: 1. Fuerza la renovación de la IP, a ver si el Cisco le asigna otra nueva y se puede configurar el adaptador de red sin problemas. Dependiendo de qué cliente dhcp uses (hoy en día me pierdo con tantas opciones: systemd, dhclient, network-manager...) tendrás que hacer una cosa u otra para renovar los datos del adaptador: Linux Force DHCP Client (dhclient) to Renew IP Address https://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address/ 2. A modo de prueba, y si te resulta posible, configura otro servidor o sistema (router/switch) como servidor DHCP (desconecta el Cisco de la red para evitar conflictos) a ver si el Debian 11 puede configurarse preguntando a otro servidor. 3. Revisa los registros para ver qué puede estar fallando (syslog, journalctl) o intenta configurar el adpatador de red desde línea de órdenes (con dhclient -v...) para ver si tienes más información del problema, recibes un timeout, etc... Saludos, Tomando en cuenta las indicaciones de Camaleón, procedí a: 1 - Eliminar resolvconf, avahi-autoipd, isc-dhcp-client-ddns e isc-dhcp-client. O sea, todo lo que tenga que ver con manejos automágicos de redes, excepto systemd, por supuesto... (network-manager está prohibido en mi sistema). 2 - Reinstalar resolvconf e isc-dhcp-client. 3 - Reconfigurar nuevamente /etc/interfaces para dirección IP por DHCP. 4 - Reiniciar el equipo. Mágicamente, funciona. Ayer pasó lo mismo en otra máquina que tiene mi hija en su habitación; empezó a no resolver IP. Y ayer, justamente, fue "día de actualización de la PC de la niña". Me huelo a alguna actualización o instalación de algo (?) que desbarató algo otro (?). Gracias. JAP
Re: IP por DHCP dejó de funcionar en Debian "bullseye"
El 2022-08-18 a las 21:59 -0300, JavierDebian escribió: > Buenas noches. > > Me ha pasado algo extraño. > Debian 11 "bullseye" con kernel 5.10.0-16-amd64. > Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. > Computadora que funciona desde hace 6 años con configuración de red por DHCP > automática, configurado "a mano" por interfaces. > resolvconf corriendo como demonio. > > Hace un par de días, se puso remolona para tomar dirección IP. Reiniciado el > enrutador y el equipo un par de veces, lo achaqué a problemas del enrutador > o del servicio provisto por mi ISP, un CISCO Technicolor DPC3848VE DOCSIS > 3.0, empresa Flow/Personal/Fibertel Argentina. El problema de tener el servidor de DHCP en equipos restringidos (routers, switches o dispositivos integrados) es que apenas permiten depurar los errores en caso de presentarse problemas. > Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. > Cambié cable de conexión, sin éxito. > "¿Será la placa de red?" > Arranqué Windows desde otra partición; conexión impecable, no es ni el cable > ni la placa ni el enrutador. > Arranco un SystemRescueCD, y toma la dirección sin problemas. > Vuelvo a Debian, no toma dirección IP. > Levanto una máquina VirtualBox en Debian que corre un Win7 con la red en > modo puente... toma la dirección sin inconvenientes > > Configuro la red en forma manual, con IP fija y todo a mano > Funciona sin inconvenientes. > > Vuelvo atrás, a configurar por DHCP automático; no funciona, pero sólo en > Debian 11. > Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún problema, > aún siendo "stable"; sigue sin funcionar. > > Ahora estoy en modo IP estático, funcionando sin problemas... salvo que no > puedo volver a DHCP dinámico, porque no funciona. > > Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL SISTEMA HAGA > COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. > > Seguiré investigando. > > Si a alguno le pasó algo así, escucho sugerencias. Yo probaría lo siguiente: 1. Fuerza la renovación de la IP, a ver si el Cisco le asigna otra nueva y se puede configurar el adaptador de red sin problemas. Dependiendo de qué cliente dhcp uses (hoy en día me pierdo con tantas opciones: systemd, dhclient, network-manager...) tendrás que hacer una cosa u otra para renovar los datos del adaptador: Linux Force DHCP Client (dhclient) to Renew IP Address https://www.cyberciti.biz/faq/howto-linux-renew-dhcp-client-ip-address/ 2. A modo de prueba, y si te resulta posible, configura otro servidor o sistema (router/switch) como servidor DHCP (desconecta el Cisco de la red para evitar conflictos) a ver si el Debian 11 puede configurarse preguntando a otro servidor. 3. Revisa los registros para ver qué puede estar fallando (syslog, journalctl) o intenta configurar el adpatador de red desde línea de órdenes (con dhclient -v...) para ver si tienes más información del problema, recibes un timeout, etc... Saludos, -- Camaleón
IP por DHCP dejó de funcionar en Debian "bullseye"
Buenas noches. Me ha pasado algo extraño. Debian 11 "bullseye" con kernel 5.10.0-16-amd64. Network-manager prohibido en el sistema, lo odio porque hace lo que quiere. Computadora que funciona desde hace 6 años con configuración de red por DHCP automática, configurado "a mano" por interfaces. resolvconf corriendo como demonio. Hace un par de días, se puso remolona para tomar dirección IP. Reiniciado el enrutador y el equipo un par de veces, lo achaqué a problemas del enrutador o del servicio provisto por mi ISP, un CISCO Technicolor DPC3848VE DOCSIS 3.0, empresa Flow/Personal/Fibertel Argentina. Hoy hizo lo mismo; intenté la solución anterior y no hubo caso. Cambié cable de conexión, sin éxito. "¿Será la placa de red?" Arranqué Windows desde otra partición; conexión impecable, no es ni el cable ni la placa ni el enrutador. Arranco un SystemRescueCD, y toma la dirección sin problemas. Vuelvo a Debian, no toma dirección IP. Levanto una máquina VirtualBox en Debian que corre un Win7 con la red en modo puente... toma la dirección sin inconvenientes Configuro la red en forma manual, con IP fija y todo a mano Funciona sin inconvenientes. Vuelvo atrás, a configurar por DHCP automático; no funciona, pero sólo en Debian 11. Cambio a kernel 5.10.0-13, no sea que el kernel nuevo tenga algún problema, aún siendo "stable"; sigue sin funcionar. Ahora estoy en modo IP estático, funcionando sin problemas... salvo que no puedo volver a DHCP dinámico, porque no funciona. Para usar la máquina, no me afecta, pero... NO ME GUSTA QUE EL SISTEMA HAGA COSAS QUE NO DEBERÍA HACER, O NO HAGA LO QUE SÍ. Seguiré investigando. Si a alguno le pasó algo así, escucho sugerencias. Gracias. JAP
wpa y dhcp es stretch
Estoy montando un terminal remoto en una "Intel NUC", por temas de dependencias de HW lo estoy montando con testing. La red donde va a funcionar es una red securizada con 802.1x. Si configuro la red con ifupdown se ejecutan procesos antes de que la red este levantada y fallan, por lo que he probado a usar systemd.networkd, lo he hecho con: # systemctl enable systemd-networkd wpa_supplicant@enp3s0 # systemctl disable NetworkManager NetworkManager-dispatcher # systemctl enable systemd-networkd-wait-online.service # dpkg --purge ifupdown Con esto el orden de carga es correcto pero tengo otro problema, la mitad de las veces lanza el dhclient antes que el wpa, por lo que la red le da una ip de una vlan sin identificar, posterior mente hace la identificación y el conmutador lo lleva a la vlan correcta (puedo verlo en el conmutador y si lanzo a mano dhclient -v enp3s0 toma una ip de la red correcta), pero se ha quedado con la ip de la vlan no identificada, por lo que es inaccesible. ¿Alguna idea? -- *Antonio Trujillo Carmona* *Técnico de redes y sistemas.* *Subdirección de Tecnologías de la Información y Comunicaciones* Servicio Andaluz de Salud. Consejería de Salud de la Junta de Andalucía _antonio.trujillo.sspa@juntadeandalucia.es_ Tel. +34 670947670 747670)
Re: DHCP seguro (portal cautivo o similar)
El 01/07/16 a las 19:17, Leo Perez escribió: Hola Grupo. Les dejo una nueva consulta, en este momento en la red de mi empresa tenemos un server DHCP. Esto genera comodidad para los equipos nuevos pero tiene la contra que cualquiera que "enchufe" un equipo a la red ya queda conectado. Al respecto quisiera implementar una capa de seguridad para que cuando alguie conecte un nuevo equipo a la red, antes de que se le configure la red le pida un usuario contraseña, o bien algún control por MAC ADDRESS. Algo similar busco aplicar para los routers wifi. Que se podría "armar"? Muchas Gracias a todos!!! Saludos. Si tenes ese tipo de problemas, es que tus usuarios no son muy confiables. Eso no es nada raro, pero el daño depende de la capacidad de los mismos para saltarse las restricciones.No se cómo tienes montado el servidor DHCP, si es un equipo dedicado a esa tarea y que funge como enrutador (router), o usas las bondades de un enrutador de buena marca. Desde un "router" más o menos bueno, podés ir cargando las MAC de los equipos que se vayan a conectar, sin inconvenientes, y de esa manera sólo los equipos autorizados pueden conectarse. La forma de saltarse la restricción es clonado las MAC en las placas de red. Los enrutadores son un poco tontos, y dan como válidas mil y una conexiones con la misma placa de red. Por eso es conveniente pasarle este trabajo a una máquina que funcione como router y contrafuegos del sistema. Uno muy bueno es ZeroShell http://www.zeroshell.org/ (Es con el que más he trasteado, justamente para saltármelo) Los "usuarios y contraseñas" al momento de la conexión son los "portales cautivos" que mencionas, y ZeroShell también lo maneja. La forma de saltear el límite a esto es que alguien en alguna máquina con más de una placa de red comparta la conexión a través de reglas NAT en su máquina y de allí difunda la conexión. Como alguno ha hecho https://lists.debian.org/debian-user-spanish/2016/06/msg00098.html En pocas palabras, la seguridad de la red depende de cuan honrado son tus usuarios. Acá tenés una lista de "firewalls" https://en.wikipedia.org/wiki/List_of_router_and_firewall_distributions Por lo que el submundo suele comentar, Smoothwall sería el mejor. Nunca lo usé, y espero no topármelo en algún lado. JAP
RE: DHCP seguro (portal cautivo o similar)
> El Fri, 01 Jul 2016 19:17:21 -0300, Leo Perez escribió: > >> Hola Grupo. > > Ese formato... > >> Les dejo una nueva consulta, en este momento en la red de mi empresa >> tenemos un server DHCP. >> >> Esto genera comodidad para los equipos nuevos pero tiene la contra que >> cualquiera que "enchufe" un equipo a la red ya queda conectado. > > >> Al respecto quisiera implementar una capa de seguridad para que cuando >> alguie conecte un nuevo equipo a la red, antes de que se le configure la >> red le pida un usuario contraseña, o bien algún control por MAC ADDRESS. > >> Algo similar busco aplicar para los routers wifi. >> >> Que se podría "armar"? > Una de la cosas mas senscillas de fitracion para validar los usuarios es por MAC desde un APoint, en eso no tendras problemas por lo Otro de igual manera en iptables pode hacer lo mismo. http://www.enlinux.org/filtrar-acceso-de-direcciones-ip-y-mac-addres-en-el-servicio-ssh-de-gnulinux/ saludos WRC >
Re: DHCP seguro (portal cautivo o similar)
El Fri, 01 Jul 2016 19:17:21 -0300, Leo Perez escribió: > Hola Grupo. Ese formato... > Les dejo una nueva consulta, en este momento en la red de mi empresa > tenemos un server DHCP. > > Esto genera comodidad para los equipos nuevos pero tiene la contra que > cualquiera que "enchufe" un equipo a la red ya queda conectado. Hombre, no. Puedes crear varias redes, una local y otra para invitados con acceso restringido (p. ej., que sólo puedan ver al router para navegar por Internet). Pero eso no es cosa del DHCP sino de cómo estructures tu red interna. > Al respecto quisiera implementar una capa de seguridad para que cuando > alguie conecte un nuevo equipo a la red, antes de que se le configure la > red le pida un usuario contraseña, o bien algún control por MAC ADDRESS. Por MAC puedes filtrar pero es tedioso y poco práctico, además de que las MAC se pueden alterar, no es un sistema fiable para el control de acceso. > Algo similar busco aplicar para los routers wifi. > > Que se podría "armar"? Puedes separar las redes pero el servidor con DHCP tendrá que tener al menos 2 tarjetas instaladas. Saludos, -- Camaleón
Re: DHCP seguro (portal cautivo o similar)
En los router tenes una parte que dice mac, para que pongas las mac un están habilitadas a conectarse a tu empresa. http://askubuntu.com/questions/392599/how-to-reserve-ip-address-in-dhcp-server http://www.cyberciti.biz/tips/iptables-mac-address-filtering.html http://forums.fedoraforum.org/showthread.php?t=211419 Garacciolo Marcxelo Enviado desde TypeApp En 1 jul. 2016 19:18, en 19:18, Leo Perez escribió: >Hola Grupo. > >Les dejo una nueva consulta, en este momento en la red de mi empresa >tenemos un server DHCP. > >Esto genera comodidad para los equipos nuevos pero tiene la contra que >cualquiera que "enchufe" un equipo a la red ya queda conectado. > >Al respecto quisiera implementar una capa de seguridad para que cuando >alguie conecte un nuevo equipo a la red, antes de que se le configure >la >red le pida un usuario contraseña, o bien algún control por MAC >ADDRESS. > >Algo similar busco aplicar para los routers wifi. > >Que se podría "armar"? > >Muchas Gracias a todos!!! > >Saludos.
Re: DHCP seguro (portal cautivo o similar)
El día 1 de julio de 2016, 17:17, Leo Perez escribió: > Hola Grupo. Hola > > Les dejo una nueva consulta, en este momento en la red de mi empresa tenemos > un server DHCP. > > Esto genera comodidad para los equipos nuevos pero tiene la contra que > cualquiera que "enchufe" un equipo a la red ya queda conectado. Algunos equipos de red a nivel Ethernet dejan realizar filtrado por la MAC de las tarjetas de red. > > Al respecto quisiera implementar una capa de seguridad para que cuando > alguie conecte un nuevo equipo a la red, antes de que se le configure la red > le pida un usuario contraseña, o bien algún control por MAC ADDRESS. No conozco algún sistema de login a nivel de capa 2 :( > > Algo similar busco aplicar para los routers wifi. Esto sí se puede lograr con un servidor Radius. > > Que se podría "armar"? > > Muchas Gracias a todos!!! Mucha suerte, saludos. > > Saludos. -- Juan Pablo Jaramillo Pineda Ingeniero en Sistemas y Computación http://pablox.co @pablox_co
DHCP seguro (portal cautivo o similar)
Hola Grupo. Les dejo una nueva consulta, en este momento en la red de mi empresa tenemos un server DHCP. Esto genera comodidad para los equipos nuevos pero tiene la contra que cualquiera que "enchufe" un equipo a la red ya queda conectado. Al respecto quisiera implementar una capa de seguridad para que cuando alguie conecte un nuevo equipo a la red, antes de que se le configure la red le pida un usuario contraseña, o bien algún control por MAC ADDRESS. Algo similar busco aplicar para los routers wifi. Que se podría "armar"? Muchas Gracias a todos!!! Saludos.
Re: Samba_dlz, bind9, dhcp con la zona inversa error TSIG
El Tue, 12 Apr 2016 16:45:31 -0400, cosme escribió: > Despues de haber compilado samba-4.4.0 e instalado bind9 y > isc-dhcp-server desde los repos en Debian 8 todo funciona bien excepto > la zona inversa que no actualiza desde el DHCP al DNS. > > > Probé el ejemplo que viene en > https://wiki.archlinux.org/index.php?title=Samba_4_Active_Directory_domain_controller&oldid=427930 Vale, pero mejor si copias/pegas o subes a alguna página tu configuración en concreto (omite los datos sensibles), no vaya a ser que te falte algo y desde aquí no lo podemos ver ;-) > Este es el error que da pero no he logrado solucionar > > Apr 12 16:22:45 cd1 named[848]: samba_dlz: starting transaction on zone > 7.168.192.in-addr.arpa > Apr 12 16:22:45 cd1 named[848]: samba_dlz: spnego update failed > Apr 12 16:22:45 cd1 named[848]: client 192.168.57.10#54515/key rndc-key: > updating zone '7.168.192.in-addr.arpa/NONE': update failed: rejected by > secure update (REFUSED) > Apr 12 16:22:45 cd1 named[848]: samba_dlz: cancelling transaction on zone > 7.168.192.in-addr.arpa > Apr 12 16:22:45 cd1 dhcpd: Unable to add reverse map from > 39.7.168.192.in-addr.arpa. to xp2.cuba.co.cu: REFUSED > > no he logrado que la zona inversa se actualize usando el dhcp, solo > actualiza la zona directa > > He ido modificando los permisos para probar pero nada > > Alguna idea? Sí, ese mensaje de error aparece en Google, por lo que puedes ir probando las cosas que sugieren, luego nos vas diciendo lo que has hecho y con qué resultado. https://www.google.com/webhp?complete=0&hl=en&gws_rd=cr,ssl#complete=0&hl=en&q=rndc-key:+updating+zone+update+failed:+rejected+by+secure+update+%28REFUSED%29 Saludos, -- Camaleón
Re: Samba_dlz, dhcp y zona inversa no actualiza
El Tue, 12 Apr 2016 16:45:31 -0400, cosme escribió: (...) (ya abriste un hilo hace poco sobre ese tema, te respondo allá para no separarlos) Saludos, -- Camaleón
Samba_dlz, dhcp y zona inversa no actualiza
Despues de haber compilado samba-4.4.0 e instalado bind9 y isc-dhcp-server desde los repos en Debian 8 todo funciona bien excepto la zona inversa que no actualiza desde el DHCP al DNS. Probé el ejemplo que viene en https://wiki.archlinux.org/index.php?title=Samba_4_Active_Directory_domain_controller&oldid=427930 Este es el error que da pero no he logrado solucionar Apr 12 16:22:45 cd1 named[848]: samba_dlz: starting transaction on zone 7.168.192.in-addr.arpa Apr 12 16:22:45 cd1 named[848]: samba_dlz: spnego update failed Apr 12 16:22:45 cd1 named[848]: client 192.168.7.10#54515/key rndc-key: updating zone '7.168.192.in-addr.arpa/NONE': update failed: rejected by secure update (REFUSED) Apr 12 16:22:45 cd1 named[848]: samba_dlz: cancelling transaction on zone 7.168.192.in-addr.arpa Apr 12 16:22:45 cd1 dhcpd: Unable to add reverse map from 39.7.168.192.in-addr.arpa. to xp2.cuba.co.cu: REFUSED no he logrado que la zona inversa se actualize usando el dhcp, solo actualiza la zona directa He ido modificando los permisos para probar pero nada Alguna idea?
Samba_dlz, dhcp y zona inversa no actualiza
Despues de haber compilado samba-4.4.0 e instalado bind9 y isc-dhcp-server desde los repos en Debian 8 todo funciona bien excepto la zona inversa que no actualiza desde el DHCP al DNS. Probé el ejemplo que viene en https://wiki.archlinux.org/index.php?title=Samba_4_Active_Directory_domain_controller&oldid=427930 Este es el error que da pero no he logrado solucionar Apr 12 16:22:45 cd1 named[848]: samba_dlz: starting transaction on zone 7.168.192.in-addr.arpa Apr 12 16:22:45 cd1 named[848]: samba_dlz: spnego update failed Apr 12 16:22:45 cd1 named[848]: client 192.168.57.10#54515/key rndc-key: updating zone '7.168.192.in-addr.arpa/NONE': update failed: rejected by secure update (REFUSED) Apr 12 16:22:45 cd1 named[848]: samba_dlz: cancelling transaction on zone 7.168.192.in-addr.arpa Apr 12 16:22:45 cd1 dhcpd: Unable to add reverse map from 39.7.168.192.in-addr.arpa. to xp2.cuba.co.cu: REFUSED no he logrado que la zona inversa se actualize usando el dhcp, solo actualiza la zona directa He ido modificando los permisos para probar pero nada Alguna idea?
Re: Samba_dlz, bind9, dhcp con la zona inversa error TSIG
El Tue, 05 Apr 2016 17:04:08 -0400, cosme escribió: > Después de haber compilado Samba-4.4.0 con con Bind9 todo funciona ok > > Aunque para el caso de la zona inversa el modulo de bind_dlz no lo > agrega automaticamente, se puede hacer de el entrono de las herramientas > para windows o con samba-tool. (...) > En mis log no me da ningun mensaje solo el de la zona directa Eso me da a entender que: 1/ O estás mirando en el registro incorrecto (revisa los de todos los jugadores: samba, dhcp y bind) 2/ O no está generado registros porque no lo está teniendo en cuenta (no está bien configurado, no actualiza la zona, se le ha dicho que no registre ese tipo de eventos...) (...) > Como vincular TSIG Samba4, bind9 y dhcp ??? En la wiki de Archlinux tienen un ejemplo de configuración, mira a ver si te vale: https://wiki.archlinux.org/index.php/Samba_4_Active_Directory_domain_controller#DHCP Saludos, -- Camaleón
Samba_dlz, bind9, dhcp con la zona inversa error TSIG
Después de haber compilado Samba-4.4.0 con con Bind9 todo funciona ok Aunque para el caso de la zona inversa el modulo de bind_dlz no lo agrega automaticamente, se puede hacer de el entrono de las herramientas para windows o con samba-tool. Agregué mi zona inversa con samba-tool dns zonecreate 0.99.10.in-addr.arpa De acuerdo a la wiki Integrando el DHCP con Samba_dlz y bind9 Las PC actualizan desde el DHCP con la zona directa sin problemas pero no para la zona inversa no, o sea que hay que hacerlo manual con samba-tool dns add 0.99.10.in-addr.arpa 55 PTR demo.samdom.example.com En mis log no me da ningun mensaje solo el de la zona directa Me imagino que debe ser problemas de una llave para la zona inversa pero como implementarlo para el dhcp?? Como vincular TSIG Samba4, bind9 y dhcp ??? Salu2
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
El Martes, 5 de abril de 2016 11:09:16 JAP escribió: Llego tarde a la conversación, así que no se de que va el resto. Solo un apunte: > > (Nota mental: averiguar cómo identificarme ante ZeroShell con un script > en el arranque en vez de un navegador, en forma similar a lo que hace > cntlm.sourceforge.net). > Supongo que será un 'portal cautivo' de esos; échale un vistazo a http://www.vicente-navarro.com/blog/2013/02/28/configurando-routers-domesticos-desde-la-linea-de-comandos-con-wget/ wget y un script en /etc/network/if-up.d/ te podría servir.
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
El Tue, 05 Apr 2016 12:01:53 -0300, JAP escribió: > El 05/04/16 a las 11:48, Camaleón escribió: >> El Tue, 05 Apr 2016 11:09:16 -0300, JAP escribió: > > >> De hecho NFS viene activado de manera predeterminada en Debian, yo >> pensé el desactivarlo porque no lo uso pero como da problemas, ahí >> está: >> >> > Como dije antes, prefiero eliminar un paquete a desactivarlo, pues si a > futuro instalo algo que lo necesite por dependencia, si está > desactivado, no genera mensaje de alerta al instalar y el nuevo paquete > no funciona al estar desactivado el servicio. > Prefiero que se cargue como dependencia y se reactive solo. Un paquete que se instale como dependencia no tiene por qué iniciarse automáticamente, tendrías que hacerlo manualmente por lo que estás en las mismas ;-) Saludos, -- Camaleón
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
El 05/04/16 a las 11:48, Camaleón escribió: El Tue, 05 Apr 2016 11:09:16 -0300, JAP escribió: De hecho NFS viene activado de manera predeterminada en Debian, yo pensé el desactivarlo porque no lo uso pero como da problemas, ahí está: Como dije antes, prefiero eliminar un paquete a desactivarlo, pues si a futuro instalo algo que lo necesite por dependencia, si está desactivado, no genera mensaje de alerta al instalar y el nuevo paquete no funciona al estar desactivado el servicio. Prefiero que se cargue como dependencia y se reactive solo. JAP
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
El Tue, 05 Apr 2016 11:09:16 -0300, JAP escribió: > avahi no tiene nada que ver con el problema. > Lo he reinstalado y no causa inconvenientes. Pues claro que no, es un buen tipo :-) > El que sí se bloquea al inicio del sistema, y por esa razón debí > eliminarlo, es nfs-common. Y repito que no era necesario, sólo con desactivarlo hubiera sido suficiente. > Lo raro, es que llevé la máquina a mi casa, la conecté directamente a > Internet, sin pasar por un contrafuegos ZeroSehll > (http://www.zeroshell.org/), y allí NFS no causa problemas. (...) De hecho NFS viene activado de manera predeterminada en Debian, yo pensé el desactivarlo porque no lo uso pero como da problemas, ahí está: root@stt008:~# service nfs-common status all daemons running Saludos, -- Camaleón
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
El 01/04/16 a las 11:40, JAP escribió: Por ahora, perecería que he dado con la solución, aunque no me gusta nada. En mi antiguo lugar de trabajo, quien administraba ese segmento de red, tenía la muy buena costumbre de asignar por DHCP a las máquinas la misma IP. Es decir, la terminal user25, siempre tenía la IP 10.3.20.132 Si bien el cliente usa DHCP dinámico, desde el servidor se mantenía esta política, la cual no la veo mal, pues facilita el funcionamiento a DNS. En el nuevo lugar de trabajo, distante unos 1.000 km del anterior, el administrador tiene una política distinta, y es que el DHCP es dinámico "en serio". Desde que estoy, nunca asigna dos veces la misma IP a la terminal. La computadora está tomando la dirección IP luego de haber: * limpiado algunas relaciones en el archivo /etc/hosts para identificación de alias. * eliminado avahi, que sinceramente, no me afectaba en lo más mínimo. Y cosa extraña: luego de eliminar avahi, el inicio del sistema se quedaba colgado con una línea que textualmente reproduzco: A start job is running for LSB: NFS support files common to client and server Dado que no tengo carpetas o archivos en la red que presten servicios NFS, eliminé el paquete, lo cual no me agradó, pero hube de hacerlo. Seguiré dando vueltas con el tema, pues si bien "funciona", me da tirria el no saber por qué las cosas no son como debería ser. Amén que no tengo muy en claro de para qué sirve, cómo se usa y qué utilidad tiene avahi. Gracias a todos. JAP avahi no tiene nada que ver con el problema. Lo he reinstalado y no causa inconvenientes. El que sí se bloquea al inicio del sistema, y por esa razón debí eliminarlo, es nfs-common. Lo raro, es que llevé la máquina a mi casa, la conecté directamente a Internet, sin pasar por un contrafuegos ZeroSehll (http://www.zeroshell.org/), y allí NFS no causa problemas. (Nota mental: averiguar cómo identificarme ante ZeroShell con un script en el arranque en vez de un navegador, en forma similar a lo que hace cntlm.sourceforge.net). Sigo investigando / aprendiendo. Saludos JAP
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
El Fri, 01 Apr 2016 12:10:56 -0300, JAP escribió: > El 01/04/16 a las 12:05, Camaleón escribió: > > >> Con desactivar el servicio NFS hubiera sido suficiente. > > "...in six months you will install the automagical printer config tool > and wonder why it isn't workingyou will file a bug and get jumped > because nobody can reproduce it.you will end up reinstalling and > everything will 'just work' then.all because you forgot that six > months ago you disabled avahi-daemon instead of uninstalling it > > the crystal ball never lies!" (...) Yo no he dicho que desactives avahi sino NFS ;-) De hecho, ni siquiera lo tengo instalado (¡gracias XFCE!): ii libavahi-client3:amd640.6.31-2 amd64Avahi client library ii libavahi-common-data:amd640.6.31-2 amd64Avahi common data files ii libavahi-common3:amd640.6.31-2 amd64Avahi common library ii libavahi-glib1:amd64 0.6.31-2 amd64Avahi GLib integration library Y no, tampoco lo eliminaría, al menos en gnome: root@stt008:~# apt-cache rdepends avahi-daemon avahi-daemon Reverse Depends: telepathy-salut task-desktop sugar-presence-service-0.90 sugar-presence-service-0.88 sugar-presence-service-0.84 sane-utils libsane rhythmbox pulseaudio-utils pulseaudio-module-zeroconf libnss-mdns lib32nss-mdns netatalk mpd libmono-zeroconf1.0-cil libapache2-mod-dnssd gnome mandos gshare gobby-0.5 gobby-0.4 gajim forked-daapd education-desktop-sugar education-desktop-other ltsp-controlaula controlaula banshee avahi-utils avahi-dnsconfd avahi-discover 4store hplip gajim cups Saludos, -- Camaleón
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
El 01/04/16 a las 12:05, Camaleón escribió: Con desactivar el servicio NFS hubiera sido suficiente. "...in six months you will install the automagical printer config tool and wonder why it isn't workingyou will file a bug and get jumped because nobody can reproduce it.you will end up reinstalling and everything will 'just work' then.all because you forgot that six months ago you disabled avahi-daemon instead of uninstalling it the crystal ball never lies!" Seguiré dando vueltas con el tema, pues si bien "funciona", me da tirria el no saber por qué las cosas no son como debería ser. Amén que no tengo muy en claro de para qué sirve, cómo se usa y qué utilidad tiene avahi. Revisa los registros para ver qué es lo que hace el cliente (y qué respuesta recibe del servidor) cuando pide una IP, si no sabes qué sucede no podrás averiguar el origen del problema. Es lo que pienso hacer. Abrazos miles. JAP
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
El Fri, 01 Apr 2016 11:40:02 -0300, JAP escribió: > Por ahora, perecería que he dado con la solución, aunque no me gusta > nada. (...) > La computadora está tomando la dirección IP luego de haber: > * limpiado algunas relaciones en el archivo /etc/hosts para > identificación de alias. > * eliminado avahi, que sinceramente, no me afectaba en lo más mínimo. > > Y cosa extraña: luego de eliminar avahi, el inicio del sistema se > quedaba colgado con una línea que textualmente reproduzco: > > A start job is running for LSB: NFS support files common to client and > server > > Dado que no tengo carpetas o archivos en la red que presten servicios > NFS, eliminé el paquete, lo cual no me agradó, pero hube de hacerlo. Con desactivar el servicio NFS hubiera sido suficiente. > Seguiré dando vueltas con el tema, pues si bien "funciona", me da tirria > el no saber por qué las cosas no son como debería ser. Amén que no tengo > muy en claro de para qué sirve, cómo se usa y qué utilidad tiene avahi. Revisa los registros para ver qué es lo que hace el cliente (y qué respuesta recibe del servidor) cuando pide una IP, si no sabes qué sucede no podrás averiguar el origen del problema. Avahi (zeroconf) es una aplicación de autoconfiguración del servicio de red para cuando nadie lo reclama o configura. Viene a ser como el botoncito mágico de los puntos de acceso wifi que se configuran solos (WPS), es decir, un dolor de muelas. En resumen: no verás avahi en servidores pero sí en portátiles o equipos de escritorio porque los entornos gráficos (kde, gnome...) lo suelen necesitar para sus "tontunas" (streaming, multicast, upnp...). Saludos, -- Camaleón
Re: Problemas con DHCP corporativo [¿SOLUCIONADO?]
Por ahora, perecería que he dado con la solución, aunque no me gusta nada. En mi antiguo lugar de trabajo, quien administraba ese segmento de red, tenía la muy buena costumbre de asignar por DHCP a las máquinas la misma IP. Es decir, la terminal user25, siempre tenía la IP 10.3.20.132 Si bien el cliente usa DHCP dinámico, desde el servidor se mantenía esta política, la cual no la veo mal, pues facilita el funcionamiento a DNS. En el nuevo lugar de trabajo, distante unos 1.000 km del anterior, el administrador tiene una política distinta, y es que el DHCP es dinámico "en serio". Desde que estoy, nunca asigna dos veces la misma IP a la terminal. La computadora está tomando la dirección IP luego de haber: * limpiado algunas relaciones en el archivo /etc/hosts para identificación de alias. * eliminado avahi, que sinceramente, no me afectaba en lo más mínimo. Y cosa extraña: luego de eliminar avahi, el inicio del sistema se quedaba colgado con una línea que textualmente reproduzco: A start job is running for LSB: NFS support files common to client and server Dado que no tengo carpetas o archivos en la red que presten servicios NFS, eliminé el paquete, lo cual no me agradó, pero hube de hacerlo. Seguiré dando vueltas con el tema, pues si bien "funciona", me da tirria el no saber por qué las cosas no son como debería ser. Amén que no tengo muy en claro de para qué sirve, cómo se usa y qué utilidad tiene avahi. Gracias a todos. JAP
Re: Problemas con DHCP corporativo [SOLUCIONADO]
El 17/03/16 a las 12:59, Camaleón escribió: El Thu, 17 Mar 2016 12:31:26 -0300, JAP escribió: Tengo un equipo con Debian "jessie" desde hace dos años, que ha corrido sin inconvenientes en la red corporativa, con las configuraciones que más abajo detallo. Hace un mes cambié de lugar físico, pero mantengo computadora. Ya he cambiado el cable que me une hasta el "switch", funciona perfectamente. Si conecto mi máquina con "jessie", es IMPOSIBLE obtener dirección IP. Si conecto una máquina con WinXP/7 al cable, obtiene dirección IP sin inconvenientes. Si de mi máquina con"jessie", QUE NO TIENE IP, inicio un VirtualBox con WinXP, obtiene IP sin inconvenientes. Es imposible iniciar la red en forma manual con "ifup". Con "ifconfig", A VECES, NO SIEMPRE, sí se inicia. Cuando uno usa la MISMA máquina durante varios años en distintos lugares, pasan estas estupideces. En mi lugar de trabajo anterior, por alguna razón que no recuerdo, configuré de la siguiente manera el archivo ### ### /etc/hosts 127.0.0.1 localhost 10.3.1.178 station37.red.corporativa station37 # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ### La línea 10.116.1.178 station37.red.corporativa station37 es la que estaba causando TODO el problema. "station37" es el nombre de host de mi máquina, definido en /etc/hostname Al cambiar de lugar de trabajo, si bien la red es la misma, cambió el segmento de red al trabajar sobre otro "switch", y la interfaz eh0 no podía configurarse sola. Gracias a todos. JAP
Re: Problemas con DHCP corporativo
El 17/03/16 a las 12:59, Camaleón escribió: Lo que veo es que eth0 (10.115.x.x ¿?) no recibe datos del servidor DHCP (10.116.x.x ¿?) por lo que lo primero que tendrías que comprobar es si configurando manualmente la interfaz eth0 en el mismo segmento de red en el que está el servidor DHCP es capaz de comunicarse con él (ping) y obtener la información que necesita para configurar dinámicamente el adaptador eth0, así descartas cualquier problema físico (de hardware, como cableado, separación física de redes, boca de switch, etc...). Si esto funciona y eth0 se inicia sin errores, el problema podría estar en la configuración de las rutas por lo que tendrías que ir revisando una a una todas las que vas cargando, en lugar de añadirlas de golpe. ¿Están todos los equipos que entran en juego (servidor DHCP, switches y equipos clientes) físicamente en la misma red? Saludos, A mí también me llamó la atención las diferencias de segmentos, pero como ves, las máquinas con windows levantan con esa configuración. Y sí, todo los equipos están conectados. El ruteo, no lo puedo tocar hasta tanto no levanta la IP. Ya he intentado con configuraciones más reducidas de las interfaces, y hasta he invertido los cables de placa. El tema es la resolución de IP en esa red, no importa cómo esté configurado ni dónde esté conectado. Seguí dando vueltas, y hace media hora desactivé y eliminé Avahi. El sistema levantó ambas redes. Lo dejaré así hasta mañana, y veré si fue un golpe de suerte o se solucionó. Otra cosa que haré, es traerme una netbook que también corre jessie, e intentar con dicha maquinita. JAP
Problemas con DHCP corporativo
Estimados: Mi red corporativa me tiene cansado. Paso a explicarme: Tengo un equipo con Debian "jessie" desde hace dos años, que ha corrido sin inconvenientes en la red corporativa, con las configuraciones que más abajo detallo. Hace un mes cambié de lugar físico, pero mantengo computadora. Ya he cambiado el cable que me une hasta el "switch", funciona perfectamente. Si conecto mi máquina con "jessie", es IMPOSIBLE obtener dirección IP. Si conecto una máquina con WinXP/7 al cable, obtiene dirección IP sin inconvenientes. Si de mi máquina con"jessie", QUE NO TIENE IP, inicio un VirtualBox con WinXP, obtiene IP sin inconvenientes. Es imposible iniciar la red en forma manual con "ifup". Con "ifconfig", A VECES, NO SIEMPRE, sí se inicia. Reinstalé todos los paquetes relativos a dhcp-client. He "tocado" el archivo /etc/dhcp/dhclient.conf, adicionándole la línea send vendor-class-identifier "MSFT 5.0"; que en algún foro lo ví como una manera de reportarse a los equipos como una terminal "Microsoft", y ha solucionado algún problema similar. Fracasé con todo éxito. ¿Cuál es el problema? Que tengo dos redes en la máquina, y luego del inicio del servicio de "networking", /etc/network/interfaces mediante, debo utilizar una serie de parámetros de ruteo para evitar colisiones. Ruteo que SIEMPRE funcionó sin inconvenientes, hasta que me cambié de escritorio (físico, el de madera, se entiende). Como no obtiene dirección IP para eth0, no se rutea como debe, y debo hacero "a mano" luego de iniciado el sistema, si es que he logrado obtener dirección IP. ¿Mi miedo 1? System-d / systemctl ¿Mi miedo 2? Que la "ferretería" (switch, routers, etc.), tengan "algo" Windows-dependiente. Escucho opiniones. Desde ya, muchas gracias. JAP # ### Configuración de redes # /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # Intranet auto eth0 allow-hotplug eth0 iface eth0 inet dhcp dns-nameserver 10.115.1.201 # Internet auto eth1 allow-hotplug eth1 iface eth1 inet dhcp dns-nameserver 190.103.220.2 dns-nameserver 8.8.8.8 # Enrutamiento post-up ip route change default via 192.168.2.1 dev eth1 post-up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.116.1.254 dev eth0 # Enrutamiento post-up route add -host 10.96.1.205 gw 10.116.1.254 dev eth0 post-up route add -host 10.1.0.231 gw 10.116.1.254 dev eth0 post-up route add -host 10.1.12.201 gw 10.116.1.254 dev eth0 post-up route add -host 10.1.0.202 gw 10.116.1.254 dev eth0 post-up route add -host 10.1.0.216 gw 10.116.1.254 dev eth0 post-up route add -host 10.1.0.211 gw 10.116.1.254 dev eth0 post-up route add -host 10.1.0.215 gw 10.116.1.254 dev eth0 post-up route add -host 10.1.0.224 gw 10.116.1.254 dev eth0 post-up route add -host 10.3.10.118 gw 10.116.1.254 dev eth0 # ### Reporte estado de redes # ifconfig eth0 Link encap:Ethernet HWaddr d0:50:99:21:90:8f inet6 addr: fe80::d250:99ff:fe21:908f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:387 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:32603 (31.8 KiB) TX bytes:3036 (2.9 KiB) eth1 Link encap:Ethernet HWaddr a0:f3:c1:01:da:92 inet addr:192.168.2.52 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::a2f3:c1ff:fe01:da92/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9124 errors:0 dropped:0 overruns:0 frame:0 TX packets:7180 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2566359 (2.4 MiB) TX bytes:848589 (828.7 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:857 errors:0 dropped:0 overruns:0 frame:0 TX packets:857 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:90841 (88.7 KiB) TX bytes:90841 (88.7 KiB) # ### Ruteo luego de un arranque de sistema o /etc/init.d/networking start ### Se ve que por no levantar eth0, no rutea como debe # route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default 192.168
Re: Problemas con DHCP corporativo
El Thu, 17 Mar 2016 12:31:26 -0300, JAP escribió: > Tengo un equipo con Debian "jessie" desde hace dos años, que ha corrido > sin inconvenientes en la red corporativa, con las configuraciones que > más abajo detallo. > Hace un mes cambié de lugar físico, pero mantengo computadora. > Ya he cambiado el cable que me une hasta el "switch", funciona > perfectamente. > Si conecto mi máquina con "jessie", es IMPOSIBLE obtener dirección IP. > Si conecto una máquina con WinXP/7 al cable, obtiene dirección IP sin > inconvenientes. > Si de mi máquina con"jessie", QUE NO TIENE IP, inicio un VirtualBox con > WinXP, obtiene IP sin inconvenientes. > Es imposible iniciar la red en forma manual con "ifup". > Con "ifconfig", A VECES, NO SIEMPRE, sí se inicia. (...) Lo que veo es que eth0 (10.115.x.x ¿?) no recibe datos del servidor DHCP (10.116.x.x ¿?) por lo que lo primero que tendrías que comprobar es si configurando manualmente la interfaz eth0 en el mismo segmento de red en el que está el servidor DHCP es capaz de comunicarse con él (ping) y obtener la información que necesita para configurar dinámicamente el adaptador eth0, así descartas cualquier problema físico (de hardware, como cableado, separación física de redes, boca de switch, etc...). Si esto funciona y eth0 se inicia sin errores, el problema podría estar en la configuración de las rutas por lo que tendrías que ir revisando una a una todas las que vas cargando, en lugar de añadirlas de golpe. ¿Están todos los equipos que entran en juego (servidor DHCP, switches y equipos clientes) físicamente en la misma red? Saludos, -- Camaleón
Re: Problemas con DHCP corporativo
El 17/03/16 a las 12:59, Camaleón escribió: Lo que veo es que eth0 (10.115.x.x ¿?) no recibe datos del servidor DHCP (10.116.x.x ¿?) por lo que lo primero que tendrías que comprobar es si configurando manualmente la interfaz eth0 en el mismo segmento de red en el que está el servidor DHCP es capaz de comunicarse con él (ping) y obtener la información que necesita para configurar dinámicamente el adaptador eth0, así descartas cualquier problema físico (de hardware, como cableado, separación física de redes, boca de switch, etc...). Si esto funciona y eth0 se inicia sin errores, el problema podría estar en la configuración de las rutas por lo que tendrías que ir revisando una a una todas las que vas cargando, en lugar de añadirlas de golpe. ¿Están todos los equipos que entran en juego (servidor DHCP, switches y equipos clientes) físicamente en la misma red? Saludos, A mí también me llamó la atención las diferencias de segmentos, pero como ves, las máquinas con windows levantan con esa configuración. Y sí, todo los equipos están conectados. El ruteo, no lo puedo tocar hasta tanto no levanta la IP. Ya he intentado con configuraciones más reducidas de las interfaces, y hasta he invertido los cables de placa. El tema es la resolución de IP en esa red, no importa cómo esté configurado ni dónde esté conectado. Seguí dando vueltas, y hace media hora desactivé y eliminé Avahi. El sistema levantó ambas redes. Lo dejaré así hasta mañana, y veré si fue un golpe de suerte o se solucionó. Otra cosa que haré, es traerme una netbook que también corre jessie, e intentar con dicha maquinita. JAP
OT: Configura DHCP, NFS y VSFTPD en Debian
Buen dia, Gente, complementando el video curso básico y medio de Debian, continuamos con unos servicios de red. DHCP: https://www.youtube.com/playlist?list=PLyLcPK3h0D7DZVICmZZWECc6L0-9nrGxg NFS: https://www.youtube.com/playlist?list=PLyLcPK3h0D7CsHi4Bx4eRZgCufM48ntqo VSFTPD: https://www.youtube.com/playlist?list=PLyLcPK3h0D7B8oZNt9GXpgfT3gZaxc1am Agradezco la retroalimentación que me puedan brindar. FRANK HARBEY SANABRIA FLOREZTecnologo en Telecomunicaciones y Sistemas Bogota - Colombia@franksanabria sugeek.co
OT: Configurar DHCP en Debian
Buen dia, Les comparto un video curso como configurar DHCP en Debían, es algo Básico. https://www.youtube.com/playlist?list=PLyLcPK3h0D7DZVICmZZWECc6L0-9nrGxg FRANK HARBEY SANABRIA FLOREZTecnologo en Telecomunicaciones y Sistemas Bogota - Colombia@franksanabria sugeek.co
Re: Saber cuantas PC están conectadas al DHCP
El Mon, 13 Apr 2015 14:16:36 -0430, Nicolas escribió: > Buenas, (ese html...) > > He estado investigando como saber cuantas PC están conectadas a mi > servidor de DHCP y no conseguí nada (sera porque busque español, soy > malo con el ingles :) ) https://www.google.es/webhp?complete=0&hl=en&gws_rd=cr,ssl&ei=GBotVcusCsSXsAHwxoA4#complete=0&hl=en&q=dhcp+active+leases > Como no consegui nada en concreto probe con: > > wc -w dhcpd.leases | grep -i 'lease' > > y me origino un resultado que no confio en el Prueba con: grep -B 4 -i active /var/lib/dchp/dhcpd.leases > Por ende me gustaría que me orientaran en saber cual es el comando o el > paquete a instalar para saber este dato. Algún comandito habrá para hacerlo (dhcpd-pools, dhcpstatus...) pero no sé hasta que punto merece la pena instalar una herramienta dedicada para ver estos datos. Si usas webmin o algún sistema similar seguramente te diga las direcciones asignadas. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.04.14.13.55...@gmail.com
RE: Saber cuantas PC están conectadas al DHCP
Para saber las activas, (actualmente conectadas) usa netstat con filtros por el puerto. El que usaste es el comando que te indica las reservas actuales. FRANK HARBEY SANABRIA FLOREZTecnologo en Telecomunicaciones y Sistemas Bogota - Colombia@franksanabria sugeek.co Date: Mon, 13 Apr 2015 14:16:36 -0430 Subject: Saber cuantas PC están conectadas al DHCP From: niko...@gmail.com To: debian-user-spanish@lists.debian.org Buenas, He estado investigando como saber cuantas PC están conectadas a mi servidor de DHCP y no conseguí nada (sera porque busque español, soy malo con el ingles :) ) Como no consegui nada en concreto probe con: wc -w dhcpd.leases | grep -i 'lease' y me origino un resultado que no confio en el Por ende me gustaría que me orientaran en saber cual es el comando o el paquete a instalar para saber este dato. P.D. No se si con awk se pueda ver esto, aunque no soy muy hábil con este comando, solo algunas cosas basicas. Gracias, Nicolás Disquin
Saber cuantas PC están conectadas al DHCP
Buenas, He estado investigando como saber cuantas PC están conectadas a mi servidor de DHCP y no conseguí nada (sera porque busque español, soy malo con el ingles :) ) Como no consegui nada en concreto probe con: wc -w dhcpd.leases | grep -i 'lease' y me origino un resultado que no confio en el Por ende me gustaría que me orientaran en saber cual es el comando o el paquete a instalar para saber este dato. P.D. No se si con awk se pueda ver esto, aunque no soy muy hábil con este comando, solo algunas cosas basicas. Gracias, Nicolás Disquin
Re: Esto esun bug del servidor DHCP, ¿no?
El lunes, 13 abr 2015, a las 18:03 UTC+2 horas, José Miguel (sio2) escribió: >El Mon, 13 de Apr de 2015, a las 01:19:27PM +, Camaleón dijo: > >> Podría ser, pero en la versión anterior de dhcpd (la que lleva Wheezy) no >> sucede lo mismo, es decir, que ante un mismo evento generado de la misma >> manera (cambio forzoso de la MAC) el servidor DHCP lo interpreta de otra >> forma, habría que preguntarse por qué. > >En realidad el fallo no tiene nada que ver con el cambio de MAC (de >hecho, el comportamiento es el correcto: se envía un paquete DHCPNACK). >Lo hice así, simplemente, para ahorrarme arrancar otra máquina virtual. >Aunque también podría haberle borrado la memoria a dhclient para que no >sugiriera nada. Si la segunda máquina no sugiere ip, también se produce >el fallo: porque éste se debe únicamente a que se agota el máximo de ips >que se pueden conceder a la clase (puesto con lease limit). Parece un >fallo bastante gordo. Lo que no he probado es qué ocurre si la falta de >disponibilidad se debe a la otra posibilidad más habitual: que se agoten >las ips porque ya no queden más en el rango que se le asignó a la clase. >Creo que hace cosa de un mes estuve haciendo pruebas, se me produjo esta >última circunstancia y no ocurrió nada raro. De todos modos, no lo puedo >asegurar y, además, de entonces ahora ha podido cambiar el paquete. Dando por hecho que el fichero de configuración es correcto: Que se agoten las IP no justifica nada, el servidor debe manejar esa situación también. Y coincido contigo en que es un fallo gordo. Si eres capaz de tumbar un servidor con una petición, has encontrado una forma de ataque de denegación de servicio, por más inusual que esta sea. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150413182556.5e2f6...@gmail.com
Re: Esto esun bug del servidor DHCP, ¿no?
El Mon, 13 Apr 2015 18:03:12 +0200, José Miguel (sio2) escribió: > El Mon, 13 de Apr de 2015, a las 01:19:27PM +, Camaleón dijo: > >> Podría ser, pero en la versión anterior de dhcpd (la que lleva Wheezy) >> no sucede lo mismo, es decir, que ante un mismo evento generado de la >> misma manera (cambio forzoso de la MAC) el servidor DHCP lo interpreta >> de otra forma, habría que preguntarse por qué. > > En realidad el fallo no tiene nada que ver con el cambio de MAC (de > hecho, el comportamiento es el correcto: se envía un paquete DHCPNACK). > Lo hice así, simplemente, para ahorrarme arrancar otra máquina virtual. (...) Está claro, pero la pregunta sigue siendo la misma ¿por qué ante un mismo evento las dos versiones de DHCP responden de distinta manera? Lo lógico es que ambas interpretaran el mismo evento de la misma manera aunque una funcione correctamente (la de Wheezy) y la otra (Jessie/Sid) genere un fallo de segmentación. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.04.13.16.10...@gmail.com
Re: Esto esun bug del servidor DHCP, ¿no?
El Mon, 13 de Apr de 2015, a las 01:19:27PM +, Camaleón dijo: > Podría ser, pero en la versión anterior de dhcpd (la que lleva Wheezy) no > sucede lo mismo, es decir, que ante un mismo evento generado de la misma > manera (cambio forzoso de la MAC) el servidor DHCP lo interpreta de otra > forma, habría que preguntarse por qué. En realidad el fallo no tiene nada que ver con el cambio de MAC (de hecho, el comportamiento es el correcto: se envía un paquete DHCPNACK). Lo hice así, simplemente, para ahorrarme arrancar otra máquina virtual. Aunque también podría haberle borrado la memoria a dhclient para que no sugiriera nada. Si la segunda máquina no sugiere ip, también se produce el fallo: porque éste se debe únicamente a que se agota el máximo de ips que se pueden conceder a la clase (puesto con lease limit). Parece un fallo bastante gordo. Lo que no he probado es qué ocurre si la falta de disponibilidad se debe a la otra posibilidad más habitual: que se agoten las ips porque ya no queden más en el rango que se le asignó a la clase. Creo que hace cosa de un mes estuve haciendo pruebas, se me produjo esta última circunstancia y no ocurrió nada raro. De todos modos, no lo puedo asegurar y, además, de entonces ahora ha podido cambiar el paquete. Un saludo. -- ¿No ha de haber un espíritu valiente? ¿Siempre se ha de sentir lo que se dice? ¿Nunca se ha de decir lo que se siente? --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150413160312.ga3...@cubo.casa
Re: Esto esun bug del servidor DHCP, ¿no?
El Sun, 12 Apr 2015 20:12:46 +0200, José Miguel (sio2) escribió: > El Sun, 12 de Apr de 2015, a las 03:41:14PM +, Camaleón dijo: > > >> Lo que me escama es el mensaje, dice que no le puede asignar una IP >> determinada (192.168.255.105) no que no sea posible asignarle una >> cualquiera :-? > > Es normal por cómo hice la prueba: usando dos veces el mismo cliente, > pero cambiándole entre una y otra petición la MAC. (...) Podría ser, pero en la versión anterior de dhcpd (la que lleva Wheezy) no sucede lo mismo, es decir, que ante un mismo evento generado de la misma manera (cambio forzoso de la MAC) el servidor DHCP lo interpreta de otra forma, habría que preguntarse por qué. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.04.13.13.19...@gmail.com
Re: Esto esun bug del servidor DHCP, ¿no?
El Sun, 12 de Apr de 2015, a las 01:49:35PM -0500, Frank Harbey Sanabria Florez
dijo:
> El server se cuelga?,
Se muere. El proceso deja de existir.
> verificaste que la MAC que duplicaste sea una
> MAC "Original" (Establecida por la IEEE)?, la configuracion de
> Seguridad ante suplantaciones del DHCP esta habilitada?
No, no lo he verificado, pero no creo que tenga mucha importancia,
porque hice varias pruebas y la misma MAC con la que casca el servidor
en la segunda petición en algunas de las pruebas, la usé como MAC en la
primera petición y el servidor le sirvió ip sin problemas.
Las MAC que me inventaba eran 00:11:22:33:44:5X. Siempre uso esas para
pruebas y nunca tengo problemas.
Además, en wheezy funciona perfectamente.
> Como tienes la configuracion en el dhcpd.conf y en el defaults?,
En /etc/default/isc-dhcp-server no cambié nada y la configuración de
dhcpd.conf la escribí en el mensaje con que abrí el hilo. Hay
efectivamente un error del que luego me di cuenta, pero que no afecta:
subnet 192.168.255.0 netmask 255.255.255.0 {
^^^
[...]
option broadcast-address 192.168.1.255;
^
}
De hecho, lo modifiqué y siguió dando los problemas.
--
Hay dos sistemas de conseguir la felicidad: uno, hacerse
el idiota; otro, serlo.
--- Enrique Jardiel Poncela. --
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150412201640.ga17...@cubo.casa
RE: Esto esun bug del servidor DHCP, ¿no?
El server se cuelga?, verificaste que la MAC que duplicaste sea una MAC "Original" (Establecida por la IEEE)?, la configuracion de Seguridad ante suplantaciones del DHCP esta habilitada? Como tienes la configuracion en el dhcpd.conf y en el defaults?, ese error creo que es mas por una mala configuración del DHCP que del mismo ISC. FRANK HARBEY SANABRIA FLOREZTecnologo en Telecomunicaciones y Sistemas Bogota - Colombia@franksanabria sugeek.co > Date: Sun, 12 Apr 2015 20:12:46 +0200 > From: sio2.sio2+lista.deb...@gmail.com > To: debian-user-spanish@lists.debian.org > Subject: Re: Esto esun bug del servidor DHCP, ¿no? > > El Sun, 12 de Apr de 2015, a las 03:41:14PM +, Camaleón dijo: > > > > Lo que me escama es el mensaje, dice que no le puede asignar una IP > > determinada (192.168.255.105) no que no sea posible asignarle una > > cualquiera :-? > > Es normal por cómo hice la prueba: usando dos veces el mismo cliente, > pero cambiándole entre una y otra petición la MAC. En esta > circunstancias, la segunda vez el cliente sugiere al servidor que le > entregue la última ip que tenía, o sea, la que recibió la primera vez. > Como está ocupada (porque no se liberó), el servidor rechaza esa > sugerencia (DCHPNACK) y se dispone a darle otra. Es entonces cuando > actúa el "lease limit 1", pero en vez de no entregar ninguna, porque ya > no hay disponibles, casca. > > > De todas formas, mira a ver si sigue en ejecución tras el "segfault". > > El servidor muere definitivamente, no es que se quede tonto. > > Ya he enviado el informe de fallo. > > > -- >Parezco en mi fortuna al Manzanares, > que con agua o sin ella siempre es río. > --- Tomé de Burguillos --- > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/20150412181246.ga12...@cubo.casa >
Re: Esto esun bug del servidor DHCP, ¿no?
El Sun, 12 de Apr de 2015, a las 03:41:14PM +, Camaleón dijo: > Lo que me escama es el mensaje, dice que no le puede asignar una IP > determinada (192.168.255.105) no que no sea posible asignarle una > cualquiera :-? Es normal por cómo hice la prueba: usando dos veces el mismo cliente, pero cambiándole entre una y otra petición la MAC. En esta circunstancias, la segunda vez el cliente sugiere al servidor que le entregue la última ip que tenía, o sea, la que recibió la primera vez. Como está ocupada (porque no se liberó), el servidor rechaza esa sugerencia (DCHPNACK) y se dispone a darle otra. Es entonces cuando actúa el "lease limit 1", pero en vez de no entregar ninguna, porque ya no hay disponibles, casca. > De todas formas, mira a ver si sigue en ejecución tras el "segfault". El servidor muere definitivamente, no es que se quede tonto. Ya he enviado el informe de fallo. -- Parezco en mi fortuna al Manzanares, que con agua o sin ella siempre es río. --- Tomé de Burguillos --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150412181246.ga12...@cubo.casa
Re: Esto esun bug del servidor DHCP, ¿no?
El Sat, 11 Apr 2015 22:26:56 +0200, José Miguel (sio2) escribió: > Un saludo a la lista: > > Tengo una configuración de prueba muy sencilla en el servidor ISC de > jessie: (...) > O sea que hay una clase de máquinas que como máximo recibirán una ip. > Con esto he tomado un cliente y le he hecho que pida ip: (...) > Como es de esperar, ha recibido su ip. A continuación he cogido ese > mismo cliente, lo he desconfigurado sin que se enterara el servidor > (dhclient -x), le he cambiado la MAC y he vuelto a pedir ip. Se supone > que es la segunda ip y que el cliente no debería recibir ninguna. Lo que > ocurre es esto: > > #v+ > Apr 11 22:10:56 zipi dhcpd: DHCPREQUEST for 192.168.255.105 from > 00:11:22:33:44:51 via eth1: lease 192.168.255.105 unavailable. > Apr 11 22:10:56 zipi dhcpd: DHCPNAK on 192.168.255.105 to 00:11:22:33:44:51 > via eth1 > Apr 11 22:10:56 zipi kernel: [ 588.513633] dhcpd[1253]: segfault at 30 ip > 7f2548edd333 sp 7ffc2f270110 error 4 in dhcpd[7f2548ec6000+b3000] > #v- Lo que me escama es el mensaje, dice que no le puede asignar una IP determinada (192.168.255.105) no que no sea posible asignarle una cualquiera :-? > El servidor parece como que le intentara dar la misma ip, aunque la > máquina es "otra" y la ip sigue ocupada, después casca. Exacto, parece que el servidor dhcp está interpretando otra situación pero en cualquier caso debe registrar el error sin llegar al fallo de segmentación. De todas formas, mira a ver si sigue en ejecución tras el "segfault". Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2015.04.12.15.41...@gmail.com
Re: Esto esun bug del servidor DHCP, ¿no?
El Sat, 11 de Apr de 2015, a las 10:39:16PM +0200, Manolo Díaz dijo: > Eso parece, que es un fallo en toda regla. No sé qué debería haber hecho > el servidor DHCP, pero desde luego cascar no. He hecho la misma prueba con wheezy y la configuración funciona perfectamente: #v+ DHCPDISCOVER from 00:11:22:33:44:55 via eth1: no available billing: lease limit reached in all matching classes #v- El cliente se queda sin ip y el servidor sigue funcionando. Voy a ver cómo se envía un informe de fallo. Gracias. -- -¿Quién le dice a v.m. que no se pueda hacer? Hacerse puede, que ser imposible es otra cosa. --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150411213704.ga20...@cubo.casa
Re: Esto esun bug del servidor DHCP, ¿no?
El sábado, 11 abr 2015, a las 22:26 UTC+2 horas,
José Miguel (sio2) escribió:
>Un saludo a la lista:
>
>Tengo una configuración de prueba muy sencilla en el servidor ISC de
>jessie:
>
>#v+
>ddns-update-style none;
>default-lease-time 18000;
>max-lease-time 18000;
>
>class "foo" {
> match if 1 = 1;
> lease limit 1;
>}
>
>subnet 192.168.255.0 netmask 255.255.255.0 {
> option domain-name-servers 192.168.255.1;
> option domain-name "smr1.iescdl.es";
> option routers 192.168.255.1;
> option broadcast-address 192.168.1.255;
> range 192.168.255.100 192.168.255.150;
>}
>#v-
>
>O sea que hay una clase de máquinas que como máximo recibirán una ip.
>Con esto he tomado un cliente y le he hecho que pida ip:
>
>#v+
>Apr 11 22:08:25 zipi dhcpd: DHCPREQUEST for 192.168.255.105 from
>00:11:22:33:44:50 via eth1
>Apr 11 22:08:25 zipi dhcpd: DHCPACK on 192.168.255.105 to 00:11:22:33:44:50
>(perico) via eth1
>#v-
>
>Como es de esperar, ha recibido su ip. A continuación he cogido ese
>mismo cliente, lo he desconfigurado sin que se enterara el servidor
>(dhclient -x), le he cambiado la MAC y he vuelto a pedir ip. Se supone
>que es la segunda ip y que el cliente no debería recibir ninguna. Lo que
>ocurre es esto:
>
>#v+
>Apr 11 22:10:56 zipi dhcpd: DHCPREQUEST for 192.168.255.105 from
>00:11:22:33:44:51 via eth1: lease 192.168.255.105 unavailable.
>Apr 11 22:10:56 zipi dhcpd: DHCPNAK on 192.168.255.105 to 00:11:22:33:44:51
>via eth1
>Apr 11 22:10:56 zipi kernel: [ 588.513633] dhcpd[1253]: segfault at 30 ip
>7f2548edd333 sp 7ffc2f270110 error 4 in dhcpd[7f2548ec6000+b3000]
>#v-
>
>El servidor parece como que le intentara dar la misma ip, aunque la
>máquina es "otra" y la ip sigue ocupada, después casca.
>
>Gracias de antemano.
>
Eso parece, que es un fallo en toda regla. No sé qué debería haber hecho
el servidor DHCP, pero desde luego cascar no.
Saludos.
--
Manolo Díaz
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150411223916.5a30d...@gmail.com
Esto esun bug del servidor DHCP, ¿no?
Un saludo a la lista:
Tengo una configuración de prueba muy sencilla en el servidor ISC de
jessie:
#v+
ddns-update-style none;
default-lease-time 18000;
max-lease-time 18000;
class "foo" {
match if 1 = 1;
lease limit 1;
}
subnet 192.168.255.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.255.1;
option domain-name "smr1.iescdl.es";
option routers 192.168.255.1;
option broadcast-address 192.168.1.255;
range 192.168.255.100 192.168.255.150;
}
#v-
O sea que hay una clase de máquinas que como máximo recibirán una ip.
Con esto he tomado un cliente y le he hecho que pida ip:
#v+
Apr 11 22:08:25 zipi dhcpd: DHCPREQUEST for 192.168.255.105 from
00:11:22:33:44:50 via eth1
Apr 11 22:08:25 zipi dhcpd: DHCPACK on 192.168.255.105 to 00:11:22:33:44:50
(perico) via eth1
#v-
Como es de esperar, ha recibido su ip. A continuación he cogido ese
mismo cliente, lo he desconfigurado sin que se enterara el servidor
(dhclient -x), le he cambiado la MAC y he vuelto a pedir ip. Se supone
que es la segunda ip y que el cliente no debería recibir ninguna. Lo que
ocurre es esto:
#v+
Apr 11 22:10:56 zipi dhcpd: DHCPREQUEST for 192.168.255.105 from
00:11:22:33:44:51 via eth1: lease 192.168.255.105 unavailable.
Apr 11 22:10:56 zipi dhcpd: DHCPNAK on 192.168.255.105 to 00:11:22:33:44:51 via
eth1
Apr 11 22:10:56 zipi kernel: [ 588.513633] dhcpd[1253]: segfault at 30 ip
7f2548edd333 sp 7ffc2f270110 error 4 in dhcpd[7f2548ec6000+b3000]
#v-
El servidor parece como que le intentara dar la misma ip, aunque la
máquina es "otra" y la ip sigue ocupada, después casca.
Gracias de antemano.
--
a ch'in amor s'invecchia, oltr'ogni pena
si convengono i ceppi e la catena.
--- Ludovico Ariosto ---
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150411202656.ga16...@cubo.casa
Servicio DHCP en Debian
Les comparto una nueva sesión, en el cual se hablara sobre DHCP y como configurarlo en un servidor Debian. https://www.youtube.com/playlist?list=PLyLcPK3h0D7DZVICmZZWECc6L0-9nrGxg FRANK HARBEY SANABRIA FLOREZTecnologo en Telecomunicaciones y Sistemas Bogota - Colombia@franksanabria sugeek.co
Re: dhcp cliente pide muy seguido ip al server
El Wed, 22 Oct 2014 16:49:47 -0500, Alejandro G Sánchez martínez escribió: > Tengo un server con debian, esta por dhcp y tengo un server que els el > dhcp este atiendo com a 120 equipos, todo bien pero este server con > deian esta pide y pide una ip cada 30 segundo, el server dhcp entrega > la ip corcta esta amarrado por mac adreess, de echo todo funciona > bine ,pero losl log me los esta generando grandes (...) > ¿alguna idea d eporque esta pide y pide ip? > > todo funciona bien siempre entrega la misma ip porque estan por mac > adres pero esta generando log grandes Revisa el archivo de registro "/var/log/syslog" en uno de los clientes "pidones" para ver cada cuánto tiempo y por qué solicita renovar la IP al servidor. De todas formas, un servidor ejerciendo como tal no debería estar configurado con direccionamiento dinámico. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.10.23.15.02...@gmail.com
dhcp cliente pide muy seguido ip al server
Tengo un server con debian, esta por dhcp y tengo un server que els el dhcp este atiendo com a 120 equipos, todo bien pero este server con deian esta pide y pide una ip cada 30 segundo, el server dhcp entrega la ip corcta esta amarrado por mac adreess, de echo todo funciona bine ,pero losl log me los esta generando grandes Oct 22 16:45:12 Oct 22 16:45:12 Oct 22 16:45:22 Oct 22 16:45:22 Oct 22 16:45:39 Oct 22 16:45:39 Oct 22 16:45:58 Oct 22 16:45:58 Oct 22 16:46:05 Oct 22 16:46:05 Oct 22 16:46:20 Oct 22 16:46:20 ¿alguna idea d eporque esta pide y pide ip? todo funciona bien siempre entrega la misma ip porque estan por mac adres pero esta generando log grandes -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1662674.uOyFDX2m0F@lurkan-desktop
Re: DHCP: máquinas que consumen dos ips
El Fri, 17 Oct 2014 20:23:54 +0200, José Miguel (sio2) escribió: > El Fri, 17 de Oct de 2014, a las 04:22:22PM +, Camaleón dijo: > >> Con la opción b) puedes decirle que envíe como UID la dirección MAC >> editando manualmente el campo desde los clientes lo que a todos los >> efectos sería como si sólo se le enviara un dato,o al menos als ervidor >> sólo le llegaría el mismo dato (UID → dirección MAC o MAC → dirección >> MAC). > > No son datos distintos: la MAC es una cosa y el UID es otra, que se > envían en campos distintos del paquete DHCPREQUEST. De hecho, de modo > predeterminado ocurre lo que tú dices: que el UID vale lo mismo que la > MAC. Pero a pesar de ello un cliente que envía un UID(=MAC) y una MAC se > considera distinto al que no envía UID y sí la misma MAC (que es dato > que siempre se envía). La idea central es que al servidor le llegue el mismo identificador (UID=MAC) para que el servidor trabaje siempre con ese dato y que pueda aplicar la configuración que necesite en base a ese identificador. >> ¿Seguro? Si fuerzo una petición de IP desde el cliente (dhclient -r) me >> da una IP distinta de la que aparece en el archivo "/var/lib/dhcp/ >> dhclient.leases" :-? > > En todo momento estoy hablando de ifup/ifdown que internamente usan > dhclient. En cualquier caso, he mirado el manual y "dhclient -r" no pide > ip, sino que para el cliente enviando al servidor una notificación para > que libere la ip. Como con ifdown ocurre esto, supongo que ipdown usará > esta opción "-r". Si usas Network-Manager ifup/down no es el comando apropiado para configurar la interfaz de red (independientemente de que lo ejecute N-M como parte de su rutina). Y obviamente cuando se libera una IP el cliente pide otra al servidor, al menos eso es lo que aparece en el syslog cuando ejecutas el comando. > Si el cliente vuelve a pedir la ip y nadie recibió esa ip entre el > momento en que se liberó y el que se ha vuelvo a pedir, se le concede la > misma, porque el cliente le sugiere al servidor que se la dé. Esa es mi > experiencia: no he hecho pruebas exhaustivas, que tampoco vienen mucho a > cuento, porque en nada cambian el problema con "deny duplicates". Ya te digo que ese no es comportamiento que veo en mi netbook (con N-M y dhcp) y no tengo ninguna configuración especial en el servidor dhcp. >> No sé qué decirte... ¿es posible que esa opción sea aplicable sólo a >> clientes que usan BOOTP? > > La estructura del paquete DHCPREQUEST que te envié yo era de un artículo > sobre el protocolo DHCP. La opción 50 que mencionabas en el correo anterior es una extensión del protocolo relacionada con BOOTP, por eso te lo decía. >> No sé... yo sigo pensando que si el cliente no pide otra IP al servidor >> no volverías a tener problemas porque mantendría la misma durante toda >> la sesión, salvo, efectivamente que el equipo reiniciara o recargara el >> demonio de la red y no tuviera información alguna de los leases que >> como dices más arriba, > > Es que el problema no se produce mientras se está usando un ordenador y, > de repente, se queda uno sin ip. El problema se produce porque se está > usando un ordenador en windows (o se estuvo usando hace sólo unas horas > por lo que la concesión de ip no ha caducado) y se reinicia en linux o > se reinicia para arrancar por red. De ahí la importancia de que el cliente se identifique (UID o MAC) siempre de la misma forma tanto en linux como en windows para que el servidor le dé la misma IP. Y si ambos sistemas mantienen los leases que han recibido, siguiendo con tu argumento de que los clientes siempre piden la última IP que tienen almacenada, tendrían que recibir la misma y no renovarla. >> Pero eso no ataca el problema de fondo que es evitar que los clientes >> pidan (u obtengan) direcciones distintas cada vez. > > Es que ese no es el problema que quiero resolver: a mí me trae sin > cuidado que un ordenador no reciba siempre la misma ip: para eso ya está > fixed-address. Lo que yo quiero impedir es que un cliente (entendiendo > por cliente una ordenador con una tarjeta de red) acapare dos ips a la > vez: una que le dieron cuando ejecutaba windows y que no está libre > porque no ha acabado la concesión, y otra que usa en el presente porque > está ejecutando linux. Con el "deny duplicates" entiendo que el cliente va a tener (o puede tener) siempre dos IP asociadas, así que tampoco te serviría. Sigo pensando que la mejor forma de ver cómo funciona o qué es lo que hace esa opción es probándola y analizando el syslog del cliente para ver qué IP recibe con cada reinicio. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.10.18.15.49...@gmail.com
Re: DHCP: máquinas que consumen dos ips
El Fri, 17 de Oct de 2014, a las 04:22:22PM +, Camaleón dijo: > Con la opción b) puedes decirle que envíe como UID la dirección MAC > editando manualmente el campo desde los clientes lo que a todos los > efectos sería como si sólo se le enviara un dato,o al menos als ervidor > sólo le llegaría el mismo dato (UID → dirección MAC o MAC → dirección > MAC). No son datos distintos: la MAC es una cosa y el UID es otra, que se envían en campos distintos del paquete DHCPREQUEST. De hecho, de modo predeterminado ocurre lo que tú dices: que el UID vale lo mismo que la MAC. Pero a pesar de ello un cliente que envía un UID(=MAC) y una MAC se considera distinto al que no envía UID y sí la misma MAC (que es dato que siempre se envía). > ¿Seguro? Si fuerzo una petición de IP desde el cliente (dhclient -r) me > da una IP distinta de la que aparece en el archivo "/var/lib/dhcp/ > dhclient.leases" :-? En todo momento estoy hablando de ifup/ifdown que internamente usan dhclient. En cualquier caso, he mirado el manual y "dhclient -r" no pide ip, sino que para el cliente enviando al servidor una notificación para que libere la ip. Como con ifdown ocurre esto, supongo que ipdown usará esta opción "-r". Si el cliente vuelve a pedir la ip y nadie recibió esa ip entre el momento en que se liberó y el que se ha vuelvo a pedir, se le concede la misma, porque el cliente le sugiere al servidor que se la dé. Esa es mi experiencia: no he hecho pruebas exhaustivas, que tampoco vienen mucho a cuento, porque en nada cambian el problema con "deny duplicates". > No sé qué decirte... ¿es posible que esa opción sea aplicable sólo a > clientes que usan BOOTP? La estructura del paquete DHCPREQUEST que te envié yo era de un artículo sobre el protocolo DHCP. > Pero ese archivo de leases no parece una base de datos sino un archivo de > información que le ha enviado el servidor. No, es un archivo que almacena los datos que se ha recibido del servidor. > No sé... yo sigo pensando que si el cliente no pide otra IP al servidor > no volverías a tener problemas porque mantendría la misma durante toda la > sesión, salvo, efectivamente que el equipo reiniciara o recargara el > demonio de la red y no tuviera información alguna de los leases que como > dices más arriba, Es que el problema no se produce mientras se está usando un ordenador y, de repente, se queda uno sin ip. El problema se produce porque se está usando un ordenador en windows (o se estuvo usando hace sólo unas horas por lo que la concesión de ip no ha caducado) y se reinicia en linux o se reinicia para arrancar por red. > Pero eso no ataca el problema de fondo que es evitar que los clientes > pidan (u obtengan) direcciones distintas cada vez. Es que ese no es el problema que quiero resolver: a mí me trae sin cuidado que un ordenador no reciba siempre la misma ip: para eso ya está fixed-address. Lo que yo quiero impedir es que un cliente (entendiendo por cliente una ordenador con una tarjeta de red) acapare dos ips a la vez: una que le dieron cuando ejecutaba windows y que no está libre porque no ha acabado la concesión, y otra que usa en el presente porque está ejecutando linux. > Saludos, Saludos. -- -¿Quién le dice a v.m. que no se pueda hacer? Hacerse puede, que ser imposible es otra cosa. --- Francisco de Quevedo --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141017182354.ga10...@cubo.casa
Re: DHCP: máquinas que consumen dos ips
El Thu, 16 Oct 2014 21:35:26 +0200, José Miguel (sio2) escribió: > El Thu, 16 de Oct de 2014, a las 06:07:37PM +, Camaleón dijo: > >> Sí, eso está claro, pero estamos hablando de tu caso donde además >> necesitas una configuración muy concreta y donde sí controlas los >> clientes y puedes elegir enviar el valor que prefieras (UID o MAC). Y >> además, puedes configurar los clientes para que envíen como UID la >> dirección MAC. > > No, no puedo, aunque controle los clientes; porque, aun habiendo en > principio dos soluciones: > > a) Hacer que todos los sistemas enviaran el mismo UID. > b) Hacer que ningún sistema enviara el UID. > > La a) no puedo hacerla porque no puedo manipular el arranque por red. > La b) no puedo hacerla porque el cliente de windows siempre envía un UID > y no hay forma de que no lo envíe: lo más que deja es cambiarlo, pero > siempre envía uno. Con la opción b) puedes decirle que envíe como UID la dirección MAC editando manualmente el campo desde los clientes lo que a todos los efectos sería como si sólo se le enviara un dato,o al menos als ervidor sólo le llegaría el mismo dato (UID → dirección MAC o MAC → dirección MAC). >> ¿Dices que el cliente mantiene una base de datos local con la última >> dirección que se le ha asignado y solicita esa dirección cuando tiene >> que renovar la IP?i > > > Sí, en /var/lib/dhcp/dhclient.nombre_interfaz.conf. El cliente le > sugiere al servidor una ip (la última que se le concedió) ¿Seguro? Si fuerzo una petición de IP desde el cliente (dhclient -r) me da una IP distinta de la que aparece en el archivo "/var/lib/dhcp/ dhclient.leases" :-? >> Pensaba que eso no dependía del cliente sino del servidor. > > La concesión de la IP depende en última instancia del servidor, pero el > cliente puede sugerirle una ip (opción 50), cuando hace la petición. Si > no hay ningún impedimento, el servidor le hace caso, y se la entrega. No sé qué decirte... ¿es posible que esa opción sea aplicable sólo a clientes que usan BOOTP? >> Bueno, ahí estás manipulando la configuración y además sin reiniciar >> los demonios, no es una prueba fiable. > > Da igual que reinicie el demonio: la caché está en un fichero. Si lo > reinicio, el servidor sigue recordando qué ips entregó, porque las lee > del fichero. Para limpiar la caché del servidor DHCP hay que vaciar por > completo ese fichero (/var/lib/dhcp/dhcpd.conf). Pero ese archivo de leases no parece una base de datos sino un archivo de información que le ha enviado el servidor. >> ¿Y no crees que si los clientes no solicitaran la renovación el >> servidor mantendría una única IP (la primera que les ha dado) para cada >> uno de ellos? > > No creo que sea un problema de renovaciones: más bien es un problema de > revocaciones. Me he dado cuenta de que cuando en linux se baja la > interfaz, dhclient le dice al servidor DHCP que libere la ip, y éste lo > hace, aunque la concesión pudiera haberse alargado más. Con los windows > en cambio no parece que pase eso: aunque el sistema se apague, la > concesión sigue vigente, así que si luego arranco linux la ip que se > concedió en windows, sigue ocupada. Si windows obrara como linux, no > habría ningún problema, salvo en el caso de que se apagara windows de > improviso (por un corte de luz) y la petición de revocación no se > efectura. No sé... yo sigo pensando que si el cliente no pide otra IP al servidor no volverías a tener problemas porque mantendría la misma durante toda la sesión, salvo, efectivamente que el equipo reiniciara o recargara el demonio de la red y no tuviera información alguna de los leases que como dices más arriba, debería usar los datos de la última configuración que ha recibido del servidor. >>> No sé, o hay un error en la programación o un error en la >>> documentación. >> Yo apuesto más por el fallo humano, que nos gustaría que se tratara de >> un parámetro que haga lo que queremos pero que sirve para otra cosa >> O:-) > > Bueno, en ese caso es un error de documentación: se interpreta una cosa > que no es. Además, no hay nadie (o yo no lo he visto) que diga por qué > no funciona y cuál es la verdadera interpretación. > >> Porque entonces el cliente podría estar pidiendo direcciones IP >> distintas continuamente, primero una (192.168.0.1), luego otra >> (192.168.0.2) y reserva la anterior, luego pide otra (192.168.0.n) y >> aunque sigue con la primera reservada no la usa, luego pide otra y se >> le da la reservada (192.168.0.1) y así... > > No, cada vez que pidiera una ip distinta y se le concediera, se > liberarían todas las ips que se hubieran asignado anteriormente a esa > MAC (eso es lo que yo y muchos entendemos al leer el manua
Re: DHCP: máquinas que consumen dos ips
El Thu, 16 de Oct de 2014, a las 06:07:37PM +, Camaleón dijo: > Sí, eso está claro, pero estamos hablando de tu caso donde además > necesitas una configuración muy concreta y donde sí controlas los > clientes y puedes elegir enviar el valor que prefieras (UID o MAC). Y > además, puedes configurar los clientes para que envíen como UID la > dirección MAC. No, no puedo, aunque controle los clientes; porque, aun habiendo en principio dos soluciones: a) Hacer que todos los sistemas enviaran el mismo UID. b) Hacer que ningún sistema enviara el UID. La a) no puedo hacerla porque no puedo manipular el arranque por red. La b) no puedo hacerla porque el cliente de windows siempre envía un UID y no hay forma de que no lo envíe: lo más que deja es cambiarlo, pero siempre envía uno. > ¿Dices que el cliente mantiene una base de datos local con la última > dirección que se le ha asignado y solicita esa dirección cuando tiene que > renovar la IP?i Sí, en /var/lib/dhcp/dhclient.nombre_interfaz.conf. El cliente le sugiere al servidor una ip (la última que se le concedió) > Pensaba que eso no dependía del cliente sino del servidor. La concesión de la IP depende en última instancia del servidor, pero el cliente puede sugerirle una ip (opción 50), cuando hace la petición. Si no hay ningún impedimento, el servidor le hace caso, y se la entrega. > Bueno, ahí estás manipulando la configuración y además sin reiniciar los > demonios, no es una prueba fiable. Da igual que reinicie el demonio: la caché está en un fichero. Si lo reinicio, el servidor sigue recordando qué ips entregó, porque las lee del fichero. Para limpiar la caché del servidor DHCP hay que vaciar por completo ese fichero (/var/lib/dhcp/dhcpd.conf). > De todas formas, si aumentas el nivel > de depuración del registro esa información debería aparecer en el syslog, > bien del cliente o del servidor. Por curiosidad, si tengo tiempo uno de estos días miraré a ver si en syslog dice algo diferente el servidor con el "deny duplicates" o sin él. > ¿Y no crees que si los clientes no solicitaran la renovación el servidor > mantendría una única IP (la primera que les ha dado) para cada uno de > ellos? No creo que sea un problema de renovaciones: más bien es un problema de revocaciones. Me he dado cuenta de que cuando en linux se baja la interfaz, dhclient le dice al servidor DHCP que libere la ip, y éste lo hace, aunque la concesión pudiera haberse alargado más. Con los windows en cambio no parece que pase eso: aunque el sistema se apague, la concesión sigue vigente, así que si luego arranco linux la ip que se concedió en windows, sigue ocupada. Si windows obrara como linux, no habría ningún problema, salvo en el caso de que se apagara windows de improviso (por un corte de luz) y la petición de revocación no se efectura. > > Sí soluciona el problema "fixed-address", porque se puede asociar la ip > > a una MAC con independencia del UID. > > Pero ya has dicho que esta opción no la querías usar ¿no? :-? Sí, ya dije eso. >> No sé, o hay un error en la programación o un error en la documentación. > Yo apuesto más por el fallo humano, que nos gustaría que se tratara de un > parámetro que haga lo que queremos pero que sirve para otra cosa O:-) Bueno, en ese caso es un error de documentación: se interpreta una cosa que no es. Además, no hay nadie (o yo no lo he visto) que diga por qué no funciona y cuál es la verdadera interpretación. > Porque entonces el cliente podría estar pidiendo direcciones IP distintas > continuamente, primero una (192.168.0.1), luego otra (192.168.0.2) y > reserva la anterior, luego pide otra (192.168.0.n) y aunque sigue con la > primera reservada no la usa, luego pide otra y se le da la reservada > (192.168.0.1) y así... No, cada vez que pidiera una ip distinta y se le concediera, se liberarían todas las ips que se hubieran asignado anteriormente a esa MAC (eso es lo que yo y muchos entendemos al leer el manual). Por tanto, un cliente podría haber tenido muchas ips, pero sólo habría ocupado una en cada momento. > Saludos, Un saludo. Gracias. -- Sabed que menda es don Mendo. --- Muñoz Seca --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016193526.ga19...@cubo.casa
Re: DHCP: máquinas que consumen dos ips
El Thu, 16 Oct 2014 18:27:37 +0200, José Miguel (sio2) escribió: > El Tue, 14 de Oct de 2014, a las 02:01:16PM +, Camaleón dijo: > >> Pero ahí no dice que el uso único de MAC como identificador vulnere >> ninguna especificación ni normativa, sólo avisa de que ese valor no es >> fiable y puede cambiar por lo que recomiendan (MAY) usar otro sistema. >> De hecho dice expresamente (MUST) que si el cliente no envía UID alguno >> el servidor usará la MAC. Además, nada te impide usar la dirección MAC >> como identificador (UID) ;-) > > Claro, si el cliente no envía UID se usa la MAC, pero al cliente no lo > controlas, así que no puedes forzarlo que no te envíe un UID y, si te lo > envía, debes (MUST) usarlo. Si el servidor no atiende el UID y sólo se > fija en la MAC, viola el RFC. Sí, eso está claro, pero estamos hablando de tu caso donde además necesitas una configuración muy concreta y donde sí controlas los clientes y puedes elegir enviar el valor que prefieras (UID o MAC). Y además, puedes configurar los clientes para que envíen como UID la dirección MAC. >> Me refería a que en tu configuración, que no tiene configurada ninguna >> reserva específica de direcciones IP para los clientes (ya has dicho >> que no quieres usar la opción de "fixed-address") cuando un equipo pide >> renovar la IP no solicita al servidor ninguna en concreto, sólo que la >> renueve. > > La opción "fixed-address" está fijada en el servidor: el cliente no > tiene nada que ver con ella (salvo que tiene la MAC que hay en la > declaración "host"). Así que haya "fixed-address" o no la haya el > cliente siempre se comporta de la misma manera: pidiendo la última ip > que se le concedió. El que actúa de diferente forma es el servidor, que > siempre le da la misma en cualquier caso (incluso si no coinciden los > UID). ¿Dices que el cliente mantiene una base de datos local con la última dirección que se le ha asignado y solicita esa dirección cuando tiene que renovar la IP? Pensaba que eso no dependía del cliente sino del servidor. > Para comprobar el "one-lease-per-client true;", yo mismo me metí en la > caché del cliente y sustituí un 66, por un 67; para hacerle creer al > cliente que le habían concedido anteriormente la 67. Cuando volví a > pedir ip, el servidor le dio la .67 y desechó la .66: señal de que el > cliente le había pedido la .67. Bueno, ahí estás manipulando la configuración y además sin reiniciar los demonios, no es una prueba fiable. De todas formas, si aumentas el nivel de depuración del registro esa información debería aparecer en el syslog, bien del cliente o del servidor. >> Simplemente que revises cuándo expiran los leases de los clientes y >> mires a ver si no te convendría hacerlos perpetuos (que no renueven >> bajo ninguna circunstancia), así el servidor sólo les asignará una >> dirección. > > Eso no resuelve el problema: mi problema no es que expiren las ips, sino > que una MAC puede recibir varias concesiones si se enviaron distintos > UID. Es más, esto agravaría el problema: si las concesiones son cortas, > puede que tenga suerte y, cuando arranque linux, ya haya expirado la > concesión que se hizo cuando arranqué windows. ¿Y no crees que si los clientes no solicitaran la renovación el servidor mantendría una única IP (la primera que les ha dado) para cada uno de ellos? > Sí soluciona el problema "fixed-address", porque se puede asociar la ip > a una MAC con independencia del UID. Pero ya has dicho que esta opción no la querías usar ¿no? :-? >> Hombre, el comentario que he puesto antes es de la lista de usuarios de >> ISC (DHCP), no se alguien que pasaba por ahí ;-) y como ves, la >> definición del manual da lugar a muchas interpretaciones. > > Yo, en realidad, lo que veo es gente que interpreta más o menos lo mismo > que interpreté yo, pero a la que luego no le salen las cosas. Y, además, > no hay nadie que argumente por qué no salen. > > No sé, o hay un error en la programación o un error en la documentación. Yo apuesto más por el fallo humano, que nos gustaría que se tratara de un parámetro que haga lo que queremos pero que sirve para otra cosa O:-) >> > Creo que la interpretación más lógica es la siguiente: >> > >> > 1. En el servidor hay una reserva vigente asociada a una MAC. >> > 2. Le llega la petición de un cliente con una MAC igual, pero >> > distinto >> >UID (si el UID fuera el mismo, no hay ningún problema). >> > 3. El servidor desecha la reserva anterior asociada a esa MAC y le da >> >una ip al cliente. No se especifica que sea la misma o no. Incluso >> >podría ser distinta, si el propio cliente le sugiere que
Re: DHCP: máquinas que consumen dos ips
El Tue, 14 de Oct de 2014, a las 02:01:16PM +, Camaleón dijo: > Pero ahí no dice que el uso único de MAC como identificador vulnere > ninguna especificación ni normativa, sólo avisa de que ese valor no es > fiable y puede cambiar por lo que recomiendan (MAY) usar otro sistema. De > hecho dice expresamente (MUST) que si el cliente no envía UID alguno el > servidor usará la MAC. Además, nada te impide usar la dirección MAC como > identificador (UID) ;-) Claro, si el cliente no envía UID se usa la MAC, pero al cliente no lo controlas, así que no puedes forzarlo que no te envíe un UID y, si te lo envía, debes (MUST) usarlo. Si el servidor no atiende el UID y sólo se fija en la MAC, viola el RFC. > Me refería a que en tu configuración, que no tiene configurada ninguna > reserva específica de direcciones IP para los clientes (ya has dicho > que no quieres usar la opción de "fixed-address") cuando un equipo > pide renovar la IP no solicita al servidor ninguna en concreto, sólo > que la renueve. La opción "fixed-address" está fijada en el servidor: el cliente no tiene nada que ver con ella (salvo que tiene la MAC que hay en la declaración "host"). Así que haya "fixed-address" o no la haya el cliente siempre se comporta de la misma manera: pidiendo la última ip que se le concedió. El que actúa de diferente forma es el servidor, que siempre le da la misma en cualquier caso (incluso si no coinciden los UID). Para comprobar el "one-lease-per-client true;", yo mismo me metí en la caché del cliente y sustituí un 66, por un 67; para hacerle creer al cliente que le habían concedido anteriormente la 67. Cuando volví a pedir ip, el servidor le dio la .67 y desechó la .66: señal de que el cliente le había pedido la .67. > Simplemente que revises cuándo expiran los leases de los clientes y mires > a ver si no te convendría hacerlos perpetuos (que no renueven bajo > ninguna circunstancia), así el servidor sólo les asignará una dirección. Eso no resuelve el problema: mi problema no es que expiren las ips, sino que una MAC puede recibir varias concesiones si se enviaron distintos UID. Es más, esto agravaría el problema: si las concesiones son cortas, puede que tenga suerte y, cuando arranque linux, ya haya expirado la concesión que se hizo cuando arranqué windows. Sí soluciona el problema "fixed-address", porque se puede asociar la ip a una MAC con independencia del UID. > Hombre, el comentario que he puesto antes es de la lista de usuarios de > ISC (DHCP), no se alguien que pasaba por ahí ;-) y como ves, la > definición del manual da lugar a muchas interpretaciones. Yo, en realidad, lo que veo es gente que interpreta más o menos lo mismo que interpreté yo, pero a la que luego no le salen las cosas. Y, además, no hay nadie que argumente por qué no salen. No sé, o hay un error en la programación o un error en la documentación. > > Creo que la interpretación más lógica es la siguiente: > > > > 1. En el servidor hay una reserva vigente asociada a una MAC. > > 2. Le llega la petición de un cliente con una MAC igual, pero distinto > >UID (si el UID fuera el mismo, no hay ningún problema). > > 3. El servidor desecha la reserva anterior asociada a esa MAC y le da > >una ip al cliente. No se especifica que sea la misma o no. Incluso > >podría ser distinta, si el propio cliente le sugiere que le dé otra > >diferente. El caso es que en el servidor siempre hay una sóla reserva > >asociada a cada MAC (de ahí el nombre de "deny duplicates"). > > Pero no serviría para el propósito que persigue el "deny duplicates" que > es evitar que un cliente solicite direcciones IP indiscriminadamente y > las agote. ¿Por qué no? Si al concedérsele una IP, se desechan las otras concesiones a esa misma MAC, resulta que una MAC sólo estaría reservando en cada momento una sola IP. Por tanto, un cliente (entendiendo cliente=MAC) no agotaría indiscriminadamente ips. > Los resultados que has obtenido son los mismos que los que ha obtenido el > resto de personas que lo han intentado pensando que servía para eso. Se > ve que no. Es cierto, no tengo mucha fe. De todos modos, algunos de los casos que he consultado en internet tenían un error manifiesto de configuración: la MAC no la habían declarado en una declaración HOST, cosa que el manual dice que es necesario. Otros en cambio, sí lo habían hecho... Ya hice la prueba de meter a las máquinas que arrancan por red (PXEClient) en una clase aparte y hacerles: a) Cortita la concesión de la ip. b) Meterlos en el pool "general", de manera que reciban una ip del rango que queda para las máquinas que no son de ninguna clase en especial. Con eso y con configurar el dhclient para que envíe el mismo UID que linux, basta. No me entusiasma la sol
Re: DHCP: máquinas que consumen dos ips
El Mon, 13 Oct 2014 21:52:21 +0200, José Miguel (sio2) escribió: > El Mon, 13 de Oct de 2014, a las 05:39:34PM +, Camaleón dijo: > >> ¿Qué es lo que viola el protocolo? ¿Que se identifique al equipo por la >> MAC en lugar del identificador? ¿Dónde has leído eso? :-? > > Pues no recuerdo bien (incluso quizás me lo he inventado o lo me > malinterpretado), así que me he ido al RFC 2131 y he leído en la sección > 4.2: > > > DHCP server needs to use some unique identifier to associate a client > with its lease. The client MAY choose to explicitly provide the > identifier through the 'client identifier' option. If the client > supplies a 'client identifier', the client MUST use the same 'client > identifier' in all subsequent messages, and the server MUST use that > identifier to identify the client. If the client does not provide a > 'client identifier' option, the server MUST use the contents of the > 'chaddr' field to identify the client. It is crucial for a DHCP client > to use an identifier unique within the subnet to which the client is > attached in the 'client identifier' option. Use of 'chaddr' as the > client's unique identifier may cause unexpected results, as that > identifier may be associated with a hardware interface that could be > moved to a new client. Some sites may choose to use a manufacturer's > serial number as the 'client identifier', to avoid unexpected changes in > a clients network address due to transfer of hardware interfaces among > computers. Sites may also choose to use a DNS name as the 'client > identifier', causing address leases to be associated with the DNS name > rather than a specific hardware box. > > Ahí dice que el servidor debe usar el UID si el cliente se lo ha > enviado; y sólo usar la MAC, si no le envió ninguno. Así que pasar del > UID y fijarse sólo en la MAC, viola este RFC. Yo lo entiendo así y > supongo que por eso el servidor del ISC no lo ha implementado. Pero ahí no dice que el uso único de MAC como identificador vulnere ninguna especificación ni normativa, sólo avisa de que ese valor no es fiable y puede cambiar por lo que recomiendan (MAY) usar otro sistema. De hecho dice expresamente (MUST) que si el cliente no envía UID alguno el servidor usará la MAC. Además, nada te impide usar la dirección MAC como identificador (UID) ;-) >> El cliente no debe pedir ninguna IP en especial, > > Sí, sí que puede pedir una: es la opción 50. El paquete DHCPREQUEST > incluye esa opción. Mira el contenido de este tipo de paquete: (...) Me refería a que en tu configuración, que no tiene configurada ninguna reserva específica de direcciones IP para los clientes (ya has dicho que no quieres usar la opción de "fixed-address") cuando un equipo pide renovar la IP no solicita al servidor ninguna en concreto, sólo que la renueve. >> eso es otra cosa que tendrías que revisar, el motivo de por qué la >> solicita una vez que ya la tiene. Si no quieres que renueve su IP (esto >> es algo que se suele hacer con clientes móviles que pasan de un >> servidor DHCP a otro) configúralo para que no haga. > > No entiendo qué quieres decir. Simplemente que revises cuándo expiran los leases de los clientes y mires a ver si no te convendría hacerlos perpetuos (que no renueven bajo ninguna circunstancia), así el servidor sólo les asignará una dirección. >> Lo interesante no es lo que dicen del "one-leases-per-client" sino lo >> que opina de la función del "deny duplicates", que aunque esté activado >> el cliente obtendrá una segunda dirección y en el caso de que lo >> necesite, podrá reutilizar la anterior. Eso no concuerda con la idea >> que tienes del funcionamiento del "deny duplicates", por eso decía que >> quizá lo estemos interpretando mal. > > El único elemento de juicio que tenemos para opinar es lo que dice la > página del manual, que copio otra vez: (...) Hombre, el comentario que he puesto antes es de la lista de usuarios de ISC (DHCP), no se alguien que pasaba por ahí ;-) y como ves, la definición del manual da lugar a muchas interpretaciones. > Yo entendí en un principio que esto me servía, porque era una forma de > violar el punto 4.2 del RFC: aunque los UID sean diferentes, si la MAC > es igual (siempre que haya una declaración "host" con ella según el > primer párrafo), el servidor desecha todas las otras reservas que le > hizo a esa MAC. Entendí que me servía, porque esto me aseguraría que > siempre habría una sola ip reservada para cada MAC. Y no eres el único que lo entiende así, como ya has visto. Pero parece que no hace lo que la gente espera. > Tú argumentaste que quizás
Re: DHCP: máquinas que consumen dos ips
El Mon, 13 de Oct de 2014, a las 05:39:34PM +, Camaleón dijo: > ¿Qué es lo que viola el protocolo? ¿Que se identifique al equipo por la > MAC en lugar del identificador? ¿Dónde has leído eso? :-? Pues no recuerdo bien (incluso quizás me lo he inventado o lo me malinterpretado), así que me he ido al RFC 2131 y he leído en la sección 4.2: DHCP server needs to use some unique identifier to associate a client with its lease. The client MAY choose to explicitly provide the identifier through the 'client identifier' option. If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client. It is crucial for a DHCP client to use an identifier unique within the subnet to which the client is attached in the 'client identifier' option. Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a clients network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the 'client identifier', causing address leases to be associated with the DNS name rather than a specific hardware box. Ahí dice que el servidor debe usar el UID si el cliente se lo ha enviado; y sólo usar la MAC, si no le envió ninguno. Así que pasar del UID y fijarse sólo en la MAC, viola este RFC. Yo lo entiendo así y supongo que por eso el servidor del ISC no lo ha implementado. > El cliente no debe pedir ninguna IP en especial, Sí, sí que puede pedir una: es la opción 50. El paquete DHCPREQUEST incluye esa opción. Mira el contenido de este tipo de paquete: http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_request Incluye la opción 50. Y una explicación más prolija de para qué sirve la opción 50, aquí: http://www.cisco.com/c/en/us/td/docs/net_mgmt/network_registrar/6-1-1/user/guide/users/UserApB.html#wp1069731 "Used in a client request (DHCPDISCOVER) to allow the client to request that a particular IP address be assigned." En el DHCPDISCOVER (si miras la página de la wiki) verás que también se puede incluir la opción. Esa es la razón por la que los ordenadores (si son menos que ips disponibles) suelen obtener siempre la misma ip: piden la que obtuvieron por última vez, y, si tienen suerte, estará libre y el servidor se la volverá a conceder. Si no lo está, el servidor les asigna otra. > eso es otra cosa que tendrías que revisar, el motivo de por qué la > solicita una vez que ya la tiene. Si no quieres que renueve su IP > (esto es algo que se suele hacer con clientes móviles que pasan de un > servidor DHCP a otro) configúralo para que no haga. No entiendo qué quieres decir. > Lo interesante no es lo que dicen del "one-leases-per-client" sino lo que > opina de la función del "deny duplicates", que aunque esté activado el > cliente obtendrá una segunda dirección y en el caso de que lo necesite, > podrá reutilizar la anterior. Eso no concuerda con la idea que tienes del > funcionamiento del "deny duplicates", por eso decía que quizá lo estemos > interpretando mal. El único elemento de juicio que tenemos para opinar es lo que dice la página del manual, que copio otra vez: $ man 5 dhcpd.conf [...] The duplicates keyword allow duplicates; deny duplicates;
Re: DHCP: máquinas que consumen dos ips
El Mon, 13 Oct 2014 19:23:24 +0200, José Miguel (sio2) escribió:
> El Mon, 13 de Oct de 2014, a las 03:52:14PM +, Camaleón dijo:
>
>> Si ya lo tienes todo hecho, sólo tendrías que añadir la IP en cada host
>> que quieras que tenga una asignación fija, p. ej.:
>>
>> host pc05-vlan9 {
>> hardware ethernet 00:11:22:33:44:55;
>> ddns-hostname "pc05"; fixed-address
192.168.129.66;
>
> Lo sé, pero esa solución no me gusta porque la ip fija no la necesito
> para nada (en realidad lo que quiero es fijarle el nombre a los
> clientes), y habría que andar con cuidado para que esas ips quedaran
> fuera de los rangos que sí se conceden. No es que sea difícil, pero
> exige al que toquetea la configuración (que está en un xml), tener en
> cuenta eso.
Siempre será mejor delimitar las direcciones IP fijas para que ciertos
equipos sólo tomen una dentro de un rango limitado en el que no se
permiten duplicados que permitir al servidor DHCP asignarle varias que se
supone es lo que quieres evitar.
>> Que windows haga una cosa y linux otra sería irrelevante si se le
>> pudiera decir al servidor DHCP que sólo tuviera en cuenta la dirección
>> MAC del equipo, que es raro que cambie.
>
> Sí, pero por lo que he leído investigando esto, eso viola el protocolo
> DHCP. Por eso, el servidor del ISC no lo permite.
¿Qué es lo que viola el protocolo? ¿Que se identifique al equipo por la
MAC en lugar del identificador? ¿Dónde has leído eso? :-?
Lo que sí que pone en la ayuda de dhcpd.conf es que precisamente la
variable "deny duplicates" va en contra de lo que dicta la normativa pero
igualmente lo permiten.
>> Y por otra parte, también cabría preguntarse por qué el cliente
>> solicita una nueva IP si se le ha asignado ya una siendo que podrías
>> configurar la opción de "leases" permanentes (infinite-is-reserved).
>
> Para investigar eso creo que debería ver el DHCPREQUEST que envía el
> cliente con wireshark. No lo he hecho. De todos modos, yo creo que el
> cliente sí que pide la misma IP, lo que ocurre es que el servidor se la
> deniega y le da otra, porque otro cliente (él mismo con otro UID) la
> reservó, y la reserva aún no ha caducado.
>
> Puede ser que esta información también aparezca en el syslog, pero estoy
> convencidísimo de que la explicación es esta.
El cliente no debe pedir ninguna IP en especial, simplemente solicitar
una al servidor cuando esté configurado para hacerlo y eso es otra cosa
que tendrías que revisar, el motivo de por qué la solicita una vez que ya
la tiene. Si no quieres que renueve su IP (esto es algo que se suele
hacer con clientes móviles que pasan de un servidor DHCP a otro)
configúralo para que no haga.
>> Por aquí arrojan algo de luz:
>
> ¿Por qué arrojan luz ahí? No soy capaz de verlo. Lo que sí veo es que
> eso no podría funcionar, porque no hay ninguna declaración "host" que el
> manual dice que es necesaria para que funcione "deny duplicates".
>
>> As I read it, the client will still get two addresses during boot, but
>> one of them will be freed by the server. This does not mean that the
>> address WILL be reused, merely that it CAN be reused if required.
>
> A mí esto sí me ha funcionado. "one-leases-per-client true;" me liberaba
> una ip previamente reservada, si el cliente pedía luego otra distinta
> sin que hubiera caducado la anterior. Lo que ocurre es que tenía que
> haber sido reservada por el mismo cliente y para eso el servidor DHCP se
> fija en el UID, no en la MAC (volvemos otra vez al problema de siempre)
Lo interesante no es lo que dicen del "one-leases-per-client" sino lo que
opina de la función del "deny duplicates", que aunque esté activado el
cliente obtendrá una segunda dirección y en el caso de que lo necesite,
podrá reutilizar la anterior. Eso no concuerda con la idea que tienes del
funcionamiento del "deny duplicates", por eso decía que quizá lo estemos
interpretando mal.
>> > Al final creo que voy a optar por la solución de meter los clientes
>> > en una clase aparte cuando arranquen por PXE.
>>
>> Supongo que tendrás varias opciones para resolverlo, la de usar clases
>> es la que maś comentan por los foros y listas que he encontrado en
>> Google. Ya nos dirás cómo te fue.
>
> En realidad, voy a probar a usar una variante de eso: crearé una clase
> para los clientes PXE, pero no les reservaré un rango. Lo que voy a
> hacer es denegarles los rangos reservados para las demas clases y las
> máquinas conocidas, de manera que acaben pillando una ip del rango
> general:
(...)
> Con esta configuración las máquinas que arranquen por pxe, acabarán
> pillando ip del último r
Re: DHCP: máquinas que consumen dos ips
El Mon, 13 de Oct de 2014, a las 03:52:14PM +, Camaleón dijo:
> Si ya lo tienes todo hecho, sólo tendrías que añadir la IP en cada host
> que quieras que tenga una asignación fija, p. ej.:
>
> host pc05-vlan9 {
> hardware ethernet 00:11:22:33:44:55;
> ddns-hostname "pc05";
> fixed-address 192.168.129.66;
Lo sé, pero esa solución no me gusta porque la ip fija no la necesito para
nada (en realidad lo que quiero es fijarle el nombre a los clientes), y
habría que andar con cuidado para que esas ips quedaran fuera de los rangos
que sí se conceden. No es que sea difícil, pero exige al que toquetea la
configuración (que está en un xml), tener en cuenta eso.
> Que windows haga una cosa y linux otra sería irrelevante si se le pudiera
> decir al servidor DHCP que sólo tuviera en cuenta la dirección MAC del
> equipo, que es raro que cambie.
Sí, pero por lo que he leído investigando esto, eso viola el protocolo
DHCP. Por eso, el servidor del ISC no lo permite.
> Y por otra parte, también cabría preguntarse por qué el cliente solicita
> una nueva IP si se le ha asignado ya una siendo que podrías configurar la
> opción de "leases" permanentes (infinite-is-reserved).
Para investigar eso creo que debería ver el DHCPREQUEST que envía el
cliente con wireshark. No lo he hecho. De todos modos, yo creo que el
cliente sí que pide la misma IP, lo que ocurre es que el servidor se la
deniega y le da otra, porque otro cliente (él mismo con otro UID) la
reservó, y la reserva aún no ha caducado.
Puede ser que esta información también aparezca en el syslog, pero estoy
convencidísimo de que la explicación es esta.
> Por aquí arrojan algo de luz:
¿Por qué arrojan luz ahí? No soy capaz de verlo. Lo que sí veo es que
eso no podría funcionar, porque no hay ninguna declaración "host" que el
manual dice que es necesaria para que funcione "deny duplicates".
> As I read it, the client will still get two addresses during
> boot, but one of them will be freed by the server. This does not mean
> that the address WILL be reused, merely that it CAN be reused if required.
A mí esto sí me ha funcionado. "one-leases-per-client true;" me liberaba
una ip previamente reservada, si el cliente pedía luego otra distinta
sin que hubiera caducado la anterior. Lo que ocurre es que tenía que
haber sido reservada por el mismo cliente y para eso el servidor DHCP se
fija en el UID, no en la MAC (volvemos otra vez al problema de siempre)
> > Al final creo que voy a optar por la solución de meter los clientes en
> > una clase aparte cuando arranquen por PXE.
>
> Supongo que tendrás varias opciones para resolverlo, la de usar clases es
> la que maś comentan por los foros y listas que he encontrado en Google.
> Ya nos dirás cómo te fue.
En realidad, voy a probar a usar una variante de eso: crearé una clase
para los clientes PXE, pero no les reservaré un rango. Lo que voy a
hacer es denegarles los rangos reservados para las demas clases y las
máquinas conocidas, de manera que acaben pillando una ip del rango
general:
#v+
pool {
deny members of pxe;
deny known-clients;
allow members of clase1;
range a b;
}
pool {
deny members of pxe;
deny known-clients;
allow members of clase2;
range b+1 c;
}
pool {
deny members of pxe;
allow known-clients;
range c+1 d;
}
pool {
range d+1 e;
}
#v-
Con esta configuración las máquinas que arranquen por pxe, acabarán
pillando ip del último rango (el de las máquinas desconocidas y que no
pertenecen a una clase con rango reservado): así no les tengo que
reservar permanentemente un rango. Debe de funcionar sin problemas.
Como lo tengo que programar, iprocuraré buscar un hueco esta seman y ya
os confirmaré (eso espero) que funciona.
Saludos.
--
Todo es vana arquitectura,
porque dijo un sabio un día
que a los sastres se debía
la mitad de su hermosura.
--- Lope de Vega --
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013172324.ga25...@cubo.casa
Re: DHCP: máquinas que consumen dos ips
El 13/10/2014 17:53, "Camaleón" escribió:
>
> El Mon, 13 Oct 2014 17:14:10 +0200, José Miguel (sio2) escribió:
>
> > El Sun, 12 de Oct de 2014, a las 09:02:12PM +, Camaleón dijo:
> >
> >> ¿Por algún motivo en particular? Dadas las restricciones que tienes con
> >> la asignación de las IP sería lo más lógico ¿no? :-?
> >
> > Es una larga historia: las configuración del DHCP no la hago
> > directamente, sino a través de un script. Ponerles ip fija me resultaría
> > engorroso.
>
> Si ya lo tienes todo hecho, sólo tendrías que añadir la IP en cada host
> que quieras que tenga una asignación fija, p. ej.:
>
> host pc05-vlan9 {
> hardware ethernet 00:11:22:33:44:55;
> ddns-hostname "pc05";
> fixed-address 192.168.129.66;
> }
>
> >> ¿Tampoco vale en los clientes Windows que arrancan por red o es que
> >> sólo los clientes Linux tiran de PXE? Si es esto último entonces
> >> entendido :-)
> >
> > En realidad son ordenadores que tienen arranque dual: a veces arrancan
> > con linux, a veces arrancan con windows y a veces (muy pocas) es
> > necesario arrancarlos por red para descargarles la imagen del disco con
> > clonezilla.
> >
> > El arranque por red o con linux no envía ningún identificador, windows
> > en cambio, sí. Así que a todos los efectos windows es un cliente y linux
> > (o el arranque por pxe), otro. Si hago que linux envíe el mismo
> > identificador que windows, sigue habiendo dos clientes: la máquina
> > arrancando windows o linux, y la máquina arrancando con pxe.
> >
> > Lamentablemente no hay forma de hacer que windows no envíe el uid al
> > servidor.
>
> Que windows haga una cosa y linux otra sería irrelevante si se le pudiera
> decir al servidor DHCP que sólo tuviera en cuenta la dirección MAC del
> equipo, que es raro que cambie.
>
> >> > Pues he probado, y no ocurre lo previsto: con "deny duplicates"
> >> > recibo primero una ip (la .66) y luego la otra (la .67).
> >> > No entiendo nada.
> >> ¿Y con "deny duplicates" sigue la .66 ocupada o el servidor la ha
> >> liberado?
> >
> > Sigue ocupada. Eso podría haber ocurrido con
> >
> > one-lease-per-client true;
> >
> > pero tampoco porque un mismo cliente es el que envía el mismo
> > identificador, no el que tiene la misma MAC.
>
> Volvemos a lo mimos de antes, si el servidor usara sólo la MAC para
> identificar a los clientes no habría problemas, al menos no en este caso,
> en otros escenarios sí que sería posible que la MAC fuera diferente.
>
> >> Es posible que estemos interpretando mal lo que hace esa variable o que
> >> nos estemos saltando algo básico, como que demos por hecho que el
> >> servidor esté evaluando la petición del cliente recibiendo la
> >> información correcta (MAC duplicadas → no más leases) cuando realmente
> >> no es así de ahí la importancia de los registros para que qué datos son
> >> los que le llegan al servidor.
> >
> > Sí, si cada vez que ha pasado algo he ido a ver qué se ha quedado
> > registrado en la caché del servidor. Es cierto que podría haber mirado
> > /var/log/syslog cuando el servidor no ha dado la ip,
>
> Más que nada para hacer ingeniería inversa, es decir, ponerse en el
> pellejo del servidor/cliente para ver qué hace y qué responde cuando se
> activa esa variable.
>
> Y por otra parte, también cabría preguntarse por qué el cliente solicita
> una nueva IP si se le ha asignado ya una siendo que podrías configurar la
> opción de "leases" permanentes (infinite-is-reserved).
>
> > pero en realidad lo que me parece inexplicable es que con "deny
> > duplicates" dé una segunda ip a un cliente con la misma MAC y distinto
> > UID. El manual da a entender que no debería darla (o bien, que le diera
> > la misma que fue lo que interpreté yo, quizás mal).
>
> Sí, es raro... es raro que obtengas el mismo resultado si activas/
> desactivas esa opción, tendría que haber algún tipo de cambio o
> diferencia que no vemos.
>
> >> > Estoy mirando /var/lib/dhcp/dhcpd.leases para comprobar todo lo que
> >> > ocurre.
> >> Y también en el cliente podrás obtener información jugosa (creo que
> >> esto va a parar al /var/log/syslog).
> >
> > En el cliente también puede consultarse la caché:
> > /var/lib/dhcp/dhclient.eth0.leases. Y el syslog, claro.
>
> Sí, pero no en la información de leases no ves el "diálogo" entre cliente/
> servidor, sólo el resultado de la asignación
Re: DHCP: máquinas que consumen dos ips
El Mon, 13 Oct 2014 17:14:10 +0200, José Miguel (sio2) escribió:
> El Sun, 12 de Oct de 2014, a las 09:02:12PM +, Camaleón dijo:
>
>> ¿Por algún motivo en particular? Dadas las restricciones que tienes con
>> la asignación de las IP sería lo más lógico ¿no? :-?
>
> Es una larga historia: las configuración del DHCP no la hago
> directamente, sino a través de un script. Ponerles ip fija me resultaría
> engorroso.
Si ya lo tienes todo hecho, sólo tendrías que añadir la IP en cada host
que quieras que tenga una asignación fija, p. ej.:
host pc05-vlan9 {
hardware ethernet 00:11:22:33:44:55;
ddns-hostname "pc05";
fixed-address 192.168.129.66;
}
>> ¿Tampoco vale en los clientes Windows que arrancan por red o es que
>> sólo los clientes Linux tiran de PXE? Si es esto último entonces
>> entendido :-)
>
> En realidad son ordenadores que tienen arranque dual: a veces arrancan
> con linux, a veces arrancan con windows y a veces (muy pocas) es
> necesario arrancarlos por red para descargarles la imagen del disco con
> clonezilla.
>
> El arranque por red o con linux no envía ningún identificador, windows
> en cambio, sí. Así que a todos los efectos windows es un cliente y linux
> (o el arranque por pxe), otro. Si hago que linux envíe el mismo
> identificador que windows, sigue habiendo dos clientes: la máquina
> arrancando windows o linux, y la máquina arrancando con pxe.
>
> Lamentablemente no hay forma de hacer que windows no envíe el uid al
> servidor.
Que windows haga una cosa y linux otra sería irrelevante si se le pudiera
decir al servidor DHCP que sólo tuviera en cuenta la dirección MAC del
equipo, que es raro que cambie.
>> > Pues he probado, y no ocurre lo previsto: con "deny duplicates"
>> > recibo primero una ip (la .66) y luego la otra (la .67).
>> > No entiendo nada.
>> ¿Y con "deny duplicates" sigue la .66 ocupada o el servidor la ha
>> liberado?
>
> Sigue ocupada. Eso podría haber ocurrido con
>
> one-lease-per-client true;
>
> pero tampoco porque un mismo cliente es el que envía el mismo
> identificador, no el que tiene la misma MAC.
Volvemos a lo mimos de antes, si el servidor usara sólo la MAC para
identificar a los clientes no habría problemas, al menos no en este caso,
en otros escenarios sí que sería posible que la MAC fuera diferente.
>> Es posible que estemos interpretando mal lo que hace esa variable o que
>> nos estemos saltando algo básico, como que demos por hecho que el
>> servidor esté evaluando la petición del cliente recibiendo la
>> información correcta (MAC duplicadas → no más leases) cuando realmente
>> no es así de ahí la importancia de los registros para que qué datos son
>> los que le llegan al servidor.
>
> Sí, si cada vez que ha pasado algo he ido a ver qué se ha quedado
> registrado en la caché del servidor. Es cierto que podría haber mirado
> /var/log/syslog cuando el servidor no ha dado la ip,
Más que nada para hacer ingeniería inversa, es decir, ponerse en el
pellejo del servidor/cliente para ver qué hace y qué responde cuando se
activa esa variable.
Y por otra parte, también cabría preguntarse por qué el cliente solicita
una nueva IP si se le ha asignado ya una siendo que podrías configurar la
opción de "leases" permanentes (infinite-is-reserved).
> pero en realidad lo que me parece inexplicable es que con "deny
> duplicates" dé una segunda ip a un cliente con la misma MAC y distinto
> UID. El manual da a entender que no debería darla (o bien, que le diera
> la misma que fue lo que interpreté yo, quizás mal).
Sí, es raro... es raro que obtengas el mismo resultado si activas/
desactivas esa opción, tendría que haber algún tipo de cambio o
diferencia que no vemos.
>> > Estoy mirando /var/lib/dhcp/dhcpd.leases para comprobar todo lo que
>> > ocurre.
>> Y también en el cliente podrás obtener información jugosa (creo que
>> esto va a parar al /var/log/syslog).
>
> En el cliente también puede consultarse la caché:
> /var/lib/dhcp/dhclient.eth0.leases. Y el syslog, claro.
Sí, pero no en la información de leases no ves el "diálogo" entre cliente/
servidor, sólo el resultado de la asignación final.
>> Y buscando en Google parece que la duda es generalizada :-):
>>
>> https://forums.novell.com/showthread.php/353997-DHCP-double-leases
>> https://forums.novell.com/showthread.php/220615-PXE-and-Windows-eating-
up-
>> DHCP-leases
>
> A mí me da la impresión de que:
>
> a) Muy posiblemente no interpretara correctamente "deny duplicates" y
>que no me sirva para lo que quiero.
>
> b) Que la interpretación correcta sea la que me
Re: DHCP: máquinas que consumen dos ips
El Sun, 12 de Oct de 2014, a las 09:02:12PM +, Camaleón dijo: > ¿Por algún motivo en particular? Dadas las restricciones que tienes con > la asignación de las IP sería lo más lógico ¿no? :-? Es una larga historia: las configuración del DHCP no la hago directamente, sino a través de un script. Ponerles ip fija me resultaría engorroso. > ¿Tampoco vale en los clientes Windows que arrancan por red o es que sólo > los clientes Linux tiran de PXE? Si es esto último entonces entendido :-) En realidad son ordenadores que tienen arranque dual: a veces arrancan con linux, a veces arrancan con windows y a veces (muy pocas) es necesario arrancarlos por red para descargarles la imagen del disco con clonezilla. El arranque por red o con linux no envía ningún identificador, windows en cambio, sí. Así que a todos los efectos windows es un cliente y linux (o el arranque por pxe), otro. Si hago que linux envíe el mismo identificador que windows, sigue habiendo dos clientes: la máquina arrancando windows o linux, y la máquina arrancando con pxe. Lamentablemente no hay forma de hacer que windows no envíe el uid al servidor. > > Pues he probado, y no ocurre lo previsto: con "deny duplicates" recibo > > primero una ip (la .66) y luego la otra (la .67). > > No entiendo nada. > ¿Y con "deny duplicates" sigue la .66 ocupada o el servidor la ha > liberado? Sigue ocupada. Eso podría haber ocurrido con one-lease-per-client true; pero tampoco porque un mismo cliente es el que envía el mismo identificador, no el que tiene la misma MAC. > Es posible que estemos interpretando mal lo que hace esa variable o que > nos estemos saltando algo básico, como que demos por hecho que el > servidor esté evaluando la petición del cliente recibiendo la información > correcta (MAC duplicadas → no más leases) cuando realmente no es así de > ahí la importancia de los registros para que qué datos son los que le > llegan al servidor. Sí, si cada vez que ha pasado algo he ido a ver qué se ha quedado registrado en la caché del servidor. Es cierto que podría haber mirado /var/log/syslog cuando el servidor no ha dado la ip, pero en realidad lo que me parece inexplicable es que con "deny duplicates" dé una segunda ip a un cliente con la misma MAC y distinto UID. El manual da a entender que no debería darla (o bien, que le diera la misma que fue lo que interpreté yo, quizás mal). > > Estoy mirando /var/lib/dhcp/dhcpd.leases para comprobar todo lo que > > ocurre. > Y también en el cliente podrás obtener información jugosa (creo que esto > va a parar al /var/log/syslog). En el cliente también puede consultarse la caché: /var/lib/dhcp/dhclient.eth0.leases. Y el syslog, claro. > Y buscando en Google parece que la duda es generalizada :-): > > https://forums.novell.com/showthread.php/353997-DHCP-double-leases > https://forums.novell.com/showthread.php/220615-PXE-and-Windows-eating-up- > DHCP-leases A mí me da la impresión de que: a) Muy posiblemente no interpretara correctamente "deny duplicates" y que no me sirva para lo que quiero. b) Que la interpretación correcta sea la que me has dado, pero que en ese caso la directiva, directamente, no funcione. Yo tampoco he visto ningún hilo en internet donde den una explicación satisfactoria. Al final creo que voy a optar por la solución de meter los clientes en una clase aparte cuando arranquen por PXE. Saludos. -- Todo es vana arquitectura, porque dijo un sabio un día que a los sastres se debía la mitad de su hermosura. --- Lope de Vega -- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141013151410.ga21...@cubo.casa
Re: DHCP: máquinas que consumen dos ips
El Sun, 12 Oct 2014 21:04:33 +0200, José Miguel (sio2) escribió:
> El Sun, 12 de Oct de 2014, a las 11:45:06AM +, Camaleón dijo:
>
>> En ese caso quizá te convenga repartir las IP de manera estática
>> ("fixed-
>> address") usando DHCP para evitar que haya duplicados y así te olvidas
>> del problema.
>
> Sé que esa es una solución posible, pero me gustaría no tener que
> utilizarla.
¿Por algún motivo en particular? Dadas las restricciones que tienes con
la asignación de las IP sería lo más lógico ¿no? :-?
>> Si los clientes Windows envían el ID ¿has pensando en configurar los
>> clientes linux para que hagan lo mismo? En "man dhclient.conf" hablan
>> de "dhcp-client-identifier", quizá te pueda servir.
>
> Sé que puedo hacer eso. De hecho, en el mensaje al que respondes creo
> que conté que las pruebas las había hecho exclusivamente con clientes
> linux. La forma de hacer las pruebas consistió en comentar y descomentar
> la línea que hace a dhclient enviar el uid. Sin embargo, esa solución no
> vale cuando se arranca por red.
(...)
¿Tampoco vale en los clientes Windows que arrancan por red o es que sólo
los clientes Linux tiran de PXE? Si es esto último entonces entendido :-)
>> El manual dice que la opción "deny duplicates" evita que un cliente
>> reciba leases adicionales cuando la MAC que está declarada en el host
>> es la misma. Bien, pero quizá eso no implica que mantenga o se le
>> vuelva a asignar el lease anterior, simplemente evita que reciba otro.
>> Y quizá lo haga porque primero da prioridad al ID y luego a la
>> dirección MAC cuando únicamente debería utilizar la dirección MAC para
>> evaluar quién es el cliente que solicita una nueva IP.
>
> Tiene sentido lo que dices y es una posible explicación de por qué no
> funcionan las cosas. Para confirmarla he hecho la siguiente prueba:
>
> 1. El rango de ips posibles, en vez de ser de una ip, es de dos:
>la 192.168.129.66 y la .67.
>
> 2. Primero pide el cliente con un uid (el típico de
>1:MAC:DE:LA:TARJETA) y luego, sin que envíe al servidor noticia de
>que ya no quiere la ip concedida, con otro distinto uid
>(1:1:1:1:1:1:1)
>
> Si fuera cierto lo que supones y estuviera bien configurado el servidor:
>
> + con "allow duplicates" (o sea, sin nada) en la primera ocasión se
> recibiría una ip (la .66, por ejemplo) y en la segunda ocasión la
> segunda (la .67). Y ya no habría más ips disponibles.
>
> + con "deny duplicates" en la primera ocasión se recibiría una ip (la
> .66, por ejemplo) y en la segunda ocasión, aunque haya una ip
> disponible no se recibiría ninguna, porque el ordenador se negaría a
> entregar una segunda ip ya que hay vigente una concesión para la MAC
> que está requiriendo otra (aunque el uid sea distinto).
>
> Pues he probado, y no ocurre lo previsto: con "deny duplicates" recibo
> primero una ip (la .66) y luego la otra (la .67).
>
> No entiendo nada.
¿Y con "deny duplicates" sigue la .66 ocupada o el servidor la ha
liberado?
Es posible que estemos interpretando mal lo que hace esa variable o que
nos estemos saltando algo básico, como que demos por hecho que el
servidor esté evaluando la petición del cliente recibiendo la información
correcta (MAC duplicadas → no más leases) cuando realmente no es así de
ahí la importancia de los registros para que qué datos son los que le
llegan al servidor.
>> De todas formas, revisa en registro para ver qué es lo que hace
>> exactamente
>
> Estoy mirando /var/lib/dhcp/dhcpd.leases para comprobar todo lo que
> ocurre.
Y también en el cliente podrás obtener información jugosa (creo que esto
va a parar al /var/log/syslog).
>> consulta también la opción "one-lease-per-client", es posible que
>> tengas que combinar ambas para que funcione.
>
> La conocía también probé y no me funcionó. Después de leer tu mensaje,
> me releí el manual:
(...)
> No me pareció que aquí dijera nada acerca de que al cliente sólo lo
> identifique por su MAC (con lo cual es de suponer que lo identifica con
> UID), pero igualemente hice una nueva prueba.
>
> La otra vez que había probado lo había hecho con sólo una ip disponible
> y pensé que a lo mejor el servidor liberaba el resto de concesiones una
> vez que concedía la nueva ip. Así que me decidí a probarlo de nuevo, con
> dos ips disponibles: quizás primero concede la .66, luego la .67, pero
> libera la .66 y así sucesivamente.
>
> Pero tampoco: se concede la .66 y luego, con uid distinto, la .67 sin
> liberar la .66. Pero esto sí tiene explicación: el uid no coincide, así
> que es otro cliente. De hecho, después de recibir la 67, pa
Re: DHCP: máquinas que consumen dos ips
El Sun, 12 de Oct de 2014, a las 11:45:06AM +, Camaleón dijo:
> En ese caso quizá te convenga repartir las IP de manera estática ("fixed-
> address") usando DHCP para evitar que haya duplicados y así te olvidas
> del problema.
Sé que esa es una solución posible, pero me gustaría no tener que
utilizarla.
> Si los clientes Windows envían el ID ¿has pensando en configurar los
> clientes linux para que hagan lo mismo? En "man dhclient.conf" hablan de
> "dhcp-client-identifier", quizá te pueda servir.
Sé que puedo hacer eso. De hecho, en el mensaje al que respondes creo
que conté que las pruebas las había hecho exclusivamente con clientes
linux. La forma de hacer las pruebas consistió en comentar y descomentar
la línea que hace a dhclient enviar el uid. Sin embargo, esa solución no
vale cuando se arranca por red.
De hecho, mi plan B, si no logro esto, es hacer que los linux también
envíen el UID y para solucionar el arranque por red (hay un servidor
PXE), podría crear una clase especial para los ordenadores que arrancan
por PXE (se pueden distinguir por la vendor-string, creo recordar) y que
ellos reciban ip de un rango distinto: así no consumirían ninguna. Pero
es una pequeña chapuza.
> El manual dice que la opción "deny duplicates" evita que un cliente
> reciba leases adicionales cuando la MAC que está declarada en el host es
> la misma. Bien, pero quizá eso no implica que mantenga o se le vuelva a
> asignar el lease anterior, simplemente evita que reciba otro. Y quizá lo
> haga porque primero da prioridad al ID y luego a la dirección MAC cuando
> únicamente debería utilizar la dirección MAC para evaluar quién es el
> cliente que solicita una nueva IP.
Tiene sentido lo que dices y es una posible explicación de por qué no
funcionan las cosas. Para confirmarla he hecho la siguiente prueba:
1. El rango de ips posibles, en vez de ser de una ip, es de dos:
la 192.168.129.66 y la .67.
2. Primero pide el cliente con un uid (el típico de
1:MAC:DE:LA:TARJETA) y luego, sin que envíe al servidor noticia
de que ya no quiere la ip concedida, con otro distinto uid
(1:1:1:1:1:1:1)
Si fuera cierto lo que supones y estuviera bien configurado el servidor:
+ con "allow duplicates" (o sea, sin nada) en la primera ocasión se
recibiría una ip (la .66, por ejemplo) y en la segunda ocasión la
segunda (la .67). Y ya no habría más ips disponibles.
+ con "deny duplicates" en la primera ocasión se recibiría una ip (la
.66, por ejemplo) y en la segunda ocasión, aunque haya una ip
disponible no se recibiría ninguna, porque el ordenador se negaría a
entregar una segunda ip ya que hay vigente una concesión para la MAC
que está requiriendo otra (aunque el uid sea distinto).
Pues he probado, y no ocurre lo previsto: con "deny duplicates" recibo
primero una ip (la .66) y luego la otra (la .67).
No entiendo nada.
> De todas formas, revisa en registro para ver qué es lo que hace
> exactamente
Estoy mirando /var/lib/dhcp/dhcpd.leases para comprobar todo lo que
ocurre.
> consulta también la opción "one-lease-per-client", es
> posible que tengas que combinar ambas para que funcione.
La conocía también probé y no me funcionó. Después de leer tu mensaje,
me releí el manual:
#v+
one-lease-per-client flag;
If this flag is enabled, whenever a client sends a DHCPREQUEST for a
particular lease, the server will automatically free any other leases
the client holds. This presumes that when the client sends a
DHCPREQUEST, it has forgotten any lease not mentioned in the
DHCPREQUEST - i.e., the client has only a single network interface
and it does not remember leases it's holding on networks to which it
is not currently attached. Neither of these assumptions are
guaranteed or provable, so we urge caution in the use of this
statement.
#v-
No me pareció que aquí dijera nada acerca de que al cliente sólo lo
identifique por su MAC (con lo cual es de suponer que lo identifica con
UID), pero igualemente hice una nueva prueba.
La otra vez que había probado lo había hecho con sólo una ip disponible
y pensé que a lo mejor el servidor liberaba el resto de concesiones una
vez que concedía la nueva ip. Así que me decidí a probarlo de nuevo,
con dos ips disponibles: quizás primero concede la .66, luego la .67,
pero libera la .66 y así sucesivamente.
Pero tampoco: se concede la .66 y luego, con uid distinto, la .67 sin
liberar la .66. Pero esto sí tiene explicación: el uid no coincide, así
que es otro cliente. De hecho, después de recibir la 67, pare el cliente
sin que se coscase el servidor, me metí en la caché de concesiones,
cambié el .67 por el .66 para que el cliente al enviar si nueva petición
le diga al servidor que quiere la .66 y... funcionó: el servidor le dió
la 66 e revocó la concesión de la 67.
Así que esta segunda opción no sirv
Re: DHCP: máquinas que consumen dos ips
El Sat, 11 Oct 2014 23:30:20 +0200, José Miguel (sio2) escribió:
> Un saludo a la lista:
>
> Tengo un pequeño problema, del que creía haber hallado la solución, pero
> que no me acaba de funcionar.
>
> Resulta que hay una serie de máquinas que he metido en un rango de ips,
> de manera que hay el mismo número de ips que de máquinas. Mientras cada
> máquina sólo consuma una ip no hay problema.
En ese caso quizá te convenga repartir las IP de manera estática ("fixed-
address") usando DHCP para evitar que haya duplicados y así te olvidas
del problema.
> Sin embargo, el servidor DHCP usa como criterio para decidir sin un
> cliente es el mismo o no, no la MAC, sino preferentemente un
> identificador que el cliente le envía. Resulta que linux de modo
> predeterminado o el arranque por red no envían ningún identificador,
> mientras que windows sí lo hace. La consecuencia es que estos
> ordenadores pueden consumir más de una ip y se me fastidia el invento,
> porque las ips se acaban.
(...)
Si los clientes Windows envían el ID ¿has pensando en configurar los
clientes linux para que hagan lo mismo? En "man dhclient.conf" hablan de
"dhcp-client-identifier", quizá te pueda servir.
> Y creí llegar a la solución: incluyo "deny duplicates" en el fichero de
> configuración y, si las máquinas están declaradas (que lo están),
> recibirán siempre una ip, aunque envíen distinto uid.
>
> Pero no me funciona. No sé si es que no he entendido algo o si me falla
> algo.
(...)
> Si prueba a fijar un "uid" a dhclient, obtengo la 192.168.129.66, como
> es de esperar. Si lo quito y vuelvo a pedir ip, ya no obtengo ninguna,
> en vez de obtener la misma; muy a pesar de la cláusula "deny
> duplicates". ¿Se me ha pasado algo por alto?
El manual dice que la opción "deny duplicates" evita que un cliente
reciba leases adicionales cuando la MAC que está declarada en el host es
la misma. Bien, pero quizá eso no implica que mantenga o se le vuelva a
asignar el lease anterior, simplemente evita que reciba otro. Y quizá lo
haga porque primero da prioridad al ID y luego a la dirección MAC cuando
únicamente debería utilizar la dirección MAC para evaluar quién es el
cliente que solicita una nueva IP.
De todas formas, revisa en registro para ver qué es lo que hace
exactamente y consulta también la opción "one-lease-per-client", es
posible que tengas que combinar ambas para que funcione.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.10.12.11.45...@gmail.com
DHCP: máquinas que consumen dos ips
Un saludo a la lista:
Tengo un pequeño problema, del que creía haber hallado la solución, pero
que no me acaba de funcionar.
Resulta que hay una serie de máquinas que he metido en un rango de ips,
de manera que hay el mismo número de ips que de máquinas. Mientras cada
máquina sólo consuma una ip no hay problema.
Sin embargo, el servidor DHCP usa como criterio para decidir sin un
cliente es el mismo o no, no la MAC, sino preferentemente un
identificador que el cliente le envía. Resulta que linux de modo
predeterminado o el arranque por red no envían ningún identificador,
mientras que windows sí lo hace. La consecuencia es que estos
ordenadores pueden consumir más de una ip y se me fastidia el invento,
porque las ips se acaban.
Estuve leyendo y llegué a esto:
$ man 5 dhcpd.conf
[...]
The duplicates keyword
allow duplicates;
deny duplicates;
Host declarations can match client messages based on the DHCP
Client Identifier option or based on the client's network
hardware type and MAC address. If the MAC address is used, the
host declaration will match any client with that MAC address -
even clients with different client identifiers. This doesn't
normally happen, but is possible when one computer has more than
one operating system installed on it - for example, Microsoft
Windows and NetBSD or Linux.
The duplicates flag tells the DHCP server that if a request is
received from a client that matches the MAC address of a host
declaration, any other leases matching that MAC address should be
discarded by the server, even if the UID is not the same. This
is a violation of the DHCP protocol, but can prevent clients
whose client identifiers change regularly from holding many
leases at the same time. By default, duplicates are allowed.
[...]
Y creí llegar a la solución: incluyo "deny duplicates" en el fichero de
configuración y, si las máquinas están declaradas (que lo están),
recibirán siempre una ip, aunque envíen distinto uid.
Pero no me funciona. No sé si es que no he entendido algo o si me falla
algo.
La configuración pertinente para el caso la tengo así:
#v+
deny duplicates;
[...]
subnet 192.168.129.0 netmask 255.255.255.0 {
option routers 192.168.129.1;
option domain-name-servers 192.168.129.1;
option domain-name "smr2.dominio.com";
option domain-search "smr2.dominio.com", "dominio.com";
option ntp-servers time.smr2.dominio.com;
ddns-domainname "smr2.dominio.com";
ddns-rev-domainname "in-addr.arpa";
option broadcast-address 192.168.129.255;
option aula "smr2";
zone smr2.dominio.com {
primary 127.0.0.1;
key "rndc-key";
}
zone 129.168.192.in-addr.arpa {
primary 127.0.0.1;
key "rndc-key";
}
pool {
allow known-clients;
range 192.168.129.66 192.168.129.66;
}
pool {
denyknown-clients;
range 192.168.129.67 192.168.129.254;
}
group {
use-host-decl-names on;
update-static-leases on;
host pc05-vlan9 {
hardware ethernet 00:11:22:33:44:55;
ddns-hostname "pc05";
}
}
}
#v-
Si prueba a fijar un "uid" a dhclient, obtengo la 192.168.129.66, como
es de esperar. Si lo quito y vuelvo a pedir ip, ya no obtengo ninguna,
en vez de obtener la misma; muy a pesar de la cláusula "deny
duplicates". ¿Se me ha pasado algo por alto?
De antemano, gracias.
--
Femmina è cosa mobil per natura.
--- Francisco Petrarca ---
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141011213020.ga9...@cubo.casa
Re: Servidor DHCP IPv6
El Wed, 18 Jun 2014 08:31:21 -0300, Mauro Antivero escribió: > Estimados, necesito empezar a ver como montar un servidor DHCP (con > isc-dhcp-server) que tenga soporte para IPv6. Lo haría primero por > supuesto con IPs privadas y lo probaría localmente. > > Tienen alguna documentación como para recomendarme? Como siempre, > buscando sale mucho, pero por eso les pregunto, ya que a lo mejor > alguno tiene algún documento que conozca y que me sugiera leer. Salvo la dificultad propia de trabajar con IPv6 a priori no veo mayores problemas en la configuración del servidor DHCP :-? Configuring ISC DHCPv6 Server https://www.sixxs.net/wiki/Configuring_ISC_DHCPv6_Server Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.06.18.14.32...@gmail.com
Servidor DHCP IPv6
Estimados, necesito empezar a ver como montar un servidor DHCP (con isc-dhcp-server) que tenga soporte para IPv6. Lo haría primero por supuesto con IPs privadas y lo probaría localmente. Tienen alguna documentación como para recomendarme? Como siempre, buscando sale mucho, pero por eso les pregunto, ya que a lo mejor alguno tiene algún documento que conozca y que me sugiera leer. Saludos y muchas gracias. Mauro. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53a17889.5090...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El Tue, 20 May 2014 08:56:50 -0300, Mauro Antivero 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:
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).
Filtrar los mensajes en rsyslog es una opción y me temo que va a ser la
ú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"
Intenta darle mayor verbosidad al demonio dhcpd ("debug" debe ser el más
verboso).
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05.20.15.14...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El 16/05/14 11:19, Camaleón escribió:
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
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-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/537b4302.9090...@gmail.com
Re: Configuración de logs de isc-dhcp-server
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.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05.16.14.19...@gmail.com
Re: Configuración de logs de isc-dhcp-server
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-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05.16.14.14...@gmail.com
Re: Configuración de logs de isc-dhcp-server
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ó:
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
Saludos,
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53760122.8010...@gmail.com
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
mchos los logs de este tipo).
Okay, ya contarás.
Saludos,
Saludos y muchas gracias, Mauro.
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5374fdbb.9040...@gmail.com
Re: Configuración de logs de isc-dhcp-server
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 {
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: ",
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
> mchos los logs de este tipo).
Okay, ya contarás.
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05.15.15.34...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El 15/05/14 11:20, Camaleón escribió: 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, 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 mchos los logs de este tipo). En fin, les estoy muy agradecido por su ayuda. Saludos, Mauro. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5374d6ec.3000...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El 15/05/14 10:49, Camaleón escribió:
El Thu, 15 May 2014 09:50:46 -0300, Mauro Antivero 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"?
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.
Bueno, en "man dhcp-eval" (sección "Reference: Action Expressions")
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).
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,
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5374ce5c.8080...@gmail.com
Re: Configuración de logs de isc-dhcp-server
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-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.05.15.14.20...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El 15/05/14 10:58, Camaleón escribió: El Thu, 15 May 2014 10:36:13 -0300, Mauro Antivero 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. A ver... en el primer mensaje que enviaste habías definido las 3 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)" 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, -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5374ca2c.5090...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El Thu, 15 May 2014 10:36:13 -0300, Mauro Antivero 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. A ver... en el primer mensaje que enviaste habías definido las 3 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-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.05.15.13.58...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El Thu, 15 May 2014 09:50:46 -0300, Mauro Antivero 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"?
> 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.
Bueno, en "man dhcp-eval" (sección "Reference: Action Expressions")
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-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05.15.13.49...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El 15/05/14 10:08, Camaleón escribió: 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 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-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5374c2cd.60...@gmail.com
Re: Configuración de logs de isc-dhcp-server
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. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.05.15.13.08...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El 14/05/14 14:43, Camaleón escribió:
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.
M... 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.
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.
Saludos y muchas gracias por la ayuda!
Mauro.
Saludos,
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5374b826.4030...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El 14 de mayo de 2014, 13:22, Camaleón escribió:
> 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.
>
> M... 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? :-?
>
> Saludos,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/pan.2014.05.14.16.22...@gmail.com
>
>
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;
y luego en rsyslog
ahi definis el archivo que deseas
y aca tens mas info
http://www.goletdoit.com/how-to-setup-dhcp-server-on-debian/
https://www.google.com.ar/search?q=isc-dhcp-server+log&oq=isc-dhcp-server+log&aqs=chrome..69i57j0l3.15166j0j1&sourceid=chrome&ie=UTF-8#q=isc-dhcp-server+rsyslog
--
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,
Re: Configuración de logs de isc-dhcp-server
El 14/05/14 14:43, Camaleón escribió:
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.
M... 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,
Excelente, te entiendo. Ahora voy a probar, pero dónde puedo conseguir
documentación sobre tales eventos?
Saludos y muchas gracias.
Mauro.
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5373b1c8.9030...@gmail.com
Re: Configuración de logs de isc-dhcp-server
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.
>> M... 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-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05.14.17.43...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El 14/05/14 13:22, Camaleón escribió:
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.
M... 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).
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-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5373a55c.3060...@gmail.com
Re: Configuración de logs de isc-dhcp-server
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.
M... 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? :-?
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05.14.16.22...@gmail.com
Re: Configuración de logs de isc-dhcp-server
El 14/05/14 12:48, Camaleón escribió:
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
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-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/537395c7.7020...@gmail.com
Re: Configuración de logs de isc-dhcp-server
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
Saludos,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.05.14.15.48...@gmail.com
Configuración de logs de isc-dhcp-server
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-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53738938.4070...@gmail.com
Re: Fwd: [O:T] (Semi-solucionado)DHCP Failoverpeer
El Fri, 28 Mar 2014 11:11:33 -0400, Fredy Guio escribió: > Bueno luego de dar vueltas y vueltas toco recurrir al scripting :) > > Les cuento un poco mi experiencia. > > - Por parte de dhcpfailoverpeer no se pudo cuadrar ya que como siempre > windows no es standar pa nada, ganas de complicar las cosas simples y > no queria instalar otro servicio de dhcp sobre un servidor de > produccion. (...) Me lo temía. Las malas lenguas echan pestes sobre el servicio DHCP de Windows, al menos para las versiones anteriores a W2008. Yo reconsideraría el sistema facilón que es tener dos servidores funcionando en la red. Salvo que tengas una estructura muy compleja con vlanes, vpns de por medio, tengas subredes o enrutamientos avanzados, los clientes preguntarán al primer servidor que responda y si no está disponible, seguirán buscando otro, etc... así hasta que se active el timeout y si no encuentran ninguno (y dependiendo de la configuración de los clientes) pasarán a usar un configuración de red preestablecida o activarán el zeroconf (169.254.x.x). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.03.28.16.03...@gmail.com
Fwd: [O:T] (Semi-solucionado)DHCP Failoverpeer
-- Forwarded message -- From: Camaleón Date: 2014-03-27 10:13 GMT-04:00 Subject: Re: [O:T] DHCP Failoverpeer To: debian-user-spanish@lists.debian.org El Wed, 26 Mar 2014 15:01:12 -0400, Fredy Guio escribió: > Sobre las direccines ip otorgadas no habria problema ya que cada > servidor maneja rangos diferentes dentro de la misma red. > > en una red 192.168.0.0/24 192.168.0.15 - 128 windows (primario) > 192.168.0.129 - 250 linux (secundario) > > Mi duda es que si por medio de dhcp failoverpeer el servidor DHCP de > backup el cual es linux se daria por enterado que el servidor primario > windows a dejado de funsionar, para que él entre a dar las direcciones > ip de su propio rango. (...) Pues no sé si el servidor de Windows de DHCP permite esa opción, tendrías que mirar si la versión sobre la que lo quieres implementar lo permite y la forma de activarlo. El servidor DHCP de ISC (disponible en los repos de Debian) sí que lo permite de manera nativa, por lo que quizá te convendría instalar ese programa en el equipo con Windows y así habrá paz y concordia entre los dos servidores :-) Saludos, -- Camaleón Bueno luego de dar vueltas y vueltas toco recurrir al scripting :) Les cuento un poco mi experiencia. - Por parte de dhcpfailoverpeer no se pudo cuadrar ya que como siempre windows no es standar pa nada, ganas de complicar las cosas simples y no queria instalar otro servicio de dhcp sobre un servidor de produccion. Aca iniciamos lo de scripting. - por parte de dhcping el servidor windows nunca responde :( aun estando arriba el servicio dhcping -r -t 5 -s x.x.x.x (x.x.x.x ip del servidor windows) no answer - haciendo un nmap sobre el puerto 67 UDP del servidor windows me encuentro con esto: nmap -p 67 -sU x.x.x.x 67/udp open | filtered dhcps ( me imagino que por el filtered no pasaba el dhcping) no voy a tocar nada sobre el server windows respecto al firewall ni nada es de produccion igual no esta a cargo mi. Pero gracias a nmap puedo ver si el servicio esta arriba o abajo y no solo esto, sino saber si es una cuestion de link fisico o cuestion de servicio. Ahora el disegno del script. #!/bin/bash if # mi servicio esta arriba en linux con ps -e | grep isc-dhcp then if # con namp -p 67 -sU x.x.x.x | grep open si en la cadena de regreso de nmap hay la palabra open then # bajo mi sericio dhcp stop else dejo todo como esta fi else if # con namp -p 67 -sU x.x.x.x | grep open si en la cadena de regreso de nmap hay la palabra open then # dejo todo como esta else # subo mi servicio. fi fi Este script aplicando al crontab. Se que se puede hacer mas bonito con logs, envio de correos, activacion de la alarma de incendios y todo pero bueno eso lo afinare con mas tiempo. Por ahora funsiona pero me deja un poco preocupado el delay respecto a la respuesta de nmap. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/capk2ghdfjzedmceswokg8w1ppd8ttzqajlqcegfr_m9n3r5...@mail.gmail.com
