http://gitweb.samba.org/?p=tridge/samba.git; a=shortlog; h=refs/heads/drs-linked-attribs

[Stefan (metze) Metzmacher]

tridge at samba.org schrieb:
> Hi Metze,
> 
>  > would it be possible to wait with pushing your drs-linked-attribs branch
>  > to master until I've reviewed it?
> 
> When are you thinking of reviewing it? Right now the core code that
> allows us to store the additional meta data for linked attributes is
> in there, and it would be great if you could look at that. You can
> see that work by using the --reveal option to ldbsearch after
> adding/removing linked attributes with ldbmodify.

Can you paste an example output here?

> It isn't hooked into ldb_add yet though, so new objects don't get the
> extended DN components. It also isn't hooked into the DRS replicated
> objects code, so we don't store the meta-data we get from a windows DC
> when we replicate. It also isn't hooked into the getncchanges code, so
> we don't serve up these extra pieces yet when another DC replicates to
> us.
> 
> Andrew and I will be working on all these missing pieces over the next
> few days. If you could review the basic approach now, that would be
> great, just be aware that is it a long way from finished.

I just want to make sure we store the correct data in a useable format....

>
> Cheers, Tridge

+/*
+  build a new extended DN, including all meta data fields
+
+  DELETED        = 1 or missing
+  RMD_ADDTIME    = originating_add_time
+  RMD_INVOCID    = originating_invocation_id
+  RMD_CHANGETIME = originating_change_time
+  RMD_USN        = originating_usn
+  RMD_VERSION    = version
+ */

We're missing the local_usn here.
We should rename RMD_USN to RMD_ORIGINATING_USN
and add a RMD_LOCAL_USN.

What does DELETED mean here?
Do you want to map it to DRSUAPI_DS_LINKED_ATTRIBUTE_FLAG_ACTIVE?
I think we should better store the complete
drsuapi_DsLinkedAttributeFlags value as RMD_FLAGS.

I think we should also store is the target is deleted or not.
This is needed to preserve the links for the new recycle-bin feature
of w2k8r2. I think RMD_LINK_FLAGS or something similar would be a good
name. This RMD_LINK_FLAGS would also be stored with the backlinks.
Then we could also store a pseudo backlink for non-linked attributes
of syntax DN* (with a special flag set). This gives us a chance to
update the DN reference when the target is renamed (I think we currently
 don't handle that), e.g. when the target stored in a wellKnownGUID moves.

You also need some special care (and researche) on how we need to handle
autoupgrades from w2k style linked attributes to the w2k3 style ones.
for adding new links it easy we just create the new link with the
special meta data. But for updates of existing links without special
meta data, we need (I assume) to update the version of the per object
meta data for the given attribute and create the link with it's own meta
data.

Also note that the add/delete/modify of a link with meta data doesn't
change the usnChanged whenChanged fields of the object. And the
local usn is then stored per link. We also need to research
if each link and the object get a different local usn,
when 2 linked attributes and 1 non linked attribute is changed
with the same ldap operation.

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/20091217/1a342de4/attachment.pgp>