Bug 26416 - Server IP-Adresse per DHCP
Server IP-Adresse per DHCP
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Network
UCS 3.0
Other Linux
: P5 enhancement (vote)
: UCS 3.0-2
Assigned To: Stefan Gohmann
Felix Botner
: interim-1
: 26601 (view as bug list)
Depends on:
Blocks: 26332 26417 26608 28465 29606
  Show dependency treegraph
 
Reported: 2012-03-09 09:26 CET by Stefan Gohmann
Modified: 2017-04-21 14:43 CEST (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Release Goal
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2012-03-09 09:26:30 CET
Aktuell ist es in UCS so, dass ein Server so konfiguriert werden kann, dass die IP-Adresse per DHCP bezogen wird. Im Backend wird die IP-Adresse aus der Installation in UCR als Fallback Adresse gespeichert.

Bekommt der Server eine neue IP-Adresse per DHCP, so wird eine Warnung am Login Prompt angezeigt.

Das ist insgesamt fehleranfällig und nicht transparent.

Folgender Vorschlag:

- Es wird keine Fallback Adresse mehr gespeichert. Bekommt das System keine Adresse zugewiesen, so wird eine Adresse aus dem Link Local Bereich verwendet: 169.254.0.0/16

- Wird eine IP Adresse per DHCP bezogen, so wird diese in UCR und auch im LDAP gespeichert. Dazu muss das System die letzte konfigurierte IP Adresse kennen, damit ein Austausch alte Adresse vs. neue Adresse erfolgen kann
Comment 1 Stefan Gohmann univentionstaff 2012-03-09 10:06:37 CET
(In reply to comment #0)
> - Wird eine IP Adresse per DHCP bezogen, so wird diese in UCR und auch im LDAP
> gespeichert. Dazu muss das System die letzte konfigurierte IP Adresse kennen,
> damit ein Austausch alte Adresse vs. neue Adresse erfolgen kann

Dafür müssen die Server die Berechtigung bekommen, dass sie am LDAP Objekt ihre IP ändern dürfen und auch im DNS.
Comment 2 Stefan Gohmann univentionstaff 2012-03-21 06:52:29 CET
(In reply to comment #0) 
> - Wird eine IP Adresse per DHCP bezogen, so wird diese in UCR und auch im LDAP
> gespeichert. Dazu muss das System die letzte konfigurierte IP Adresse kennen,
> damit ein Austausch alte Adresse vs. neue Adresse erfolgen kann

Es gibt in univention-network-common jetzt ein Tool dhclient2ucr, welches die DHCP Ausgabe in UCR speichert. Es fehlen noch ein paar Dinge, beispielsweise zu erkennen, welches das Default Interface ist.

Dieses Tool wird in system-setup-boot im EC2 Setup aufgerufen, damit bei der ersten Einrichtung per System Setup direkt die richtige IP eingetragen ist.

Die Funktioniert dhclient wurde aus dem UMC Modul übernommen. Ich glaube die ist in ähnlicher Form auch im Installer vorhanden und sollte deshalb in die univention-lib wandern.
Comment 3 Stefan Gohmann univentionstaff 2012-03-22 07:26:05 CET
Im Amazon Umfeld bekommt eine Instanz eine neue IP, wenn diese Instanz beendet und wieder gestartet wird.
Comment 4 Stefan Gohmann univentionstaff 2012-03-26 08:53:44 CEST
Es ist jetzt folgendermaßen implementiert:

- Jedes UCS Serversystem kann per DHCP installiert und konfiguriert werden, auch der Master. Probleme kann es vor allem dann geben, wenn a) die Systeme keine IP vom DHCP Server bekommen und somit nicht erreichbar sind und b) wenn der DNS Server seine IP auch per DHCP bekommt, da die anderen Systeme die IP Änderung des DNS Servers ggf. nicht mitbekommen.

- Aktuell ist es noch so, dass eine IP bei der Installation und in System Setup angegeben werden muss, beispielsweise per DHCP Query. Das kann zu UCS 3.1 und mit Bug #26417 und Bug #26608 entfernt werden.

- Bekommt ein Server per DHCP keine IP Adresse, so wird ein Fallback auf eine Link Local Adresse gesetzt, 169.254.x.y/24. x und y werden dabei zufällig gewählt: 
  http://en.wikipedia.org/wiki/Link-local_address#IPv4

- Ein Server speichert die per DHCP erhaltene IP Adresse in UCR

- Zusätzlich schreibt der Server die IP ins LDAP. Da die LDAP ACLs dafür sehr kompliziert bis unmöglich sind (bspw. Reverse Eintrag) und wir mit dem Bind LDAP Backend kein DDNS unterstützen, führen die Server die IP Änderung im Verzeichnisdienst per UMC aus: 
 umc-command -U 'master741$' -P $(</etc/machine.secret) ip/change -o ip=10.201.74.2 -o netmask=255.255.0.0 -o oldip=10.201.74.1 -o role="$server_roled"

- Von einem Rechner aus kann die Registrierung per Tool erneut gestartet werden:
     /usr/sbin/univention-register-network-address
  oder
     /etc/init.d/univention-network-common

- War die Registrierung erfolgreich, werden die aktuellen Werte in den fallback UCR Variablen gespeichert. Das ist notwendig, damit später die aktuellen IPs bekannt sind, damit nur die alten IPs ersetzt werden

- Der Ablauf ist wie folgt:
  - ifup
    - /etc/network/if-pre-up.d/10_dhclientconf
      + commit auf dhclient.conf damit eine neue Fallback IP generiert wird
    - dhclient (wird durch ifup aufgerufen
    - /etc/network/if-up.d/00_resolvconf
      + wenn das System gejoint ist, ein DC ist und ein Nameserver gesetzt ist, werden die übergebenen Nameserver als Forwarder gespeichert
      + ansonsten werden die lokal konfigurierten Nameserver noch in die resolv.conf hinzugefügt
    - /etc/network/if-up.d/12_univention_config_registry
      + An dieser Stelle werden die Interfaces ausgelesen und in UCR gespeichert
      + Wenn ein Nameserver auf die alte IP gesetzt war, so wird der Wert ersetzt
      + Das Gateway wird ebenfalls gespeichert
    - /etc/network/if-up.d/90_dns_update
      + Wenn das System gejoint ist und UMC auf dem Master erreicht wird, wird die IP per UMC Kommando geändert
  - Am Ende des Bootvorgangs wird nochmal die Registrierung im LDAP per init-Skript (univention-network-common) aufgerufen. Das ist notwendig, damit beispielsweise auf einem Master auch die Registrierung durchgeführt wird, da zum Bootzeitpunkt ifup UMC noch nicht gestartet wurde

- Folgende Punkte könnten noch verbessert werden. Sollten diese Punkte in der Praxis relevant sein, bitte neue Bugs erstellen:
  + War die Registrierung nicht erfolgreich, so könnte die Registrierung im Hintergrund erneut erfolgen
  + Anstatt nur gegen den Master zu gehen, könnten die Server auch andere Systeme Backup Systeme ansprechen
Comment 5 Stefan Gohmann univentionstaff 2012-03-26 08:55:36 CEST
*** Bug 26601 has been marked as a duplicate of this bug. ***
Comment 6 Stefan Gohmann univentionstaff 2012-03-26 12:19:54 CEST
Tests waren erfolgreich.
Comment 7 Stefan Gohmann univentionstaff 2012-04-10 12:44:00 CEST
Der Datei /etc/network/if-pre-up.d/10_dhclientconf fehlen die Ausführungsrechte. Dadurch wird die dhclient.conf nicht aktualisiert und eth0 bleibt ohne Netzwerkadresse für eth0 (Ausnahme ist, wenn die lease-Konfiguration für das Device in der dhclient.conf noch nicht abgelaufen ist)
Comment 8 Stefan Gohmann univentionstaff 2012-04-10 13:48:02 CEST
(In reply to comment #7)
> Der Datei /etc/network/if-pre-up.d/10_dhclientconf fehlen die
> Ausführungsrechte. Dadurch wird die dhclient.conf nicht aktualisiert und eth0
> bleibt ohne Netzwerkadresse für eth0 (Ausnahme ist, wenn die
> lease-Konfiguration für das Device in der dhclient.conf noch nicht abgelaufen
> ist)

Ist angepasst und auch hochgeladen.
Comment 9 Janek Walkenhorst univentionstaff 2012-04-16 16:23:13 CEST
Im Moment wird auf Master-Systemen immer der »nameserver1« in den »dns/forwarder1« übertragen, auch wenn gar kein DHCP verwendet wird.
Dadurch funktioniert nach jedem Boot das DNS nicht mehr korrekt, wenn man als NS1 die lokale IP und als FWD1 einen externen Nameserver gesetzt hatte.

Da dies bei jedem Boot geschieht und auch wenn kein DHCP verwendet wird, scheint es hier ein Problem damit zu geben wann der Code ausgeführt wird.
Comment 10 Stefan Gohmann univentionstaff 2012-06-07 14:17:28 CEST
*** Bug 27500 has been marked as a duplicate of this bug. ***
Comment 11 Stefan Gohmann univentionstaff 2012-06-12 07:58:27 CEST
(In reply to comment #9)
> Im Moment wird auf Master-Systemen immer der »nameserver1« in den
> »dns/forwarder1« übertragen, auch wenn gar kein DHCP verwendet wird.
> Dadurch funktioniert nach jedem Boot das DNS nicht mehr korrekt, wenn man als
> NS1 die lokale IP und als FWD1 einen externen Nameserver gesetzt hatte.
> 
> Da dies bei jedem Boot geschieht und auch wenn kein DHCP verwendet wird,
> scheint es hier ein Problem damit zu geben wann der Code ausgeführt wird.

Das Problem ist nur auf Systemen aufgetreten, die die DHCP Adresse nicht per DHCP bezogen haben.

So sollte es sein:

- System per DHCP

Per DHCP bezogener Nameserver wird in dns/forwarder gespeichert, wenn das System gejoint ist und ein DC ist. Dann wird der lokale Nameserver verwendet. Überschrieben werden kann diese Einstellung per "ucr --force" oder wenn nameserver/external gesetzt ist.

- System mit statischer IP

Hier sollen die konfigurierten Nameserver und Forwarder nicht überschrieben werden.
Comment 12 Felix Botner univentionstaff 2012-06-15 10:59:33 CEST
Wenn per DHCP keine Gateway und keine DNS Server übergeben werden, muss man diese Einstellungen beim Setup per Hand machen.

Dies wird jedoch später nicht übernommen. Die UCRV gateway ist leer und der dns/forwarder1 ist auf die IP des Rechners selbst gesetzt.
Comment 13 Stefan Gohmann univentionstaff 2012-06-15 13:54:03 CEST
(In reply to comment #12)
> Wenn per DHCP keine Gateway und keine DNS Server übergeben werden, muss man
> diese Einstellungen beim Setup per Hand machen.
> 
> Dies wird jedoch später nicht übernommen. Die UCRV gateway ist leer und der
> dns/forwarder1 ist auf die IP des Rechners selbst gesetzt.

Das ist jetzt behoben.
Comment 14 Felix Botner univentionstaff 2012-06-19 17:43:56 CEST
Funktioniert für verschiedene Systemrollen mit und ohne DHCP. Ohne DHCP werden die händisch getätigten Einstellungen beibehalten. Mit DHCP werden die DHCP Einstellungen übernommen (alle werden lokal in UCR gespeichert, die IP wird am LDAP Objekt angepasst)


> Jedes UCS Serversystem kann per DHCP installiert und konfiguriert werden,
> auch der Master.

OK

> Zusätzlich schreibt der Server die IP ins LDAP. Da die LDAP ACLs dafür sehr
> kompliziert bis unmöglich sind (bspw. Reverse Eintrag) und wir mit dem Bind
> LDAP Backend kein DDNS unterstützen, führen die Server die IP Änderung im
> Verzeichnisdienst per UMC aus: 
> Von einem Rechner aus kann die Registrierung per Tool erneut gestartet 
> werden: /usr/sbin/univention-register-network-address
> oder /etc/init.d/univention-network-common

OK

> Am Ende des Bootvorgangs wird nochmal die Registrierung im LDAP per
> init-Skript (univention-network-common) aufgerufen. Das ist notwendig, damit
> beispielsweise auf einem Master auch die Registrierung durchgeführt wird, da
> zum Bootzeitpunkt ifup UMC noch nicht gestartet wurde

OK

> War die Registrierung erfolgreich, werden die aktuellen Werte in den fallback
> UCR Variablen gespeichert. Das ist notwendig, damit später die aktuellen IPs
> bekannt sind, damit nur die alten IPs ersetzt werden

OK

> System per DHCP
>  Per DHCP bezogener Nameserver wird in dns/forwarder gespeichert, wenn das
>  System gejoint ist und ein DC ist. Dann wird der lokale Nameserver verwendet.
>  Überschrieben werden kann diese Einstellung per "ucr --force" oder wenn
>  nameserver/external gesetzt ist.
> System mit statischer IP
>  Hier sollen die konfigurierten Nameserver und Forwarder nicht überschrieben
>  werden.

OK

> Wenn per DHCP keine Gateway und keine DNS Server übergeben werden, muss man
> diese Einstellungen beim Setup per Hand machen.
> Dies wird jedoch später nicht übernommen. Die UCRV gateway ist leer und der
> dns/forwarder1 ist auf die IP des Rechners selbst gesetzt.

Funktioniert, gateway wird leer gelassen, dns/forwarder1 wird gesetzt, falls nicht über DHCP.
Comment 15 Stefan Gohmann univentionstaff 2012-07-20 15:25:21 CEST
UCS 3.0-2 has been released: 
  http://forum.univention.de/viewtopic.php?f=54&t=1905

If this error occurs again, please use "Clone This Bug".