extended provision-backend

[Andrew Bartlett]

On Fri, 2009-08-07 at 10:20 +0200, Oliver Liebel wrote:
> Andrew Bartlett schrieb:
> > On Fri, 2009-08-07 at 10:16 +1000, Andrew Bartlett wrote:
> >   
> >> On Fri, 2009-08-07 at 01:48 +0200, Oliver Liebel wrote:
> >>     
> >>>>
> >>>> Good, but don't go around killing processes until you have confirmed
> >>>> that it's actually listening on the port.  (The pid file could be left
> >>>> around, and another process could have that pid)
> >>>>   
> >>>> I would really prefer not to do the kill at all - perhaps just print out
> >>>> what PID we think is still listening there.  That is: do the ldap search
> >>>> test first.
> >>>>   
> >>>>         
> >>> that should be fixed quick.
> >>> first ldapsearch, then check if slapd-"provision"-pid == slapd.pid, then 
> >>> kill. ok.
> >>>       
> >> I'm not sure how you intend to check the PID, but as I said, I would
> >> prefer not to kill in the script, just print the PID. 
> >>     
> >
> > I've now read the patch more carefully.  This seems like a great
> > approach!
> >   
> thanks. please tell me how you want to handle it:
> just check the pid an print out, so the admin has to kill it self?
> (e.g. "provision finished. slapd-provison-process with pid 12345 must
> be terminated now. you should verify, that this is the correct pid
> before you kill it.")
> this would leave the responsibility to the admin.

I was unclear and confused:  This is what I want:

When we start a provision-backend, we look to see if a slapd is already
listening on the ldapi socket, before we start a new slapd to listen
there.  In this case we print the presumed PID of the old slapd that is
in our way and abort.

When we finish the provision, we shut down the slapd that we know we
started.  It's PID is recorded between provision-backend and provision,
and verified with the slapd.pid.  We also only do this if there is a
working slapd on the socket. 

> >>>> Also, if you could try and use the Ldb module, 
> >>>>         
> >>> thats matter of time. next weeks i have very limited time.
> >>> what about that: ill fix the "kill"-order, and we put the improvements
> >>> (with python-ldap) into the next alpha, so that we can get more 
> >>> testing-feedback.
> >>> functionality should be ok, i have verified it several times with all 
> >>> setup-types.
> >>>
> >>> we could handle the change from python-ldap to ldb transparently to the 
> >>> users
> >>> in the next evolution step, when both scripts are merged.
> >>>       
> >> I'll handle both the Ldb change and integration if you don't have time. 
> >>     
> i would like to handle the ldb change, if its okay for you.
> please just give a short hint where i can find some stuff about the
> ldb-related ldapsearch syntax / procedure ( ../source4/libs/ldb.. ?)
>  or a quick syntax example. ill do the rest.

Sure!

provision.py has plenty of examples:  To open the DB, see
    ldapi_url = "ldapi://%s" % urllib.quote(paths.s4_ldapi_path,
safe="")
 
ldapi_db = Ldb(ldapi_url)

ldapi_db.search(base="", scope=SCOPE_BASE)

Almost all the things on a 'samdb' in that script are actually ldb
operations, wrapped by a slightly more helpful python class. 

If they succeed (I suspect you don't even need the search) then there is
something on that socket, and we need to kill it (or abort, as
required).

> next point is the complete merge.
> if we want to get all stuff into next alpha right on time,
> i think it would be the best if you handle the merge,
> because my time will be very limited the next weeks/months.
> 
> thats also the point why i cant get deep enough into git.
> hope thats no problem.

No worries!

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20090807/8fedc94e/attachment.pgp>