Bug 186527

Just remove the "in firstboot" from the summary. It happens in other
circumstances as well.

I did a fresh install of FC5, without ldap at first. Then I added the ldap stuff
and restored my directory and various configuration files from the FC4 backup.
Everything seemed to work fine until I restarted the system. It did not get
further then "starting system message bus".

I managed isolate the problem to enabling ldap for User Information in
Authentication Configuration. As soon as I did that I could no long (re)start
the service messagebus. If I disable the ldap then the messagebus (re)starts 
without a problem.

I have experimented a bit with en-/dis-abling ldap User Information while I had
the (test!) system up at runlevel 5 (which makes it easier to look around then
in single user mode). In /var/log/messages I found a bunch of these:

Mar 26 17:07:31 lt2 kernel: audit(1143385651.940:368): avc:  denied  { search }
for  pid=3049 comm="dbus-daemon" name="pki"
 dev=dm-0 ino=40997 scontext=user_u:system_r:system_dbusd_t:s0
tcontext=system_u:object_r:cert_t:s0 tclass=dir
Mar 26 17:07:31 lt2 kernel: audit(1143385651.944:369): avc:  denied  { search }
for  pid=3049 comm="dbus-daemon" name="pki"
 dev=dm-0 ino=40997 scontext=user_u:system_r:system_dbusd_t:s0
tcontext=system_u:object_r:cert_t:s0 tclass=dir
Mar 26 17:07:31 lt2 dbus-daemon: nss_ldap: reconnecting to LDAP server (sleeping
4 seconds)...
Mar 26 17:07:35 lt2 dbus-daemon: nss_ldap: reconnecting to LDAP server (sleeping
8 seconds)...
Mar 26 17:07:35 lt2 kernel: audit(1143385655.949:370): avc:  denied  { search }
for  pid=3049 comm="dbus-daemon" name="pki"
 dev=dm-0 ino=40997 scontext=user_u:system_r:system_dbusd_t:s0
tcontext=system_u:object_r:cert_t:s0 tclass=dir
Mar 26 17:07:43 lt2 dbus-daemon: nss_ldap: reconnecting to LDAP server (sleeping
16 seconds)...

First impression is that selinux blocks dbus-deamon from getting access to
something in /etc/pki. That is where I keep my home-brew certificates for ...
the ldap server and the like.

This issue really, really needs to be fixed. We use tls_checkpeer no to just
ignore certificates (ours are self-signed anyways), but it doesn't fix the
problem. Please consider moving up the priority of this issue - it really kills
us for using LDAP auth.

Unfortunatly current policy doesn't allow you to selectively disable selinux for
this particular daemon. For many others you do have that option.

Although not a solution, a workaround could be to switch selinux to permissive.
Mind you, although you then still get most of the audit messages, you don't get
the protection!

Even if you set selinux to permissive (or disabled), the message

    dbus-daemon: nss_ldap: failed to bind to LDAP server

persists. This is caused by the fact that LDAP's slapd daemon is not yet started
when the messagebus' dbus-daemon is starting up. After checking an other system
still running Fedora Core 4 I discovered that in Fedora Core 5 the messagebus
start and stop priority levels are different from Fedora Core 4.

chkconfig line in /etc/rc.d/init.d of Fedora Core 5:

# chkconfig: 345 22 85

chkconfig line in /etc/rc.d/init.d of Fedora Core 4:

# chkconfig: 345 97 03

The start priority level of ldap is 27 for both Fedora Core 4 and Fedora Core 5.

In my case a suitable workaround was to change the ldap start priority level
from 27 to 21, so it is started just before the dbus-daemon is launched, but
probably it would be better to find a more suitable start priority level for
messagebus.

in my previous comment, /etc/rc.d/init.d should read /etc/rc.d/init.d/messagebus

In my case, this has absolutely nothing to do with when the ldap server starts
up, as my ldap server is running on an entirely different machine. The sole
issue in my particular case is that if the slapd.pem file isn't in place,
message bus stalls for about 15 minutes, then cups does the same -- eventually,
the system finishes starting up, it just takes ages. (This is actually somewhat
related to another bug I've got open, #186525). Put slapd.pem in place, and all
is well.

However, in the case where the ldap server is on the local machine, yes, I
believe slapd should get started earlier.

*** Bug 186525 has been marked as a duplicate of this bug. ***

Does it help if you put 'bind_policy soft' to the /etc/ldap.conf file?

(In reply to comment #1)> I have experimented a bit with en-/dis-abling ldap
User Information while I had
> the (test!) system up at runlevel 5 (which makes it easier to look around then
> in single user mode). In /var/log/messages I found a bunch of these:
> 
> Mar 26 17:07:31 lt2 kernel: audit(1143385651.940:368): avc:  denied  { search }
> for  pid=3049 comm="dbus-daemon" name="pki"
>  dev=dm-0 ino=40997 scontext=user_u:system_r:system_dbusd_t:s0
> tcontext=system_u:object_r:cert_t:s0 tclass=dir
[snip]
> First impression is that selinux blocks dbus-deamon from getting access to
> something in /etc/pki. That is where I keep my home-brew certificates for ...
> the ldap server and the like.

Does updating to the latest selinux-policy for FC5 (2.2.29-3.fc5) do anything to
alleviate the problem?  This specific error should have been fixed then.

After I updated to selinux-policy-targeted-2.2.29-3.fc5, I could (while at
runlevel 5):

root@lt2 ~> setenforce Enforcing
root@lt2 ~> service messagebus restart
Stopping system message bus:                               [  OK  ]
Starting system message bus:                               [  OK  ]

without a problem! The audit messages mentioned in comment #1 are gone.

But ... I can not longer reboot into runlevel 5 even with selinux in Permissive
mode. First impression is that various daemons have a hard time getting in touch
with ldap. I am still investigation.

Seems I was to impatient. Where it normally takes no more then a few minutes to
reboot, it now takes 38 minutes. There are loads of syslog entries like these
(with increasing sleeping xx seconds).

Apr 19 17:30:48 lt2 rpc.statd[1651]: nss_ldap: reconnecting to LDAP server
(sleeping 64 seconds)...
Apr 19 17:30:52 lt2 dbus-daemon: nss_ldap: reconnecting to LDAP server (sleeping
64 seconds)...

Apr 19 17:44:34 lt2 dbus: nss_ldap: reconnecting to LDAP server (sleeping 16
seconds)...
Apr 19 17:44:35 lt2 runuser: nss_ldap: reconnecting to LDAP server (sleeping 16
seconds)...

Apr 19 18:03:02 lt2 slapd[1741]: nss_ldap: reconnecting to LDAP server (sleeping
4 seconds)...

Now ntpd seems to run into /etc/pki problems:

Apr 19 18:05:15 lt2 kernel: audit(1145462715.267:8): avc:  denied  { search }
for  pid=1798 comm="ntpd" name="pki" dev=dm-0
 ino=40997 scontext=system_u:system_r:ntpd_t:s0
tcontext=system_u:object_r:cert_t:s0 tclass=dir

Also xfs runs into als sorts of access problems.

In reply to comment #6: Same problem with named, ldap is started too late

I changed named:

# chkconfig: - 13 87

to:

# chkconfig: - 33 67

ldap has:

# chkconfig: - 27 73

and nscd has:

# chkconfig: - 30 74

(In reply to comment #1)
>
I Am having similar problems. Using ldap for samba for windows users and 
computers. Have tried the suggestion in changing ldap startup prioity will no 
luck.
Has anyone found a working solution??
Steve

In the scenario where slapd is run on the host and selinux isn't involved the 
following:

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon

in /etc/ldap.conf is enough to stop real ldap use long enough for slapd to 
start.

The users correspond to:

grep "policy user" /etc/dbus-1/system.d/*

In the scenario where slapd is run on the host and selinux isn't involved the 
following:

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon

in /etc/ldap.conf is enough to stop real ldap use long enough for slapd to 
start.

The users correspond to:

grep "policy user" /etc/dbus-1/system.d/*

Shouldn't this be high severity?

I don't know for sure if this is related, but authconfig --test is showing
that "Authenticate system accounts against network services" is enabled,
even though I've disabled it in authconfig-gtk.

Anyone know what I should be looking at the actual config files to check
this?

Comment #17 is just a typo in the '--test' option implementation. It will be
fixed in next authconfig rebuild and it isn't related to this bug.

It seems like what's really needed here is a way to not search LDAP (or NIS?)
for groups to which system users belong.  "nss_initgroups_ignoreuidsbelow" or
something like that.  Otherwise, every random service that someone installs
can potentially cause this problem.

"Me too!"

I am suffering badly because of this with my laptop: in our intranet where LDAP
server is running on a server everything works all ok but when I roam to another
network boot will hang at dbus. My laptop is using DHCP and autofs and SELinux
is disabled everywhere but the system integration seems to be incomplete as a
change in network environment will cause my system to halt on boot.

Perhaps you could also consider investigating the DHCP extension ldap-server to
be used with DHCP?

Thanks.

Okay, finally getting back to this... Current rawhide has
"nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon" (see comment #14)
on by default, so there's no more hangup of named/avahi/dbus/hal on a test box
of mine (ldaps auth client only). However, startup of nscd still hangs for quite
some time, presumably trying to establish an encrypted session to the ldap
server, sans required pem file. Altering /etc/ldap.conf to include 'bind_policy
soft' per comment #8 does indeed make nscd startup quick again.

While its not exactly the same situation, I think the combination of these two
options should help tremendously in Daniel's case (comment #20) as well.

As for what the defaults ought to be so these hangs can't happen, I dunno...
Should we perhaps be setting 'bind_policy soft' whenever users select ldap auth,
or possibly only if they select ldaps auth? Not sure what negative impacts this
could have on networks with busy ldap servers or slow links though. Or should we
just add a checkbox to let the user decide? (I think I'm in favor of a
checkbox). If so desired, I can try to whip up a patch to implement a checkbox
for setting bind_policy.

Setting bind_policy to soft solved the boot problen but whem the server got busy
my users started seeing authentication problems. The authentication problems
went away when the bind_policy was set back to hard. In the end I moved the LDAP
daemon startup priority ahead of named (27 --> 12) and things are working.

Brian, I don't quite follow... I was setting bind_policy on a client system, not
the server. The client system doesn't ever start an LDAP daemon... Where were
you setting bind_policy?

Jarod, sorry I wasn't clear. I have a single server with slapd (for samba auth)
running on the same box. This box hangs at boot because slapd isn't started soon
enough for named, etc. Setting the bind_policy to soft let the box boot quickly
(ignoring the missing ldap server) but appears to cause problems later on. So I
guess my point is I may have seen problems with bind_policy soft.

(In reply to comment #24)
> Jarod, sorry I wasn't clear. I have a single server with slapd (for samba auth)
> running on the same box. This box hangs at boot because slapd isn't started soon
> enough for named, etc. Setting the bind_policy to soft let the box boot quickly
> (ignoring the missing ldap server) but appears to cause problems later on. So I
> guess my point is I may have seen problems with bind_policy soft.

Ah, okay, thank you for the clarification. I *think* you should actually be okay
leaving slapd starting up where it was (27) if you have
'nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon' in /etc/ldap.conf,
even while leaving the bind_policy set to hard.

But yes, bind_policy soft does have the potential to cause havoc, so I think an
extra check box is the way to go.

Additional thoughts, anyone?

FWIW, I'm all ok with a checkbox, soft for bind policy made my day, thanks!

PS. Perhaps you still could check DHCP option ldap-servers (I think Debian has
it) as we already have ntp-servers and nis-servers DHCP options although I won't
complain if you decide to ignore it.

I can confir all of the above.
i had to add some users to the nss_initgroups_ignoreusers variable in
/etc/ldap.conf. That solved the problem with the System Message Bus and other
services as well, but it would still hang when starting the Hal Deamon
(haldaemon was added to nss_initgroups_ignoreusers). I had to change the
bind_policy to soft.
That worked ok for the system boot.

The problems arised when i tried to use a local user. First i could not login
nor su - to the user. When trying to do an ls -l with root i would take ages.
Finaly i had to comment every entry with ldap.so in the
/etc/pam.d/system-auth-ac aparently the auth failed when pam recieved and error
from the ldap bind.

Something is really wrong here, authentication and user information should
automaticaly fallback to local files when ldap is not available. (nsswitch.conf
was correctly configured, first files then ldap.)

The ldap start order / system users being looked up in ldap part of this bug is also in bug #206399. I'd 
suggest splitting the issues here.

Anything happening on this front? It's _really_ bad that a machine refuses to
boot when the LDAP server is missing.

Another interesting tidbit I've found is that a machine with a fully working
LDAP client configuration will fail to boot properly (hanging at "starting
system message bus") if I do nothing other than simply go into the BIOS and
setting the date improperly.  Setting it correctly (or getting the system to
boot once so that it gets set properly by NTP) is enough to get things working.

I'm pretty much at a complete loss as to why the date would make a difference
here.  On a hunch I deleted the nscd caches but that didn't help.

This problem (or one of them) affects RHEL5.  On a machine which hosts its own
LDAP directory, messagebus still hangs during boot.  The situation is resolved if:

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon

becomes:

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus

Can this change be pushed into the appropriate package?

Note that the nss_initgroups_ignoreusers change in the comment above also
"fixes" messagebus when using a remote ldap server (tested on rhel5)

If this is really needed, then an errata needs to be made to fix the default
/etc/ldap.conf file in RHEL5.

(In reply to comment #32)
> Note that the nss_initgroups_ignoreusers change in the comment above also
> "fixes" messagebus when using a remote ldap server (tested on rhel5)

Note that RHEL5 is *a lot* closer to FC6 than FC5.

(In reply to comment #33)
> If this is really needed, then an errata needs to be made to fix the default
> /etc/ldap.conf file in RHEL5.

This bug is about FC5; if you need this fixed in RHEL5 someone need to clone
this bug against RHEL5.

Ok... there is an identical issue opend for RHEL5.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234541

And it seems that these are all related to the fact that groups are missing from
/etc/group that udev needs.

I was deleting the uucp group as many people do.  Its one of those "unused" gids
that many people delete from their systems as part of their build.  In fact its
recommended by CIS, Bastille etc.  

Well, udev NEEDS the uucp group to be in /etc/group and if it can find it there,
then NSS will try ldap too, but of course the network is not up and hence the
errors and hang.

The FIX FOR THIS is probably to go into /etc/udev/rules.d and do a "grep GROUP=
*" and get a list of all the different groups/gid's that udev needs and make
sure all of them exist in your /etc/group file.

This is also happening on FC7 and CentOS5. I thought Redhat was suppose to be
for the enterprise? With a problem like this how can it be? 

I have a stock FC7 and also stock CentOS with LDAP auth enabled and this is
happening. If the clients can reach the LDAP server everything is fine and dandy
but when they cannot, it hangs on system message bus. to reproduce all i have to
do is block the ldap port using iptables (which is one way a client will not be
able to talk to the LDAP server) I am running FDS ldap.

I'm seeing this on F8T2, installed from Live. The workaround for me was to put
this in /etc/ldap.conf:

bind_timeout 2
nss_reconnect_tries 2
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 3
nss_reconnect_maxconntries 3

Otherwise, things would hang at "starting system message bus" for many, many
minutes (after which I lost patience and pressed the button).

Let me clarify on comment 36 and comment 37: you did not remove any of the
default groups from /etc/group and did not change nss_initgroups_ignoreusers?

Correct.

FWIW, nss_ldap has been forked and the new incarnation, nss-ldapd, promises to
fix many of the issues found with nss_ldap. Please see

http://ch.tudelft.nl/~arthur/nss-ldapd/
http://ch.tudelft.nl/~arthur/nss-ldapd/design.html

I downloaded and installed rawhide today, and it seemed to have these problems.
 I installed with kickstart, and the only way I touched ldap was:

auth --enableldap --enableldapauth --ldapserver=[server] --ldapbasedn=[basedn]

I also did `selinux --disabled` in kickstart.

On boot, it hangs at "Starting system message bus".  If I switch `group: files
ldap` to `group: files` in /etc/nsswitch.conf, messagebus starts.

By the way, this bug looks like it's the same as 182464 and 221199.

I followed the link to nss-ldapd, and it really does look promising.  Is there
any word on whether/when it's planned to be included in Fedora?

I was originally resistant to it due to feature differences, but despite that
I'm warming up to the idea.

What if nss-ldapd were made available as an alternative to nss-ldap?  Then you
sort of get the best of both worlds (although I'm sure it would be more work to
maintain).

(In reply to comment #44)
> What if nss-ldapd were made available as an alternative to nss-ldap?

I like the idea.  I'd prefer to have it happen without requiring user
intervention (probably keying somehow off of whether the daemon was enabled at
all), if only to avoid having to write some sort of tool to do it (or document
it somewhere and depend on people finding the documentation).  If someone else
gets to it first, great, otherwise it's near the top of my list for the upcoming
development cycle.

(In reply to comment #45)
> it's near the top of my list for the upcoming development cycle.

Great.  I'm excited to see it.

Thank you!

One more "FWIW" comment from me: I asked about this in the FreeIPA dev list and
they were aware of nss-ldapd but they're planning creating something "a bit more
sophisticated":

https://www.redhat.com/archives/freeipa-devel/2008-April/msg00103.html

per comment #41 changing version to 'rawhide'

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Wasn't this reported as happening against rawhide? Should it have been
automatically closed?

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Can this be closed? Anyone still seeing this?

Until nss-ldapd replaces nss_ldap, this problem won't go away.  Everything else is just a temporary workaround.

Still seeing an issue with F10.  As I stated in #182464, if I chkconfig network on this change resolves the issue for me since the network is started and the messagebus service can talk to my AD LDAP server.

> Until nss-ldapd replaces nss_ldap, this problem won't go away.
> Everything else is just a temporary workaround.

As stated in another case, it seems that SSSD comes to rescue:

https://fedoraproject.org/wiki/Features/SSSD

SSSD looks like is tied to FreeIPA from a brief look that I had so I don't see how it's going to help with people using a different ldap server.

(In reply to comment #57)
> SSSD looks like is tied to FreeIPA from a brief look that I had so I don't see
> how it's going to help with people using a different ldap server.  

SSSD is independent from IPA. It is developed under the umbrella of the IPA project but can be used with different back ends: LDAP, NIS, IPA etc.
There are plans for making Samba a back end some time in future.

One of the cases where this bug happens is a system that runs an LDAP server.  Unfortunately, the LDAP server (S27ldap) starts after DBUS (S22messagebus).  Would it be possible to change LDAP to start just before DBUS (make it S21ldap instead of S27ldap).  This doesn't solve all of the places where this hang happens, but it does help for one important case.

By the way, this bug is still set for Fedora 10 but is still present in Rawhide.  I think the version field needs to be updated.

This bug is still present in F12 Beta.  I installed from the Live CD and set up LDAP (both PAM and NSS parts).  The LDAP server in question is remote and already set up.

After the reboot, it hangs (seemingly forever) on «starting message bus».

Booting up in single user mode, setting "bind_policy soft", and rebooting again does seem to fix the problem - at least it boots up correctly and allows me to log in using a user only found in the LDAP directory.

Tore

Since nss_initgroups_ignoreusers has been used as the workaround to this problem so far, "rtkit" and "pulse" must now be added to that setting.  This is going to require a patch to authconfig.  I'll try to submit a new bug to that package later today, unless someone else does it sooner.

This is not done by authconfig but it is set up in the default configuration file in nss_ldap.

(In reply to comment #62)
> Since nss_initgroups_ignoreusers has been used as the workaround to this
> problem so far, "rtkit" and "pulse" must now be added to that setting.

Gordon, thanks for doing the legwork in finding what we needed to add here.  It should be part of the new default in Raw Hide.

Terrific, I wouldn't have gotten around to submitting a patch until later today.  Thanks.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

As far as I can tell, having rtkit and pulse in the nss_initgroups_ignoreusers doesn't seem to help.  In Fedora 12, it looks like a lot of services are hanging, not just messagebus.  I ended up coming up with a great workaround.  I created the file /etc/chkconfig.d/slapd with the single line "# chkconfig: - 11 89".  This makes slapd start up just after network (before messagebus and a slew of other services).  I haven't seen any negative effects yet; is there any reason that this ordering couldn't be the default?

I agree with Andrew McNabb. Although I implemented the same fix slightly differently.

Change the chkconfig line in /etc/rc.d/init.d/slapd to read:

  # chkconfig: - 12 73

Then do:

 # chkconfig --del slapd
 # chkconfig slapd on

This ensures slapd starts after networking and before anything that hangs without it.

Andrew Meredith, that's a great way to do the fix.  Is there any particular reason you picked it to start at 12 instead of 21?  I'm not sure it really matters either way, but I'm curious.

Is there any chance of moving the ldap server earlier in the boot order in Fedora 13?  Adding more users to nss_initgroups_ignoreusers just patches around the problem temporarily.  This problem has been happening for years, and it's open in three different bugs (this one and bug #182464 and bug #502072).  There's a nice, quick, easy, and elegant fix (switching the boot order), and it would be really nice to have it fixed once and for all.

@Andrew McNabb: I chose 12 as it is before 13, which is where named sits in the sequence. I was getting several service scripts freezing, the earliest of which was named. I use LDAP as the core authority across this particular system, and as it a small business style job, the LDAP server box is itself an ordinary service machine, so it needs the same user accounts as all the others.

Same symptoms on Fedora 12 with openldap-servers-2.4.19-4.fc12.i686, selinux is in permissive mode, system hangs after "Starting message bus" with syslog messages:

Jun 29 10:45:23 yellow runuser: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server
Jun 29 10:45:23 yellow runuser: nss_ldap: reconnecting to LDAP server (sleeping 4 seconds)...
Jun 29 10:45:27 yellow runuser: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server
Jun 29 10:45:27 yellow runuser: nss_ldap: reconnecting to LDAP server (sleeping 8 seconds)...
Jun 29 10:45:35 yellow runuser: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server
Jun 29 10:45:35 yellow runuser: nss_ldap: reconnecting to LDAP server (sleeping 16 seconds)...
Jun 29 10:45:51 yellow runuser: nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can't contact LDAP server
Jun 29 10:45:51 yellow runuser: nss_ldap: reconnecting to LDAP server (sleeping 32 seconds)...

I've changed start LDAP at 12 and after that (and another unsuccessful reboot) commented out configtest line at start() function in LDAP init script (/etc/init.d/slapd):

function start() {
        [ -x $slapd ] || exit 5
        [ `id -u` -eq 0 ] || exit 4
        # configtest

That was 'quick and dirty' but fixed the problem. Looks like /sbin/runuser called in configtest() needs running instance of LDAP.

Hope it helps.

I'm pretty sure this behavior is finally gone in F13 due to this setup by default not using nss_ldap at all.  SSSD is used instead, and while it seems to have its own quirks it at least appears to handle this situation.

This still happens in fedora 14. ipa-client-install uses nss_ldap by default and causes this.

There is a directive in /etc/ldap.conf that might be involved here.

------ 8< ---------------
# Just assume that there are no supplemental groups for these named users
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon
------ 8< ---------------

If people are upgrading from an older install that didn't have as many entries on this line, specifically named, avahi and haldaemon, then they will see the problem. Having extended the above line to include these system users, the problem has stopped; even when named and haldaemon are started before LDAP. This is probably the true cure, although a directive to assume that any UID below (eg) 501 has no suplemental groups would be more universal and would not require updates to ldap.conf every time a new startup involved system user was created.

I've always done clean installs, and my ldap.conf has:

nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm,polkituser,rtkit,pulse

SSSD is not currently running on this particular machine, but nss_initgroups_ignoreusers should still stop processes from hanging while trying to lookup any of these users.  I have run into this problem because runuser hangs in /etc/init.d/slapd (the hang stopped when I commented out a line that calls runuser).  SSSD is great, but it shouldn't have to be running for slapd to be able to start.

Keep in mind this is on an ldap -client- only. This does happen only when the network is down at boot.

Should nscd/sssd start before messagebus/mdmonitor/et al ?

I tried adding
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm,polkituser,rtkit,pulse
to the nss_initgroups_ignoreusers entry but it did not change behavior.

I cannot reproduce this on FC13, just FC14

I was under impression that nss_ldap is deprecated and one should use SSSD instead. Even nss-pam-ldapd would be better alternative than nss_ldap, though it might not necessarily help in this particular case.

But it is very surprising to hear ipa-client-install not using SSSD. I filed bug 645506 about that.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I can confirm that Fedora 13 has the same issue as Fedora 12 with LDAP accounts and booting. As I am neither the maintainer nor the reporter, could one of them please up-version this bug.

Cheers

I'm bumping the version to 13.  It looks like Fedora 14 finally seems to integrate SSS well enough to fix the problem, but I still have a bit more testing to do before I'll know for sure.

Re. #81: SSSD does not support acquiring AFS tokens on login, so people like me,
who need to operate in a KRB5/LDAP/AFS environment can't use it yet. I had to
use --enableforcelegacy with authconfig to get pam_krb5 and nss_ldap configured
instead of SSSD (see bug # 605857).

Interestingly enough, I haven't encountered this problem in F12. I skipped F13,
and only ran into it now once I upgraded to F14.

BTW, authconfig now sets 'nss_initgroups_minimum_uid 500' in /etc/nss_ldap.conf
instead of enumerating most system users in 'nss_initgroups_ignoreusers' as it
did in F12 in /etc/ldap.conf. According to the man page for nss_ldap, this should
accomplish the same effect (neither statement does help in F14, BTW).

The spot it hangs at in F14 is 'starting mdmonitor'.

To be precise, I'm not running any LDAP/KRB5/AFS servers, this is a client setup only.

Could someone please up-version (again) to F14 ?

FWIW, I don't use LDAP for groups at all. So, changing from

   group: files ldap

to

   group: files

in /etc/nsswitch.conf turns out to be a usable workaround in my situation.

This bug STILL EXISTS in FC15.

Gabriel's suggestion also worked for me -- just now it shows the GIDs instead of the name on any 'ls -l' command.  And always the possibility that something else will break down the line if a group name is required.

Isn't this getting a little ridiculous, or is someone gunning for the prize for the oldest bug on record?

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I was searching the problem and finally i found it in my case. I am going to describe the procedure that I followed.

1. Turn off nscd service and execute the next command
 
 nscd -d

2. In other console try to run next:
 
bash -x /etc/init.d/slapd start

3. Script stopped when try to run "runuser", look the first console and you can see that some group could not be found.

4. Go to the /etc/security/limits.d and search that group and comment that line. In my case was pulse-rt.

5. try again start slapd service.

I hope this information can be usefull. good luck.

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping