[Samba] Replication Failure Issue

[David Minard]

On 24/03/18 01:35, lingpanda101 wrote:
> On 3/22/2018 8:06 PM, David Minard wrote:
>> G'day All,
>>
>>     Will replay to all messages so far in this one to keep it all 
>> together.
>>
>> On 21/03/18 22:52, lingpanda101 wrote:
>>> On 3/21/2018 7:32 AM, David Minard via samba wrote:
>>>> Thanks Carlos,
>>>>
>>>> The thing is, that I did not upgrade the version of Samba - that is 
>>>> the next step, so the ports used would not have changed. I only 
>>>> updated the OS.
>>>>
>>>>
>>>>> On 21/03/2018, at 10:04 PM, Carlos Alberto Panozzo Cunha 
>>>>> <carlos.hollow at gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>> I have same problem after update for samba.
>>>>> I allow new ports in firewall.
>>>>>
>>>>> https://wiki.samba.org/index.php/Samba_AD_DC_Port_Usage
>>>>>
>>>>> Regards
>>>>>
>>>>>
>>>>> On Wed, Mar 21, 2018, 00:15 David Minard via samba 
>>>>> <samba at lists.samba.org> wrote:
>>>>> G'day All,
>>>>>
>>>>>          I have 4 DCs on Centos 7.1. Everything was working really 
>>>>> well for
>>>>> years, including replication.
>>>>>
>>>>>          Then I decided that the OS needed updating. Did the yum 
>>>>> update on one
>>>>> of the DCs, rebooted. That server is now running Centos 7.4. Samba
>>>>> seemed to start okay.
>>>>>
>>>>>          However, samba-tool drs showrepl gives this error on all 3 
>>>>> of the other
>>>>> DCs, and shows success on the updated DC.
>>>>>
>>>>> DC=DomainDnsZones,DC=samba4,DC=scem,DC=westernsydney,DC=edu,DC=au
>>>>>          Default-First-Site-Name\SAMBA4-10 via RPC
>>>>>                  DSA object GUID: 7fa7fc88-8d99-4217-b329-7e82324ec084
>>>>>
>>>>>                  Last attempt @ Wed Mar 21 12:58:13 2018 AEDT 
>>>>> failed, result 58
>>>>> (WERR_BAD_NET_RESP)
>>>>>
>>>>>                  10623 consecutive failure(s).
>>>>>                  Last success @ Thu Mar  8 14:34:14 2018 AEDT
>>>>>
>>>>>
>>>>>          Any thoughts on why this DC is now not replicating 
>>>>> properly? Any
>>>>> thoughts on how to remedy this?
>>>>>
>>>>>
>>
>>>>
>>> You most likely will need to turn up the samba log level to get 
>>> additional information but you can start with running 'yum history 
>>> list all' and post results. This might help identify the changes that 
>>> were made to the OS. Are you using bind or the internal DNS?
>>>
>>>
>>
>> I will turn up the logs and test it out.
>>
>> I use Bind-9.9.4-51 (before update 9.9.4-18)
>>
>> yum history shows 348 packages that got updated... Bind being one. 
>> Will sift through them.
>>
>> My firewall is very lose. All ports are open for the subnets on which 
>> the samba servers need to talk. eg:
>>
>> -A INPUT -s 172.20.0.0/16 -p tcp -m state --state NEW -m tcp -j ACCEPT
>> -A INPUT -s 172.20.0.0/16 -p udp -m state --state NEW -m udp -j ACCEPT
>>
>> When I first set this up with 4.0.0-a2 (or whatever it was right at 
>> the beginning), I was not able to work out what ports exactly were 
>> needed, hence the lose rules. Now I see they are documented clearly on 
>> the Samba site, I will tighten them up, but not until the issue is 
>> resolved.
>>
>> My samba is complied from source. I am currently running 4.3.2. It's 
>> been running flawlessly so no urgency to update, until the huge 
>> security hole was announced the other week. Now I've got to get it 
>> done, but want the ailing server going right first - or should I just 
>> do the updates and then worry about the ailing server?
>>
>> Smb.conf:
>>
>> # Global parameters
>> [global]
>>     workgroup = SCEM_AD
>>     realm = samba4.scem.westernsydney.edu.au
>>     netbios name = SAMBA4-10
>>     server role = active directory domain controller
>>     server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, 
>> winbindd, ntp_signd, kcc, dnsupdate
>>
>> #        log level = 1 auth:2
>> # logs split per machine
>>         log file = /var/log/samba/log.%m
>>         # max 50KB per log file, then rotate
>>         max log size = 0
>>
>> [netlogon]
>>     path = 
>> /usr/local/samba/var/locks/sysvol/samba4.scem.westernsydney.edu.au/scripts 
>>
>>     read only = No
>>
>> [sysvol]
>>     path = /usr/local/samba/var/locks/sysvol
>>     read only = No
>>
>>
>> It is the out of the box config from the original provision.
>>
>>
> I myself would hold off updating until you correct the DC's with the 
> issues. Anything in the Samba logs or yum history stand out? You can try 
> and force replication 'samba-tool drs replicate --full-sync' from 
> FirstDC to SecondDC.
> 

Going through the yum history, there were 348 updates. Bind,
     Updated     iproute-3.10.0-21.el7.x86_64 
          @base
     Update              3.10.0-87.el7.x86_64 
          @base
     Updated     iprutils-2.4.3-3.el7.x86_64 
          @base
     Update               2.4.14.1-1.el7.x86_64 
          @base
     Updated     iptables-1.4.21-13.el7.x86_64 
          @anaconda
     Update               1.4.21-18.2.el7_4.x86_64 
          @updates
     Updated     iptables-services-1.4.21-13.el7.x86_64 
          @base
     Update                        1.4.21-18.2.el7_4.x86_64 
          @updates
     Updated     iputils-20121221-6.el7_1.1.x86_64 
          @updates
     Update              20160308-10.el7.x86_64 
          @base


The firmware updates.

I can list them all, but it's rather long (348 updates).
Never needed to, but can I undo certain yum updates?

Nothing seems to stand out in the samba logs either. Will investigate 
with higher debug levels between working and less working server.

I will try the forced replication with debug flag.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.