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

Am 24.11.22 um 08:58 schrieb Michael Tokarev:
> 24.11.2022 10:10, Stefan G. Weichinger via samba wrote:
> ..
>> So you basically say, I should/could "rm -fr /var/lib/samba"
while
>> upgrading?
> 
> No.? I'm saying that - in case of a failed upgrade - reinstalling the 
> binaries
> should not help, as you're installing the same binaries which were 
> before anyway,
> but removing state data and reconfiguring usually helps.
> 
>> I currently try upgrading the second dc and I see the same issue with 
>> winbind. No, I haven't yet tried that rejoin step.
> 
> Which issue is that? I just re-read whole thread, I see you had
> several issues with winbindd.
> 
> What's wrong with winbindd now, exactly?
for example:

# wbinfo -t
could not obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE
could not obtain winbind domain name!
checking the trust secret for domain (null) via RPC calls failed
failed to call wbcCheckTrustCredentials: WBC_ERR_WINBIND_NOT_AVAILABLE
Could not check secret

# wbinfo -u
could not obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE
could not obtain winbind domain name!
Error looking up domain users

-

currently it seems I have broken things even more

samba-tool drs showrepl ... looks ok on adc1, but shows failures on adc2 
...

-

Should I demote adc1 again?

The procedure with "samba-tool domain demote" failed before .. maybe I
have to demote it from adc2 again.

# samba-tool domain demote -U Administrator
Using adc2.arbeitsgruppe.my.tld as partner server for the demotion
Password for [ARBEITSGRUPPE\Administrator]:
Deactivating inbound replication
Asking partner server adc2.arbeitsgruppe.my.tld to synchronize from us
Error while replicating out last local changes from 
'CN=Schema,CN=Configuration,DC=arbeitsgruppe,DC=ikw-amstetten,DC=at' for
demotion, re-enabling inbound replication
ERROR(<class 'samba.WERRORError'>): Error while sending a
DsReplicaSync
for partition 
'CN=Schema,CN=Configuration,DC=arbeitsgruppe,DC=ikw-amstetten,DC=at' - 
(31, 'WERR_GEN_FAILURE')
   File "/usr/lib/python3/dist-packages/samba/netcmd/domain.py", line 
860, in run
     drsuapiBind.DsReplicaSync(drsuapi_handle, 1, req1)



rm-ing /var/lib/samba: wouldn't I have to take care of SYSVOL etc ?

rsyncing an empty dir to the productive DC wouldn't be nice ...

thanks

Am 24.11.22 um 09:12 schrieb Stefan G. Weichinger via samba:
> Should I demote adc1 again?
> 
> The procedure with "samba-tool domain demote" failed before ..
maybe I
> have to demote it from adc2 again.
> 
> # samba-tool domain demote -U Administrator
> Using adc2.arbeitsgruppe.my.tld as partner server for the demotion
> Password for [ARBEITSGRUPPE\Administrator]:
> Deactivating inbound replication
> Asking partner server adc2.arbeitsgruppe.my.tld to synchronize from us
> Error while replicating out last local changes from 
>
'CN=Schema,CN=Configuration,DC=arbeitsgruppe,DC=ikw-amstetten,DC=at' for
> demotion, re-enabling inbound replication
> ERROR(<class 'samba.WERRORError'>): Error while sending a
DsReplicaSync
> for partition 
>
'CN=Schema,CN=Configuration,DC=arbeitsgruppe,DC=ikw-amstetten,DC=at' -
> (31, 'WERR_GEN_FAILURE')
>  ? File "/usr/lib/python3/dist-packages/samba/netcmd/domain.py",
line
> 860, in run
>  ??? drsuapiBind.DsReplicaSync(drsuapi_handle, 1, req1)

seeing this on adc1:

# tail log.samba
[2022/11/24 09:31:35.847095,  1] 
../../source4/auth/gensec/gensec_gssapi.c:791(gensec_gssapi_update_internal)
   GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see 
text): Decrypt integrity check failed for checksum type 
hmac-sha1-96-aes256, key type aes256-cts-hmac-sha1-96
[2022/11/24 09:31:35.906647,  1] 
../../source4/auth/gensec/gensec_gssapi.c:791(gensec_gssapi_update_internal)
   GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see 
text): Decrypt integrity check failed for checksum type 
hmac-sha1-96-aes256, key type aes256-cts-hmac-sha1-96

24.11.2022 11:12, Stefan G. Weichinger wrote:
..
> # wbinfo -t
> could not obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE
So your wbinfo can't contact you winbindd running on the same host.
I just checked the strace of wbinfo, knowing nothing about how it
works internally.  It only makes connections to /run/samba/winbindd/pipe,
a local unix-domain socket which is created by winbindd.

So winbindd is not running on this host.  And this is consistent with what
you've seen before, when one winbindd process hasn't been starting,
logging an error of some sort.  Is it the same error message now?
It's been in your message with Date: Tue, 22 Nov 2022 14:07:23 +0100.

And at Tue, 22 Nov 2022 13:23:06 +0100:
[2022/11/22 13:19:27.912603,  5]
../../source3/winbindd/winbindd_dual_srv.c:72(_wbint_InitConnection)
   _wbint_InitConnection: ARBEITSGRUPPE returning without initialization online
= 1

this seem to be about ARBEITSGRUPPE, not about idmap part, but let's
see..

It's better to see *current* situation and *current* error messages
instead of assuming it's the same as on another machine.

Is there anything interesting in /var/log/samba/log.winbindd-idmap?
You had idmap process failing, that's the log of it.

You can also try stopping samba-ad-dc and run winbindd manually:

  /usr/sbin/winbindd -D --option="server role check:inhibit=yes"
--foreground --debug=10

and take a look at the log files. There should be some errors in there
hopefully.

If not, here's a hammer debugging tool:

systemctl stop samba-ad-dc
apt install strace   # if not installed already)
strace -ff -o /tmp/trc /usr/sbin/winbindd -D --option="server role
check:inhibit=yes" --foreground
(and hit Ctrl+C to stop it).

and maybe take a look at /tmp/trc.* or make them available for download
somewhere?

it will show what exactly your winbindd is doing, how it is failing.
It *MIGHT* show sensitive data, but should actually not, provided
there's no other activity on this host (samba is not running) which
is asking for sensitive winbindd data.  The important info should
be at the

This is one thing to fix first: why winbindd refuses to start.

idmap child does not open any inet conenctions, it does not use DNS,
it just manages idmap caches and queries. It is one of the simpler
daemons, to mean, it should not depend on any network-related stuff.

The other thing - errors on another DC - is next.

Thanks,

/mjt