Ubuntu

Ubuntu 7.10 hangs after "starting kernel log daemon" when using LDAP

Asked by Michael Zacherle

Hi,

I installed Ubuntu 7.10 as an update to 7.04. Unfortunately, when configuring LDAP and then rebooting, the system hangs after "Starting kernel log daemon...". I've tested this now with a clean install just to be sure, and the problem is the same. I use LDAP version 3 and have configured it to use libnss-ldap and libpam_ldap with pam_password=crypt. It used to work with 6.10 an 7.04 without any problems...

Thanks for any help!

Michael
<email address hidden>

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
Anhur
Solved:
Last query:
Last reply:
Revision history for this message
Anhur (linux-bernd-nmedien) said : 		#1

Hi

I have the same problem. One thing I found out is, that it seems, that hte file /etc/ldap.conf is not configured.
I found two entries there which do not seem to be correct.
host pointed to 127.0.0.1 and base was dc=padl,dc=com, thought I entered values when installing libpam-ldap an co.
Setting those values compatible to my environment did not fix the problem. So I think there must be other missconfigured files ...

Revision history for this message
fejes (anthony-fejes) said : 		#2

I'm suffering the same issue - I believe I have my ldap.conf file correctly configured (thought it's a possibility that it's not.)

I have no idea where to go to start diagnosing this yet. I haven't yet figured out what process the kernel log daemon is running at boot.

Revision history for this message
Robert Schöftner (rmu) said : 		#3

I just had the same issue and it turned out that my ldap.conf was not correct. I wrongly used ldapi://some.ip.address, changing to ldap://some.ip.address solved it.

Revision history for this message
Mehdi AMINI (joker-eph) said : 		#4

I had the same problem when upgrading to gutsy. I solved it by changind bind_policy from hard to soft.

Revision history for this message
Michael Zacherle (zacherle) said : 		#5

My ldap.conf referred to ldap://... and not to ldapi://... , and changing the bind_policy didn't change anything here. Hmm. I had to disable LDAP on my computer for the moment and rely on local users only.

Revision history for this message
Best Anhur (linux-bernd-nmedien) said : 		#6

Hi

It works now for me. I edited some entries in /etc/ldap.conf after that anythning is good :-)

Here are all entries I set up in my configs. Hopefully it is of help for you too.
My LDAP Server is running on IP 192.168.1.254, the ldap manager is called "manager" and the domain is dc=ragnarok,dc=local

--------------------/etc/ldap.conf---------------------------
host 192.168.1.254
base dc=ragnarok,dc=local
uri ldap://192.168.1.254/
ldap_version 3
rootbinddn cn=manager, dc=ragnarok,dc=local
bind_policy soft
pam_password md5

------------/etc/ldap/ldap.conf----------------------
HOST 192.168.1.254
BASE dc=ragnarok,dc=local
rootbinddn cn=nssldap,ou=DSA,dc=ragnarok,dc=local
nss_base_passwd dc=ragnarok,dc=local?sub
nss_base_shadow dc=ragnarok,dc=local?sub
nss_base_group ou=Groups,dc=ragnarok,dc=local?one
ssl no
pam_password md5

-----------------------/etc/nsswitch-------------------
passwd: files ldap
group: files ldap
shadow: files ldap

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

----------------------------/etc/pam.d/common-account-----------------
account sufficient pam_ldap.so
account required pam_unix.so

----------------------------/etc/pam.d/common-auth-----------------
auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok_secure
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

----------------------------/etc/pam.d/common-password-----------------
password required pam_cracklib.so retry=2 type=
password sufficient pam_unix.so nullok use_authtok md5 shadow
password sufficient pam_ldap.so use_authtok
password required pam_deny.so

----------------------------/etc/pam.d/common-session-----------------
session required pam_limits.so
session required pam_unix.so
session optional pam_ldap.so
session optional pam_foreground.so

--------------------------/etc/ldap.secret-------------------------------
;-)

With this settings everything works fine on my gutsy systems

Revision history for this message
Michael Zacherle (zacherle) said : 		#7

Hahaha, now it works. Thanks a lot!!!

What I changed in /etc/ldap.conf (I do not have a /etc/ldap/ldap.conf) was:

- added a slash at the end of the uri ldap://...
- changed host from name to IP
- added "rootbinddn cn=manager, dc=..."
- added "pam_passwd crypt"
- added ldap_version 3

I don't know which of these five things did the trick, but now it works. Great! The bind_policy soft didn't change the behaviour at all.

Best,

Michael

Revision history for this message
Michael Zacherle (zacherle) said : 		#8

Thanks Anhur, that solved my question.

Revision history for this message
Mehdi AMINI (joker-eph) said : 		#9

Hello,

I don't know which of these five things did the trick, but now it works.
> Great! The bind_policy soft didn't change the behaviour at all.
>

It would be fine if you can try each of those parameters to identify where
was the problem.

Thanks.

Mehdi

Revision history for this message
Anhur (linux-bernd-nmedien) said : 		#10

Funny thing that in my system the problem was solved after adding
  bind_policy soft

Without this entry the system did not get across "starting kernel log daemon".

Revision history for this message
Tyrel Newton (tyrel-newton) said : 		#11

I was having the same problem and tried the five listed above in addition to setting "bind_policy soft". I'm not sure what ultimately did it, but I'm guessing it was the bind_policy since it lets a bind fail immediately rather than retrying a bunch of times.

As an aside, I noticed somewhere (I think the changelogs for sysklogd) some note about changing the user that the syslog daemons run as. Since this problem wasn't present in feisty, I'm betting they are related problems, though I don't really know how at the moment . . .

Revision history for this message
fejes (anthony-fejes) said : 		#12

Oddly enough, the solution for me was to do an apt-get remove libnss-ldap.

Once that was done, everything works again... very odd.

Revision history for this message
Mehdi AMINI (joker-eph) said : 		#13

If you remove libss-ldap, how do you access to ldap ?

Revision history for this message
Motin (motin) said : 		#14

I don't even use ldap but get this hang... Removing libnss-ldap doesn't help. Any ideas?