Bug 436307 - runuser breaks starting ldap service
runuser breaks starting ldap service
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap (Show other bugs)
4.6
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-06 08:55 EST by Laszlo Beres
Modified: 2012-06-20 09:29 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 09:29:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Laszlo Beres 2008-03-06 08:55:16 EST
Description of problem:

Our customer reported that since updating to 4.6 the ldap service cannot be
started. Our investigation showed that /sbin/runuser caused the problem.

Version-Release number of selected component (if applicable):

How reproducible:

Always, when the ldap server is on localhost.

Steps to Reproduce:
1. Create LDAP environment
2. Authenticate against ldap
3. Restart ldap service
  
Actual results:

Mar  6 10:07:59 XXX runuser: nss_ldap: failed to bind to LDAP server 127.0.0.1:
Can't contact LDAP server
Mar  6 10:07:59 XXX runuser: nss_ldap: reconnecting to LDAP server...

Expected results:

A working ldap service.

Additional info:

It seems that runuser ignores authentication settings and tries to find ldap
user in ldap, regardless they are local users. Our solution was putting ldap and
root users into the ldap.conf:

nss_initgroups_ignoreusers root,ldap
Comment 1 Ondrej Vasik 2008-03-06 09:39:56 EST
This is not the issue with runuser - works as expected. Changing component to
nss_ldap as possible source of problems.
Comment 2 Buchan Milne 2011-03-02 07:45:13 EST
Easiest workaround:

echo "bind_policy soft" >> /etc/ldap.conf

If you have multiple servers listed in uri or host, this may not necessarily do exactly what you want if the first server fails, in that case, look at the nss_reconnect_tries,nss_reconnect_sleeptime,nss_reconnect_maxsleeptiome,nss_reconnect_maxconntries options.
Comment 3 Jiri Pallich 2012-06-20 09:29:48 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

Note You need to log in before you can comment on or make changes to this bug.