Releases, locking and ldb

Andrew Bartlett abartlet at samba.org
Mon Jun 26 20:07:00 UTC 2017


On Mon, 2017-06-26 at 18:11 +0200, Stefan Metzmacher wrote:
> Am 24.06.2017 um 09:02 schrieb Andrew Bartlett via samba-technical:
> > On Sat, 2017-06-24 at 08:32 +1200, Andrew Bartlett via samba-technical
> > wrote:
> > > On Fri, 2017-06-23 at 13:25 +0200, Stefan Metzmacher wrote:
> > > > 
> > > > > For the 1.1.30 ldb version, the even context changes require this in
> > > > > Samba (less important, only hits -M single):
> > > > > 
> > > > > commit 7259661467776a76c4fa3aabaf1ae8a3d531e506
> > > > > Author: Andrew Bartlett <abartlet at samba.org>
> > > > > Date:   Fri May 12 01:55:45 2017 +0200
> > > > > 
> > > > >     dsdb: Use ldb_handle_use_global_event_context for rootdse modifies
> > > > >     
> > > > >     The modify operations on the rootDSE turn into IRPC messages, and
> > > > > these need
> > > > >     to be handled on the global event context, not the per-operation
> > > > > context
> > > > 
> > > > Would it help to introduce an
> > > > ldb_set_allow_private_event_context() that's called by a new Samba
> > > > release. And other callers get the old behavior?
> > > > 
> > > > It would still leave us with unusable 1.1.30 and 1.1.31,
> > > > but 1.2.0 would be usable again.
> > > 
> > > No, I don't think that is wise.  That just invites other operations
> > > (possibly writes) to happen during a read lock, and that invites
> > > LDB_ERR_BUSY (unable to upgrade hash locks). 
> > 
> > I'm not really worried about this use case, in that the only thing that
> > happens is that rootDSE modifies against -M single (not the default,
> > and not really that workable) DCs would fail. 
> > 
> > However the change in behaviour is only needed with the locking
> > patches, so we could:
> >  - fork a new ldb 1.1 branch in the repo
> >  - release ldb 1.1.32 with this change reverted
> > 
> > This would give us a basis to make backported fixes to ldb that may be
> > required by Samba 4.6 and earlier, which can't take ldb 1.2.0.
> > 
> > The locking change is like an ABI break, but only really impacts Samba
> > the the full extent because of the way we use the partitions module. 
> > 
> > I'm not sure we want to enforce a full ABI break for this (ldb-2.0.0),
> > as it would just make backporting this even more difficult. 
> > 
> > Let's continue to work on this.  
> > 
> > So we don't find ourselves under artificial deadlines here, can we
> > agree not to fork 4.7 without this resolved?  
> 
> At least we can't release 4.7.0 without this.

I'm still blocked from putting the multi-process LDAP server in to
master by this patch (because now we know it would be quite unsafe
without it). 

> I don't like having an ldb 1.1 branch.
> I'm still thinking about possible solutions.
> Maybe reverting things in master for a ldb-1.1.32
> and then reapplying for a 1.2.0.

OK.

> Would sssd break with these changes?
> 
> Do we have other known external users, beside openchange?

I'm not sure.  I'll check with apt reverse depends when I get to the
office. 

The biggest impacts are on those using the modules API (not fixed) and
nested event loops (deprecated).  Simple use of ldb should just keep
working like it always did.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba




More information about the samba-technical mailing list