Member Mode / LDAP move

Hallo,

ich habe 2 Fragen:
1.)
wir haben bei einem Kunden kürzlich einen UCS-Server im Member Mode an ein MS-AD angebunden. Das hat wunderbar funktioniert, jedoch ist uns aufgefallen, dass wir im LDAP keine neu angelegten Objekte verschieben können. Konkret war das ein dhcp/host-Objekt, welches ich in einen untergeordneten Container (Subnet) verschieben wollte.

Dies war weder in der UMC noch auf der CLI mit (udm dhcp/host move) möglich. Wie gesagt es ging dabei um neu angelegte Objekte, die sich nur im LDAP und nicht im AD befinden.
Löschen und neu Erstellen der Objekte direkt an der richtigen Position war schließlich erfolgreich.

Woran kann das liegen?
Ist das eine Besonderheit des Member Mode? Dass man AD-Objekte nicht verschieben kann, ist klar, aber in diesem Fall soll es doch gehen, oder?
(bzw. über Umwege kann man das Ziel schließlich ja auch erreichen)

Nachtrag:
Es hat nichts mit dem Member Mode zu tun. Es geht bei uns intern auch nicht.
Ich habe einen neuen DHCP-Host erstellt:

[code]root@mastersrv:~# univention-ldapsearch cn=testi

testi, siedl.local, dhcp, siedl.local

dn: cn=testi,cn=siedl.local,cn=dhcp,dc=siedl,dc=local
objectClass: top
objectClass: univentionDhcpHost
objectClass: univentionObject
univentionObjectType: dhcp/host
dhcpHWAddress: ethernet 11:22:33:44:55:66
cn: testi
[/code]

und wollte diesen dann verschieben:

[code]root@mastersrv:~# udm dhcp/host move \

–dn “cn=testi,cn=siedl.local,cn=dhcp,dc=siedl,dc=local”
–position “cn=192.168.168.0,cn=siedl.local,cn=dhcp,dc=siedl,dc=local”
Move dhcp/host not allowed[/code]

Direkt dort anlegen geht in der UMC nicht - da stehen nur diese Objekte zur Verfügung:
Container: Container
Container: MS Policy Group
Container: Organisationseinheit
DHCP: Pool

Manuell anlegen geht jedoch sehr wohl:

[code]root@mastersrv:~# udm dhcp/host create \

–superordinate “cn=192.168.168.0,cn=siedl.local,cn=dhcp,dc=siedl,dc=local”
–set host=“testi”
–set hwaddress=“ethernet 00:11:22:33:44:55”
Object created: cn=testi,cn=192.168.168.0,cn=siedl.local,cn=dhcp,dc=siedl,dc=local[/code]

Dieser Client erbt dann auch die Richtlinien von “cn=192.168.168.0,cn=siedl.local,cn=dhcp,dc=siedl,dc=local”, worum es mir eigentlich geht.

Wo habe ich die “Best Practice” verlassen?

(wir haben intern noch die 4.0.1 - der Kunde hat 4.0.3.)

2.)
Wir haben für mehrere VLANs jeweils ein DHCP-Subnet angelegt und mit Richtlinien soweit angepasst, dass nur bekannte Clients gemäß ihrer MAC-Adresse eine ganz bestimmte IP bekommen. Dazu gibt es ja in den Richtlinien die Möglichkeit bei “Unbekannte Clients” auf “Deny” oder “Ignore” zu stellen, um genau das zu erreichen. (bei der Option steht übrigens, dass sie nicht mehr empfohlen ist, aber leider nicht, was stattdessen empfohlen wird)
Das funktioniert auch wunderbar, aber in der dhcpd.leases -Datei scheinen keine Einträge auf. Lediglich wenn man unbekannte Cients zulässt und diese dann eine freie Adresse zugewiesen bekommen, kann man das in /var/lib/dhcp/dhcpd.leases auch sehen.

Die Frage ist nun also: Wie kann ich sehen, welche aktiven Leases meine bekannten Clients sich wann abgeholt haben und wie lange die Leases noch laufen?
Kann man mit UCS-Bordmitteln eigentlich auch sehen, welche Clients momentan laufen?

TIA,
Roland.

Moin,

Das ist ein bekannter Bug in UCS.

[quote]Die Frage ist nun also: Wie kann ich sehen, welche aktiven Leases meine bekannten Clients sich wann abgeholt haben und wie lange die Leases noch laufen?
Kann man mit UCS-Bordmitteln eigentlich auch sehen, welche Clients momentan laufen?[/quote]

Das geht momentan nicht. Es war ursprünglich als Feature für 4.1 geplant, musste dann aber aufgrund von Zeitmangels verschoben werden. Laut Univention ist es »für die nahe Zukunft geplant«.

Super, danke.

Beim gleichen Kunden hatten wir heute morgen folgendes Problem: DHCP hat in der Früh nicht funktioniert.
Das Problem begann aus heiterem Himmel gestern (Feiertag in Österreich - daher ist es erst heute früh aufgefallen) um ca. 10 Uhr:

Dec 8 09:48:51 ucs-master dhcpd: DHCPACK to 10.1.4.201 (00:01:80:7e:0d:d0) via eth0 Dec 8 09:53:54 ucs-master dhcpd: DHCPINFORM from 10.1.4.201 via 10.1.4.254 Dec 8 09:53:54 ucs-master dhcpd: DHCPACK to 10.1.4.201 (00:01:80:7e:0d:d0) via eth0 Dec 8 09:53:54 ucs-master dhcpd: DHCPINFORM from 10.1.4.201 via 10.1.4.253 Dec 8 09:53:54 ucs-master dhcpd: DHCPACK to 10.1.4.201 (00:01:80:7e:0d:d0) via eth0 Dec 8 09:56:57 ucs-master dhcpd: Error: Cannot find LDAP entry matching (&(objectClass=dhcpServer)(cn=ucs-master)) Dec 8 09:56:57 ucs-master dhcpd: Configuration file errors encountered -- exiting Dec 8 09:57:02 ucs-master dhcpd: Error: Cannot find LDAP entry matching (&(objectClass=dhcpServer)(cn=ucs-master)) Dec 8 09:57:02 ucs-master dhcpd: Configuration file errors encountered -- exiting Dec 8 09:57:12 ucs-master dhcpd: Error: Cannot find LDAP entry matching (&(objectClass=dhcpServer)(cn=ucs-master)) Dec 8 09:57:12 ucs-master dhcpd: Configuration file errors encountered -- exiting Dec 8 09:57:32 ucs-master dhcpd: Error: Cannot find LDAP entry matching (&(objectClass=dhcpServer)(cn=ucs-master)) Dec 8 09:57:32 ucs-master dhcpd: Configuration file errors encountered -- exiting Dec 8 09:58:12 ucs-master dhcpd: Error: Cannot find LDAP entry matching (&(objectClass=dhcpServer)(cn=ucs-master))

Reboot des Servers brachte keine Besserung. Erst nach einem erneuten Ausführen des join-Skripts 25univention-dhcp lief es wieder wie gewohnt.
In der UMC wurde unter “Domain Join” nicht angezeigt, dass ein Join-Skript fehlgeschlagen wäre. (es hat ja auch schon einen Tag lang funktioniert)

Das folgende LDAP-Objekt wurde dabei neu angelegt:

dn: cn=ucs-master,cn=buero.ginzinger.com,cn=dhcp,dc=buero,dc=ginzinger,dc=com objectClass: top objectClass: dhcpServer objectClass: univentionObject dhcpServiceDN: cn=buero.ginzinger.com,cn=dhcp,dc=buero,dc=ginzinger,dc=com univentionObjectType: dhcp/server cn: ucs-master structuralObjectClass: dhcpServer entryUUID: e31987ca-3280-1035-83ef-93ee52111c03 creatorsName: cn=admin,dc=buero,dc=ginzinger,dc=com createTimestamp: 20151209052438Z entryCSN: 20151209052438.796857Z#000000#000#000000 modifiersName: cn=admin,dc=buero,dc=ginzinger,dc=com modifyTimestamp: 20151209052438Z

Im LDIF-Backup von heute um Mitternacht war es nicht vorhanden.

Die UCR-Variable dhcpd/ldap/base ist (nach wie vor) gesetzt.

Wie kann es sein, dass es verschwindet?
Wo kann ich den Fehler suchen?

LG,
Roland.

Eventuell ist es versehentlich bei Ihren Verschiebe-Tests mit verschwunden? Falschen Button angeklickt, oder das falsche Objekt verschoben? Beim Test des Löschens aus Versehen ein DHCP-Server-Objekt ausgewählt gehabt anstelle eines Hosts?

Nein, das kann ausgeschlossen werden.
Gestern war wie gesagt Feiertag und niemand hat gearbeitet.

War das Objekt denn in dem Backup vom Tag davor noch enthalten?

Mir ist nicht bekannt, dass ein DHCP-Server-Objekt irgendwann gelöscht wird. Allerhöchstens, wenn auf dem betroffenen Server das Paket univention-dhcp entfernt wird. Aber nicht mal in dessen prerm- und postrm-Scripten wird etwas mit dem LDAP/UDM gemacht.

Ja, am Montag war das Objekt noch da:

dn: cn=ucs-master,cn=buero.ginzinger.com,cn=dhcp,dc=buero,dc=ginzinger,dc=com objectClass: top objectClass: dhcpServer objectClass: univentionObject dhcpServiceDN: cn=buero.ginzinger.com,cn=dhcp,dc=buero,dc=ginzinger,dc=com univentionObjectType: dhcp/server cn: ucs-master structuralObjectClass: dhcpServer entryUUID: eb745632-2d5a-1035-97e3-1371444f2db2 creatorsName: cn=admin,dc=buero,dc=ginzinger,dc=com createTimestamp: 20151202161016Z entryCSN: 20151202161016.124127Z#000000#000#000000 modifiersName: cn=admin,dc=buero,dc=ginzinger,dc=com modifyTimestamp: 20151202161016Z

Sie können ja mal auf dem DC Master in »/var/log/univention/directory-logger.log*« schauen, wann und wie genau das Objekt angefasst wurde. Vielleicht gibt das einen Hinweis…

Das Paket univention-directory-logger war leider nicht installiert, aber wir werden das nun nachholen, um der Sache auf den Grund zu gehen, falls es wieder vorkommen sollte.

Schade :slight_smile: Den kann ich wirklich wärmstens für alle UCS-Installationen empfehlen, gerade um das nachträgliche Debugging zu erleichtern.

Mastodon