upgradeprovision alpha17 to alpha18: dbcheck errors

Andrew Bartlett abartlet at samba.org
Mon Mar 26 16:32:23 MDT 2012


On Tue, 2012-03-27 at 00:27 +0200, Michael Adam wrote:
> Andrew Bartlett wrote:
> > On Wed, 2012-03-21 at 10:22 +0100, Michael Adam wrote:
> > > Andrew Bartlett wrote:
> > > > - upgradeprovision should not be run when upgrading to this release
> > > >   from a recent release.  No important database format changes have
> > > >   been made since alpha16.  
> > > 
> > > But wouldn't it be good to make upgradeprovision idempotent?
> > > It should not harm to run it (again), imho.
> > 
> > It would be great if that were the case, but it simply isn't what
> > upgradeprovision was designed to do.  Internally, for --full, a full new
> > provision is generated, and each new object gains a new unique GUID etc.
> > Some key objects are constrained, and that's why it works, but it is a
> > very different approach to dbcheck, which was written to be idempotent.
> > The default upgradeprovision mode is however more like dbcheck,
> > attempting to primarilly fix known issues around ACLs (as I understand
> > it).  (Mathieu can explain more)
> > 
> > Both tools have their place in Samba, and without upgradeprovision, it
> > would be impossible for the older databases to move to a modern Samba.
> > And if we have the need to again make major changes our provision
> > template again (unlikely as we have used ldapcmp to verify it), then it
> > will be absolutely key to allowing that to happen. 
> > 
> > Does this explain thing better?
> 
> Yes, it does!

Now we just need to figure out the right way to explain this to our
users.  

Matthieu,

With the provision-time markers you made in the DB, is there a way we
can check these to tell if an upgradeprovision is required?  Could we
make dbcheck check these markers, and only then offer an
upgradeprovision (with --full if we detect that is needed)?  

That way, folks would not run this if not required, and we would have
just one 'run this on upgrade' command.

Let me know what you think,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org



More information about the samba-technical mailing list