Gruppen(mitgliedschaften) über LDAP an Clients verteilen

[tomiondrums]

Hi!
Die Datei /etc/group legt ja bekanntlich fest, wie eine Gruppe heißt, welche GID sie hat und wer alles Mitglied in ihr ist. Ein Benutzer der die Audio-Devices am Rechner verwenden will, sollte in der Gruppe 'audio' sein, damit ihn sein System das auch lässt....
Jetzt kommt es aber vor, daß man einen Teil seiner Benutzer im Netzwerk zentral verwalten will/muß und benutzt dazu NIS oder LDAP oder ähnliches. Auch dort gibts das Konzept mit den Gruppen und ihren Mitgliedern. Ich möchte beispielsweise die Mitglieder der Gruppe 'audio' zentral mit LDAP verwalten und hab deswegen unter Anderem meinen Benutzer 'tomi' auf dem LDAP zu einem Mitglied von 'audio' gemacht. (Daß der Client das auch mitkriegt zeigt mir 'getent group', indem es den Benutzer 'tomi' als eines der Mitglieder von 'audio' anzeigt)
Soweit so schön!
Der Haken an der ganzen Sache ist nur, daß ich als Benutzer 'tomi' in der Praxis nicht die Rechte bekommen, die mir als 'audio'-Mitglied zustehen, d.h. z.B. ich kann von der KDE aus keine Musik hören, die Laustärkeregelung nicht benutzen und bekommen X Fehlermeldungen diesbetreffend.
Ich glaube mittlerweile daß es sich hierbei um ein Problem im Zusammenhang mit PAM handelt, weil ich schon früher, als ich noch mit NIS rumgemurkst hab, mir die Zähne an dem Problem ausgebissen hab. Im Moment behelfe ich mir indem ich wie gesagt, die Gruppen alle trotzdem lokal (/etc/group) anlege und dort auch die über LDAP importierten Nutzer eintrage, was natürlich LDAP vollkommen sinnfrei macht.

Woran könnte das o.g. Problem liegen? Was kann ich dagegen tun?

Vielen herzlichen Dank schonmal für alle Ideen!
MfG
Tom

[tomiondrums]

ich hab grad die ganze Sache auch nochmal vereinfacht und folgendes ausprobiert:

ein Verzeichnis /testdir erstellt
dessen Lese/Schreibrechte auf die Gruppe beschränkt und es mit 'chown root:audio /testdir' Root und der Gruppe audio übereignet
'ls -la' sagt jetzt:


...
d---rw---- 2 root audio 4096 Jun 24 00:41 testdir
...

die Zeile für die Gruppe 'audio' in der '/etc/group' gelöscht (wofür mich udev bei Neustart gleich mal heftig bestraft hat... :-/ )
mich mit getent versichert, daß mein Benutzer auch in der Gruppe 'audio' drin ist


# getent group |grep 18
dhcp:x:1018:
audio:*:18:anja,gabi,reinhold,tomi

(Der Benutzer 'tomi' wird vom LDAP-Server bezogen und ein Login damit auf dem Client funktioniert wunderbar)
Probiert ob ich mit 'tomi' auch in das Verzeichnis reinkomme:


tomi@dual / $ cd testdir/
bash: cd: testdir/: Permission denied




Wie man sieht passt da was nicht... Woran kanns liegen?

Meine /etc/pam.d/system-auth


auth required pam_env.so
auth required pam_unix.so try_first_pass likeauth nullok
auth sufficient pam_ldap.so use_first_pass

account sufficient pam_ldap.so
account required pam_unix.so

password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password required pam_unix.so try_first_pass use_authtok nullok md5 shadow
password sufficient pam_ldap.so use_authtok use_first_pass

session required pam_limits.so
session required pam_env.so
session required pam_unix.so
session optional pam_ldap.so


Kanns auch sein, daß ich noch an einer anderen Datei in /etc/pam.d was hätte ändern sollen?

Meine /etc/nsswitch.conf


# /etc/nsswitch.conf:
# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $

passwd: files ldap
shadow: files ldap
group: files ldap

#passwd: compat
#shadow: compat
#group: compat

hosts: files ldap dns
#hosts: files dns
networks: files dns

services: db files
protocols: db files
rpc: db files
ethers: db files
netmasks: files
netgroup: files
bootparams: files

automount: files
aliases: files

[hessijens]

d---rw---- 2 root audio 4096 Jun 24 00:41 testdir

Damit der Benutzer in das Verzeichnis schauen darf musst Du es "ausführbar" machen:



chmod g+x testdir
ls -la
....
d---rwx--- 2 root audio 4096 Jun 24 00:41 testdir
....

[tomiondrums]

hast vollkommen recht, danke für den Hinweis, nur der Fehler bleibt trotzdem bestehen, auch mit

...
d---rwx--- 2 root audio 4096 Jun 24 00:41 testdir
...

[tomiondrums]

Ich hab's!
Der Teufel sitzt wie immer im Detail:
Das genannte Problem wird nämlich weder von einer der hier genannten Dateien noch von PAM oder sonst einem Fehler in der NSS-LDAP-Software verursacht. Im Gentoo-OpenLDAP-Leitfaden steht, daß man auf den Clients in der /etc/ldap.conf unter anderem folgende Zeilen eintragen soll:

pam_member_attribute memberuid
Die Schreibung des Attributs passt aber nicht mit den im Verzeichnis abgelegten Daten zusammen, weil dort heißt das Attribut nämlich memberUid
Wenn man außerdem noch
nss_connect_policy persist einträgt und neustartet, sodaß NSS die Infos über die Gruppen neu vom Server abholen muß, dann läufts.