Univention Bugzilla – Bug 26211
backup2master passt Samba4 Service-Records für Global Catalog nicht an
Last modified: 2012-07-20 15:25:10 CEST
Folgende Service Records müssten durch backup2master zusätzlich angepasst werden: _gc._tcp.ucs3s4x2.qa has SRV record 0 100 3268 master.ucs3s4x2.qa. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.ucs3s4x2.qa has SRV record 0 100 3268 master.ucs3s4x2.qa. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.ucs3s4x2.qa has SRV record 0 100 3268 master.ucs3s4x2.qa. _gc._tcp.Default-First-Site-Name._sites.ucs3s4x2.qa has SRV record 0 100 3268 master.ucs3s4x2.qa. _ldap._tcp.fa8f7274-25f2-4109-9a46-74b4e20347a6.domains._msdcs.ucs3s4x2.qa has SRV record 0 100 389 master.ucs3s4x2.qa.
Created attachment 4208 [details] Script zum Auslesen üblicher Service-Records
Es geht hier um den Einsatz von backup2master auf einem server, der als LDAP backup mit Samba-server installiert wurde. Dieser server soll master werden und gleichzeitig eine ordentliche Samba-Konfiguration haben. Der Test, ob die Samba-Konfiguration ordentlich ist, geht mit dem script /usr/share/univention-samba4/scripts/check_essential_samba4_dns_records.sh und kann auf 10.200.32.2 ausprobiert werden.
In meiner Test-Umgebung aus master und backup hab ich mal das script backup2master aufgerufen und kann hier das Problem reproduzieren. Nach dem Umschalten gab es im AD noch folgende Referenzen auf den alten master (ucs30-64-dc). host -t SRV -l jkahrs.dev | grep ucs30-64-dc _ldap._tcp.pdc._msdcs.jkahrs.dev has SRV record 0 100 389 ucs30-64-dc-smb.jkahrs.dev. _kerberos._tcp.dc._msdcs.jkahrs.dev has SRV record 0 100 88 ucs30-64-dc-smb.jkahrs.dev. _gc._tcp.Default-First-Site-Name._sites.jkahrs.dev has SRV record 0 100 3268 ucs30-64-dc-smb.jkahrs.dev. _ldap._tcp.Default-First-Site-Name._sites.jkahrs.dev has SRV record 0 100 389 ucs30-64-dc-smb.jkahrs.dev. _kerberos._tcp.Default-First-Site-Name._sites.jkahrs.dev has SRV record 0 100 88 ucs30-64-dc-smb.jkahrs.dev. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.jkahrs.dev has SRV record 0 100 3268 ucs30-64-dc-smb.jkahrs.dev. _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.jkahrs.dev has SRV record 0 100 389 ucs30-64-dc-smb.jkahrs.dev. _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.jkahrs.dev has SRV record 0 100 88 ucs30-64-dc-smb.jkahrs.dev. _ldap.a0e3a740-cfd3-4f61-a128-e58064b105a2.domains._msdcs.jkahrs.dev has SRV record 0 100 389 ucs30-64-dc-smb.jkahrs.dev. _ldap._tcp.f1dccdc1-dc88-4123-b85f-dd199fbd43a1.domains._msdcs.jkahrs.dev has SRV record 0 100 389 ucs30-64-dc-smb.jkahrs.dev.
Stefan hat gestern noch mal erklärt, wie er die Änderungen implementiert haben möchte. backup2master soll die Umschaltung allein mit den Mitteln von UDM löst. D.h. soll also in den richtigen UDM-Modulen das Ändern der Namen auslösen. Anschließend kann die Wirkung der Änderungen mit Hilfe des o.g. scripts check_essential_samba4_dns_records.sh überprüft werden. Auf die "low-level" tools wie ldapmodify soll im Rahmen dieses bugs nicht zurückgegriffen werden. Beim Ändern von SRV records solen die vorhandenen Record-Einträge wie port und prio erhalten bleiben, nur der Name des alten masters soll geändert werden. Falls bisher master und backup irgendwo beide eingetragen waren, soll nur der des neuen masters erhalten bleiben, keine doppelten Einträge.
Wenn auf einem server SAMBA aktiv ist, dann werden für die Konfiguration von SAMBA im LDAP neue server-Namen nach dem Muster xxx-smb angelegt. Diese neuen Namen stimmen nicht überein mit dem hostname des servers. Wo kommen die Namen xxx-smb her ? Kann ich diese Namen einfach so "mitbearbeiten" oder ist das komplizierter ? Gibt es noch mehr solche Namen, die ich berücksichtigen muss ? Unangenehmer wird die Sache noch dadurch, dass auch in UDM-Modulen, die nichts mit SAMBA zu tun haben, diese neuen Namen auftauchen. dns/forward_zone dns/reverse_zone shares/share Im Rahmen von Bug #10038 und Bug #16789 hatte ich das eigentlich gerade zum Laufen gebracht, nun treten diese bugs im backup2master aber wieder auf, weil das "nameserver" Attribut dieser Module nun die Namen der Machart xxx-smb enthält.
Das Problem mit dem Namen xxx-smb war ein Fehler von mir, ich hatte vergessen, dass ich selbst den alten master so benannt hatte. Im script backup2master sind nun die meisten Attribute aus dem LDAP berücksichtigt und werden ordentlich ersetzt. Zum Testen habe ich folgende scripts verwendet: 1. check_essential_samba4_dns_records.sh | grep -i ucs30-64-dc-smb Der alte master existiert nicht mehr in den records. 2. Das script aus dem attachment findet auch keine Referenzen mehr. 3. ./univention-backup2master -c ucs30-64-dc-smb -f | grep -i ucs30-64-dc-smb Die Option -c des scripts such im gesamten LDAP nach strings und findet ein paar Stellen mit dem Namen des alten masters. Das sind aber fast alles Namen von Containern und das ist erlaubt, weil es nur Namen von Containern sind und keine echten Referenzen auf den alten master. dn: uid=dns-ucs30-64-dc-smb,cn=users,dc=jkahrs,dc=dev dn: cn=ucs30-64-dc-smb.jkahrs.dev,cn=shares,dc=jkahrs,dc=dev dn: cn=Heimat von Ruprecht,cn=ucs30-64-dc-smb.jkahrs.dev,cn=shares,dc=jkahrs,dc=dev dn: krb5PrincipalName=ldap/ucs30-64-dc-smb.jkahrs.dev@JKAHRS.DEV,cn=kerberos,dc=jkahrs,dc=dev Nur die letzte Fundstelle (krb5PrincipalName) ist ein Problem. Stefan sagt sie soll gelöscht werden. Sie kann aber nicht mit den Mitteln von udm gelöscht werden sondern nun mit ldapdelete. Ich muss noch klären, wie das geht.
Einen schönen einfach Test habe ich noch vergessen zu erwähnen: 4. host -t SRV -l jkahrs.dev | grep -i ucs30-64-dc-smb Auch der verläuft schon jetzt erfolgreich, d.h. er enthält keine Referenzen auf den alten master mehr.
Ich habe das script backup2master so geändert, dass es in allen vorhandenen SRV records nach Referenzen auf den alten master sucht und eine interaktive Änderung vorschlägt. Im Paket univention-ldap habe ich debian/changelog aktuallisiert und aus dem Paket alle binären Pakete bauen lassen. Nach dem Bauen konnten die binären Pakete mit "apt-get upgrade" installiert werden. Es waren in den SRV records keine veralteten Referenzen mehr vorhanden. Ich habe diese Änderung im changelog des Handbuchs eingetragen.
In meiner Testumgebung gibt es einen Traceback, da ein UDM-Modul mit unvollständigen Argumenten aufgerufen wird, komplettes Log hängt an: Für das Attribut location wird ein leerer Wert ausgelesen und als Argument übegeben: udm dns/srv_record modify --dn relativeDomainName=_ldap._tcp,zoneName=jmm302.test,cn=dns,dc=jmm302,dc=test --set location= Das führt zu folgendem Traceback: Traceback (most recent call last): File "/usr/share/univention-directory-manager-tools/univention-cli-server", line 233, in doit output = univention.admincli.admin.doit(arglist) File "/usr/lib/pymodules/python2.6/univention/admincli/admin.py", line 387, in doit out=_doit(arglist) File "/usr/lib/pymodules/python2.6/univention/admincli/admin.py", line 946, in _doit out.extend(object_input(module, object, input, append, remove)) File "/usr/lib/pymodules/python2.6/univention/admincli/admin.py", line 361, in object_input object[key]=[val] UnboundLocalError: local variable 'val' referenced before assignment In der Folge wird der Record _ldap._tcp nicht angepasst.
Created attachment 4492 [details] Log eines B2M mit Traceback
OK, wir haben noch ein grundsätzliches Problem. Moritz hat es an folgendem UDM-Eintrag provozieren können. Jedes Attribut (z.B. "nameserver" oder "location" kann mehrfach pro DN vorkommen. udm dns/srv_record list --superordinate zoneName=$domainname,cn=dns,$ldap_base DN: relativeDomainName=_ldap._tcp,zoneName=jmm302.test,cn=dns,dc=jmm302,dc=test ARG: None zonettl: 3 hours name: None location: 0 100 7389 master.jmm302.test. location: 0 100 7389 backup.jmm302.test. location: 0 100 389 master.jmm302.test. b2m hat bei der Auflösung der Referenzen bisher mit "udm --set" ein Setzen der Attribute gemacht; korrekt wäre es aber erst mit "udm --append" das neue Attribut hinzuzufügen und danach mit "udm --remove" das alte Attribut zu entfernen.
Ich habe es so implementiert wie im vorigen Kommentar beschrieben. Nachdem ich einen backup-Rechner mit Hilfe von b2m konvertiert habe, sieht (nach einem reboot) sieht der udm-Eintrag nun so aus: udm dns/srv_record list --superordinate zoneName=$domainname,cn=dns,$ldap_base DN: relativeDomainName=_ldap._tcp,zoneName=jkahrs.dev,cn=dns,dc=jkahrs,dc=dev ARG: None zonettl: 3 hours name: None location: 0 100 389 ucs30-64-backup.jkahrs.dev. Es gab keinen Traceback aus udm und die udm-Einträge sahen plausibel aus.
Created attachment 4532 [details] Bei all diesen SRV Records wird der Administrator einzeln gefragt, ob sie angepasst werden sollen. Die 21 Rückfragen zu well known SRV Records könnten deutlich gekürzt werden. Am einfachsten wäre vermutlich eine whitelist relativeDomainName=_gc._tcp relativeDomainName=_ldap._tcp relativeDomainName=_kpasswd._tcp ... Nach 10 fast identischen Fragen dürfte der Aufmerksamkeitslevel des Administrators ungefähr Homer Simpson Level erreicht haben, sodass potentiell wirklich wichtige Rückfragen blind bestätigt werden. Die SRV Records, die GUIDs enthalten kann/sollte man vermutlich nicht einfach whitelisten, da sind Rückfragen IMHO ok.
Die Domain GUID, die in _ldap._tcp.$Domain_GUID.domains._msdcs kennzeichnet, kann man ebenfalls bestimmen: Domain_GUID="$(ldbsearch -H /var/lib/samba/private/sam.ldb -b "$samba4_ldap_base" -s base objectGUID | sed -n 's/^objectGUID: \(.*\)/\1/p')" Den Record _ldap.$Partition_GUID.domains._msdcs kann man ignorieren oder auf Rückfrage entfernen (siehe Bug 26325): Partition_GUID="$(ldbsearch -H /var/lib/samba/private/sam.ldb -b "CN=$windows_domain,CN=Partitions,CN=Configuration,$samba4_ldap_base" objectGUID | sed -n 's/^objectGUID: \(.*\)/\1/p')"
(In reply to comment #13) > Created an attachment (id=4532) [details] > Bei all diesen SRV Records wird der Administrator einzeln gefragt, ob sie > angepasst werden sollen. > > Die 21 Rückfragen zu well known SRV Records könnten deutlich gekürzt werden. Am > einfachsten wäre vermutlich eine whitelist > relativeDomainName=_gc._tcp > relativeDomainName=_ldap._tcp > relativeDomainName=_kpasswd._tcp > ... > > Nach 10 fast identischen Fragen dürfte der Aufmerksamkeitslevel des > Administrators ungefähr Homer Simpson Level erreicht haben, sodass potentiell > wirklich wichtige Rückfragen blind bestätigt werden. Die SRV Records, die GUIDs > enthalten kann/sollte man vermutlich nicht einfach whitelisten, da sind > Rückfragen IMHO ok. Ja, das habe ich an Bug #27741 ergänzt.
Ich kann die QA nicht machen, da ich Teile davon implementiert habe.
Verified: * Records werden angepasst * Der S4 Connector legt danach neu im UDM angelegten Benutzer korrekt in Samba4 an * Changelog OK
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".