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? Is the LDAP server on the system that also runs nss-ldapd, what options do you use, which LDAP server software etc? Your configuration file should also help. > 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? If ls can't resolve numeric user and group ids it should print the numeric form, not make up something. 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. > 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. > After 10-30 minutes of running the problem disappears. This makes me > think that some timeout occours, but I can't tell which. > > I thought its probably somehow related to the udev resolution issues > that are handled different in libnss-ldapd from libnss-ldap which > produces a significant delay when booting because groups can't be > resolved while ldap is accessible, which is handled gracefully bei > libnss-ldapd. Maybe you gather invalid results while booting, because > LDAP is not accessible. But I don't see why nslcd should cache these > results so I think my idea is absurd. 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. 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. One known issue (#475626) is related to the order at which nslcd is started during boot. If the LDAP server is unavailable when nslcd is started a timeout could occur and the LDAP server will not be found immediately when it is available. > I've choosen severity serious for this issue because at the one hand > the problem would fit severity 'Critical', because it "makes unrelated > software on the system (or the whole system) break", but then again I > felt uncomfortable with it, because the problem does not persist over > the uptime of the system and after 10-30 minutes the problem > disappears. I am inclined to lower it to important because it seems to work in a lot of common environments. > But I think it should definitive be fixed for lenny. I hope to fix this soon. Thanks for your bugreport. -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
