wieder mal massive Probleme mit Open Directory

  • Ersteller lutzministrator
  • Erstellt am
L

lutzministrator

Aktives Mitglied
Thread Starter
Dabei seit
01.12.2009
Beiträge
152
Reaktionspunkte
3
Ich weiß nicht ob meine OSX Server Installationen ein eingebautes Haltbarkeitsdatum haben, aber irgendwie treten bei mir nach einiger Zeit immer wieder Probleme auf...

Neulich ist wohl die Synchronisierung des Open Directory Masters auf meine (stellenweise über ein Site-to-Site verbundenen) Replikas fehlgeschlagen, jedenfalls haben sie die neuen Benutzereinstellungen nicht übertragen. Ich habe kurzerhand die Replicas in eigenständige Verzeichnisse umgewandelt (wahrscheinlich nicht die eleganteste Methode) um sie anschließend wieder du Replikas zu machen und den Sync erneut anzustoßen.
Hat soweit auch funktioniert, außer dass ich seitdem einen "leeren" Eintrag im Replikbaum habe (merkwürdig #1) und der eine Server den ich seitdem außer Dienst gestellt habe ist ebenfalls noch drin (merkwürdig #2).
Ich habe versucht über "sudo slapconfig -removereplica 192.xx.xx.xx" den alten Server zu löschen was aber mit meinen root-Rechten nicht geklappt hat (merkwürdig #3).

Was mich aber viel mehr gestört hat war, dass mein Arbeitsgruppenmanager auf einmal um ein vielfaches (mind. Faktor 50) langsamer war (merkwürdig #4) ebenso die Open Directory Einstellungen im Server Admin (merkwürdig #5). Außerdem hatte ich plötzlich gigantisch viele Fehlermeldungen à la:

"Aug 22 02:57:20 xserve slapd[66]: *** process 66 exceeded 500 log message per second limit - remaining messages this second discarded ***

Aug 22 02:57:21 xserve slapd[66]: dnssd_clientstub deliver_request: socketpair failed 24 (Too many open files)"
(merkwürdig #6)

Nach mehreren Stunden Webrecherche habe ich mich entschlossen den Prozess zu killen und über Terminal neuzustarten, mit dem prompten Erfolg dass meine OD-Einstellungen im Serveradmin sich wieder reibungslos verändern lassen, die Fehleinträge sind allerdings geblieben. (der Dienst slapd hat sich mit der PID 66 übrigens NICHT wieder gestartet)

Schattenseite dieses Versuchs ist, dass mein VPN seitdem nicht mehr funktioniert (merkwürdig #7). Ich kann zwar den Einwahlversuch im VPN-Protokoll nachvollziehen, aber die Authentifizierung schlägt fehl.

Was ich weiterhin absolut komisch finde (ich hör jetzt mal auf zu zählen) sind massenweise Karteileichen von Computereinträgen die schon lange nicht mehr in meinem Verzeichnis weilen wie z.B.
"Aug 22 17:57:42 xserve slapd[92559]: SASL [conn=2868] Failure: no user in database Rechner14$
Aug 22 17:58:12: --- last message repeated 1 time ---"

Werde es heute Nacht mal mit einem klassichen Neustart probieren, wobei ich da keine großen Hoffnungen habe. Irgendwas ist da Essig aber ich weiß nicht was geschweigedenn wie der auf diese Einträge und das Fehlverhalten kommt.

Meine DNS-Dienste sind richtig konfiguriert und lassen sich prima in beide Richtungen auflösen. Wir haben ca. 40 Clients, also überfordert sollte ein xserve jetzt auch nicht damit sein.

Die Lösungsvorschläge diverser anderer Foren haben mich bis jetzt nicht wirklich weitergebracht, da lag es meistens am DNS. Ich bin mir schon ziemlich sicher, dass es bei mir irgendwo am Verzeichnisdienst hängt, zumal ich es bis heute auch nie geschafft habe einen Benutzer mit seinem OD-Kennwort an einem Rechner anzumelden...

Für einen Fingerzeig in eine Richtung (außer vielleicht die Neuinstallation von 5 Servern oder die Google-Suche) wäre ich wirklich äußerst dankbar!
 
Könnte das dein Problem gewesen sein:

Port 389 oder 636 muss zwischen Master und Replik geöffnet sein, während die Replik deaktiviert wird. LDAP verwendet Port 389, wenn SSL deaktiviert ist, bzw. Port 636, wenn SSL auf dem Master aktiviert ist. (Port 22, der für SSH verwendet wird, braucht nicht geöff- net zu sein, wenn eine Replik deaktiviert wird.)
Wichtig: Wenn Sie eine Replik deaktivieren, während keine Netzwerkverbindung zwi- schen der Replik und dem Master besteht, verbleibt die deaktivierte Replik in der Replik- liste des Masters. Der Master versucht, so an die deaktivierte Replik zu replizieren, wie im Bereich „Allgemein“ für den Open Directory-Dienst auf dem Master-Server angegeben.


Quelle: http://manuals.info.apple.com/de_DE/Open_Directory_Administration_v10.5.pdf
 
Hallo,

ich hatte bei der Deaktivierung leider keine Möglichkeit eine Verbindung herzustellen, die Ports wären hierbei nicht das Problem gewesen...
Es sollte ja wohl irgendwie möglich sein eine Replika anders zu entfernen?
 
mögliche Ursache

OK. Ich glaube ich kann das Problem jetzt eingrenzen:

Aus weiß Gott welchem Grund befindet sich mein OD Verzeichnis in dem Pfad "servername.local/LDAPv3/127.0.0.1" anstatt wie gewohnt "server.domain.de/LDAPv3/127.0.0.1" und das obwohl ich mich im Arbeitsgruppenmanager über den FQDN erfolgreich anmelde.
Auch im Serveradmin finde ich unter den Netzwerkeinstellungen nur noch den "servername.local" als DNS Namen.

Lasse ich hingegen einen "sudo changeip -checkhostname" laufen bekommen ich als Ausgabe die IP und den FQDN (success), also sollte dort alles passen...

Wie kann ich denn das Verzeichnis wieder auf den richtigen DNS-Namen verweisen und diese .local-Verknüpfung wegkriegen?? Und warum in aller Welt verändert sich sowas "selbstständig" (d.h. ich muss wohl irgendwas damit zu tun haben aber das hat sich von heute auf morgen ohne mein dazutun wie Updates, Veränderungen o.ä. ereignet...)??
Letztere war eine rethorische Frage.
 
der weg über changeip ist "eigentlich" nicht mehr der richtige. dafür gibt es es seit 10.6 (oder 10.5?) den befehl scutil.
mit

scutil --get HostName
scutil --get ComputerName
scutil --get LocalHostName

kannst du die drei einträge erst mal kontrollieren. groß/kleinschreibung beachten!
bei unserem server stimmten die auch nicht. mit changeip kommt man hier auch nicht weiter, da die drei namen getrennt voneinander gesetzt werden müssen. wenn man das --get gegen --set austauscht kann man die namen ändern.
HostName ist übrigens der fqdn. ComputerName und LocalHostName sollten die namen sein, die z.b. auch unter systemeinstellungen -> sharing auftauchen.
 
  • Gefällt mir
Reaktionen: lutzministrator
Hi Enti,

Danke erst mal für den Tipp.

Also prinzipiell scheint das auch zu stimmen.
---get Hostname spuckt mir den FQDN aus
ComputerName und LocalHostname unterscheiden sich (wie auch bei den Netzwerkeinstellungen im Serveradmin) um ein Zeichen, d.h. das "-" ist ein "_" wobei ComputerName dem Sharingnamen entspricht... Könnte das ein möglicher Konflikt sein?
 
um jegliche konflikte auszuschließen (und leider bin ich da ein gebranntes kind was hostnamen betrifft...) würde ich auf jeden fall beide namen gleich setzen. unter der client-version von os x ist das der selbe name (wird über sharing gesetzt), bei der server-version kann man den getrennt setzen. warum auch immer, bisher hatte ich eigentlich mehr scherereien damit falls doch mal der hostname oder der fqdn geändert werden muss.
 
so. ich habe eine größere Katastrophe abgewandt indem ich kurzerhand eine Replica zum Master gemacht habe und meine alten defekten Master zur Replica degradiert habe (natürlich mit vorherigen umwandeln in eigenständige Verzeichnisse etc.)
Jetzt läuft erst mal wieder alles sauber, allerdings ist das kein Lösungsweg wenn man nur einen Server hat. Ob diese Probleme dann überhaupt erst auftreten ist die andere Frage...

Das mit den Sharingnamen ist wirklich strange, der LocalHostName generiert sich bei mir nämlich aus dem ComputerName und ersetzt in diesem Fall den Unterstrich durch ein Minus, daher der Unterschied. Einen LocalHostName mit Minus habe ich nie vergeben... Werde das aber baldmöglichst ändern.
 
Zurück
Oben Unten