upgradeprovision alpha17 to alpha18: dbcheck errors

[Jelmer Vernooij]

Am 27/03/12 00:32, schrieb Andrew Bartlett:
> 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,
>
This would also make things a lot easier for distributions, which could
then simply run upgradeprovision after upgrades and be sure that it only
does something (and the right thing) when necessary.

Cheers,

Jelmer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120327/c171cc07/attachment.pgp>