DNS startet nicht automatisch

UCS - Univention Corporate Server
#1

Hallo,

als neuer UCS Anwender bin ich ein wenig hilflos, was die Fehlersuche angeht. Das Produkt sieht ja toll aus, wenn ich es auch noch zu funktionieren bringen könnte, wäre das ideal.

Mein Problem ist folgendes:
Ich habe den UCS als PDC installiert. Das ging schon einmal gut. Danach konnte ich auch einen meiner W7 PC in die Domäne hängen. Nun habe ich die IP-Adresse des Server geändert und nach einem Neustart war die NETLOGON-Freigabe, eigentlich der ganze SMB Server nicht erreichbar. Ein Kontrolle der Domain-Joins ergab, dass der samba4-dns aud “due” war. daraufhin habe ihc ihn ausgeführt und nu springt der DNS nach enem reboot nicht an. von der Kommandozeile kann ich ihn starten /etc/init.d/univention-bind start und /etc/init.d/univention-bind-proxy start und die Auflösung geht, jedoch werden neue Hostname (A Records) nicht aufgelöst, obwohl im DNS eingetragen.

Was passt dem Ding nicht?

Danke für die Hilfe!

#2

Hallo,

könnten Sie bitte einmal schildern, auf welchem Weg Sie die IP-Adresse geändert haben?
Desweiteren wäre es interessant, ob der Windows 7 Client zuvor (mit “alter” IP) erfolgreich in die Domäne gejoined und getestet werden konnte.

Mit freundlichen Grüßen,
Tim Petersen

#3

Guten Tag!

Danke für das Feedback.

Ich habe den UCS mit (abgeänderte IP-Adresse) 10.12.12.249 installiert. Nach der Installation habe ich Windows 7 Client erfolgreich in die Domäne gejoined. Auch mehrere Reboots des UCS ware problemlos. Danach habe ich via UCS Management Console unter Basic Settings -> Network die Adresse von eth0 (ist das einzige Interface) auf 10.12.12.253 korrigiert und gespeichert. Seit dem ist der Server unter der neuen Adresse erreichbar, jedoch konnte von den Windows Cliente keine Anmeldung durchgeführt werden (Domaincontroller nicht erreichabr). Daraufhin habe ich in der UMC unter Domain join gesehen, dass beim univention-samba4-dns statt “successful” “due” stand, woraufhin ich den join mittels klick auf due durchgeführt habe. Dieser war auch erfolgreich, nun zeigt das System “successful” an und weitere Windows 7 Client können der Domäne beitreten. Rebootet man den UCS startet der bind Dienst nicht. Im UMC erhält man eine Fehlermeldung, wenn man versuch den Dienst manuell zu starten.
“Internal module error: An error occured during command processing.
Server error message:
Starting the following services failed: bind”

Über die Komanndozeige kann man die bind - Diesnte jedoch z.B. mittels /etc/init.d/univention-bind starten.

Danke für die Hilfe!

Gruß,

Christoph Huber

#4

Sehr geehrter Herr Huber,

bezüglich der Fehlermeldung in der UMC2 beim beenden des Dienstes habe ich einen entsprechenden Eintrag in unserem Bugtracking-System erzeugt.
Das Handling des Bind wurde zu UCS 3.0-0 derart angepasst, so dass die Dienste univention-bind und univention-bind-proxy gemeinsam über das Init-Skript /etc/init.d/bind9 gestartet und gestoppt werden können.
Beachten Sie hierbei bitte, dass die “alten” Init-Skripte univention-bind und univention-bind-proxy zur Abwärtskompatibiltät nach wie vor verwendbar sind.

Könnten Sie bitte einmal verifizieren, dass der Bind nach einem Reboot nicht läuft?
Hierzu könnten Sie uns am einfachsten einmal die Ausgabe der folgenden Befehle zukommen lassen:

ps aux | grep named ucr get bind/autostart

Haben Sie den “alten” Windows-Client über DHCP konfiguriert? Unter Umständen ist es ansonsten auch denkbar, dass hier der Nameserver oder beispielsweise der WINS-Server (sofern eingetragen) nach dem Ändern der IP-Adresse des Masters nicht von Ihnen aktualisiert wurden.
Sollte dies nicht der Fall sein, ist es vermutlich ausreichend wenn Sie das System über die Windows-Funktionalität neu in die Domäne joinen.

[quote=“chuber”]
[…]Daraufhin habe ich in der UMC unter Domain join gesehen, dass beim univention-samba4-dns statt “successful” “due” stand, woraufhin ich den join mittels klick auf due durchgeführt habe.[…][/quote]
Unter Umständen ist die Bezeichnung “Join” an dieser Stelle etwas verwirrend - an dieser Stelle werden lediglich die UCS-spezifischen, sogenannten Join-Skripte, der UCS-Domäne verwaltet. Sehen Sie hierzu gern auch einmal das Dokument UCS Domaenenkonzept.

Mit freundlichen Grüßen,

Tim Petersen

#5

Guten Tag Herr Petersen!

Danke für die Inforamationen. Jetzt ist mir zumindest einmal klar, warum es soviele verschiedene bind Dienste auf UCS gibt. Ich werde mich daher zukünftig immer nur auf den bind9 beschränken.

Um auch meinerseits Mißverständnissen vorzubeugen, möchte ich nochmals festhalten, dass das Joinen von Windows Clients in die Domäne funktioniert, wenn ich den bind Dienst manuell via Kommandozeie starte. Der Start via GUI schlägt mit der gleichen Meldung fehl wie der Stop.

Nach einem Reboot läuft der bind-Prozess definitiv nicht.

Hier das Ergebnis der Kommandos nach frisch gebootetem Server:

Ich werde mir gerne das Domänenkonzept ansehen - Danke für den Querverweis. Wobei mir schon klar war, dass es sich bei den Einträge unter Domain Join um Systemvorbereitungsskripte handelt, die dem Aufbau der UCS Domänenstruktur dienen.

Danke für die Hilfe!

Beste Grüße,

Christoph Huber

#6

Sehr geehrter Herr Huber,

zur weiteren Analyse des Verhaltens wäre es gut, wenn Sie uns ein nach SDB-Artikel #1174 erstelltes Univention-Support-Info Archiv zukommen lassen könnten.
Um uns das Archiv zur Verfügung zu stellen, verwenden Sie am einfachsten den im SDB-Artikel erwähnten Upload auf upload.univention.de. Ich werde das Archiv dann bei uns entsprechend verknüpfen.

Mit freundlichen Grüßen,
Tim Petersen

#7

Guten Abend Herr Petersen!

Das Supportpaket ist upgeloaded (upload_rnRJXZ.bz2). Ich hoffe, dass damit das Mysterium gelöst werden kann.

Vielen Dank für die Unterstützung!!

Beste Grüße,

Christoph Huber

#8

Hallo Herr Petersen,

ich ein paar Tage weg. Konnte das Supportpaket bei der Problemsuche helfen?

Danke und beste Grüße

Christoph Huber

#9

Hallo Herr Huber,

ich habe parallel bisher leider ohne Erfolg versucht, das von Ihnen beobachtete Verhalten nachzustellen.
Im Support-Info-Archiv fällt unter anderem auf, dass der univention-directory-notifier nicht läuft - ist dies derzeit noch immer der Fall?

ps aux | grep notifier

Ich schlage hier folgendes weiteres Vorgehen vor, um das Verhalten weiter eingrenzen zu können:
[ul]
[li]1. Erhöhen des Debuglevels
Hierzu editieren Sie bitte die Datei /etc/runit/univention-bind-samba4/run und passen die Zeile “OPTS=”-c /etc/bind/named.conf.samba4 -f"" folgendermaßen an:
“OPTS=”-d4 -c /etc/bind/named.conf.samba4 -f""
[/li]
[li]2. Sammeln weiterer Informationen
Anschließend rebooten Sie das System bitte einmal und lassen uns folgende Dateien zukommen:
/var/log/syslog
/var/log/daemon.log[/li][/ul]

Mit freundlichen Grüßen,
Tim Petersen

#10

Hallo Herr Petersen!

Der Notifier dürfte laufen:

[quote]root@ucsdc01:~# ps aux | grep notifier
root 1838 0.0 0.0 112 28 ? Ss Mar14 0:00 runsv univention-directory-notifier
root 20441 0.0 0.1 3304 764 pts/0 S+ 12:46 0:00 grep notifier
root@ucsdc01:~# [/quote]

und nach dem Reboot auch:

[quote]root@ucsdc01:~# ps aux | grep notifier root 1832 0.0 0.0 112 28 ? Ss 12:49 0:00 runsv univention-directory-notifier
root 2676 0.0 0.1 3308 776 pts/0 S+ 12:56 0:00 grep notifier
root@ucsdc01:~#
[/quote]

Hier nun auch gleich die beiden Log-Files.
Das syslog als upload_yetLBz.unknown
Das daemon.log als upload_Bd3UYp.asc

Danke für die Hilfe!

Beste Grüße,

Christoph Huber

#11

Hallo Herr Huber,

aus der angehängten Ausgabe wird ersichtlich, dass lediglich der runsv läuft (runsv univention-directory-notifier). Der Notifier selbst scheint nicht starten zu können.
Könnten Sie bitte einmal folgende Schritte durchführen:

ucr set notifier/debug/level="4" invoke-rc.d univention-directory-notifier restart

Im Anschluss hängen Sie hier bitte die Datei “/var/log/univention/notifier.log” an.

Mit freundlichen Grüßen,
Tim Petersen

#12

Hallo Herr Petersen!
Danke für die Antwort. Das Log ist als upload_ovSKf3.asc upgeloaded.

Beste Grüße,

Christoph Huber

#13

Hallo Herr Huber,

es scheint hier parallel Probleme im LDAP zu geben.
Leider ist es schwer nachzuvollziehen, wie es zu der aktuellen Situation gekommen ist - da der Notifier beim Starten aber Probleme mit einer DNS-Zone hat, ist ein Zusammenhang zu den von Ihnen beobachteten Bind-Problemen wahrscheinlich.

Könnten Sie uns bitte einmal die Datei /var/lib/univention-ldap/notify/transaction und die Ausgabe des Befehls “udm dns/forward_zone list”(als root) per Mail an feedback@univention.de zukommen lassen?

Mit freundlichen Grüßen,
Tim Petersen

#14

Guten Tag Herr Petersen!

Vielen Dank für die bisherige Unterstützung. Das Email ist unterwegs!

Beste Grüße,
Christoph Huber

#15

Sehr geehrter Herr Huber,

da es sich nur sehr schwer nachvollziehen lässt, was hier genau die Ursache des aktuellen Verhaltens ist und was dieses hervorgerufen hat, wäre an dieser Stelle ein Remote-Zugriff oder Ähnliches vermutlich die einzig sinnvolle Möglichkeit, das Verhalten tiefer zu analysieren.
Aufgrund der Tatsache, dass uns dieses Verhalten so nicht bekannt ist und ich es hier bisher nicht nachstellen konnte, gehe ich auch nicht von einem generischen Problem aus.
Leider kann die weitere Bearbeitung allerdings nicht im Rahmen der kostenlosen Unterstützung im Forum erfolgen. Sollten Sie eine weitere Bearbeitung wünschen, können Sie sich aber selbstverständlich gern an unsere Vertriebsabteilung (vertrieb@univention.de) wenden.

Sollte sich das System gegenwärtig noch nicht im produktiven Einsatz befinden bzw. noch nicht viele Clients, etc. eingebunden sein würde ich vermuten, dass eine Neuinstallation des Masters den schnellsten Weg zu einem sauber funktionierenden System für Sie darstellt.

Mit freundlichen Grüßen,
Tim Petersen

#16

Guten Tag Herr Petersen!

Danke für die bisherigen Bemühungen. Dies ist bereits die 3. Instllation des Systems, die mit exakt dem gleichen Problem kämpft (das System habe ich vor Post im Forum schon 2x installiert, da es immer wieder Probleme mit dem bind gab). Das Problem scheint also weniger generisch als systemisch zu sein.
Da ich die Plattform für den Einsatz bei verschiedenen KMUs als Alternaitive zu Windows evaluieren wollte, ist auch der Schaden derzeit noch nicht groß. Es sind lediglich zwei Clients angebunden. Wahrscheinlich ist jedoch der Einsatz vom Microsoft Windows Server auch im KMU-Bereich mit richtigem Augenmaß sinnvoller, zumal die verfügbaren Samba/AD Lösungen eigenlich alle mit seltsamen Problemen kämpfen und bei dieser Zielgruppe ein umfangreiches Troubleshooting mit den erheblichen Standzeiten nicht rentabel ist.

Danke nochtmals für den Support. Ich denke, dass dies das Ende unseres Ausflugs in die alternativen zu Microsoft Server für AD Dienste und Co ist.

Beste Grüße,

Christoph Huber

#17

Sehr geehrter Herr Huber,

aufgrund der bisher unbekannten Tatsache, dass Sie die Installation bereits 3 mal durchgeführt haben und drei mal dieses, uns unbekannte Verhalten reproduzieren konnten, würde ich gern noch einmal nachfragen.
Da wir das Verhalten hier nicht reproduzieren können, wäre es gut wenn Sie in einem ersten Schritt einmal ein aktuelles ISO von unserem Downloadserver beziehen würden, um alle Eventualitäten ausschließen zu können.

Im Anschluss wäre es gut, wenn Sie einmal evaluieren könnten, dass mit der bisher verwendeten Konfiguration die Installation ohne Fehlermeldungen durchläuft und das System im Anschluss kein fehlerhaftes Verhalten aufweist.
Sollten Sie die bisher von Ihnen beobachteten Auffälligkeiten erneut beobachten können, so melden Sie sich bitte erneut zurück und schildern uns die verwendete Konfiguration für die Installation.
hierzu können Sie uns am einfachsten die folgenden Dateien direkt nach der Installation bereitstellen:

/var/log/univention/installation.log /var/log/univention/installer.log /etc/univention/installation_profile
Mit freundlichen Grüßen,
Tim Petersen

#18

Guten Tag Herr Petersen!

Danke für Information und das Bemühen. Ich werde bei guter Gelegenheit versuchen, eine neue Installation durchzuführen. Was mich jedoch stört ist die Tatsache, dass offenbar der Fehler werde auffindbar noch einschränkbar ist. Sollte so etwas bei Kunden auftreten, ist das durchwegs problematisch.
Bei allen drei Versuchen trat das Problem nach der Adressenänderung auf.

lG

Christoph Huber

#19

Sehr geehrter Herr Huber,

ich nehme an, dass Sie das System als Gast unter einer VMWare-Virtualisierungslösung mit installierten VMWare-Tools betrieben haben?
Genau in diesem Szenario konnte das von Ihnen beschrieben Verhalten nun erneut beobachtet und auch zuverlässig reproduziert werden.
Es scheint so zu sein, dass es durch die Installation der VMWare-Tools zu Timing-Problemen in der Abarbeitung der Startskripte kommt, so dass die Dienste Univention-Directory-Notifier und Bind beim Boot nicht gestartet werden können.

Hierzu wurde ein Eintrag in unserem Bugtracking-System angelegt: [bug]26848[/bug], welcher über ein kommendes Errata-Update behoben werden wird.

Ich hoffe, Sie haben Verständnis dafür, dass sich die Ursachenforschung hier aufgrund der stark umgebungsabhängigen Konstellation entsprechend schwierig gestaltet hat.

Mit freundlichen Grüßen,
Tim Petersen

#20

Guten Tag Herr Petersen!

Vielen Dank für die Nachricht. Ja, die Maschine ist virtualisiert und VMWare ESXi

Es freut mich, dass Sie das Fehlerszenario nachvollziehen konnten. Damit bleibe ich in Warteposition und hoffe auf eine baldige Umgehung oder Behebung.

Vielen Dank für das Bemühen!

Beste Grüße,

Christoph Huber

Mastodon