Bug 181306 - nss_ldap is started to early on init
nss_ldap is started to early on init
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: nss_ldap (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On: 181432
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-13 06:54 EST by Andreas Bierfert
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-26 10:33:35 EST
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 Andreas Bierfert 2006-02-13 06:54:38 EST
Right when udev is started, nss_ldap tries to find my ldap server but because
eth0 is not up yet cannot find it. The ugly part is that it goes to the
background after a while but it still prints [failed] and a lot of messages to
the screen

[12:59 PM][awjb@alkaid ~]$ rpm -q nss_ldap
nss_ldap-248-2.1
nss_ldap-248-2.1
Comment 1 Nalin Dahyabhai 2006-02-13 08:09:18 EST
Is this improved at all by 248-3's default configuration?  This may have been
fixed by #180657.
Comment 2 Nalin Dahyabhai 2006-02-13 08:21:34 EST
Hmm, that should be 248-2, which added "nss_initgroups_ignoreusers root,ldap" to
the default configuration.
Comment 3 Andreas Bierfert 2006-02-13 08:27:39 EST
#180657 is probably the same problem I see. I did a fresh install from
10.2.2006's rawhide tree and my config has the entry you mention... :/
Comment 4 Nalin Dahyabhai 2006-02-13 08:33:15 EST
Hmm.  If it's not an initgroups() call that's causing nss_ldap to be called on,
then it's either a straight-up user or group lookup, for one which is not
defined in the flat files under /etc.  Just to be sure, you're not using
nss_ldap for host resolution, are you?
Comment 5 Andreas Bierfert 2006-02-13 08:37:34 EST
Nope, just for user,group lookups.
Comment 6 Nalin Dahyabhai 2006-02-13 17:44:54 EST
It looks like it's getting stuck looking up the GID of the "nogroup" group,
which doesn't exist.  I've filed that as bug #181432.
Comment 7 Andreas Bierfert 2006-02-13 17:46:39 EST
Thanks :)
Comment 8 Andreas Bierfert 2006-02-26 03:40:45 EST
Hm, I think this one can be closed now... everything is working now with lates
updates... :)  Thanks again.

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