Open Directory / LDAP

[turkey0815]

Hallo,

ich bin offensichtlich nicht der Einzige, der nach einem Update von Mac OS X Server Probleme mit dem OD hat. Ich habe hier im Forum ne Menge darüber lesen können, aber irgendwie passt mein Problem nicht so richtig zu den Lösungen.

Nachdem ich Mac OS X Server ein Update auf 10.4.8 gegönnt habe, konnten die Clients nicht mehr auf ihre Home-Verzeichnis zugreifen. Die genaue Ursache weiß ich jetzt nicht mehr, aber ich glaube es gab Probleme mit dem Passwortserver. Ich habe dann den Open Directory Server neu konfiguriert. Der Server läuft jetzt auch ohne Probleme mit DNS und Kerberos. Ich habe einen neuen User angelegt und kann mich auch von meinem PowerBook unter diesem User anmelden. Leider funktioniert das von meinem Desctop-G4 nicht. Ich erhalte folgende Fehlermeldung: "Logging in to the account failed because an error occured. The home folder for the user account is located on an AFP or SMB server. Contact your system administrator for help."

Der Systemadministrator bin ich, deshalb hilft mir die Fehlermeldung nicht weiter und das das Homeverzeichnis auf einem AFP Server liegt, wusste ich auch schon Mir ist diese Fehlermeldung nicht ganz neu, aber ich kann mich nicht mehr daran erinnern, wie ich das Problem gelöst habe. Eigentlich wollte ich mir die Vorgehensweise, wie ich den Open Directory Server aufgesetzt habe und die Clients erfolgreich in das LDAP-Verzeichnis eingebunden habe, immer mal notieren. An sich ist das ja aber gut dokumentiert, allerdings habe ich trotzdem immer 1-2 Tage mit Probieren zugebracht, bis es endlich lief. Am Ende wusste ich nie, was zum Erfolg führte.

Da ich mich mit dem Desctop nicht mit einem User aus dem LDAP-Verzeichnis anmelden kann, möchte ich nun der Sache auf den Grund gehen und das möglichst ohne Blindflug mit den GUI-Tools. Ich hoffe ihr könnt mir hier ein paar Tipps geben, wie ich unter die Haube schauen kann.

Die Verbindung zum LDAP-Server scheint zu stehen, denn im Anmeldefenster erscheinen auch die User, die im LDAP-Verzeichnis angelegt wurden. Das Problem besteht beim Zugriff auf das Homeverzeichnis, dass ja auf dem Server liegt. Ich bin mir nicht sicher, aber ich denke der Server ist o.k. weil es mit dem PB funktioniert.

1. Frage: Mit welchem Aufruf im Terminal kann ich mir die Informationen ansehen, die vom LDAP-Server kommen oder testen, ob die Verbindung steht?

Manchmal zeigte mir der Client aber auch Nutzer an, die schon gar nicht mehr im Verzeichnis waren. Wer spinnt hier, der Server oder der Client?

2. Frage: Wie kann ich den LDAP-Server von Hand neustarten? Oder ist das nicht sinnvoll?

3. Frage: Kann ich im Client die LDAP-Verbindung zurücksetzen?

4. Frage: Wie heißt die Preference-Datei, die für das Verbinden mit den Netzwerkshares zuständig ist?

Offensichtlich scheint es ja damit ein Problem zu geben. Ich gehe davon aus, dass das Share mit den Homeverzeichnissen beim Starten des Rechners verbunden wird, denn der Nutzer muss ja bereits beim Anmelden auf das Homeverzeichnis zugreifen können. Im Übrigen habe ich natürlich Netzwerkaktivierung für das Share mit den Homeverzeichnissen aktiviert.

5. Frage: Kann ich den Anmeldevorgang eines Users aus dem LDAP-Verzeichnis im Terminal nachvollziehen?

6. Frage: Welche Rechte muss das Share haben? Bei mir sieht das derzeit so aus: dr-xr-xr-x 16 admin staff 500 Nov 14 21:06 home01

7. Frage: Gibt es auf dem Client auch irgendwelche Logfiles, wo ich schauen kann, welche Probleme es beim Anmelden gegeben hat?

Für Hilfe wäre ich sehr dankbar.

Gruß, André

 

[richard_it]

hab leider gerade stress, aber vielleicht kann ich was zur ersten frage beitragen:

ipconfig getpacket en0

(bzw en1 wenns zb über airport oder eine zweite ethernetschnittstelle gehen soll)

tip: schau ganz genau im arbeitsgruppenmanager die pfade der home-ordner an, besonders anschließende slashs und so - haben alle user das selbe home, was ist im ag-manager bei der detailansicht unter home-folders zu finden?

gutes gelingen

richard

 

[turkey0815]

Hallo Richard,

danke für Deine schnelle Antwort. Das mit dem ipconfig hat mir Aufschluss darüber gebracht, dass die Verbindung zum LDAP-Server steht. Bei den Pfaden habe ich noch einmal nachgesehen. Sie scheinen alle zu stimmen, müssen sie ja eigentlich auch, den von meinem PowerBook kann ich mich ohne Probleme anmelden. Nur von meinem Desctop-G4 nicht und das, obwohl die selben Systeme (Mac OS X 10.4.8) installiert sind. Ich denke, es liegt an der Konfiguration des Desctop-G4s. Ich könnte jetzt ein neues System drüber bügeln, aber ich möchte diesmal der Ursache auf den Grund gehen ... mich nervt die Rumprobiererei total

Kann mir noch jemand auf die anderen fragen antworten ? Wäre nett.

Danke, André

 

[turkey0815]

Im Übrigen ist mir aufgefallen, dass sich die Pfade des Automount-Verzeichnisses zwischen Client und Server unterscheiden. Besser gesagt, es wird ein ganz anderes Protokoll genommen.

Auf dem Server sieht der Pfad beispielsweise so aus:
afp://ldap.server.com/home/user1 /Network/Servers/ldap.server.com/Volumes/home/user1

so steht es zumindest im AG-Manager unter "Privat" des Nutzers. Außerdem gibt es einen Eintrag im LDAP-Verzeichnis unter mounts:

url==afp://;AUTH=NO%20USER%20AUTHENT@ldap.server.com/home01

Der Client hat jedoch das Verzeichnis wie folgt eingebunden:
Ort: /Network/Servers/ldap.server.com/Volumes/home/user1
Server: nfs://automount%20-fstab%20%5B110]

Wie kommt er denn darauf? Ich habe überhaupt keine NFS-Freigaben für das Homeverzeichnis. Wie kommt er darauf und wo kann ich das von Hand umstellen?

Wie kann ich über das Terminal herausfinden auf welche Art und Weise ein Verzeichnis eingebunden wurde?

Sehr verwirrend ist, dass er unter /Network/Servers/ldap.server.com/Volumes/home/ tatsächlich die Verzeichnisse der Nutzer anzeigt (manchmal gar nicht, manchmal unvollständig). Sowas habe ich noch nicht gesehen

Kann es vielleicht sein, dass erst dann das Share automatisch gemountet wird, wenn darauf zugegriffen wird und das ich deshalb immer einen anderen Inhalt gezeigt bekomme (das passiert auch ohne Neustart).

André

 

[slowfranklin]

Hallo Andre,

der automount Kram ist schon haarig wenns funktioniert. Aus dem Dreck der passiert wenns schief läuft daraus zu schließen warum es das tut ist als Laie unmöglich. Sinnvoller ist ein systematisches Vorgehen mit dscl, testen von Kerberos vom Client aus (Kerberos ist zwar nicht zwingend nötig, wenn es aber vom Client am Server "vorgefunden" wird, will er es auch benutzen und ignoriert dann afair andere auth-Methoden wenn Kerberos-auth fehlschlägt).

Naheliegendes: Uhrzeit zw. Server und Client synchronisieren.

Deine Privatordner und mount records sehen erstmal ganz gut aus (wobei zweitere entgegen _aller_ aktuell verfügbaren Literartur mit Stand 10.4.8 gar nicht mehr nötig sind und tendenziell nur noch die passende Konfiguration des Privatverzeichnisses eines Benutzers erleichtern)

man dscl
z.B. dscl /Search -read /Users/test
dscl /Search -list /Mounts

Antwort auf Frage 7:
http://www.supported.de/content/view/16/8/

Gruß

Ralph

 

[turkey0815]

Hallo Ralph,

danke für die wertvollen Tipps. DSCL ist genau das, was ich gesucht habe. Ich habe mich einstweilen mit JXplorer begnügt. Soweit ich das überblicken kann, stimmt aber alles in den Directory-Einträgen. Ich habe Zugriff, ich finde den Nutzer, dort sind alle Angaben, wie ich sie gemacht habe und die Pfade zum Home-Verzeichnis stimmen auch. Das Share mit den Homeverzeichnissen ist in den Mounts aufgeführt.

Das AFP-Logging ist echt geil. Dort sind mir ein paar Sachen aufgefallen.
Mit Kerberos scheint es keine Proble zu geben:
kerberos authentication for principal user1@ldap.server.com succeeded.\n

Mehrfach ist Folgendes zu lesen:
GetPascalCFString: couldn't find the localized string\n
GetPascalCFString: Using the default string\n

außerdem:
IsVolMounted: inMaxPath = 0 outMounPath = (null) mntFlags = 0000\n
IsVolMounted: error = 2\n
FetchVolumeList: Checking Access on workflow volflags = 00\n
FetchVolumeList: User has access\n

weiter unten:
SharedVolumeEnumerator::Mount:couldn't resolve path, errno = 13\n
The bad path segment is /private/Network/Servers/ldap.server.com/Volumes/home\n
Logging out of Session that we own\n
TAFPSession::AFPLogout: Logging out of session 34b490\n
UserCommand failed: error 0x16, afpResult 0x0\n

Die Uhr von Server und Client laufen synchron.
Vielleicht sollte man dem "couldn't find the localized string\n" nachgehen, noch habe ich keine Ahnung, was damit gemeint ist. Vielleicht weiß ja jemand Rat.

Gruß, André

 

[slowfranklin]

GetPascalCFString: couldn't find the localized string\n
GetPascalCFString: Using the default string\n

afair i.O. so.

Post doch bitte mal die Ausgabe von
dscl /Search -read /Users/eddie_the_eagle | grep Home
dscl /Search -list /Mounts
dscl /Search -read /Mounts/ldap.server.com:\\/Volumes\\/home | grep VFS

Mir ist da doch noch was komisches Aufgefallen in deinem dritten Posting:

url==afp://;AUTH=NO%20USER%20AUTHENT@ldap.server.co m/home01

Wo kommt die 01 her?

Gruß

Ralph

 

[turkey0815]

Hallo Ralph,

sorry die home01 war ein Schreibfehler. Der Pfad ist überall richtig.

Hier die Ausgabe:
root# dscl /Search -read /Users/eddie_the_eagle | grep Home
root# dscl /Search -list /Mounts
ldap.server.com:/Volumes/fotoarchiv
ldap.server.com:/Volumes/home
root# dscl /Search -read /Mounts/ldap.server.com:\\/Volumes\\/home | grep VFS
VFSLinkDir: /Network/Servers/
VFSOpts: net url==afp://;AUTH=NO%20USER%20AUTHENT@ldap.server.com/home
VFSType: url

Vielen Dank für Dein Engagement. Schade, eigentlich dachte ich das mit den AFP-Fehlermeldungen wäre eine heise Spur.

Gruß, André

 

[slowfranklin]

dscl /Search -read /Users/[B]eddie_the_eagle[/B] | grep Home

Kicher... eddie_the_eagle bitte passend ersetzen.

Ralph

 

[slowfranklin]

VFSOpts: net url==afp://;AUTH=NO%20USER%20AUTHENT@ldap.server.com/home

Aargh. In der Threadansicht ist zwischen c und om bei .com immer ein Leerzeichen, hier im Editor ists auf einmal wieder weg...????

Ralph

 

[turkey0815]

ist mir auch schon aufgefallen, putzig nicht wahr? Ich weiß nicht wie es da hin kommt, aber daran liegt es definitiv nicht. Ich greife doch über einen anderen Mac mit dem selben Pfad auf das Homeverzeichnis zu und es geht super. Den Pfad holt der doch aus dem LDAP-Verzeichnis, er ist also auf allen Clients gleich oder nicht? Das Problem hat nur der eine Client.

André

 

[slowfranklin]

Verflucht, ich hatte überlesen das das mounten von einem host klappt und vom anderen nicht. Dementsprechend wird das Problem eher nicht der Server sein, sondern der Client.

Ich hatte zu 10.4.<3 Zeiten mal den Fall, dass afair Leichen im automount Keller Sand im Getriebe waren. Die wirst du zum Teil nur im su mode los. Folgende Zombiehöhlen gälte es zu exorzieren:

rm -rf /automount/*
rm -rf /private/var/automount/*
rm -rf /private/Network/*
rm -rf /Network

Obacht: falls du dir wichtige Körperteile mit wegexorzierst, bin ichs nicht gewesen.

Desweiteren könntest du zu meiner persönlichen Freude mal den automount Eintrag des Benutzerverzeichnisses entfernen und berichten, ob es auf deinem Powerbook dann immer noch geht (auf dem geht es doch im Moment, oder?)

Ralph

 

[slowfranklin]

Die wirst du zum Teil nur im su mode los.

So ein Schmarrn! Ein beherztes sudo killall automount reicht. Einen Neustart später läuft der automounter auch wieder, aber wie angedeutet: wer will den schon.

Ralph

 

[turkey0815]

So ein Schmarrn! Ein beherztes sudo killall automount reicht. Einen Neustart später läuft der automounter auch wieder, aber wie angedeutet: wer will den schon.

Ich probiere es dann gleich aus, derzeit wird an dem Rechner lokal gearbeitet. Wie meinst Du das mit "wer will den schon."? Du meinst ich soll eher mobile Accounts einrichten? Funktioniert die Synchronisation ohne automount? Wenn ich Dich nicht richtig verstanden habe, wie sieht denn ein optimales Mac-Netzwerk aus, wo sich auch der Administrationsaufwand in Grenzen hält?

Danke, André

 

[slowfranklin]

Das bezieht sich darauf, das man trotz anderslautender Doku im Arbeitsgruppenmanager unter Sharing -> Freigabe -> Netzwerkordner -> Netzwerkaktivierung _KEIN_ Häkchen machen braucht.

Dieses Häkchen erzeugt in LDAP ein Eintrag in mounts, was auf den Client von lookupd ausgelesen wird und an automount weitergerreicht wird. Was sich dann tendenziell wunderbar mit dem eigentlichen Prozedere wie das Benutzerverzeichnis gemountet wird (nämlich von einem Kindprozess von longinwindow mit den Credential die man gerade eingegeben hat) ins Gehege kommt.

Merke: Userhomes werden anders automatisch gemountet als andere automounts (z.B. Library oder selbst definierte).

So mit Stand 10.4.8 Server/Client. Seit wann genau dem so ist, will ich in bälde aus der mac-osx-server Mailingliste extraieren.

Gruß

-Ralph

 

[turkey0815]

Du hast recht, wenn man die Netzwerkaktivierung heraus nimmt funktioniert es trotzdem.

Ich habe die Automount-Einstellungen mal etwas entrümpelt und alle Prozesse gekillt und siehe da, ich kann mich anmelden. Das ist doch erst einmal ein Erfolgserlebnis, ABER zu früh gefreut nach einem Neustart ist alles wie vorher.

Das Homeverzeichnis wird unter dscl /Search -list /Mounts nicht mehr mit aufgeführt, dass sollte also keine Verwirrung mehr stiften.

Frage: Wir haben ja nur die Mount-Einträge gelöscht, die er angelegt hat. Wo werden die denn definiert / eingetragen? Vielleicht gibts auch ne Pref-Datei, die ich mal entsorgen müsste.

Noch Ideen?

Gruß, André