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

[tridge at samba.org]

Hi Metze,

 > Can you paste an example output here?

sure, here is one inactive and one active link.

member: <DELETED=1>;<GUID=5cbc4b37-3039-47c5-8aca-3bd02e45ea52>;<RMD_ADDTIME=1
 29055204490000000>;<RMD_CHANGETIME=129055204920000000>;<RMD_INVOCID=2702501f-
 efa3-4e94-8fcc-433eba84686f>;<RMD_USN=3322>;<RMD_VERSION=13>;<SID=S-1-5-21-17
 33446877-4185599002-1065162094-1003>;CN=tridge,CN=Users,DC=bludom,DC=tridgell
 ,DC=net
member: <GUID=d396bd3b-d45a-4135-905a-787145199b1f>;<RMD_ADDTIME=1290552044900
 00000>;<RMD_CHANGETIME=129055204920000000>;<RMD_INVOCID=2702501f-efa3-4e94-8f
 cc-433eba84686f>;<RMD_USN=3322>;<RMD_VERSION=4>;<SID=S-1-5-21-1733446877-4185
 599002-1065162094-500>;CN=Administrator,CN=Users,DC=bludom,DC=tridgell,DC=net

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

yep, thanks.

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

ok, makes sense. We missed that as it isn't sent on the wire as part
of the linked attribute replication, but of course its needed to work
out which linked attributes need to be sent in the DRS getncchanges
server code.

 > 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.

hmm, the docs list it as just one bit (BOOL fIsPresent, see section
5.156 of MS-DRSR). Are you concerned that future revisions might add
more bits?

We can certainly change it to an integer fairly easily, although we'll
have to either change dsdb_dn_is_deleted_val() to use a bit slower way
to see if an entry is deleted, or we could keep the DELETED=1 as a
flag, and store a separate RMD_FLAGS value.

Being able to quickly tell that a link is deleted without parsing the
whole DN is nice, so I'm tempted to leave DELETED=1 in, and put any
additional flags that we need in the future into a RMD_FLAGS field if
we need it. We can add additional fields later without breaking
things.

 > 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.

We looked at that, but even with w2k8-r2 we didn't manage to get
windows to keep its deactived links on deletion. Once we did a
delete, the links were gone even with a SHOW_DEACTIVATED_LINK
control. Is there something else we need to do to enable this on
windows?

ahh, darn. I hadn't realised you have to separately enable the recycle
bin feature. I've now enabled it on my test box and the links to
deleted objects are now showing up with --show-deactivated-link in
ldbsearch, and also showing up in msDS-ReplValueMetaData.

Andrew and I will work on updating the linked attributes code to cope
with this (I don't think it will be a big change).

 > 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.

ok, that makes sense, and I just tested renaming the 'CN=Program Data'
container and the wellKnownObject did auto-update on w2k8-r2. 

What attribute name are you thinking of for this pseudo backlink?
Obviously we'll have to hide it on the wire. Just take for forward
link name and add BL, so for example wellKnownObjectsBL ? Or maybe use
a @ prefixed attribute name to indicate its special, so something like
@wellKnownObjectsBL ? The @ would make it easier to quickly strip them
on the way out.

 > 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.

yes, that's what we do now. It does need more testing though.

 > Also note that the add/delete/modify of a link with meta data doesn't
 > change the usnChanged whenChanged fields of the object.

It does change them in the testing I've done against w2k8-r2. Why do
you think they don't change?

Or maybe you mean a change made via DRS? Changes made via LDAP
certainly do change the usnChanged and whenChanged attributes. I
haven't looked into whether changes made via DRS change these, but it
could make sense for them not to.

 > And the local usn is then stored per link.

yes, we need that to work out what links need to be sent during a
getncchanges call, but I think we need to use the objects overall
uSNChanged attribute to work out which objects to look at for possible
changes. So the uSNChanged attribute of the object would be the
maximum of the local_usn of all the entries in the
replPropertyMetaData array, plus all of the RMD_LOCAL_USN values in
all the forward links.

 > 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.

I just tested this by looking at msDS-ReplValueMetaData, and w2k8-r2
updates the two local_usn fields separately. So a change to member and
description done at the same time ends up with local_usn for
description in replPropertyMetaData changed to a different value than
the value in the DS_REPL_VALUE_META_DATA for member. Windows updates
the linked attribute first, then the normal attribute second,
regardless of the order of the modify request. I doubt that ordering
matters though.

Cheers, Tridge