Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
dhcpd ignore interface geht nur mit gewalt
71 views
Skip to first unread message
Kay Martinen
Nov 8, 2020, 1:00:02 PM11/8/20
to
Hallo
Eine ubuntu Server 18 VM mit isc-dhcp-server 4.3.5 hat mehrere
Interfaces zu verschiedenen Segmenten und war bisher für 3 davon
zuständig. Nun wollte ich ihm das erste Interface eth0 ignorieren lassen
weil ich dort einen anderen einsetzen will. Doch das entfernen von eth0
aus INTERFACESv4 in /etc/default/isc-dhcp-server hat das nach neustart
nicht gebracht. Er meldet immer noch "listen on eth0..." Stop,
lease-datei bereinigen und start brachten es auch nicht. Löschen aller
fixed-hosts für dies subnet nicht und auch das eindampfen der
subnet-deklaration auf ein paar deny-parameter nicht. Schlußendlich hab
ich eine leere subnet deklaration gehabt und er lauscht immer noch an
eth0, meckert natürlich über unbekannte leases (vom anderen server) und
ich bin langsam etwas genervt. Also schmeiße ich die ganze Subnet
deklaration raus und erst dann lauscht er nicht mehr an eth0 - meckert
aber im log
> No subnet declaration for eth0 (192.168.1.2).
> ** Ignoring requests on eth0. If this is not what
> you want, please write a subnet declaration
> in your dhcpd.conf file for the network segment
> to which interface eth0 is attached. **
>
> Sending on Socket/fallback/fallback-net
> Server starting service.
Das ist zwar jetzt was ich will aber das kann's doch so nich sein!
Gibt es einen Weg dem dhcpd dies interface zu verbieten OHNE
log-meckerei OHNE das interface zu deaktivieren und OHNE merkwürdige
Klimmzüge? Ich finde grad keinen!
Kay
--
Posted via leafnode
Eine ubuntu Server 18 VM mit isc-dhcp-server 4.3.5 hat mehrere
Interfaces zu verschiedenen Segmenten und war bisher für 3 davon
zuständig. Nun wollte ich ihm das erste Interface eth0 ignorieren lassen
weil ich dort einen anderen einsetzen will. Doch das entfernen von eth0
aus INTERFACESv4 in /etc/default/isc-dhcp-server hat das nach neustart
nicht gebracht. Er meldet immer noch "listen on eth0..." Stop,
lease-datei bereinigen und start brachten es auch nicht. Löschen aller
fixed-hosts für dies subnet nicht und auch das eindampfen der
subnet-deklaration auf ein paar deny-parameter nicht. Schlußendlich hab
ich eine leere subnet deklaration gehabt und er lauscht immer noch an
eth0, meckert natürlich über unbekannte leases (vom anderen server) und
ich bin langsam etwas genervt. Also schmeiße ich die ganze Subnet
deklaration raus und erst dann lauscht er nicht mehr an eth0 - meckert
aber im log
> No subnet declaration for eth0 (192.168.1.2).
> ** Ignoring requests on eth0. If this is not what
> you want, please write a subnet declaration
> in your dhcpd.conf file for the network segment
> to which interface eth0 is attached. **
>
> Sending on Socket/fallback/fallback-net
> Server starting service.
Das ist zwar jetzt was ich will aber das kann's doch so nich sein!
Gibt es einen Weg dem dhcpd dies interface zu verbieten OHNE
log-meckerei OHNE das interface zu deaktivieren und OHNE merkwürdige
Klimmzüge? Ich finde grad keinen!
Kay
--
Posted via leafnode
Tim Ritberg
Nov 8, 2020, 1:18:31 PM11/8/20
to
Am 08.11.20 um 18:54 schrieb Kay Martinen:
Aber /etc/default ist auch richtig, keine Probleme bei mir damit.
Und so aus dem Kopf steht auch irgendwo in der Doku, dass er wegen
Listen-mode das Interface so oder so aufmachen muss.
Wohl das hier:
https://serverfault.com/questions/812892/cant-bind-isc-dhcp-server-to-interface
Tim
> Hallo
>
> Eine ubuntu Server 18 VM mit isc-dhcp-server 4.3.5 hat mehrere
> Interfaces zu verschiedenen Segmenten und war bisher für 3 davon
> zuständig. Nun wollte ich ihm das erste Interface eth0 ignorieren lassen
> weil ich dort einen anderen einsetzen will. Doch das entfernen von eth0
> aus INTERFACESv4 in /etc/default/isc-dhcp-server hat das nach neustart
> nicht gebracht. Er meldet immer noch "listen on eth0..." Stop,
> lease-datei bereinigen und start brachten es auch nicht. Löschen aller
> fixed-hosts für dies subnet nicht und auch das eindampfen der
> subnet-deklaration auf ein paar deny-parameter nicht. Schlußendlich hab
> ich eine leere subnet deklaration gehabt und er lauscht immer noch an
> eth0, meckert natürlich über unbekannte leases (vom anderen server) und
> ich bin langsam etwas genervt. Also schmeiße ich die ganze Subnet
> deklaration raus und erst dann lauscht er nicht mehr an eth0 - meckert
> aber im log
>
>
>> No subnet declaration for eth0 (192.168.1.2).
>> ** Ignoring requests on eth0. If this is not what
>> you want, please write a subnet declaration
>> in your dhcpd.conf file for the network segment
>> to which interface eth0 is attached. **
>>
>> Sending on Socket/fallback/fallback-net
>> Server starting service.
>
> Das ist zwar jetzt was ich will aber das kann's doch so nich sein!
Doch!
>
> Eine ubuntu Server 18 VM mit isc-dhcp-server 4.3.5 hat mehrere
> Interfaces zu verschiedenen Segmenten und war bisher für 3 davon
> zuständig. Nun wollte ich ihm das erste Interface eth0 ignorieren lassen
> weil ich dort einen anderen einsetzen will. Doch das entfernen von eth0
> aus INTERFACESv4 in /etc/default/isc-dhcp-server hat das nach neustart
> nicht gebracht. Er meldet immer noch "listen on eth0..." Stop,
> lease-datei bereinigen und start brachten es auch nicht. Löschen aller
> fixed-hosts für dies subnet nicht und auch das eindampfen der
> subnet-deklaration auf ein paar deny-parameter nicht. Schlußendlich hab
> ich eine leere subnet deklaration gehabt und er lauscht immer noch an
> eth0, meckert natürlich über unbekannte leases (vom anderen server) und
> ich bin langsam etwas genervt. Also schmeiße ich die ganze Subnet
> deklaration raus und erst dann lauscht er nicht mehr an eth0 - meckert
> aber im log
>
>
>> No subnet declaration for eth0 (192.168.1.2).
>> ** Ignoring requests on eth0. If this is not what
>> you want, please write a subnet declaration
>> in your dhcpd.conf file for the network segment
>> to which interface eth0 is attached. **
>>
>> Sending on Socket/fallback/fallback-net
>> Server starting service.
>
> Das ist zwar jetzt was ich will aber das kann's doch so nich sein!
Aber /etc/default ist auch richtig, keine Probleme bei mir damit.
Und so aus dem Kopf steht auch irgendwo in der Doku, dass er wegen
Listen-mode das Interface so oder so aufmachen muss.
Wohl das hier:
https://serverfault.com/questions/812892/cant-bind-isc-dhcp-server-to-interface
Tim
Kay Martinen
Nov 8, 2020, 2:10:01 PM11/8/20
to
Am 08.11.20 um 19:18 schrieb Tim Ritberg:
Send Pix. :)
> Aber /etc/default ist auch richtig, keine Probleme bei mir damit.
Und du hast auch n Interfaces und dein dhcpd soll nur an n-1 Interfaces
lauschen und das tut er auch? Benutzt du das alte INTERFACES oder das
neue INTERFACESv4?
> Und so aus dem Kopf steht auch irgendwo in der Doku, dass er wegen
> Listen-mode das Interface so oder so aufmachen muss.
Wenn man ihm sagen kann das er Interface A, B und C nutzen soll dann
erwarte ich das er auch nur an A B und C lauscht, aber nicht an D auch
wenn es existiert. Für so ein Verhalten gibt es m.E. weder einen
Technischen Grund noch eine Logische Rechtfertigung (ohne Relaying)
>
> Wohl das hier:
> https://serverfault.com/questions/812892/cant-bind-isc-dhcp-server-to-interface
Das liest sich eigentlich als ob es da um dhcp-relaying ginge. Das ist
hier aber nicht der Fall. Es soll nur ein Interface das er vorher
bedient hat nun nicht mehr bedient werden. ÜBERHAUPT nicht mehr. Aber
wg. ssh u.a. ist das Interface natürlich weiterhin aktiv.
> Aber /etc/default ist auch richtig, keine Probleme bei mir damit.
lauschen und das tut er auch? Benutzt du das alte INTERFACES oder das
neue INTERFACESv4?
> Und so aus dem Kopf steht auch irgendwo in der Doku, dass er wegen
> Listen-mode das Interface so oder so aufmachen muss.
erwarte ich das er auch nur an A B und C lauscht, aber nicht an D auch
wenn es existiert. Für so ein Verhalten gibt es m.E. weder einen
Technischen Grund noch eine Logische Rechtfertigung (ohne Relaying)
>
> Wohl das hier:
> https://serverfault.com/questions/812892/cant-bind-isc-dhcp-server-to-interface
hier aber nicht der Fall. Es soll nur ein Interface das er vorher
bedient hat nun nicht mehr bedient werden. ÜBERHAUPT nicht mehr. Aber
wg. ssh u.a. ist das Interface natürlich weiterhin aktiv.
0 new messages