[PATCH] Attempt to replicate DNS zones at domain join time (drepl server crash)

[Amitay Isaacs]

On Fri, Jun 22, 2012 at 6:08 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> On Fri, 2012-06-22 at 17:17 +1000, Amitay Isaacs wrote:
>> Hi Andrew,
>>
>> On Fri, Jun 22, 2012 at 9:48 AM, Andrew Bartlett <abartlet at samba.org> wrote:
>> > On Thu, 2012-06-21 at 23:49 +1000, Andrew Bartlett wrote:
>> >> This patch tries to reduce the pain around replicating DNS.  We now do
>> >> it at join time.
>> >>
>> >> However, at least during make test, it causes a segfault in the DRS
>> >> server, which I can't yet pin down (even with valgrind I don't get a
>> >> useful answer).
>> >
>> > I've found and fixed the segfault issue, so now I want testing of the
>> > join.py modifications.
>> >
>> > https://git.samba.org/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/fix-dns-replication
>> >
>> > If those who are having pain getting DNS replication up and going can
>> > try with these 2 patches, I hope this may solve some of the issues.
>>
>> If the DNS role is not assigned to a (windows) DC, it never replicates
>> the DNS partition and also does not have DNS NCs listed in
>> msDS-hasMasterNCs. So, it appears that adding DNS NCs in
>> msDS-hasMasterNCs attribute is equivalent to adding DNS role to the
>> second DC.
>>
>> May be that'll fix the replication issue. I was under the assumption
>> that msDS-hasMasterNCs attribute is set only after the replication is
>> complete. But that's not true. It has to be set if the DC is going to
>> hold a full replica of the NC.
>
> OK.  So, aside from fixing it to use the right attribute, we might be on
> the way to a solution then.
>
>> > You still need to run samba_upgradedns after the join, but I'll include
>> > that when I get a chance.  This should at least mean that the partitions
>> > are correctly replicated, which has been the biggest pain point.
>>
>> Since you have added dns_backend option to join, we can potentially
>> short-circuit running samba_upgradedns and run parts of dns provision
>> directly.
>
> That's essentially what I want to have happen.
>
> The one query I have is:  What happens if the DC we choose to replicate
> the rest of the data from doesn't hold the DNS partitions?

As I understand, it should be the job of KCC to figure out which
partitions should be replicated. The current implementation of KCC
sets up replication between each DC for all partitions. So if a second
DC does not have application partitions, first DC should not try to
replicate those partitions to second DC. May be we need to switch to
python KCC and make sure it does the correct thing.

Amitay