AD-Takeover: Abbruch bei "take_over_domain"

[MKunert]

“Active Directory Takeover” ist bei mir im letzten Schritt (nach dem Kopieren von SYSVOL und Abschalten des Windows-Domänencontrollers) auf einen Fehler gelaufen:

Ein Fehler ist aufgetreten: Die Ausführung des Kommandos 'take_over_domain' ist fehlgeschlagen: Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/management/console/modules/adtakeover/__init__.py", line 60, in _background result = func(self, request) File "/usr/lib/pymodules/python2.7/univention/management/console/modules/adtakeover/__init__.py", line 119, in take_over_domain takeover.take_over_domain(self.progress) File "/usr/lib/pymodules/python2.7/univention/management/console/modules/adtakeover/takeover.py", line 349, in take_over_domain takeover_final.create_reverse_DNS_records() File "/usr/lib/pymodules/python2.7/univention/management/console/modules/adtakeover/takeover.py", line 1664, in create_reverse_DNS_records p = subprocess.Popen(["univention-ipcalc6", "--ip", self.ad_server_ip, "--netmask", self.ucr["interfaces/%s/netmask" % self.primary_interface], "--output", "pointer", "--calcdns"], stdout=subprocess.PIPE, stderr=subprocess.PIPE) AttributeError: AD_Takeover_Finalize instance has no attribute 'primary_interface'
Konfigurationsdetails, die vielleicht relevant sind:
[ul][li]IPv6 ist nicht konfiguriert[/li]
[li]Die physischen Netzwerkschnittstellen eth0 und eth1 sind zu bond1 zusammengefasst, bond1 ist als “Primäres Netzwerkgerät” im System bekannt[/li]
[li]Der verbleibende DNS-Nameserver läuft mit dnsmasq auf dem Gateway (“entfernter Rechner”, 192.168.0.1)[/li][/ul]

Wo liegt das Problem genau? Was kann ich tun, um den Takeover zu retten?
h.i.l.f.e.!

[MKunert]

Je länger ich mir die Protokolle anschaue, desto plausibler erscheint mir die Annahme, dass eigentlich alles ok gelaufen ist - der Abbruch wird in der ad-takeover.log mit folgender Meldung quittiert:Warning: Could not determine primary IPv4 network interface. Failed to setup a virtual IPv4 network interface with the AD IP address.Habe das zwar noch nie gemacht, halte die Aufgabe “virtuellen IP-Adress-Alias für Bonding-Interface einrichten” aber für lösbar …
Weiß jemand, welche wichtigen “logischen Schritte” das ad-Takeover-Skript nach der Vergabe der virtuellen Alt-AD-IP für den UCS-AD noch so unternimmt?

Anbei die Datei ad-takeover.log - da scheint schon ziemlich viel gut gelaufen zu sein…
ad-takeover.log (42.9 KB)

[MKunert]

Leider auch zu früh gefreut: zwar bietet das UCS-Web-Interface die Möglichkeit, eine zweite IP-Adresse für meine bond1-Schnittstelle zu definieren, das scheitert dann aber beim Speichern der Änderungen:

[quote]Validierungsfehler
Die folgenden Einträge konnten nicht validiert werden:[ul][li]Netzwerkgeräte: bond1: Mehrere IPv4 Adressen sind an diesem Gerät nicht unterstützt.[/li][/ul][/quote]Was jetzt wirklich nicht nachvollziehbar ist. Technisch begründet ist das jedenfalls nicht. Mitroot@ucsdc1:/# ifconfig bond1:1 192.168.0.4 kann ich mir an der Konsole temporär meine zweite IP-Adresse “besorgen”, leider überlebt das aber keinen Server-Neustart.
Wäre schon cool, wenn das über das Interface / die Registry konfigurierbar wäre… guck in Richtung Univention-Entwickler

[MKunert]

So: Fehlende Schritte nach Abbruch in take_over_domain:
[ol][li]create_reverse_DNS_records
Also anlegen der DNS-Einträge, die nach IP-Adressen suchen lassen und Namen zurückgeben (anlegen wo? Im UCS? Im “entfernten” Nameserver?)[/li]
[li]reconfigure_nameserver_for_samba_backend
Leider sehr obskur (auch hier: lokaler oder entfernter Nameserver?)[/li]
[li]create_DNS_SPN
Anlegen von Kerberos service principal names (SPNs) … (im Nameserver? Für den DNS service?)[/li]
[li]configure_SNTP
Konfigurieren des Zeitdienstes[/li]
[li]finalize
Whatevs…[/li][/ol]
Sind diese Prozeduren isoliert lauffähig? Wie muss ich takeover.py pimpen, damit die “restlichen” Schritte ablaufen?
Alternativ: Gibt es eine Übersicht, welche Einstellungen ich in meinem “externen” Nameserver vornehmen muss?

Sinnigerweise konnte ich mich bereits an einem Client mit einem Nutzer anmelden, der sich dort noch nie angemeldet hatte. Die AD-Funktionalität scheint (zumindest teilweise) bereits zu funktionieren …

[MKunert]

Also: wenn das System beim AD-Takeover abbricht, weil keine primäre Schnittstelle identifiziert werden kann (“AD_Takeover_Finalize instance has no attribute ‘primary interface’”), warum auch immer:
[ol][li]create_virtual_IP_alias
Virtuelle IP vergeben
Bei mir (bonding) möglich überifconfig bond1:1 192.168.0.4
[/li]
[li]create_reverse_DNS_records
Anlegen des Reverse-DNS-Eintrags für die “alte” IP im UCS
Also in meinem Beispiel: über das DNS-Modul in der UMC, “Alle DNS-Zonen”–>“192.168.0”, neuer Eintrag “4” (letzter Teil der alten IP-Adresse), Typ “Pointer Record”, Pfad “net.mydomain.local:/dns/0.168.192.in-addr.arpa”

[/li]
[li]reconfigure_nameserver_for_samba_backend
Setzen von nameserver1 auf (UCS-)lokalen Nameserver, setzen von dns/backend auf samba4
Ist beides in meinem Beispiel schon richtig konfiguriert (die Registry-Variable nameserver1/local ist noch vorhanden, tut aber auch nicht weh)

[/li]
[li]create_DNS_SPN
Anlegen und Verknüpfen des service principal names (SPNs) für den DNS-Service in der Samba-LDB, z.B. über

/usr/share/univention-samba4/scripts/create_spn_account.sh --samaccountname 'dns-ucsdc1' --serviceprincipalname 'DNS/ucsdc1.local.mydomain.net' --privatekeytab 'dns-ucsdc1.keytab'Hinweis: Für den Accountnamen ist “dns-” und der Servername im Code fest verdrahtet

[/li]
[li]configure_SNTP
Aktualisieren der Kerberos keytab und konfigurieren des signierten Zeitdienstes

/usr/share/univention-samba4/scripts/create-keytab.sh ucr set ntp/signed='yes' /etc/init.d/ntp restartHinweis: Die letzten beiden Befehle waren bei mir überflüssig - SNTP lief bereits auf meinem UCS

[/li]
[li]finalize
Aufräumarbeiten

univention-run-join-scripts ucr set univention/ad/takeover/completed='yes' ucr unset univention/ad/takeover/ad/server/ip samba-tool dbcheck --fix --yesHinweis: Die ersten drei Befehle waren nicht wirklich entscheidend. Der Samba-DB-Check hat zwei Korrekturen durchgeführt.[/li][/ol]

Glossar der hier verwendeten Installations-individuellen Einstellungen (jeweils je System anzupassen):
Domäne: local.mydomain.net
FQDN des neuen Domänencontrollers: ucsdc1.local.mydomain.net
IP des “alten” AD-Domänencontrollers: 192.168.0.4
Primäres Interface des UCS-Servers: bond1