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

Thu Dec 17 23:04:15 MST 2009

tridge at samba.org schrieb:
> 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?

I didn't noticed that. I think we should use RMD_ISPRESENT=1|0 then.

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

maybe @BL-<attrname>

I think we should have something like LINK_FLAGS (only used internally)
and calculate DELETE=1 our of RMD_ISPRESENT and the LINK_FLAGS.
Ans the parsing code for searches can rely on DELETE (maybe VISIBLE
would be a better name) as fast path.

Does it matter (regarding performance) that DETELED=1 is the first
element in?

member: <DELETED=1>;<GUID=5cbc4b37-3039-47c5-8aca-3bd02e45ea52>;
<RMD_ADDTIME=129055204490000000>;
<RMD_CHANGETIME=129055204920000000>;
<RMD_INVOCID=2702501f-efa3-4e94-8fcc-433eba84686f>;
<RMD_USN=3322>;<RMD_VERSION=13>;<SID=S-1-5-21-1733446877-4185599002-1065162094-1003>;
CN=tridge,CN=Users,DC=bludom,DC=tridgell,DC=net

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

because only the linked attributes are changed.

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

We need research:-)

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

you mean two members (if not you should retest with 2 or more)

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

And what's in usnChanged in that case?

Can you paste the output of the ldif the passed to ldbmodify
and the result from ldbsearch?

I think we should try to match as exactly as we can.
And makes (dual server) testing much easier,
as the test only needs to compare instead of doing a lot of complex logic.

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/20091218/3bf498f7/attachment.pgp>