udevd: nss_ldap: failed to bind to LDAP server

Currently 251-5 has 5 RC bugs open, so we'd be trading 1 RC bug for 5 others.

Sync for 251-5.2 has been requested

Bug is not clearly closed in Debian and I still have this issue upgrading from Dapper to Edgy.
Andrew, what kind of information I could provide to help ?

This should be marked critical IMHO

-s

I do have the same problem.

During boot i get the following message:

udevd[374]: nss_ldap: could not connect to any LDAP server as (null) -
Can't contact LDAP server

I tried to install Edgy Eft either from the CD or by upgrading via apt, both ways I meet the same error.

And i would agree that the bug should be marked as Critical.

I can confirm this in edgy. Is it trying to connect prior to the network interface coming up?

I tested with the latest release in Debian (251-7) and the bug is fixed for me. It could be a good candidate for edgy-updates.

Little precision, by "tested" I mean recompiled from source in and Edgy pbuilder and install on a station that fails to boot with a "hard" bind policy. Now it works.

For those who are interested, the package is available here:
http://www.porcheron.info/libnss-ldap_251-7_i386.deb

Confirmed on both Dapper and Edgy. The problem is worse on Edgy

I'm using a temporary fix on Dapper
in the nscd init script, I copy nsswitch.conf.ldap before starting nscd and put nsswitch.conf.default back when stopping.

This does not work on Edgy because nscd seems to be started before the network is available (circular dependency).

Note that setting bind_policy to soft as suggested does not fix the problem.

It makes the boot process proceed normally, but the error still remains and udev fails.

I've have had the same problem, found the reason and solved it.

The problem is caused by the usage of the non existing group 'nvram' in /etc/udev//rules.d/40-permissions.rules:
...
KERNEL=="nvram", GROUP="nvram"
...

When udev starts, is looks up 'nvram'. While 'nvram' could not be found in /etc/group NSS tries to connect the ldap server. As result the boot sequence stops.

To fix this problem is very easy: Add the local group 'nvram' to /etc/groups

After that booting with nss_ldap and bind_policy hard works without any problem.

I've got the same, or a similar problem, but it's blocking when setting up resolvconf, not udev, or so it appears.

Adding the nvram group did not fix the problem. The only thing so far that seems to work is booting without ldap enabled. Things basically worked ok on dapper, but eft has been something of a minor disaster so far.

mmmh... I've an efty client up and running...

I'm using a static ip address, an hand made resolv.conf and my nsswitch.conf is very simple:

passwd: files ldap
group: files ldap
hosts: files dns
services: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files
automount: files
aliases: files
sendmailvars: files
netgroup: files

confirmed in Edgy

I have nsswitch set up like this:

passwd: ldap compat
group: ldap compat

Because I want to have it check ldap prior to checking the local system. Still though, that worked before and it shouldn't fail now.

Thanks,
Dave

You should make it check compat first. It is illogical to override a local user with a remote one. We should then identify what the actual problem is.

We had this same problem. We worked around it by putting the ip address instead of the hostname. That way the query fails immediately because it doesn't have to do a hostname lookup.

A better bug report is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375215 which gives the following solution (which wfm):

"I guess I could have been clearer on these, in your libnss-ldap.conf:
nss_reconnect_tries 1
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 8
nss_reconnect_maxconntries 2"

which makes nss-ldap fail a lot faster. For those bringing up single user mode, if it hangs, you can get a sulogin prompt by pressing ctrl-alt-del after libnss-ldap has completely timed out.

I have installed libnss_251-7.amd64.deb to fix the boot problem but though now I see my ldap users at logging time no way to connect to any of them ; in console mode a :
# su ldap_user
displays the following error message
ID unknown : ldap_user

Ldap servers is running and I can add mor Ldap users using Kuser ! ; before running the patch everything worked fine until I had to reboot !

What is wrong ?
Regards.

I'd like to echo Ralph Becker's solution. Doing a:

sudo addgroup --system nvram

fixed my problem.

i was also bitten this time..i used Scottie's sudo addgrpoup --system nvram which did not resolve the problem..installing latest libnss http://www.porcheron.info/libnss-ldap_251-7_i386.deb
Did resolve the problem.chuck liebow

Also confirmed in a new Edgy install.

sudo addgroup --system nvram
fixed my problem.

I tried a full reinstall, but no luck.

The closest thing to fixing it is to use bindpolicy soft.

I also have this bug #67307 with ldap users, it was not fxed with the new deb package

Doing a addgroup --system nvram
fixed my problem.

Doing a "addgroup --system nvram" makes the:

udevd: nss_ldap: failed to bind to LDAP server

error disappear, but my boot-time still remains abount 40 minutes long!
When I remove ldap from nsswitch.conf my boot-time returns to acceptable values.

This should be marked CRITICAL in my opinion. This bug makes Ubuntu unusable on LDAP-authenticated networks!

ldap works just fine here on dapper&feisty. I have 251-5.2 on dapper and 251-7 on feisty.

nsswitch.conf:
passwd: files ldap
group: files ldap
shadow: files ldap

of course it complains about nvram but that's Bug #38203.

This bug still remains in Feisty Fawn. I've upgraded from Edgy and it still remains.. please fix it!

sudo addgroup nvram solves the problem! Now there is another one with hal CPU consumption.

"sudo addgroup nvram" didn't solve the problem.

After boot, I do:
sudo /etc/init.d/udev stop
sudo /etc/init.d/udev start

It works and set CPU for 0% and not 100%.

Hi there,
There's no news since december, I tried to install ldap recently but I got all those problems above... nothing fix it.
And i would agree that the bug should be marked as Critical.

thanks.

I'm very frustrated about that. Ubuntu is "free software and comes with no warranty", I understand... I'm not pretending this bug to be resolved immediatly, but at least it should be marked as CRITICAL or HIGH because it makes Ubuntu *unusable* on LDAP-authenticated networks!

libnss-ldap is in Universe, ie it's not part of the official Ubuntu support. slapd on the other hand is, so you can get support for serving LDAP, but not using it. How this makes Ubuntu "enterprise" quality is a question for Canonical.

Then *please* test libnss-ldap in edgy-proposed, it hasn't made it into edgy-updates due to lack of community feedback on the package.

ok, nice that there is an update in testing, it would have been nice to have a comment here to warn us about it... (unless I overlooked).

How do we give feedback on the package?

I didn't know there was a package updated in edgy-proposed. I tested it and it seems to work, login prompt appears quickly and LDAP users get authenticated but error messages like ``udevd[374]: nss_ldap: could not connect to any LDAP server'' still remain on boot-up process.

Add feedback on bug 70146

We installed 2 Dell SC1435s with edgy and libnss_ldap. We got the error with "Cannot contact LDAP server" on both (one is a slave slapd). /home is an NFS mount on one of them and will not mount on boot (despite being in /etc/fstab). I don't know if it's related.

When we started using the machine as a webserver, apache2 was segfaulting and the machine would hang/lockup for a few minutes every 10/15 minutes. We took the load of the machine and tried to debug. Again, I don't know if it's related.

I installed the new package from edgy-proposals. Now, you don't get the "Cannot contact - sleeping for [2,4,8,16,32,64] seconds but it still does give an error that it cannot contact the LDAP server.

Doing:
sudo addgroup --system nvram

And changing the order of "ldap files" to "files ldap" on nsswitch.conf
passwd: ldap files TO passwd: files ldap
group: ldap files TO group: files ldap
shadow: ldap files TO shadow: files ldap

ON
#cat /etc/issue
Ubuntu 6.10 \n \l

the problem was fixed!!!!

adding the group nvram worked for me.

could this be automatically done when installing libnss-ldap or libpam-ldap ?

installing 251-7 fixed it.

nsswitch.conf:
passwd: files ldap
group: files ldap
shadow: files ldap

/etc/issue:
Ubuntu 6.10 \n \l

With libnss-ldap from edgy-proposed, problem is still there - 15 minutes to boot. Tried adding nvram as a local group. Nothing.

nsswitch.conf:
passwd: files ldap
group: files ldap
shadow: files ldap

Installed libnss-ldap 251-7.5 from Feisty (including the upgraded libc). Solved the problem.

I use a combination of libnss-ldap and libnss-db. With "bind_policy soft" in libnss-ldap.conf I can boot without any problem. My nsswitch.conf look like this:

passwd: files db [SUCCESS=return] ldap
group: files db [SUCCESS=return] ldap
shadow: files ldap

(Ubuntu Edgy/Server)

I had the same problem, after 5 minutes of `udevd[374]: nss_ldap: could not connect to any LDAP server' messages, I saw the message of fuse group doesn't exist, so I copy the /etc/group from another computer (which has another kind of installation) and it has the line:
fuse:x:494:
Now, everything is ok.

I had to add two groups to get udevd to start without querying LDAP.
addgroup --system nvram
addgroup --system scanner

A tips: grep for "GROUP" inside the udev rules directory:
 grep GROUP *

Then check if all groups are listed in /etc/group

(Ubuntu Edgy)

Any Progress on this?

It's not long till hardy and this is not fixed since 2 releases. I'm losing trust in enterprise capabilities of ubuntu....

Same here with Gutsy: I try to work as local user on a client with libnss-ldap installed while the server is down. It just does not work. Perhaps the following observations are helpful.
1) Server running slapd, bind9 : client boot : yes
2) server running bind9 only : client boot : yes
3) server running : client boot : yes
4) server running, networking stopped : client boot : no
I really doublechecked for running processes and state of interface on the server. Above behaviour is reproducible. It seems libnss-ldap disregards the sequences given in nsswitch.conf when the server cannot be reached at all.
Regards
Michael

does not work with hardy/i386 as of April 3, 2008, a very long delay before booting completes.

presumably having not listed first in /etc/nsswitch.conf is a partial fix but it ought to work in any
position.

After 2 and a half years from my previous post here and the problem still unsolved. I want to make Ubuntu work with LDAP so we can install it in a Computer Lab at my University but this is making it pretty difficult.

I'm in the same situation.

After all I'd suggest dropping ubuntu in environments with these requirements. Personally I'll go back to Debian. I'll miss the X config stuff that works most of the time for me, but on the other end once I updated my template to deploy with etch or testing again on the boxes I'll be done with. And I can be pretty sure that bugs like these are fixed within a considerable amount of time by debian.

The problem is clear. No networking when udev attempts to configure devices with certain ownerships presumably
and yet the startup scripts to setup networking come after the udev ones:

 find /etc/rc?.d -type l -ls|egrep '(udev|networking)'
3646856 0 lrwxrwxrwx 1 root root 14 Nov 15 2006 /etc/rcS.d/S10udev -> ../init.d/udev
3646868 0 lrwxrwxrwx 1 root root 20 Nov 15 2006 /etc/rcS.d/S40networking -> ../init.d/networking
3647204 0 lrwxrwxrwx 1 root root 21 Feb 11 14:59 /etc/rcS.d/S37udev-finish -> ../init.d/udev-finish

guess what udev starts up before networking....and it finishes before networking starts. As an initial fix
please reorder these?

Even doing this:

files ldap [UNAVAIL=return]

does not work. Strangely enough if I first go into rescue mode and then let it resume it works?? Perhaps enough
time has gone by?

All this with hardy/i386 April 7, 2008

Debian Etch showed the same problem for me..

On Mon, 2008-04-07 at 14:39 +0200, Martin Marcher wrote:
> I'm in the same situation.
>
> After all I'd suggest dropping ubuntu in environments with these
> requirements. Personally I'll go back to Debian. I'll miss the X config
> stuff that works most of the time for me, but on the other end once I
> updated my template to deploy with etch or testing again on the boxes
> I'll be done with. And I can be pretty sure that bugs like these are
> fixed within a considerable amount of time by debian.
>
--
_______________________________________________
Guy Van Sanden || http://nocturn.vsbnet.be

PGP KeyID: 28F16C35
Registered Linux user #249404 - September 1997

The problem is two config files to ref the ldap server and in the config
files two methods of referencing.
What is needed is an evaluation of the lib referenced by both configs and
the ref methods in the configs.

On Mon, Apr 7, 2008 at 4:36 PM, Guy Van Sanden <email address hidden> wrote:

> Debian Etch showed the same problem for me..
>
>
> On Mon, 2008-04-07 at 14:39 +0200, Martin Marcher wrote:
> > I'm in the same situation.
> >
> > After all I'd suggest dropping ubuntu in environments with these
> > requirements. Personally I'll go back to Debian. I'll miss the X config
> > stuff that works most of the time for me, but on the other end once I
> > updated my template to deploy with etch or testing again on the boxes
> > I'll be done with. And I can be pretty sure that bugs like these are
> > fixed within a considerable amount of time by debian.
> >
> --
> _______________________________________________
> Guy Van Sanden || http://nocturn.vsbnet.be
>
> PGP KeyID: 28F16C35
> Registered Linux user #249404 - September 1997
>
> --
> udevd: nss_ldap: failed to bind to LDAP server
> https://bugs.launchpad.net/bugs/51315
> You received this bug notification because you are a member of Ubuntu
> Directory Services, which is subscribed to libnss-ldap in ubuntu.
>

https://bugs.edge.launchpad.net/ubuntu/+source/libnss-ldap/+bug/155947 seems to be related I
just noticed an update to libnss-ldap. From the changelog in /usr/share/doc/libnss-ldap/changelog.Debian.gz

libnss-ldap (258-1ubuntu3) hardy; urgency=low

  * add nssldap-update-ignoreusers that updates nss_initgroups_ignoreusers in
    /etc/ldap.conf based on nss_initgroups_minimum_uid. Added initscript to
    call nssldap-update-ignoreusers on shutdown. Based on changes by
    Dustin Kirkland. Fix for LP: #155947
  * References
    https://bugs.edge.launchpad.net/ubuntu/+source/libnss-ldap/+bug/155947

 -- Jamie Strandboge <email address hidden> Tue, 22 Apr 2008 14:07:14 -0400

I copied this comment here from bug https://bugs.launchpad.net/ubuntu/+source/dhcdbd/+bug/93360 , where I'd originally reported by problem. I think my problem is more related to this bug though....

Hi!

I'd like to say I've 'solved' my problem - I'm not sure this bug is the right one for what I was experiencing.
I think my problem was more related to:

https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/51315

although it manifested itself at login or when switching network with nm-applet, rather than at boot-up.

The problem basically seems to be that dbus is trying to get user/group information on a system configured to use a LDAP user database.
When the network is entirely disconnected, dbus/nss-ldap fail quickly, and everything works normally.
When the network is connected, but the LDAP server is unavailable, dbus/nss-ldap perform large numbers of lookups, which all time-out, causing many operations (login, switching network) to take seemingly forever.

I solved the problem by simply removing ldap from nsswitch.conf. This is possible for me, because I am also using nss-updatedb to cache the ldap users/groups in a local database, and pam_ccreds to authenticate against this database when ldap is unavailable.

I do think dbus/nss-ldap should handle a missing ldap server more gracefully. Think of laptop users.

Regards from Vienna,

Richard Unger

Hi

I was facing th e same problem of nss_ldap so read this list and changed he bind policy soft.
But the issue is still not resolved for me.
I am still facin gthe same problem.

user.info: Sep 18 11:24:35 nscd: nss_ldap: reconnecting to LDAP server...
user.err: Sep 18 11:24:35 nscd: nss_ldap: could not connect to any LDAP server as uid=example,dc=com - Can't contact LDAP server

But on restarting the NSCD and SLAPD it starts working, but that too for some time.

Please respond to me.

thanx.

Should be a Confirmed bug, enough users to warrant this.

On my Debian Lenny, adding following groups and user solved the problem:
addgroup --system nvram
addgroup --system fuse
addgroup --system rdma
addgroup --system tss
addgroup --system kvm
adduser --system --no-create-home tss

According to the Debian bug report, this issue was fixed in version 251-6, so should be fixed in all versions since Hardy, therefore I have marked it Fix Released. If this is not the case, and it is still an issue for you, please report back by changing the status back to New, or alternatively open a new bug report with ubuntu-bug (probably better for the bug visibility's sake). Thank you.