[patches] make upgradeprovision use replPropertyMetaData and others cools things

[Stefan (metze) Metzmacher]

Hi Matthieu,

> Please find attached 5 patches for provision and upgradeprovision
> 
> 0001-s4-provision-Add-information-about-provisioned-usn-r.patch
> 0002-s4-upgrade-provision-Refactor-code-to-do-all-the-mod.patch
> 0003-s4-Add-functions-related-to-ldb-manipulation-when-do.patch
> 0004-s4-upgradeprovision-Inform-about-new-dns-dynamic-upd.patch
> 0005-s4-upgradeprovision-Use-replPropertyMetaData-for-bet.patch
> 
> 
> The first one is to add the @PROVISION object to the base sam.ldb, this
> object for the moment store the lastProvisionUSN attribute that indicate
> which usn range has been touched by the provision. This information will
> be used later on by the upgradeprovision to know which range can be
> safely modified and which can't ...
> 
> The second one is a refactoring of the code of upgradeprovision to allow
> to use 1 transaction so that it's easier to track usn modification
> during upgradeprovision and also if upgradeprovision fails it leaves the
> database as it was before.
> 
> The third patch is to add functions needed by upgradeprovision

Why are the registry functions commented out?

> The forth one is to inform about the new dns changes and the fact that
> maybe the sysadmin should do something.
> 
> The last one is the introduction of replPropertyMetaData to drive the
> upgrade, the idea here is to modify only the current host is the owner
> of the attribute (originate_invocationid) and if the attribute was
> modified during a provision or a previous upgradeprovision. This
> information will only be available on new provision but there is a
> script that I have (and that I can share but in the same time I didn't
> wan't to spend ages on the cleaning) that creates an ldif file ready to
> be integrated in the current provision to populate the range (it use an
> educated guess to do so).

Why do we have special cases for "member"?

Do we have some documentation that describes the logical steps
do do on the upgrade? At least for me it's hard to find out how this is
supposed to work.

I'm not sure it's correct to only "fix" local generated values.
It might be better to generate a new invocationId for the database
(as the restore on from backup on windows does) and important the old
stuff as replicated updates.

metze

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