Bug 181306 - nss_ldap is started to early on init
Summary: nss_ldap is started to early on init
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: nss_ldap (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On: 181432
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-02-13 11:54 UTC by Andreas Bierfert
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-26 15:33:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Andreas Bierfert 2006-02-13 11:54:38 UTC
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 13:09:18 UTC
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 13:21:34 UTC
Hmm, that should be 248-2, which added "nss_initgroups_ignoreusers root,ldap" to
the default configuration.

Comment 3 Andreas Bierfert 2006-02-13 13:27:39 UTC
#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 13:33:15 UTC
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 13:37:34 UTC
Nope, just for user,group lookups.

Comment 6 Nalin Dahyabhai 2006-02-13 22:44:54 UTC
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 22:46:39 UTC
Thanks :)

Comment 8 Andreas Bierfert 2006-02-26 08:40:45 UTC
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.