KDE error beim Anmelden von LDAP clients am Openldapserver
Hallo, Beim Anmelden von LDAP Client (SUSE 9.2) am OPENLDAP Server(SuSE 9.2) tritt folgender Fehler auf: The following installation problem was detected while trying to start KDE: No wirte access to 'home/simon/.ICEauthority'! KDE is unable to start. Bei der KDE Einrichtung Interprozess Kommunikation bleibt er dann hängen, gibt dann die obige Fehlermeldung aus KDE is unable to start Oben links steht dann: could not start ksmserver. check your installation. OK. Dann kommt wieder das Anmeldefenster. Lokale Benutzer, auch root, können sich einwandfrei anmelden. Wenn ich die Homeverzeichnisse nicht mounte, klappt die Anmeldung der LDAP user einwandfrei, ohne KDE Fehler. Die Homeverzeichnisse werden dann halt nicht auf dem Server syncronisiert, logisch ohne /home/simon gemountet zu haben. Meld ich mich von der Konsole über ssh simon@192.168.0.7 am Server an, klappt die Anmeldung und der Zugriff auf das Homeverzeichnis einwandfrei. Das Homeverzeichnis habe ich mit nfs gemountet mit Schreibrechten, das mounten klappt anscheinend auch einwandfrei: amd:# mount 192.168.0.7:/home on /home type nfs (rw,addr=192.168.0.7) /etc/exports: /home/ *(rw,async,all_squash) Die Rechte für das Homeverzeichnis sind Schreib-Leserechte sowohl auf dem Client wie auf dem Server: rwxr -xr -xr simon simon users Wenn ich Besitzer und Gruppe so setze: rwxr -xr -xr simon nobody nogroup klappt die Anmeldung. Die ACL Rechte in slapd.conf habe ich so gesetzt: access to attr=userPassword by self write by * auth access to by dn.base=cn=Manager,dc=samba,dc=org wirte by selfwrite by * read Danke schon mal im Vorraus Andreas
Hallo,
"Andreas Bauer"
Hallo,
Beim Anmelden von LDAP Client (SUSE 9.2) am OPENLDAP Server(SuSE 9.2)
tritt folgender Fehler auf:
[...]
Die ACL Rechte in slapd.conf habe ich so gesetzt:
access to attr=userPassword
by self write
by * auth
Lies die Manual Page slapd.access(5) und frage dich dann, was die obigen Regeln bewirken.
access to by dn.base=cn=Manager,dc=samba,dc=org wirte
by selfwrite
by * read
Diese Regel steht in dieser Form bestimmt nicht in slapd.conf, denn es fehlt die <what> Clause, also nach dem 'access to' fehlt das Argument, weiterhin gibt es die Option 'selfwrite' nicht. Eigentlich startet slapd nicht bei einer fehlerhaften Konfigurationsdatei, also prüfe, ob slapd überhaupt läuft. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
access to by dn.base=cn=Manager,dc=samba,dc=org wirte
by selfwrite
by * read Dieter Klünter wrote:
Diese Regel steht in dieser Form bestimmt nicht in slapd.conf, denn es fehlt die <what> Clause, also nach dem 'access to' fehlt das Argument, weiterhin gibt es die Option 'selfwrite' nicht. Eigentlich startet slapd nicht bei einer fehlerhaften Konfigurationsdatei, also prüfe, ob slapd überhaupt läuft. Das by self write war ein Kopierfehler beim Kopieren von der slapd.conf in die NG. Der Server startet aber ohne Fehlermeldung, auch in var/log/messages sind keine Fehlermeldungen. Kannst Du mir vielleicht eine für das Homeverzeichnis funktionierende ACL mailen?
Danke und Gruss Andreas
Hallo,
"Andreas Bauer"
Diese Regel steht in dieser Form bestimmt nicht in slapd.conf, denn es fehlt die <what> Clause, also nach dem 'access to' fehlt das Argument, weiterhin gibt es die Option 'selfwrite' nicht. Eigentlich startet slapd nicht bei einer fehlerhaften Konfigurationsdatei, also prüfe, ob slapd überhaupt läuft.
Das by self write war ein Kopierfehler beim Kopieren von der slapd.conf in die NG. Der Server startet aber ohne Fehlermeldung, auch in var/log/messages sind keine Fehlermeldungen.
slapd logged auch nicht nach /var/log/messages, sondern nach /var/log/localmessages
Kannst Du mir vielleicht eine für das Homeverzeichnis funktionierende ACL mailen?
Sieh dir meine Homepage an (in der Signatur), da findest du eine simple-slapd.conf und eine Muster-slapd.conf. Dann findest du unter http://www.openldap.org/admin22/ etliche Bespiele, in der FAQ http://www.openldap.org/faq/data/cache/189.html findest du noch mehr, wenn du dann noch Fragen hast, melde dich. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Hallo, Also, ich komm mit dem Homeverzeichnis überhaupt nicht mehr klar. Ich habe den usern jetzt alle ACL Rechte eingeräumt: access to * by dn.base="cn=Manager,dc=samba,dc=org" write by self write by * write sollte man natürlich nicht machen; aber die Anmeldung gibt immer noch den gleichen Fehler aus, wobei ich so langsam glaub, daß der Fehler überhaupt nicht an der ACL slapd.conf Einstellung liegt, da ich ja sämtliche ACL Rechte in der slapd.conf freigegeben habe. Wie in meiner vorherigen Mail schon beschrieben habe, müßte das Homeverzeichnismounten mit den Eigentümerechten für die Homeverzeichnisse korrekt sein. Setz ich die Eigentümerrechte auf nobody nogroup klappt die Anmeldung, so kann man die einzelnen Homes natürlich nicht abgrenzen. Die Fehlermeldung bei der Anmeldung vom Client zum Openldapserver ist immer noch die gleiche: The following installation problem was detected while trying to start KDE: No write access to $Home directory (/home/simon) KDE is unable to start. OK. Und dann: Could not start the ksmserver. Check your installation. OK. Dann kommt wieder die Anmelde GUI. Vielen Dank und Gruss Andreas Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hallo,
"Andreas Bauer"
Hallo, [...] Die Fehlermeldung bei der Anmeldung vom Client zum Openldapserver ist immer noch die gleiche:
The following installation problem was detected while trying to start KDE: No write access to $Home directory (/home/simon) KDE is unable to start. OK.
Wennn ich das richtig interpretiere, ist dies keine Fehlermeldung von slapd, sondern von KDE. Es scheint, dass $HOME nicht gemouted wurde und daher auch nicht beschrieben werden kann. Prüfe mal die Logs von NFS, sowohl auf dem Server als auch auf dem Client. Aber helfen kann ich dir da nicht, denn ich bin nicht der ausgesprochene Spezialist für NFS. Wenn du trotzdem glaubst, dass OpenLDAP die Ursache für dein Problem ist, setze einmal 'loglevel 132' in slapd.conf und maile die relevanten Zeilen aus /var/log/localmessages. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Hallo, Dieter Klünter wrote:
Wennn ich das richtig interpretiere, ist dies keine Fehlermeldung von slapd, sondern von KDE. Es scheint, dass $HOME nicht gemouted wurde und daher auch nicht beschrieben werden kann. Prüfe mal die Logs von NFS, sowohl auf dem Server als auch auf dem Client. Aber helfen kann ich dir da nicht, denn ich bin nicht der ausgesprochene Spezialist für NFS. Wenn du trotzdem glaubst, dass OpenLDAP die Ursache für dein Problem ist, setze einmal 'loglevel 132' in slapd.conf und maile die relevanten Zeilen aus /var/log/localmessages.
mount auf dem Client bringt: linux# mount amd:/home on /home type nfs (rw,addr=192.168.0.7) müßte eigentlich in Ordnung sein. Kannst Du mir bitte sagen, wo die Logs von NFS auf Client und Server zu finden sind. /var/log/localmessages bringt nach Einfügen von loglevel 132 in slapd.conf beim Start des Servers - rclapd restart: Jul 19 13:12:58 amd slapd[4410]: @(#) $OpenLDAP: slapd 2.2.15 (Dec 7 2004 12:08:05) $ abuild@boltzmann:/usr/src/packages/BUILD/openldap-2.2.15/servers/slapd Jul 19 13:12:58 amd slapd[4410]: bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (October 5, 2004) Jul 19 13:12:58 amd slapd[4410]: bdb_db_init: Initializing bdb database Jul 19 13:12:58 amd slapd[4415]: bdb_db_open: dc=samba,dc=org Jul 19 13:12:58 amd slapd[4415]: slapd starting Jul 19 13:12:59 amd slapd[4415]: connection_get(12) Jul 19 13:12:59 amd slapd[4415]: send_ldap_result: err=0 matched="" text="" Jul 19 13:12:59 amd slapd[4415]: connection_get(12) Jul 19 13:12:59 amd slapd[4415]: SRCH "" 0 0 Jul 19 13:12:59 amd slapd[4415]: 0 0 0 Jul 19 13:12:59 amd slapd[4415]: filter: (objectClass=*) Jul 19 13:12:59 amd slapd[4415]: attrs: Jul 19 13:12:59 amd slapd[4415]: Jul 19 13:12:59 amd slapd[4415]: => access_allowed: search access to "" "objectClass" requested Jul 19 13:12:59 amd slapd[4415]: => acl_get: [2] attr objectClass Jul 19 13:12:59 amd slapd[4415]: => acl_mask: access to entry "", attr "objectClass" requested Jul 19 13:12:59 amd slapd[4415]: => acl_mask: to all values by "", (=n) Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: cn=manager,dc=samba,dc=org Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: self Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: * Jul 19 13:12:59 amd slapd[4415]: <= acl_mask: [3] applying write(=wrscx) (stop) Jul 19 13:12:59 amd slapd[4415]: <= acl_mask: [3] mask: write(=wrscx) Jul 19 13:12:59 amd slapd[4415]: => access_allowed: search access granted by write(=wrscx) Jul 19 13:12:59 amd slapd[4415]: => access_allowed: read access to "" "entry" requested Jul 19 13:12:59 amd slapd[4415]: => acl_get: [2] attr entry Jul 19 13:12:59 amd slapd[4415]: => acl_mask: access to entry "", attr "entry" requested Jul 19 13:12:59 amd slapd[4415]: => acl_mask: to all values by "", (=n) Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: cn=manager,dc=samba,dc=org Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: self Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: * Jul 19 13:12:59 amd slapd[4415]: <= acl_mask: [3] applying write(=wrscx) (stop) Jul 19 13:12:59 amd slapd[4415]: <= acl_mask: [3] mask: write(=wrscx) Jul 19 13:12:59 amd slapd[4415]: => access_allowed: read access granted by write(=wrscx) Jul 19 13:12:59 amd slapd[4415]: => access_allowed: read access to "" "objectClass" requested Jul 19 13:12:59 amd slapd[4415]: => acl_get: [2] attr objectClass Jul 19 13:12:59 amd slapd[4415]: access_allowed: no res from state (objectClass) Jul 19 13:12:59 amd slapd[4415]: => acl_mask: access to entry "", attr "objectClass" requested Jul 19 13:12:59 amd slapd[4415]: => acl_mask: to value by "", (=n) Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: cn=manager,dc=samba,dc=org Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: self Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: * Jul 19 13:12:59 amd slapd[4415]: <= acl_mask: [3] applying write(=wrscx) (stop) Jul 19 13:12:59 amd slapd[4415]: <= acl_mask: [3] mask: write(=wrscx) Jul 19 13:12:59 amd slapd[4415]: => access_allowed: read access granted by write(=wrscx) Jul 19 13:12:59 amd slapd[4415]: send_ldap_result: err=0 matched="" text="" Jul 19 13:12:59 amd slapd[4415]: connection_get(12) Und beim vergeblichen Einloggen von user simon: ssimn komisch, habe Namen simon Korrekt eingegeben. In var/log/messages auf dem Client beim vergeblichen Einloggen von user simon hab ich noch was aufgezeichnet: Jul 19 13:38:05 linux kdm: :0[3892]: pam_unix2: session finished for user root, service xdm Jul 19 13:38:24 linux kdm: :0[4099]: pam_unix2: session started for user simon, service xdm Jul 19 13:38:27 linux kdm: :0[4129]: Can't update authorization file in home dir /home/simon Jul 19 13:38:27 linux kdm: :0[4129]: Cannot create session log file .xsession-errors: Permission denied Jul 19 13:39:35 linux kdm: :0[4099]: nss_ldap: reconnecting to LDAP server... Jul 19 13:39:35 linux kdm: :0[4099]: nss_ldap: reconnected to LDAP server after 1 attempt(s) Jul 19 13:39:35 linux kdm: :0[4099]: pam_unix2: session finished for user simon, service xdm Jul 19 13:39:37 linux kdm: :0[4099]: Can't update authorization file in home dir /home/simon Jul 19 13:39:54 linux kdm: :0[4212]: pam_unix2: session started for user root, service xdm Gruss und vielen Dank Andreas Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hallo,
"Andreas Bauer"
Hallo,
Dieter Klünter wrote:
Wennn ich das richtig interpretiere, ist dies keine Fehlermeldung von slapd, sondern von KDE. Es scheint, dass $HOME nicht gemouted wurde und daher auch nicht beschrieben werden kann. Prüfe mal die Logs von NFS, sowohl auf dem Server als auch auf dem Client. Aber helfen kann ich dir da nicht, denn ich bin nicht der ausgesprochene Spezialist für NFS. Wenn du trotzdem glaubst, dass OpenLDAP die Ursache für dein Problem ist, setze einmal 'loglevel 132' in slapd.conf und maile die relevanten Zeilen aus /var/log/localmessages.
mount auf dem Client bringt: linux# mount amd:/home on /home type nfs (rw,addr=192.168.0.7) müßte eigentlich in Ordnung sein. Kannst Du mir bitte sagen, wo die Logs von NFS auf Client und Server zu finden sind.
Das hängt von der Konfiguration des syslog ab, aber suche mal in /var/log/messages und auf der Standardfehlerausgabe tty10
/var/log/localmessages bringt nach Einfügen von loglevel 132 in slapd.conf beim Start des Servers - rclapd restart:
Jul 19 13:12:58 amd slapd[4410]: @(#) $OpenLDAP: slapd 2.2.15 (Dec 7 2004 12:08:05) $ abuild@boltzmann:/usr/src/packages/BUILD/openldap-2.2.15/servers/slapd Jul 19 13:12:58 amd slapd[4410]: bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (October 5, 2004) Jul 19 13:12:58 amd slapd[4410]: bdb_db_init: Initializing bdb database Jul 19 13:12:58 amd slapd[4415]: bdb_db_open: dc=samba,dc=org Jul 19 13:12:58 amd slapd[4415]: slapd starting Jul 19 13:12:59 amd slapd[4415]: connection_get(12) [...] Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: cn=manager,dc=samba,dc=org Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: self Jul 19 13:12:59 amd slapd[4415]: <= check a_dn_pat: * Jul 19 13:12:59 amd slapd[4415]: <= acl_mask: [3] applying write(=wrscx) (stop) Jul 19 13:12:59 amd slapd[4415]: <= acl_mask: [3] mask: write(=wrscx) Jul 19 13:12:59 amd slapd[4415]: => access_allowed: read access granted by write(=wrscx) [...] Jul 19 13:12:59 amd slapd[4415]: send_ldap_result: err=0 matched="" text="" Jul 19 13:12:59 amd slapd[4415]: connection_get(12)
Das sieht gut aus.
Und beim vergeblichen Einloggen von user simon: ssimn
komisch, habe Namen simon Korrekt eingegeben.
Wo wird 'ssimn' ausgegeben?
In var/log/messages auf dem Client beim vergeblichen Einloggen von user simon hab ich noch was aufgezeichnet: [...] Jul 19 13:39:35 linux kdm: :0[4099]: pam_unix2: session finished for user simon, service xdm Jul 19 13:39:37 linux kdm: :0[4099]: Can't update authorization file in home dir /home/simon
Es scheint, dass /home/simon nicht gemountet ist, daher auch keine Schreibmöglichkeit. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Dieter Klünter writes:
Es scheint, dass /home/simon nicht gemountet ist, daher auch keine Schreibmöglichkeit.
Ich habe /home/simon mit yast noch mal gemountet, gleiche Ergebinis beim Anmelden am Server: The following installation problem was detected while trying to start KDE: No write access to $Home directory (/home/simon) KDE is unable to start. OK. Und dann: Could not start the ksmserver. Check your installation. OK. mount auf der Konsole des Clients gibt auch korrekte Meldungen aus: linux~ # mount amd:/home/simon on /home/simon type nfs (rw,adr=192.168.0.7) ist doch korrekt? Das Anmeldedilema passiert übrigends auch, wenn die Homeverzeichnisse nicht gemountet sind. Meine ganzen Konfigurationen auf dem Openldapserver mache ich als root und zwischen Client und Server switche ich mit einem Bildschirm, ist vielleicht wichtig wegen des Desktops und der Auflösung für den KDE Desktop. NFS logs habe ich in /var/log/messages nicht gefunden. SSH mit ssh simon@192.168.0.7 funktioniert auch mit den Homeverzeichnissen einwandfrei. Was könnte der KDE Anmeldefehler sein? Ich hab mittlerweile sämtliche Möglichkeiten probiert, immer mit dem gleichen Ergebnis. Vielen Dank und Gruss Andreas -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hallo, ich habe jetzt /home/simon gemountet und die Rechte von /home/simon auf volle Rechte rwx-rwx-rwx gesetzt. Jetzt funktioniert die Anmeldung. Das ist natürlich wegen des Umstandes jedes Homeverzeichnis jedes Benutzers einzeln mounten zu müssen und wegen der uneingeschränkten Rechte auf den Rechnern keine Lösung. Jeder LDAP Benutzer des Clientrechners kann ja uneingeschränkt in jedes Homeverzeichnis schreiben und löschen. Gibts da keine flexiblere Lösung? Gruss und Danke Andreas
"Andreas Bauer"
Hallo,
ich habe jetzt /home/simon gemountet und die Rechte von /home/simon auf volle Rechte rwx-rwx-rwx gesetzt. Jetzt funktioniert die Anmeldung. Das ist natürlich wegen des Umstandes jedes Homeverzeichnis jedes Benutzers einzeln mounten zu müssen und wegen der uneingeschränkten Rechte auf den Rechnern keine Lösung. Jeder LDAP Benutzer des Clientrechners kann ja uneingeschränkt in jedes Homeverzeichnis schreiben und löschen. Gibts da keine flexiblere Lösung?
automount(8), autofs(5) -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
Hallo,
Umstandes jedes Homeverzeichnis einzeln mounten zu müssen und wegen der
uneingeschränkten Rechte auf den Rechnern keine Lösung. Jeder LDAP
Benutzer des Clientrechners kann ja uneingeschränkt in jedes
Homeverzeichnis schreiben und löschen. Gibts da
keine flexiblere Lösung?
Dieter Klünter wrote:
automount(8), autofs(5)
Danke, klappte auf Anhieb. Kann man Yast/Netzwerkdienste/LDAP "Automounter starten" beim LDAP Client bei Suse 9.2 über den LDAP Server aktivieren/deaktivieren? Gibt es da ne Lösung mit den uneingeschränkten Homeverzeichnisrechten? Gruss und Danke Andreas -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
participants (2)
-
Andreas Bauer -
Dieter Kluenter