upgradeprovision alpha17 to alpha18: dbcheck errors

Andrew Bartlett abartlet at samba.org
Wed Mar 21 04:33:30 MDT 2012


On Wed, 2012-03-21 at 10:22 +0100, Michael Adam wrote:
> Andrew Bartlett wrote:
> > On Fri, 2012-03-16 at 10:08 +0000, Thomas Mueller wrote:
> > > hi
> > > 
> > > tried to test the upgrade from alpha 17 to alpah18 on debian wheezy/sid.
> > > 
> > > i've installed alpah18 on my workstation and rsynced the data from the 
> > > "live" system.
> > > 
> > > before the upgrade i've run "samba-tool dbcheck". it shows 10 errors (5x 
> > > orphaned backlink attribute 'memberOf', 5x incorrect DN string component 
> > > for member in object, http://pastebin.com/10gSSzst )
> > > 
> > > i proceed without "samba-tool dbcheck --fix".
> > > 
> > > I run "/usr/share/samba/setup/upgradeprovision --full" which completes 
> > > succesfully but one error is printed: "Unable to set ACLs on policies 
> > > related objects: an integer is required" (http://pastebin.com/Dha2s7C5)
> > > 
> > > then i run again the "samba-tool dbcheck". Now it shows 74 errors (many 
> > > "incorrect GUID component for * in object", http://pastebin.com/s4v34Mng)
> > > 
> > > are these messages something to worry about? 
> > 
> > I don't think you should have needed to run upgradeprovision, as we
> > didn't change the template DB during that time. 
> > 
> > KNOWN ISSUES
> > ============
> > 
> > - 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?

Thanks,

Andrew Bartlett 

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




More information about the samba-technical mailing list