Am 13.03.19 um 11:22 schrieb L.P.H. van Belle via samba:> > Hi Stefan, > > Debian 8 ? 9? > DC's samba version ?Deb 9.8, Samba-4.8.9> Can you post your smb.conf and resolv.conf > > If you check with (per server what is the outcome. ) > samba-tool dbcheck0 errors> samba-tool dbcheck --cross-ncChecked 3754 objects (3174 errors) on the DC1. where does that come from ... everything was fine last time we checked ... very frustrating - checking around for DNS dc.my.tld is there fine, but "dc" doesn't resolve on DC2. dc.my.tld does resolve resolv.conf on DC2: nameserver 192.168.16.205 nameserver 192.168.16.206 search my.tld (trying around)
Am 13.03.19 um 11:33 schrieb Stefan G. Weichinger via samba:> where does that come from ... everything was fine last time we checked > ... very frustratingI mean, replication worked fine for a month or so already. And afaik there were no changes on the DCs (maybe unattended debian-upgrades). DC1 has: nameserver 192.168.16.111 search my.tld .111 is the router/fw to WAN ... for forwarding DNS, but this should be covered with smb.conf already: dns forwarder = 192.168.16.111 - So I assume it should point to the own IPv4-IP of DC1 itself, which is .205 But I don't understand yet if the mistake is on DC1 and/or DC2 so I wait with further changes. prod machines, you know. Maybe resolv.conf was changed by some automation script here, could be, can't bet right now.
On Wed, 13 Mar 2019 11:43:57 +0100 "Stefan G. Weichinger via samba" <samba at lists.samba.org> wrote:> Am 13.03.19 um 11:33 schrieb Stefan G. Weichinger via samba: > > > where does that come from ... everything was fine last time we > > checked ... very frustrating > > I mean, replication worked fine for a month or so already. And afaik > there were no changes on the DCs (maybe unattended debian-upgrades). > > DC1 has: > > nameserver 192.168.16.111 > search my.tld > > .111 is the router/fw to WANStefan, how many times does this have to be said, A DC must use itself as its nameserver. Change 192.168.16.111 to the DC's ipaddress>... for forwarding DNS, but this should > be covered with smb.conf already: > > dns forwarder = 192.168.16.111The forwarding is done by the Samba DC's DNS server, not via /etc/resolv.conf> > - > > So I assume it should point to the own IPv4-IP of DC1 itself, which > is .205Yes> > But I don't understand yet if the mistake is on DC1 and/or DC2 so I > wait with further changes.If this mistake is on both DC's, then it is on both.> > prod machines, you know. > > Maybe resolv.conf was changed by some automation script here, could > be, can't bet right now.You must stop anything altering resolv.conf e.g. resolvconf Rowland
Hai, Ok, so the reboot changed your resolv.conf check the timestamp of /etc/resolv.confs Write this down.> So I assume it should point to the own IPv4-IP of DC1 itself, > which is .205Yes correct. After that reboot the server. Check the timestamp again and/or did it change? Now the hunt for the resolv.conf change. cat /etc/network/interfaces If you have dns-nameserver these are picked up with systemd-resolved. Or by package: resolvconf Run these: networkctl status systemd-resolve --status Show the output. Other options: Server with dhcp ip? echo 'make_resolv_conf() { :; }' > /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone chmod 755 /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone Or edit /etc/dhcp/dhclient.conf supersede domain-name "example.com"; supersede domain-search "example.com"; supersede domain-name-servers 127.0.0.1; One of above is your fix. ;-) A last resort fix is : rm -f /etc/resolv.conf editor /etc/resolv.conf chattr +i /etc/resolv.conf But i dont like that, its up2you. Greetz, Louis> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Stefan G. Weichinger via samba > Verzonden: woensdag 13 maart 2019 11:44 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] replication fails > > Am 13.03.19 um 11:33 schrieb Stefan G. Weichinger via samba: > > > where does that come from ... everything was fine last time > we checked > > ... very frustrating > > I mean, replication worked fine for a month or so already. And afaik > there were no changes on the DCs (maybe unattended debian-upgrades). > > DC1 has: > > nameserver 192.168.16.111 > search my.tld > > .111 is the router/fw to WAN ... for forwarding DNS, but this > should be > covered with smb.conf already: > > dns forwarder = 192.168.16.111 > > - > > So I assume it should point to the own IPv4-IP of DC1 itself, > which is .205 > > But I don't understand yet if the mistake is on DC1 and/or > DC2 so I wait > with further changes. > > prod machines, you know. > > Maybe resolv.conf was changed by some automation script here, > could be, > can't bet right now. > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > >
Am 13.03.19 um 11:55 schrieb L.P.H. van Belle via samba:> Hai, > > Ok, so the reboot changed your resolv.conf > check the timestamp of /etc/resolv.confs > Write this down. > >> So I assume it should point to the own IPv4-IP of DC1 itself, >> which is .205 > Yes correct. > After that reboot the server. > Check the timestamp again and/or did it change? > > Now the hunt for the resolv.conf change. > > cat /etc/network/interfaces > If you have dns-nameserver these are picked up with systemd-resolved. > Or by package: resolvconf > > Run these: > networkctl status > systemd-resolve --status > > Show the output. > > Other options: > Server with dhcp ip? > echo 'make_resolv_conf() { :; }' > /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone > chmod 755 /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone > > Or edit /etc/dhcp/dhclient.conf > supersede domain-name "example.com"; > supersede domain-search "example.com"; > supersede domain-name-servers 127.0.0.1; > > > One of above is your fix. ;-) > A last resort fix is : > rm -f /etc/resolv.conf > editor /etc/resolv.conf > chattr +i /etc/resolv.conf > > But i dont like that, its up2you.I have a specific idea where that comes from and stopped/disabled systemd-resolved now. No DHCP. manual replicate seems to time out (no error, no success ...) I reboot DC2 now for a test. Should /etc/hosts contain pointers to own FQDN or not? To DCs? thanks