samba - Dec 2022 - accidentally upgraded DC to 4.17.3 ... didn't work

On 30/11/2022 10:58, Stefan G. Weichinger via samba wrote:
>>>
>>
>> Did the new DC's nameserver point to its own ipaddress before you 
>> started Samba ?
> 
> adc1 has the IP 10.0.0.231 on interface "eno1"
> 
> the resolv.conf contains its own IP at first and 10.0.0.230 for
"adc2"
> at second ->
> 
> # resolv.conf
> 
> nameserver 10.0.0.231
> nameserver 10.0.0.230
> search arbeitsgruppe.my.tld
> 
> both DCs have several VLAN-interfaces and IPs as well
> 
> on adc2 I have
> 
> bind interfaces only = yes
> interfaces = lo enp0s31f6
> 
> while on adc1 these lines are currently missing -> smb.conf was created 
> from scratch at the join
> 
> Last week there were numerous DNS-records added: one per VLAN ... maybe 
> that is a problem, I removed them last week to run the DC in plain 
> VLAN1= LAN only.
What are the VLANs for and what do they have to do with the DC ?
> 
> I assume I should add that binding-config to adc1 as well.
> 
>> You could try adding:
>>
>> dns update command = /usr/sbin/samba_dnsupdate --use-samba-tool
>>
>> to the DC's smb.conf and then restart Samba.
> 
> Can do, have to check with the customer first: breaking the DNS as 
> before isn't good while people are working.
> 
The samba_dnsupdate python script is run by a DC at startup and then 
every 10 minutes, it adds any missing AD dns records and there are quite 
a few missing from a newly joined DC. You can see the records that are 
added here:

/var/lib/samba/private/dns_update_list

There can be a problem with the ticket, but, by using samba-tool, this 
can be got around.

Rowland

Am 30.11.22 um 12:37 schrieb Rowland Penny via samba:
>> Last week there were numerous DNS-records added: one per VLAN ... 
>> maybe that is a problem, I removed them last week to run the DC in 
>> plain VLAN1= LAN only.
> 
> What are the VLANs for and what do they have to do with the DC ?
The 2 servers also are isc-kea-dhcp servers for these VLANs, so I had to 
add interfaces for that.

But I bound samba to eno1 now again. VLANs out of the game, I assume.
>> I assume I should add that binding-config to adc1 as well.
>>
>>> You could try adding:
>>>
>>> dns update command = /usr/sbin/samba_dnsupdate --use-samba-tool
>>>
>>> to the DC's smb.conf and then restart Samba.
>>
>> Can do, have to check with the customer first: breaking the DNS as 
>> before isn't good while people are working.
>>
> 
> The samba_dnsupdate python script is run by a DC at startup and then 
> every 10 minutes, it adds any missing AD dns records and there are quite 
> a few missing from a newly joined DC. You can see the records that are 
> added here:
> 
> /var/lib/samba/private/dns_update_list
> 
> There can be a problem with the ticket, but, by using samba-tool, this 
> can be got around.
Let me add good news:

I think I made progress. As usual it was my mistake (mostly).

It seems I misunderstood how to use backports: I had only installed 
samba-related packages from backports, but never ran something like

apt-get dist-upgrade -t bullseye-backports

so there were packages related and/or required that were still missing.

Stupid mistake?


# apt-get upgrade -t bullseye-backports
Paketlisten werden gelesen? Fertig
Abh?ngigkeitsbaum wird aufgebaut? Fertig
Statusinformationen werden eingelesen? Fertig
Paketaktualisierung (Upgrade) wird berechnet? Fertig
Die folgenden Pakete sind zur?ckgehalten worden:
   libpam-systemd libsystemd0 linux-image-amd64 systemd tmux
Die folgenden Pakete werden aktualisiert (Upgrade):
   bind9-host curl e2fsprogs git git-man init init-system-helpers 
iproute2 less libbpf0 libcom-err2 libcurl3-gnutls libcurl4 libelf1 
libext2fs2 libldap-2.4-2 libldap-common libpcap0.8 libss2 libudev1 
libwbclient0 linux-libc-dev logsave man-db manpages-de
   monit nmap nmap-common python3-gi rsync rsyslog rsyslog-gnutls 
systemd-sysv tcpdump udev

( I also ran "dist-upgrade" to get even the 5 missing packages up to
date).

After this I have a working wbinfo:

# wbinfo -t
checking the trust secret for domain ARBEITSGRUPPE via RPC calls succeeded

# wbinfo -p
Ping to winbindd succeeded

*phew*

DNS works after re-adding the dns forwarders to that minimal smb.conf

-

The only thing:

"samba-tool drs showrepl" looks good on adc1, but on adc2 there are 
still lines like:

DSA object GUID: 0b67bcba-16f6-43ec-8856-2097311f4f57
		Last attempt @ Wed Nov 30 12:56:42 2022 CET failed, result 31 
(WERR_GEN_FAILURE)
		14 consecutive failure(s).


I expect these to disappear soon, at least I have seen it "fix itself"
a
few times already (some object gets renewed or ... ?).

Or do I have to do something else?

-

Additionally I have to think about the sysvol-replication: I am still 
with one-way-rsync .. dangerous now that I made adc2 the FSMO-roles-owner.

-

Now that was another adventure ...

I hope I am on the right track now.

thanks all, sorry for the noise.

30.11.2022 15:01, Stefan G. Weichinger via samba wrote:
> # apt-get upgrade -t bullseye-backports
Umm, nope, this will upgrade everything from backports.. but ok.
> Die folgenden Pakete werden aktualisiert (Upgrade):
>  ? bind9-host curl e2fsprogs git git-man init init-system-helpers iproute2
less libbpf0 libcom-err2 libcurl3-gnutls libcurl4 libelf1 libext2fs2
> libldap-2.4-2 libldap-common libpcap0.8 libss2 libudev1 libwbclient0
linux-libc-dev logsave man-db manpages-de
libwbclient0.  This is the only package which is/was needed.

Now.. I wonder if we can end up in a situation like this, when
libwbclient0 is old and everything else is new...  Lemme look...

Package: winbind
Version: 2:4.17.3+dfsg-2
Depends: libwbclient0 (>= 2:4.5.0+dfsg) ...

It looks like this is wrong.  And this explains why your wbinfo
didn't work - it used old libwbclient (from 4.13 apparently - from
bullseye) which weren't able to talk to current (4.17) winbindd.

Wow.

This is a bug, a real packaging bug.

Before, in bullseye, it was:

Package: winbind
Version: 2:4.13.13+dfsg-1~deb11u5
Depends: libwbclient0 (= 2:4.13.13+dfsg-1~deb11u5) ...

so winbind required exact version of libwbclient - apparently
in order to be sure that the two talk the same protocol between
each other.

Now I wonder why it hasn't been noticed before.  Because when
upgrading bullseye samba from backports, the same thing WILL
happen for sure - apt will not upgrade libwbclient0, and this
anomaly will happen.

It is interesting that there was nothing in bullseye package of
samba which ensured this "= current" relation between winbind
and libwbclient0. This "= current" relation was because the
packages were wrongly split, so an internal library without a
stable ABI were put into libwbclient, and winbindd used that
library, - from this usage, this "=current" relation come.
When I fixed that, making the split right, the original bug
(lack of special dependency on the exact version) has shown
itself, and no one noticed.

Stefan, you found a bug. A big one. Stupid thing which can
make whole setup very problematic, which you already know
about...

I'm sorry for this. Please accept my apologies. You suffered
quite a lot due to this. I didn't know. And I didn't know
libwbclient should match winbind in the first place. The only
excuse for me is that this is something I inherited, :) -
there were lots of issues in there, hidden like this one and
obvious, small and not so small.. I'll fix this on in the next
upload so the dependencies will be right.

And thank you very much for your patience!

/mjt