[Samba] samba Digest, Vol 132, Issue 25

[Tushar Dalvi]

I think the 6month period comes from the "tombstoneLifetime" attribute
present under this DN. The default is 180 days.
dn: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, BASEDN

Can this value be reduced and wait for samba to purge the old deleted
objects?
Modifying this value has other implications as per AD docs but I wonder if
it can be changed for a simple directory setup.

-Tushar



>
> ---------- Forwarded message ----------
> From: lp101 <lingpanda101 at gmail.com>
> To: Andrew Bartlett <abartlet at samba.org>
> Cc: samba at lists.samba.org
> Date: Sun, 22 Dec 2013 21:47:48 -0500
> Subject: Re: [Samba] DomainDnsZone Replication Shows 200,000 Objects
>     Appreciate the response. You indicated the items will be retained for
> 6 months. Any possibilty of a parameter being introduced to modify this?
>
> -James
>
> On 12/22/2013 4:56 AM, Andrew Bartlett wrote:
>
>> On Fri, 2013-12-20 at 12:44 -0500, lp101 wrote:
>>
>>>       During the samba domain join process I see over 200,000+ objects
>>> that need to be replicated. This takes several hours to complete if at
>>> all. I don't believe this to be correct. I'm currently running Samba
>>> 4.1.0 on several DC's across a couple sites. Tried to join a new DC
>>> using Samba4.1.0 as well but it failed with an error code similar to the
>>> one found here
>>>
>>> https://lists.samba.org/archive/samba/2013-October/176237.html.
>>>
>>>    Reverted back to a 4.0.9 build and it completed the join process
>>> without this error. I would like to join another DC but it takes an
>>> excessive amount of time to replicate the DomainDnsZone partition. I
>>> can't fathom this containing 200,000+ objects. My domain consist of
>>> approximately 125 users and 150 machines. Thanks for any help.
>>>
>> A flawed fix was introduced and reviewed into our internal DNS server a
>> few months ago, purporting to fix issues with clients not being able to
>> update their DNS records.
>>
>> The fix caused the create of a new deleted record for every DNS
>> transaction, even one that should have had no impact on the database
>> (same IP).
>>
>> The only workaround to avoid creating more is to change from the
>> internal DNS server to the BIND9 DLZ module, but this won't fix the
>> issue with having a database that is drowning in deleted records.  We
>> don't have a tool to purge these at this time, and by default they will
>> be kept for 6 months.
>>
>> We do realise we are going to have to come up with a better fix, but
>> sadly nobody has yet proposed a patch to do this properly.  (We should
>> probably at least revert the one that was put in).
>>
>> Sorry,
>>
>> Andrew Bartlett
>>
>>