abartlet at samba.org
Thu Aug 6 16:26:25 MDT 2009
On Thu, 2009-08-06 at 14:19 +0200, Michael Ströder wrote:
> Oliver Liebel wrote:
> > Andrew Bartlett schrieb:
> >> I've been thinking about it, and the
> >> main thing I dislike is the way you try to detect another slapd process
> >> using ps and grep. Instead, how about trying a rootDSE search against
> >> the ldapi socket?
> > what about a simple bind via python-ldap to the socket?
> This would introduce another dependency on the python-ldap module. I guess
> Andrew would prefer if you do that with Samba4 modules.
> >> If it succeeds, then have the script fail with 'an
> >> ldap server appears to already be listening on .../ldapi, please shut it
> >> down before you continue'.
> Maybe I missed something in the thread but I wonder what's the issue here. If
> you explicitly invoke slapd with -h "ldapi://<Samba4path> [..]" the likelihood
> that another server not related to Samba is running there is almost zero.
Except that I've found that many new administrators of Samba are just a
little too smart for their own good. I should know, I've been a
sysadmin too :-). Silly assumptions about who's task it is to start the
ldap server are best avoided if we can check.
In particular, until the work to integrate the two provision scripts is
done, then this script will leave a slapd behind, listening on the
socket. This needs to be detected, so we don't start a second, if an
admin runs provision-backend twice.
Even after integration, we need to detect the slapd that the
administrator has to start for the final operation of Samba4.
> Just food for thought: If you'd like to check whether you're really accessing
> the right OpenLDAP backend you could query a generated provision ID in the
> rootDSE by slapd.conf directive 'rootDSE' which points to an arbitrary LDIF
> file which you could generate.
While I agree with Oliver's suggestion that it might be overkill, I have
to say I'm tempted by this. I get too many mails with odd failures in
setting up the OpenLDAP backend.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the samba-technical