Hi,
On Fri, May 15, 2009 at 12:52, Manuel Monteiro
<Manuel.Monteiro@xxxxxxxxxxx> wrote:
>> # Reconnect policy: hard (default) will retry connecting to
>> # the software with exponential backoff, soft will fail
>> # immediately.
>> #bind_policy hard
>
> As far as I remember we are using soft because system would take to long
> to boot trying to connect to LDAP, but I'll try this over the weekend
> with less users around!
You can add some local users that will not belong to LDAP groups to
the ignore list, that will probably fix most of your problems during
bootup before the network is up:
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
In the past I have had problems with OpenLDAP not being able to get
new connections because of the open file descriptors limit (of 1024)
being reached, so it was not able to create new sockets. IIRC, the
message on the logs was clear in that sense, saying the limit had been
reached. To increase the number of file descriptors I added this line
to /etc/sysconfig/ldap:
ulimit -n 8192
If you are reaching the file descriptor limit, it may also mean that
you do not have enough threads to work on the requests. You may
increase that number. I have in my /etc/openldap/slapd.conf:
threads 64
When I start it up, it gives me a warning that this is larger than 32
which they think should be enough for anyone, but I guess that number
is pretty outdated considering today's hardware. Anyway, I'd rather
have too many and have a small overhead for the task switching than
having too few and not being able to cope with a burst.
> Meanwhile I'm also getting some authentication problems with IMAP server
> (dovecot)... the only service that I didn't find any failure was with
> SSH, but it's only used occasionally.
Since I introduced the changes above my problems with OpenLDAP stopped
completely. I even implemented LDAP over SSL for all connections
(including user/group lookup) after that and had no noticeable
performance issues due to the overhead.
HTH,
Filipe
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
