Anlage IP-Managed-Clients bei DHCP-Failover

UCS - Univention Corporate Server
#1

Hallo,

wir haben bei einem Kunden folgendes Problem:

Dort laufen zwei DHCP-Server (UCS Master und Backup) im Failover-Betrieb. Das funktioniert so weit wunderbar.
Für jedes VLAN wurde ein DHCP-Pool-Objekt erstellt, welches unter “Fortgeschritten” den Failover-Peer eingetragen hat.

Nun wurde für alle bereits vorhanden IP-Managed-Clients ein Skript ausgeführt, welches eben jene angelegt hat.
Das Kernstück sieht so aus:

udm computers/ipmanagedclient create \
	--position "cn=computers,dc=gfm,dc=local" \
	--set name="$HOST" \
	--set network="cn=$NET,cn=networks,dc=gfm,dc=local" \
	--set mac="$MAC" \
	--set ip="$IP" \
	--set dnsEntryZoneForward="zoneName=gfm.at,cn=dns,dc=gfm,dc=local" \
	--set dnsEntryZoneReverse="zoneName=$REVERSE.in-addr.arpa,cn=dns,dc=gfm,dc=local" \
	--set dhcpEntryZone="cn=$ZONE,cn=gfm.at,cn=dhcp,dc=gfm,dc=local $IP $MAC"

Zu beachten ich hier, dass die UCS-Domäne firma.local heisst, während die verwaltete DHCP-Domäne öffentlich ist. (k.A. ob das wesentlich ist)

Das funktioniert auch bestens, Probleme gibt es nur, wenn neue IP-Managed-Clients angelegt werden.
Bei diesem Kunden kommt das leider sehr häufig vor, daher auch dieser Foreneintrag … :wink:

Diese neuen Clients kommen nämlich nicht automatisch das richtige Gateway zugewiesen.
Das liegt daran, dass sie bei der Neuanlage über die UMC eben nicht unterhalb des korrekten DHCP-Pool-Objekts angelegt werden, sondern im darüberliegenden. (firma.at)
In der UMC kann man die einzelnen Pools auch gar nicht auswählen.
(das entsprechende Feld bei den durch das Skript angelegten Clients ist leer - siehe Anhang)

Workaround ist derzeit, dass nach der Anlage das korrespondierende DHCP-Objekt im LDAP-Baum verschoben wird.
Damit ist der Kunde sehr unzufrieden.

Kann man das irgendwie lösen, ohne dass man ein Skript schreibt, welches sich um die korrekte Anlage des DHCP-Objekts kümmert?
Wenn nein, wie könnte so ein Skript aussehen und wo müsste es eingebaut werden, damit es bei Neuanlagen automatisch ausgeführt wird?

LG,
Roland.

#2

Moin,

ohne, dass ich das jetzt im Detail nachgestellt hätte (klingt nach nicht wenig Arbeit, das nachzustellen): Sie können doch im selben Script, mit dem Sie die IP-Managed-Clients anlegen, anschließend mit »ldapmodrdn« das DHCP-Objekt an den gewünschten Ort verschieben. Hier ein Beispiel zum Verschieben eines Clients:

ldapmodrdn -h $(ucr get ldap/master) -p $(ucr get ldap/master/port) \ -D $(ucr get ldap/hostdn) -y /etc/machine.secret \ -s cn=test-container,cn=computers,$(ucr get ldap/base) \ cn=test-client,cn=computers,$(ucr get ldap/base) \ cn=test-client

Die ersten zwei Zeilen sind nur Verbindungsparameter & Authentifizierung mit dem Maschinenaccount. Zeile 3 gibt dann mit »-s …« das neue Elternobjekt (»superordinate object«, daher auch das -s) an. Zeile 4 gibt das zu verschiebene Objekt an, und Zeile 5 sagt dann nur, dass das Objekt am neuen Zielort weiterhin so heißen soll wie am alten Zielord (»ldapmodrdn« wird nämlich auch/eigentlich zum Umbenennen benutzt).

Analog sollte das mit den DHCP-Objekten gehen.

Natürlich kann man jetzt anfangen zu debuggen, warum wieso weshalb der DHCP-Dienst nicht auswählbar bzw. gesetzt ist, aber ich glaub, ich würde da ganz pragmatisch rangehen und das Script ändern: IP-Managed-Client anlegen, mit »univention-ldapsearch« in einer Schleife warten, bis das gewünschte Objekt auch da is (vermutlich sofort nach dem »udm«-Call, aber wer weiß!), anschließend mit »ldapmodrdn« verschieben.

Gruß,
mosu

#3

Ok, das Problem ist aber, dass es bei der Anlage über die UMC die beschriebenen Probleme gibt.
Mit meinem Skript funktioniert ja alles.

Ich müsste dieses ldapmodrdn also immer dann ausführen, wenn der Admin in der UMC ein neues IP-Managed-Client-Objekt anlegt.
Ich vermute, dass es dafür ein Python-Skript gibt, welches ich nur erweitern müsste. Bloss welches? Und wie mache ich das update-sicher …

#4

Moin Herr Gsell,

ach, da hatte ich Ihr erstes Posting in der Tat falsch verstanden. Das tut mir leid.

Dass die UMC die Objekte unterhalb eines Subnets anlegt und nicht unterhalb eines Pools ist irgendwie logisch. Man kann ja pro Subnet beliebig viele Pools haben, z.B. um nicht zusammenhängende Bereiche zu vergeben. Kommt oft genug bei unseren Kunden vor; oftmals haben die initial kein DHCP, wollen’s dann einführen, und haben wegen hier und da vergebenen festen Adressen einfach keine großen zusammenhängenden Bereiche mehr frei. Ergo mehrere Pools, und woher sollte die UMC wissen, in welchen Pool ein neu erstelltes Objekt zu stecken ist?

Nun aber zu einer potenziellen Lösung. Jede LDAP-Änderung wird vom Directory Notifier an alle verbundenen Directory Listener (einer pro UCS-Server) mitgeteilt. Der Directory Listener führt dann alle registrierten, in Python geschriebenen Module aus. Die Module können dann auf die Änderungen so reagieren, wie es gerade nötig ist.

Dieser Mechanismus wird z.B. genutzt, um in externer Software Dinge anzulegen oder zu entfernen, wenn die korrespondierenden Elemente im LDAP angelegt/entfernt werden, und wenn die Software selber keine LDAP-Anbindung besitzt. Beispielsweise öffentliche Ordner in einem E-Mail-Server.

Sie müssen bzw. sollten nun kein bestehendes Listener-Modul verändern. Das wäre nicht sicher gegen Updates. Statt dessen sollten Sie schlicht ein eigenes Listener-Modul schreiben und dem Listener bekannt machen. Das Listener-Modul könnte dann prüfen:

[ul][li]Ist die Aktion das Neuanlegen eines DHCP-Objekts?[/li]
[li]Wurde das neu angelegte DHCP-Objekt direkt unterhalb des Subnetzes angelegt?[/li][/ul]

Falls beides zutrifft, dann einfach das neu angelegte Objekt verschieben.

Damit man sich das nicht alles mühsam erarbeiten muss, stellt Univention dafür freundlicherweise Entwickler-Doku bereit (nur auf Englisch). Lesen Sie sich einmal Abschnitt 5 komplett durch. Letztlich ist der Einstieg nicht so schwer, ein triviales Modul bekommt man relativ fix implementiert. Und dann heißt’s einfach nur verfeinern und testen, bis es wie gewünscht funktioniert :slight_smile:

Gruß,
mosu

#5

Wow, super!

Vielen herzlichen Dank für die ausführliche Antwort.
Diese Doku habe ich schon mal überflogen und sie scheint sehr ausführlich zu sein. Ich denke da kann man auch einiges über den Listener-/Notifier-Mechanismus lernen.

Danke nochmal und schönes Wochenende,
Roland.

Mastodon