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

[Fernando J V da Silva]

Hi!

I've been working on DRS Urgent Replication ToDo item
(http://wiki.samba.org/index.php/Samba4_DRS_TODO_List#Urgent_replication)
and I wrote a small patch which tries to follow the approach described
by Tridge (see below).

> I think to implement this we'll need some modifications to
> repl_meta_data.c. For each modification that happens in that module,
> we'll need to work out if it involves an urgent attribute. If it does
> involve an urgent attribute then we need to get that information up to
> the repl task (see dreplsrv_notify_check() in
> dsdb/repl/drepl_notify.c).
>
> Probably the best way to do that is to extend the @REPLCHANGED
> object in the root of each NC. To see these attributes with ldbsearch,
> do something like this:
>
>  ldbsearch -H $PREFIX/$DN.ldb -s base -b @REPLCHANGED
>
> where $DN is each of the naming contexts.
>
> currently it contains just a uSNHighest attribute, which is the
> highest uSN of a modify to this NC. We could add a new attribute
> uCNUrgent which will be the highest uSN of any urgent changes. Then
> the drepl_notify.c code can work out if it should mark the
> notification as urgent.

In this initial patch, the uSNUrgent is stored when one of the objects
mentioned in http://msdn.microsoft.com/en-us/library/dd240020(PROT.13).aspx
are created/updated/deleted (depending on the objectclass ...).

It seems that it's working correctly in a few tests that I've done
when I was adding or modifying some of those objects/attributes, but
it hangs on a infinite loop when I run make test...

Following are more details about what I'm doing:

- The implementation:
  * The replmd_check_urgent(...) function that I've created on
repl_meta_data.c gets a ldb_message and only checks if it intends to
update/create/delete some urgent object or update some urgent
attribute;
  * replmd_check_urgent(...) is called inside functions like
replmd_add(...) or replmd_modify(...) and if it indicates the need for
urgent replication, then the callback function for the modify request
or add request is replmd_urgent_callback instead of
replmd_op_callback;
  * replmd_urgent_callback(...) is very similar to
replmd_op_callback(...), but it store the partitions that need urgent
replication on replmd_private->ncs_urg instead of replmd_private->ncs
(perhaps there is a better approach to this task? ...);
  * uSNUrgent and uSNHighest are stored for the necessary partitions
on replmd_notify_store(...)

- The bug (infinite loop when run make test):
  * The infinite loop happens during provision, when it tries to
create the following object (with controls relax:0):
      dn: CN=Users,DC=samba,DC=example,DC=com
      objectClass: top
      objectClass: container
  * A few other objects were created correctly before that one and it
seems that none of those objects were among the ones whose need urgent
replication;
  * It hangs on replmd_op_callback(...) at loop:
               for (modified_partition = replmd_private->ncs;
modified_partition;
		     modified_partition = modified_partition->next) {
			if (ldb_dn_compare(modified_partition->dn, partition->dn) == 0) {
				break;
			}
		}
      It hangs there because, for this object, we have
modified_partition == modified_partition->next and it never leaves
that loop.
  * The replmd_check_urgent(...) function returns false for all
objects, but if I didn't call it when I'm adding an object, then this
infinite loop doesn't happen (perhaps I'm doing something wrong inside
that function so I broke the replmd_private->ncs list? I couldn't see
anything yet ...);
  * I also tried to add a very similar object on my current
development environment (where only the basedn was different) using
ldbadd and it worked correctly...

The patch is attached in this message and also available at
git://repo.or.cz/Samba/fernandojvsilva.git

Best regards,

-- 
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: 11534 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091211/a981d72e/attachment.bin>