Bug 436307

Summary: runuser breaks starting ldap service
Product: Red Hat Enterprise Linux 4 Reporter: Laszlo Beres <beres.laszlo>
Component: nss_ldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 4.6CC: bgmilne, jplans, ovasik
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 13:29:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Laszlo Beres 2008-03-06 13:55:16 UTC
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 14:39:56 UTC
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 12:45:13 UTC
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 13:29:48 UTC
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.