Hi Arthur, On Wed, Oct 01, 2008 at 10:27:04PM +0200, Arthur de Jong wrote: > On Wed, 2008-10-01 at 13:11 +0200, Patrick Schoenfeld wrote: > > Our setup is a mixed Windows/Linux environment with a LDAP server, for > > central authentication. Linux clients use libnss-ldapd for resolution of > > usernames and groups. > > Could you provide some more details?
Yep, I can. I'm just unsure which informations are of interest (I'm at a point where I'm kinda clueless whats the cause of the trouble :/). > Is the LDAP server on the system that also runs nss-ldapd, what options do > you use, No, it runs on another host. I don't use any special options. In fact the configuration is the default configuration, except the server address and the search base. [EMAIL PROTECTED]:~# grep -v '\(^#\|^$\)' /etc/nss-ldapd.conf uri ldap://majestix-linux.intra.in-medias-res.com base dc=intra,dc=in-medias-res,dc=com uid nslcd gid nslcd > which LDAP server software etc? Your configuration file should also help. The LDAP server is a usual slapd as it is in Etch: slapd (2.3.30-5+etch1) > > After reboot of the Linux clients they are unable to resolve groups and > > sometimes are also unable to resolve users. The result is that files are > > owned by [nobody]:nogroup, while getent passwd and getent group show > > the right result. > > I don't understand this. If you perform getent passwd and getent group > you get the expected result but if you do ls -l the files are reported > as nobody:nogroup? Right. Sometimes all files are "owned" by nobody:nogroup but the most common problem is that only groups are a problem. And yes, while the problem exists getent passwd and getent group show up groups properly. > If ls can't resolve numeric user and group ids it should print the > numeric form, not make up something. Well, I think this is related to the fact that it is a NFSv4 filesystem. nobody:nogroup is what idmapd from NFS does if it cannot properly resolve the ids. > Can you produce logs of nslcd? It should report whether the LDAP server > was reachable or not. If you can run nslcd with the -d option it should > report more information that will help in tracking this down. OK. I will add this logs ASAP. > > In consequence people are unable to properly login > > (because desktop environment need read permissions on their setting ;) > > and user permissions are broken. > > Note that for logging in you also need pam_ldap which has it's own > configuration. If the problem is in that you should probably also > provide information about that. Well, the problem is not the login per se, but that some programs (for example GNOME) simply do not work, because they can't read their settings (if the nobody problem exists as well. if the groups are the only problem, then only accessing shared files is a problem) > nslcd only caches the relationship between DNs and uids for group > membership lookups (when the uniqueMember attribute is used). This > timeout is hardcoded at 15 minutes. Other than that I can't think of a > timeout as long unless you set it that high in the config. I would have said first, that 15 minutes could be the time frame, but then again: no. Today I saw the problem disappearing after more then half an hour. > The way nss-ldapd solves the udev problem is by not doing LDAP lookups > that early during boot at all and "fail" quickly. Only when nslcd is > started are lookups attempted. In any case I can't think of a case where > getent passwd should work and ls would fail. Well, sounds reasonable and I don't see why this should cause the problems. > I am inclined to lower it to important because it seems to work in a lot > of common environments. Well, yes, thats true. But on the other side it has serious affect on the functionality on the system at a whole (because it is a client that mounts /home etc. from the server), so I felt serious is a good compromise. > I hope to fix this soon. Thanks for your bugreport. No bug report, no solution, right? So no need to thank me, instead I thank you if you'd find a solution for it. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
