FreeBSD, OpenLDAP and the boot process
October 2018
Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
About
This site is an effort to share some of the base knowledge I have gathered through all this years working with Linux, FreeBSD, OpenBSD, Python or Zope, among others. So, take a look around and I hope you will find the contents useful.
Recent Entries
Recent Comments
Recent Trackbacks
Categories
OpenBSD (9 items)
BSD (0 items)
FreeBSD (19 items)
Linux (3 items)
Security (3 items)
Python (22 items)
Zope (13 items)
Daily (144 items)
e-shell (9 items)
Hacks (14 items)
PostgreSQL (3 items)
OSX (8 items)
Nintendo DS (0 items)
enlightenment (0 items)
Apache (3 items)
Nintendo Wii (1 items)
Django (24 items)
Music (12 items)
Plone (7 items)
Varnish (0 items)
Lugo (2 items)
Sendmail (0 items)
europython (7 items)
Cherokee (1 items)
self (1 items)
Nature (1 items)
Hiking (0 items)
uwsgi (0 items)
nginx (0 items)
cycling (10 items)
Networking (1 items)
DNS (0 items)
Archives

Syndicate this site (XML)

RSS/RDF 0.91

12 agosto
2008

FreeBSD, OpenLDAP and the boot process

or how difficult is to debug some problems.

This is something that happens from time to time to me, so I need to write the solution to the problem somewhere as soon as I find it.

Here at the office I've a FreeBSD intranet server, which acts as an authentication server for the local network. User information is stored in a LDAP database (OpenLDAP) and every service that performs any kind of user authentication/identification connects to it to retrieve such information. That means local system accounts, samba accounts, svn and trac accounts and more.

It is not my first time setting up such a server, and I've set up LDAP authentication backends for more kind of servers (mail servers, web servers, etc), but it is the first time I have to deal with this issue.

When booting the server, it took too long to finish the boot process, because each time a daemon (like named, sendmail or mountd) was launched before slapd (the OpenLDAP daemon) it tried to connect to the LDAP database to search for the user associated with the daemon. As slapd wasn't running, it kept trying once and another until some kind of timeout forced the boot process to continue with the rest of the daemons.

And that was unacceptable, can you imagine a server that takes more than 5 minutes to boot?

The first thing in my mind was the FreeBSD boot order, perhaps changing the slapd boot order, so it boots before any other daemon could be a solution...

Could be, but I wasn't sure about the root of the problem, I mean, it was quite strange that something like that didn't create much more noise over the internet. So, I tried Google for a while, and I ended founding an email on the FreeBSD ports mailing list which covers exactly the same problem.

Someone pointed there to a posible solution, modifying the RC scripts to force slapd to be launched before anything else (yupp!, my idea) but, reading carefully, I found here something very interesting:

Additionally you could set "bind_policy soft" in
${LOCALBASE}/etc/nss_ldap.conf to let nss_ldap return in case of
connection problems to slapd instead of waiting forever.

That's it!, I mean, it is supposed that having something like:

#
# nsswitch.conf(5) - name service switch configuration file
# $FreeBSD: src/etc/nsswitch.conf,v 1.1 2006/05/03 15:14:47 ume Exp $
#
group: files ldap
group_compat: nis
hosts: files dns
networks: files
passwd: files ldap
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files

in /etc/nsswitch.conf should prevent ldap queries to keep there opened forever (which in fact seemed to be my problem). User and/or group information should be retrieved first from local files (/etc/group, /etc/passwd, etc), then from the LDAP database. But apparently that's not working at all (i've no idea why)

Well, a quick look over /usr/local/etc/nss_ldap.conf and I realized that I had two options that could be the reason behind the boot delay:

bind_timelimit 120
bind_policy hard

Seems like bind_policy hard force the ldap connections (or tries) retrying once and another until reached bind_timelimit (which in my case had a value of 2 minutes). That means that every failed connection to the slapd daemon will took 2 minutes to realize the connection couldn't be done... awful.

After changed those options to:

bind_timelimit 10
bind_policy soft

everything went back to normal, and the server took only a few seconds to start.

UPDATE: Seems like setting bind_policy to soft wasn't a good idea after all. It solved the boot problem, but it caused some other problems, like users being not associated with their groups in the LDAP database. It seems like FreeBSD knows there are such groups in the ldap database (as running getent group shows all of them, even showing usernames associated with each group), but when running id as a user who is in some groups that are defined in the ldap database, it said the user is only in groups defined in /etc/group. Setting bind_policy to hard again solved the problem, but now I'm back to the boot problem again...

Posted by wu at 12:27 | Comments (0) | Trackbacks (0)
<< I'll be at the djangocon | Main | First Codigo23 sprint >>
Comments
Re: FreeBSD, OpenLDAP and the boot process

Edit the init scripts that hang to be dependent on slapd. Add the comment:
# REQUIRE: slapd

to the top of any init script that requires slapd

Posted by: rhavenn at diciembre 02,2008 04:35
Re: FreeBSD, OpenLDAP and the boot process

Thnx for the comment rhavenn. I've solved that problem and I described how I did it here:

http://blog.e-shell.org/118

But anyway, seems there are still some issues with the fact that the system is trying to find the slapd user when launching slapd itself for the first time, which ends in some waiting time.

Posted by: Wu at diciembre 02,2008 23:11
Re: FreeBSD, OpenLDAP and the boot process

It is normal that local users lookup also hang when slapd is down. Even local users are checked against ldap server for looking up their group membership.

Anyway even setting low timeout and bind_timeout as well as a soft binding policy do not help my system to boot fast.

I perfectly understand that at one point it must hang when it does not find the server but why so long ? I hope this problem will be solved...

Posted by: Kally at abril 14,2009 19:29
Re: FreeBSD, OpenLDAP and the boot process

Yes, this is a real PITA. I didn't have too much time to keep searching for a solution, so if you find one, you are welcome! :D

Posted by: Wu at abril 15,2009 21:31
Trackbacks
Please send trackback to:http://blog.e-shell.org/86/tbping
There are no trackbacks.
Post a comment