ClearFoundation Tracker - ClearOS
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000385ClearOSapp-openldap-directory - Directory Serverpublic2011-10-28 07:112019-03-12 14:24
ReporterNickH 
Assigned To 
PrioritynormalSeveritytweakReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version5.2-SP1 
Target VersionFixed in Version 
Summary0000385: LDAP failing to respond ro requests
DescriptionQuote from thread http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,26/func,view/id,32600/#33161 [^] by Tony Ellis

[quote]
Way back in the distant past there was a problem with ldap starting up. The
default is to retry forever, and in certain race conditions when booting up
the system a situation sometimes arose where a command to ldap was failing
and being retried again and again, hanging the machine so it never completed
initialization.

The fix was to add the directive "bind_policy soft" to /etc/dlap.conf. What
this does is to provide an immediate negative response if the command cannot
be honoured - the caller aborts and the machine proceeds to the next phase
of the initialization sequence.

This is fine to fix that problem. However, I believe it causes a problem
once the machine is up. If ldap cannot respond to a request at an instant in
time - it gives the same negative response and the caller aborts with the
results experienced.
[/quote]

Again from the thread, it appears that setting "nss_reconnect_tries 3" in nss_ldap.conf.template fixes the issue and allows for a slow response from LDAP. This has been verified by a number of users.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-10-28 07:11NickHNew Issue
2011-10-28 08:15user2Assigned To => dloper
2011-10-28 08:15user2Statusnew => assigned
2011-10-28 08:21user2Categoryapp-ldap - LDAP Engine => app-openldap-directory - OpenLDAP Directory
2012-03-05 22:13devferretNote Added: 0000419
2012-03-05 22:19devferretNote Edited: 0000419
2012-03-05 22:23devferretNote Edited: 0000419
2012-03-05 22:45devferretNote Edited: 0000419
2019-03-12 14:24NickHNote Added: 0011061
2019-03-12 14:24NickHStatusassigned => closed
2019-03-12 14:24NickHAssigned Todloper =>
2019-03-12 14:24NickHResolutionopen => won't fix

Notes
(0000419)
devferret   
2012-03-05 22:13   
(edited on: 2012-03-05 22:45)
In my case, the underlying problem of slapd becoming unresponsive was fixed by a change to the samba configuration.. see http://tracker.clearfoundation.com/view.php?id=456 [^]

With respect to the system failing to boot, and setting bind_policy to soft in the nss_ldap configuration (see man nss_ldap) as a work-around:

* Basically, the problem is that in order to start a system service as user x (eg. as user dbus) the system needs to look up the group membership of user x. That lookup normally happens using ldap; but of course it can't happen if slapd hasn't been started. With the default bind_policy of hard_open, nss hangs around waiting for a very long time (not forever, but on the order of tens of minutes, long enough for most folks to assume the boot will hang forever). Setting bind_policy to soft works around the issue by allowing the initgroups() call to fail immediately.

* This boot problem is discussed fairly thoroughly at https://bugzilla.redhat.com/show_bug.cgi?id=186527 [^]

* I believe a better solution to the boot issue is to set "nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,nscd,dbus". This tells nss not to use ldap to look up the group memberships of those users. Which is completely kosher as those users belong to system services and their group membership is completely defined in /etc/group.

* Settting bind_policy to soft exposes the entire system to transient slapd failures. In my view, the default bind_policy of hard_open is much safer.

* But, I guess you could argue that soft, with additiona nss_reconnect_retries is a better option. There's no perfect solution; if slapd isn't working, the system will break eventually. This option tends toward having it break sooner rather than later.

* In any case, it world be a good idea to add the nss_initgroups_ignore_users setting to the default configuration, because boot hangs suck.
(0011061)
NickH   
2019-03-12 14:24   
Does not appear to be a current problem.