[gelöst] Unterschiedliche IP während d-i und pxe/system

[reox]

Ich habe ein preseed file entwickelt um Rechner vollautomatisch aufzusetzen. Dabei setze ich auch den Hostname, basierend auf dem Reverse DNS eintrag der aktuellen IP, also zB 192.168.0.42 erhält dann sowas wie somehost42 als hostname.
Nun bekommen die Rechner aber während der PXE Bootphase, dem Debian Installer und dem System dann unterschideliche IP Adressen, wobei sich immer nur die vom d-i unterscheidet.
Im lease file vom DHCP Server schaut das so aus:

Code: Alles auswählen

lease 192.168.0.117 {
  starts 2 2018/09/25 11:36:52;
  ends 2 2018/09/25 13:36:52;
  tstp 2 2018/09/25 13:36:52;
  cltt 2 2018/09/25 11:39:43;
  binding state free;
  hardware ethernet 00:1f:d0:ff:ff:ff;
  uid "\001\000\037\320#\366\217";
  set vendor-class-identifier = "d-i";
}
lease 192.168.0.118 {
  starts 5 2018/11/16 06:47:57;
  ends 5 2018/11/16 08:47:57;
  cltt 5 2018/11/16 06:47:57;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:1f:d0:ff:ff:ff;
  set vendor-class-identifier = "PXEClient:Arch:00000:UNDI:002001";
  client-hostname "somehost-117";
}

Wie man sieht, bekommt der host während dem d-i die .117 zugeteilt und setzt den hostname entsprechend.
Liegt das nur am vendor-class-identifier, welcher vermutlich vom d-i gesetzt wird?
Lässt sich dieses Verhalten im d-i weg konfigurieren? Idealerweise möchte ich die selbe IP wie zum Zeitpunkt von PXE erhalten.
Ich habe jetzt IPAPPEND 2 am PXE eingeschalten, so dass der Kernel cmdline die Adresse mitgegeben wird, wobei es damit auch bugs gibt bzw das zT nicht implementiert ist.
Allerdings besteht das Problem, so wie ich das sehe, ja auch wenn nicht über PXE gebootet wird. dH gibt es da eine Option im d-i um die selbe IP wie im laufenden System zu erhalten?

[BenutzerGa4gooPh]

Idealerweise möchte ich die selbe IP wie zum Zeitpunkt von PXE erhalten.

PXE "kenne" ich nur theoretisch.

Im Rahmen des PXE-Bootvorgangs führt der PXE-Code am Client zunächst über DHCP eine Konfiguration der Netzwerkschnittstelle durch, dabei werden vom Server Konfigurationen wie die IP-Netzwerkadresse und die Netzmaske am Client eingestellt, des Weiteren werden zusätzliche Daten im Rahmen der Erweiterung von DHCP zur Unterstützung von PXE, übertragen. Dabei werden unter anderem auch Daten vom Client wie die Systemarchitektur oder die Globally Unique Identifier übertragen.
...
Mit diesen über DHCP bezogenen Konfigurationsdaten bezieht der PXE-Client in Folge das initiale Network Bootstrap Program vom TFTP-Server und führt diese Datei im Arbeitsspeicher aus. Dabei muss sichergestellt sein, dass die Bootloaderdatei zu der jeweiligen Systemarchitektur passt und der Binärcode vom Prozessor ausgeführt werden kann. Dieser Vorgang ist im Prinzip vergleichbar mit dem Bootvorgang über den Master Boot Record (MBR) bei einer lokalen Festplatte, nur dass dabei die Bootloaderdaten über das Netzwerk übertragen werden.

Der weitere Verlauf richtet sich nach der Gestaltung des initialen Bootloaderprogrammes und ist nicht mehr Teil der PXE-Spezifikation.

https://de.wikipedia.org/wiki/Preboot_E ... nvironment
Die beobachtete IP-Adress-Änderung (per DHCP) während verschiedener "PXE-Phasen" kann ich mir nur so vorstellen, dass sich der Netzwerkadapter gegenüber dem DHCP-Server 2x und verschieden "meldet": PXE + Betriebssystem: Konstante MAC-Adresse aber eventuell unterschiedliche Darstellung: Client-Identifier (MAC-Adresse + "mehr") und später Hardware-Adresse (Linux-DHCP-Client).
https://websistent.com/cisco-dhcp-configuration/
https://www.cisco.com/c/en/us/td/docs/i ... #wp1000999 (Configuring Manual Bindings)
Also würde ich die DHCP-Kommunikation beobachten (Wireshark oder Logs/Leases vom DHCP-Server) oder/und dem DHCP-Server zumindest testweise MAC-IP-Reservation (manual binding) für den PXE-Client verpassen. Und das mittels Hardware-Adresse und Client-Identifier. Vielleicht kannst du für die gleiche MAC aber mit HW-Adresse und Client-Identifier versuchsweise sogar 2 unterschiedliche IPs konfigurieren? Ich tippe drauf, das beide Reservations benutzt werden.

Ich würde zumindest testweise einen DHCP-Server einsetzen, der "hübsch" loggt und sich schnell (um)konfigurieren lässt. pfSense, Cisco-Router, Mikrotik.
Interessehalber gefragt: Warum stören dich die 2 Leases beim PXE-Boot? Die erste ist doch schon wieder freigegeben (binding state free). Im laufenden Betrieb will man sicherlich keine Reservations für jeden DHCP-Client. Vielleicht wäre ein Workaround (oder prinzipiell gar besser) für die OS-Installation mit PXE ein extra Netzsegment mit speziellem DHCP nebst TFTP nur dafür?

[reox]

Interessehalber gefragt: Warum stören dich die 2 Leases beim PXE-Boot? Die erste ist doch schon wieder freigegeben (binding state free). Im laufenden Betrieb will man sicherlich keine Reservations für jeden DHCP-Client. Vielleicht wäre ein Workaround (oder prinzipiell gar besser) für die OS-Installation mit PXE ein extra Netzsegment mit speziellem DHCP nebst TFTP nur dafür?

Zwischen PXE und dem fertig installierten System ist kein Unterschied bei der Adresse. Da bekommt er jedes mal die .118.
Das Problem ist, dass obwohl der Client beim PXE die .118 hatte, er dann in der Installation die .117 bekommt.
Da ich den Hostname während der Installation über die IP Adresse zuweise (sonst heißen alle Systeme nacher debian), bekommt der jetzt den Hostname somehost-117 und hat aber später die .118 als IP.

Wieso sollte man keine langen Leases für die Hosts verwenden? Ich brauche bei dem Setup jedenfalls eindeutig zuordbare Adressen für jeden Host.
Wenn ich die Hosts in einem extra Netz aufsetze, muss ich mir auch was wegen dem Hostname überlegen.
So funktioniert es sehr elegant: Neuer Host wird angehängt, aufgesetzt und fertig.

[BenutzerGa4gooPh]

Wieso sollte man keine langen Leases für die Hosts verwenden?

Ich schrieb nicht von der Lease Time sondern von Reservations. Gegen Letztere spricht der Konfigurationsaufwand im DHCP-Server bei vielen Hosts. Workstations und Desktops benötigen kaum konstante IP-Adressen.

bekommt der jetzt den Hostname somehost-117

Wenn du nun beabsichtigst, einen Teil der IP-Adresse im Hostname zu verwenden (m. E. ungünstig, s. u.), kommst du um DHCP-Reservations u. a. mit IP-Adresse und Hostname (oder um statische Netzwerk-Konfiguration) nicht umhin. Wäre mir bei vielen Hosts (Desktops) zu viel unnötiger Aufwand im DHCP-Server. Mit der DHCP-Reservation von Hostname und IP dürfte doch die von dir bemängelte Adressänderung Geschichte sein. Eventuell das vermutete Problem Client-Identifier und später Hardware-Adresse für DHCP-Initialisierung wäre zu testen.

Tipps:
Mit pfSense / unbound und wenigen Clients könntest du per DHCP-Reservation einen Hostnamen vergeben, der dann in unbound automatisch als DNS-Name registriert wird. Somit bequeme Erreichbarkeit per Namensauflösung und keine Hostnamen-Konfig. auf Client erforderlich. Sinnvoll nur bei wenigen Clients. Bei Cisco-Routern muss man eben Hostname in der DHCP-Reservation und den FQDN im DNS eintragen.

Bei vielen Clients müsste der sinnvolle (s. u.) Hostname manuell auf dem Client konfiguriert und dann idealerweise auch im DNS automatisch registriert werden. Analog dem Windows-DNS-Server mit automatischer Registration von Hostname + dynamischer IP vom Windows-DHCP-Server. Da holpert pfSense mit unbound wohl etwas, bei Neuanmeldung von DHCP-Clients startet unbound neu.

Deshalb mein Vorschlag für eine Hostnamenskonvention massenhaft vorhandener Desktops/Workstations/DHCP-Clients mit dynamischen IPs:
x Buchstaben für Typ (Workstation, Desktop, evtl. auch OS, Abteilung) gefolgt von Inventarnummer
Remote-Administration/-Support per DNS-Name, dazu Blick auf Inventarliste mit Nutzername - oder cleverer:
Hostname gut sichtbar auf Desktops kleben. Diesen nennt der Nutzer bei remote-Supportbedarf oder schreibt ihn ins Ticket. Mit Hostnamen im DNS/FQDN ist Wissen um dynamische IP-Adressen der DHCP-Clients nicht notwendig. Überhaupt "ungut", dynamische IPs in Hostnamen/FQDNs zu kodieren. Hast du ja bemerken müssen.
(Server und Netzwerkkomponenten sollte man aussagekräftig in Kleinbuchstaben benennen und fest adressieren.)

[reox]

Vermutlich ist das ganze hier eh ein XY Problem... Also erklär ich vielleicht kurz die Ausgangssituation:
Es geht da nicht um workstations, sondern um nodes eines clusters. Maximale Anzahl an nodes ist dzt ca 20 Stück, evt mal mehr. Normalerweise kommen kaum neue Nodes hinzu, aber es kann notwendig sein wegen HW defekten die Nodes neu aufzusetzen.
Jeder Node sollte einen eindeutigen Hostname haben, sonst ist es nachher über SSH schwer da was auseinander zu halten. Außerdem werden die Hostnames auch verwendet um die Daten an den Server zu liefern (damit man weiß auf welchen Node das gelaufen ist).
Das Aufsetzen der Nodes soll so schnell wie möglich und am besten ohne viel manuelles herumbasteln gehen. Nimmt man den Default im preseed file, so bekommt der Node den Hostname "debian", was man dann wieder umkonfigurieren muss. Da ich puppet verwende, ist es aber einfacher, wenn der Host nach dem ersten Boot den puppet agent ausführt, ich den Host am Server freischalte und das Ding ist aktiv. Wenn ich vorher den Hostname umkonfigurieren muss, ist das nur unnötiger aufwand.
Da der Debian Installer den Hostname vom DNS aus setzen kann, dachte ich mir das wird eine gute Möglichkeit sein. Da die Nodes eh immer die gleiche IP bekommen, dachte ich mir, dass es am einfachsten ist die Hosts genau darüber zu identifizieren - im laufenden Betrieb klappt das auch super nur, wie schon gesagt, ist es ein Problem wenn der Host im Installer dann eine andere IP bekommt. Extra die MAC am DHCP server zu registrieren ist IMO zu viel Aufwand, zumal durch HW defekte immer mal wieder neue Karten verbaut werden und das alles zu tracken ist mir zumindest zu blöd...
Das einzige was die Lösung nicht kann, ist einen Hostname predictable zu machen. dH ich warte bis der host aufgesetzt ist und schreibe dann den Hostname auf das Gehäuse, damit ich den Node später in dem Haufen von Rechnern wiederfinde. Funktioniert aber soweit auch gut, zumindest bis sich wirklich die Netzwerkkarte ändert.

Als DHCP Server kommt der isc-dhcp-server zum einsatz - evt muss man dort einfach nur irgendwas umstellen, dass keine neue IP vergeben wird?

[r4pt0r]

Wenn der isc-dhcp verwendet wird:

dhpcd.conf(5) manpage:

The one-lease-per-client statement

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.

Alternativ:
IPs statisch vergeben, idealerweise auch mit hostnamen + ggf anderen Einstellungen (VLAN!!) entweder per DHCP oder RADIUS. Also so wenig Konfiguration wie möglich "fest" am client vornehmen, sondern per dhcp/radius + ggf backends wie LDAP bereitstellen.
Für unsere automatisch installierten clients (FreeBSD) wird das auch so gehandhabt - das default LAN der client-ports ist nur die staging-umgebung; dort bekommen _nur_ clients mit vorab erfasster MAC überhaupt eine IP sowie alle PXE-optionen vom DHCP. Das Netz ist nicht geroutet und komplett isoliert, nur die PXE/bootp/nfs und lokale pkg-server für die installation sind erreichbar.
Aktuell wird das zwar noch direkt (von ansible) am dhcpd eingetragen, in der testumgebung (und bald auch im produktivnetz) aber bereits per RADIUS der dann einiges aus LDAP holt, inklusive VLAN-Konfiguration (die dann je nach art des clients bereits vom switch umgesetzt wird) bzw 802.1x Konfiguration für den Client UND die VM die auf jedem Client läuft.
Damit können dann clients sogar (sobald alle APs gegen aruba ersetzt sind) dynamisch zwischen LAN (und verschiedenen switchports) und WLAN wechseln und landen immer im korrekten VLAN (und die Windows-VM landet nur im Windows-VLAN...).
Aufbau der Infrastruktur ist zwar aufwändiger, dafür wird danach das handling der Clients dank zentralem "single point of config" _deutlich_ einfacher.

[reox]

The one-lease-per-client statement

Also wenn ich das richtig verstehe, würde damit nie der Fall auftreten dass zwei mal die MAC im Lease file steht - aber sehr wohl, dass ich unterschiedliche IPs bekomme?
Müsste man vermutlich einfach mal testen.

Ja sicher, staging VLAN und so weiter sind sicher eine Option. Vielleicht muss ich die ganze Architektur von dem Netz nochmal überdenken...

[r4pt0r]

Das lease-file funktioniert etwas anders; daher steht die selbe MAC (und ip) oft auch mehrfach im lease-file; aber solange das lease entweder aktiv ist oder die ip noch nicht neu vergeben wurde, bewirkt "one-lease-per-client", dass eine MAC immer die selbe IP erhält.
"ping-check true" ist in diesem zusammenhang sehr sinnvoll, verzögert aber die vergabe von IPs etwas. "ping-timeout" sollte relativ niedrig gesetzt werden (max 3 sec), sonst kommt es vor allem bei windows und android clients hin und wieder vor, dass diese sich eine link-local adresse geben da sie angeblich keine IP erhalten.

Ja sicher, staging VLAN und so weiter sind sicher eine Option. Vielleicht muss ich die ganze Architektur von dem Netz nochmal überdenken...

Ich habe hier alles komplett gelockt - unbekannte Geräte landen automatisch im gäste-netz, das nur begrenzten internetzugang bietet. Nur Geräte die sich korrekt mit bekannter mac + credentials per 802.1x authentifizieren kommen in die höherprivilegierten VLANs.
Wie gesagt: initiale konfiguration und aufbau der infrastruktur ist etwas aufwändiger, dafür verringert sich der administrationsaufwand danach erheblich. Habe schon lange keinen switchport mehr an einem access-switch von hand bzw per macro konfiguriert, das läuft jetzt alles automatisch per radius
Das plus an Sicherheit ist ebenfalls nicht zu verachten, erst recht wenn man so z.b. clients/anwendungen/server die personenbezogene daten übertragen in abgeschottete netze stecken kann und sich somit einiges an Papierkrieg bzgl DSGVO erspart.

[reox]

Ich habe das Problem jetzt ganz anders gelöst: Im Preseed wird explizit der Hostname abgefragt und ich vergebe die jetzt manuell. IP Adressen werden einfach nicht mehr verwendet und die Hosts nur noch über ihren namen angesprochen. So ist es mir relativ egal welche IP die bekommen.
Macht auch die verwaltung dann einfacher.

[sys_op]

Wenn es nur darum geht, doppelte Hostnamen zu verhindern hier noch eine Möglichkeit.
Über

Code: Alles auswählen

d-i preseed/late_command string \
in-target /usr/bin/wget http://192.168.0.2/scripts/init.sh ; \
in-target /bin/sh init.sh ; \
in-target /bin/rm init.sh ;

Ein Script init.sh starten und damit eine hosts-Datei auf allen Clients schreiben, in der du dem Adressbereich des dhcp-Servers den Hostnamen zuordnest.