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

I think I solved it.

Completely uninstalled samba-related packages and dependent libraries 
and stuff and installed fresh from bullseye-backports.

did:

apt-get install  -t bullseye-backports  acl attr samba 
samba-dsdb-modules samba-vfs-modules winbind libpam-winbind 
libnss-winbind krb5-config krb5-user dnsutils

Seems to work now.
phew

side note:

# host -t A  adc2.arbeitsgruppe.my.tld

host: error while loading shared libraries: libdns-9.16.33-Debian.so: 
cannot open shared object file: No such file or directory

Can't find that file on

https://packages.debian.org/

-

I now also upgraded one domain member server. Same picture.

I had to remove "samba-common  samba-common-bin  samba-libs" extra,
and
run "autoremove" ... that removed

"libnss-winbind libpam-winbind libsmbclient python3-samba samba 
samba-common samba-common-bin samba-dsdb-modules samba-libs 
samba-vfs-modules smbclient winbind"

After that installing again from backports. -> works so far

*phew*

I will keep it like this for today and wait for feedback.

The other DC and the second domain member (=fileserver) tomorrow.

22.11.2022 18:58, Stefan G. Weichinger via samba wrote:
> 
> I think I solved it.
> 
> Completely uninstalled samba-related packages and dependent libraries and
stuff and installed fresh from bullseye-backports.
> 
> did:
> 
> apt-get install? -t bullseye-backports? acl attr samba samba-dsdb-modules
samba-vfs-modules winbind libpam-winbind libnss-winbind krb5-config
> krb5-user dnsutils
Um.  Usually you don't have to go that far route.  And more to the point,
when you just
remove ("uninstall") a package, its data and configuration is not
removed, - unless
you do "purge" instead of "remove"; even with purge, some
packages do not perform
a cleanup.

With samba, - unless you installed package from scholelinux or something like
that,
which is just an awful abuse of package system, - upgrading software from
previous
version makes the same set of binaries as installing anew, - the binaries are
the
same thanks to the package management.  But with samba, when something is left
in
the data (/var/lib/samba or /var/cache/samba/ or /run/samba) from previous
attempt,
*that* one might stay on the way.

When I want to try something else with samba "anew", I just remove
whole thing
(after stopping samba-related processes) -
  rm -rf /var/lib/samba/* /var/cache/samba/* /run/samba /etc/samba/smb.conf
  mkdir /var/lib/samba/private # samba is unable to create this dir
automatically

and this gives me clean/fresh state.

I haven't watched this thread closely (had my own pile of issues to deal
with),
it'd be interesting to find out what exactly didn't work. 
Unfortunately, as
many times before, most of the time we don't know what actually happens
"when
it doesn't work", because people are advised to
reinstall/rejoin/reconfigure
from scratch, which "fixes the problem" (so it isn't even remotely
understood
what the original problem was).
> Seems to work now.
> phew
> 
> side note:
> 
> # host -t A? adc2.arbeitsgruppe.my.tld
> 
> host: error while loading shared libraries: libdns-9.16.33-Debian.so:
cannot open shared object file: No such file or directory
There's a bug in bind9/host packaging somewhere, and there was a bugreport
about libdns-9 missing, with a long discussion in there.

Many years ago I was scared about huge size of NAMED and its tools and
clumsy user interfaces of the tools, and wrote small dns library named
udns, with its simple-to-use dns query tool, dnsget.  It works quite
well still..  JFYI ;)

Thanks,

/mjt