On Wed, Feb 16, 2011 at 8:51 AM, Howard Chu <[email protected]> wrote: > Andrew Findlay wrote: > >> On Tue, Feb 15, 2011 at 05:08:43PM -0200, Leonardo Carneiro wrote: >> >> fileserver:/etc/ldap# /usr/sbin/slapd -h ldapi:/// ldap:/// -g openldap >>> -u >>> openldap -F /etc/ldap/slapd.d -d 128 >>> >> >> Aha! Your server is using LDAP-based config so it is ignoring the config >> file entirely. >> >> Does these changes that we are making into slapd.conf really being >>> processed? Normally, i see just the "-F /etc/ldap/slapd.d" flag and never >>> the "-f /etc/ldap/slapd.conf". >>> >> >> I suspect the config file was converted to a config dir during the >> Debian upgrade process, so the file is now being ignored. >> >> I also suspect that there may not be a valid password set on the >> cn=config suffix, so you will not be able to manage the server through >> LDAP either. >> > > Since it's starting on ldapi:/// he should just do a SASL EXTERNAL bind on > ldapi:// using Unix root. Pretty sure Debian packages it with the > appropriate authz-regexp already configured. > > Tks for the tips guys. I'll try all this stuff at launch time here in Brazil (about 2 hours from now). There are to many users using Samba right now, and every time I have to restart the OpenLDAP something on samba crashes.
As far as i'm concerned, i didn't have the need to use SASL, and it seems that all this SASL mechanism was auto-introduced in my setup after the upgrade. Is it safe to edit /etc/defaults/slapd and remove the "ldapi:///" parameter in SLAPD_SERVICES line or i can break something very hard doing this?
