Bug 585802 - Problems installing RPMs with LDAP auth configured
Problems installing RPMs with LDAP auth configured
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nss_ldap (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Nalin Dahyabhai
BaseOS QE Security Team
Depends On:
  Show dependency treegraph
Reported: 2010-04-26 01:42 EDT by cavanaug
Modified: 2010-06-30 10:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-30 10:38:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description cavanaug 2010-04-26 01:42:56 EDT
Description of problem:

I encountered a hang while installing nagios-nrpe on a LDAP authentication enabled system.   The hang was associated with the useradd command.  


 /usr/sbin/useradd -r -d /var/log/nagios -s /bin/sh -c nagios nagios

Only way to get the above command to work was to remove the "ldap" fields from /etc/nsswitch.conf

I was surprised this was a problem as I have pam_min_uid set at 5000 set in /etc/ldap.conf so with the -r flag it shouldnt have even gone to ldap while adding this account.

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

How reproducible:

Steps to Reproduce:
1. configure auth to an ldap server, w/o admin ability to create account in ldap
2. attempt to install any rpm that creates a service account
3. watch it hang

Additional info:
Comment 1 Nalin Dahyabhai 2010-06-30 10:38:34 EDT
This delay most likely occurs when useradd attempts to find an unused UID to assign to the new nagios account.  Basically, it has to guess by choosing a UID, checking if there's already a user with that ID, and if there is, checking the next higher one, continuing until it finds one that isn't used.  It can take a while, but I believe that tweaking the UID_MIN and UID_MAX values in /etc/login.defs to adjust the range which useradd checks will solve this.  Marking this works-for-me because I believe it's solvable in the configuration.

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