[PATCH] s4-drs: Store uSNUrgent for Urgent Replication

Fernando J V da Silva fernandojvsilva at yahoo.com.br
Thu Jan 7 12:07:43 MST 2010

Hi Tridge!

I modified this patch (following your recommendations in our last
meeting), now rebased with the drs linked attrs code. It's in my
repository and attached here.

I still have to check on w2k8 if we should enable urgent replication
when an object is created, but following MS-ADTS documentation it
should indicate replication if this class of object is updated. I also
have to check if we should enable urgent replication if an attribute
that needs urgent replication is mentioned when creating some object
(MS-ADTS also only says about updates on attributes...).

Some points about it that should be commented:
* At this point, we're not checking urgent attributes when creating
objects (it would cause things like urgent replication when creating
users, because of auto generated userAccountControl attribute... so
I'm intended to change it if I confirm it is really necessary ...);
* We are enabling urgent replication when creating an object that
should indicate urgent replication on updating;

Best Regards,

Fernando J V da Silva
M Sc Computer Science Student
Institute of Computing, State University of Campinas
+55 15 8801-2165

2009/12/21 Fernando J V da Silva <fernandojvsilva at yahoo.com.br>:
> Hi Tridge!
> Thanks for the comments!
>> When you look at updating your patch based on the comments below, I
>> think you should also have a look at my drs-linked-attribs branch, as
>> that contains some changes that overlap with your changes. I think it
>> would be best if you rebase your changes on the drs-linked-attribs
>> branch (see my email to Eduardo for how to checkout that branch, in
>> case you are not familiar with tracking multiple branches in git).
> Ok! Should I send a .patch file for this branch as well or something like this?
>> In the replmd_check_urgent(), I don't see why you are doing an
>> ldb_search(). It looks like what you are doing is saying that a change
>> is urgent if the object contains any urgent attributes, whereas I
>> think the correct behaviour is that a change is urgent if any urgent
>> attributes are changed by the operation. So for example, if you change
>> just the 'description' field of user, then the change is not urgent,
>> even though the user object does contain 'urgent' attributes.
> I've created two new functions which replace that one, but I'm still doing an
> ldb_search() at replmd_check_urgent_attribute(). My goal was to use the result
> and check if the attribute value was indeed modified by the message. If the
> value is equal to the old one, then it doesn't set urgent replication.
> Would it be right?
>> I also think that replmd_check_urgent() is hooking into the wrong
>> place in the code. Right now you hook into replmd_add() and
>> replmd_modify(), but I think you would be better off hooking into
>> replmd_update_rpmd_element() and into the existing loop over the
>> element array in replmd_add() (the latter could also be removed, if it
>> was changed to call replmd_update_rpmd_element()).
> Ok! Now I'm calling replmd_check_urgent_attribute() inside
> replmd_update_rpmd_element() and
> replmd_check_urgent_object() only once outside it. In replmd_add() I'm
> only checking the object
> using replmd_check_urgent_object(). The reason is because [MS-ADTS]
> documentation says about
> urgent replication when attributes are updated. I imagined that if you
> create an user (for example),
> mentioning its userAccountControl for some reason, then it would
> enable urgent replication if I did so.
> (or, perhaps, would it be a correct behavior?).
> --
> Fernando J V da Silva
> M Sc Computer Science Student
> Institute of Computing, State University of Campinas
> +55 15 8801-2165
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s4-drs-Store-uSNUrgent-for-Urgent-Replication.patch
Type: text/x-patch
Size: 12127 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100107/471538ba/attachment.bin>

More information about the samba-technical mailing list