| Anonymous | Login | 2024-12-22 00:08 MST |
| Main | My View | View Issues | Change Log | Roadmap | Repositories |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0000385 | ClearOS | app-openldap-directory - Directory Server | public | 2011-10-28 07:11 | 2019-03-12 14:24 | ||||
| Reporter | NickH | ||||||||
| Assigned To | |||||||||
| Priority | normal | Severity | tweak | Reproducibility | have not tried | ||||
| Status | closed | Resolution | won't fix | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | 5.2-SP1 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0000385: LDAP failing to respond ro requests | ||||||||
| Description | Quote 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(0000419) devferret (reporter) 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 (developer) 2019-03-12 14:24 |
Does not appear to be a current problem. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2011-10-28 07:11 | NickH | New Issue | |
| 2011-10-28 08:15 | user2 | Assigned To | => dloper |
| 2011-10-28 08:15 | user2 | Status | new => assigned |
| 2011-10-28 08:21 | user2 | Category | app-ldap - LDAP Engine => app-openldap-directory - OpenLDAP Directory |
| 2012-03-05 22:13 | devferret | Note Added: 0000419 | |
| 2012-03-05 22:19 | devferret | Note Edited: 0000419 | |
| 2012-03-05 22:23 | devferret | Note Edited: 0000419 | |
| 2012-03-05 22:45 | devferret | Note Edited: 0000419 | |
| 2019-03-12 14:24 | NickH | Note Added: 0011061 | |
| 2019-03-12 14:24 | NickH | Status | assigned => closed |
| 2019-03-12 14:24 | NickH | Assigned To | dloper => |
| 2019-03-12 14:24 | NickH | Resolution | open => won't fix |
|
Issue History |