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

24.11.2022 14:41, Stefan G. Weichinger via samba wrote:
> Am 24.11.22 um 12:10 schrieb Stefan G. Weichinger via samba:
>> Am 24.11.22 um 11:12 schrieb Stefan G. Weichinger via samba:
> 
>> somehow the 2 DCs can't talk to each other?
> 
> I assume that somehow the adc1 comes with a wrong "identity"
somehow.
> 
> "samba-tool dbcheck --cross-nc --fix" on adc2 works ok.
> 
> But there is some mismatch:
> 
> [2022/11/24 12:37:11.755128,? 1]
../../source4/dsdb/common/util.c:4978(dsdb_validate_dsa_guid)
>  ? ../../source4/dsdb/common/util.c:4978: Failed to find DSA objectGUID
afe62553-1846-4d35-96c1-1b939cec36f2 for sid
> S-1-5-21-2777655458-4002997014-749295002-5650
Unfortunately I don't know that far.
Don't even know what a DSA objectGUID is.

What do you have now in the end?  Do you
have at least one working DC?

If yes, it should be easy to recreate the
other DCs from scratch, - removing all old
data in them after demotion and rejoining.
Including smb.conf, - it gets recreated by
samba-tool domain join DC command, you can
make some adjustments later from old smb.conf.

This is a way without understanding what's happening.
It'd be very good if we're able to find the actual
reason why it is failing and fix that one instead
of going the reinstall (in this case: rejoin)
route.  Thankfully rejoin procedure is easy to
do, at least.

But for this, someone with more knowlege in this
area is needed, who knows what does these error
messages mean.

If you go the actual rejoin route, I suggest you
to clear 5 places: /var/lib/samba/* (recreating private/
there), /var/cache/samba/* /var/log/samba/log.*,
/etc/samba/smb.conf and /run/samba. there's nothing
in /var/lib/samba/ which might be needed before
rejoin as a DC - samba-tool domain join foo DC will
create everything in there (except of the private/
subdir itself), with all the info populated from
the AD (from active DCs).

If I follow you right, samba-tool domain join works,
but when you start samba it fails to do the work, -
it suggest either some configuration (in smb.conf?)
which is not used by samba-tool join but is used
when you start samba, or some cache or other "later"
state file in one of the mentioned places.

Again, it'd be very interesting to find out what
it is, but here we go.

/mjt

Am 24.11.22 um 13:13 schrieb Michael Tokarev:
>>> Am 24.11.22 um 11:12 schrieb Stefan G. Weichinger via samba:
t there is some mismatch:
>>
>> [2022/11/24 12:37:11.755128,? 1] 
>> ../../source4/dsdb/common/util.c:4978(dsdb_validate_dsa_guid)
>> ?? ../../source4/dsdb/common/util.c:4978: Failed to find DSA 
>> objectGUID afe62553-1846-4d35-96c1-1b939cec36f2 for sid 
>> S-1-5-21-2777655458-4002997014-749295002-5650
> 
> Unfortunately I don't know that far.
> Don't even know what a DSA objectGUID is.
I think it's the ID of the node in terms of replication in DRS.

Just guessing: the newly joined DC doesn't use the ID expected by the 
existing other DC.

Maybe I didn't clear enough config in the process.

Maybe demoting/rejoining also needs a renaming, at least I find older 
threads mentioning that (might be OK with later samba-releases now).
> What do you have now in the end?? Do you
> have at least one working DC?
Thankfully yes. adc2 seems OK (and running 4.17.3, btw!).

I have a online backup via samba-tool from this morning on adc1 (the 
broken DC).

adc2 is quite small, /tmp doesn't allow me to run another online backup 
there (~2 GB, $SYSVOL is rather big). Maybe there is way to define a 
different temp-dir, dunno.
> If yes, it should be easy to recreate the
> other DCs from scratch, - removing all old
> data in them after demotion and rejoining.
> Including smb.conf, - it gets recreated by
> samba-tool domain join DC command, you can
> make some adjustments later from old smb.conf.
> 
> This is a way without understanding what's happening.
> It'd be very good if we're able to find the actual
> reason why it is failing and fix that one instead
> of going the reinstall (in this case: rejoin)
> route.? Thankfully rejoin procedure is easy to
> do, at least.
> 
> But for this, someone with more knowlege in this
> area is needed, who knows what does these error
> messages mean.
> 
> If you go the actual rejoin route, I suggest you
> to clear 5 places: /var/lib/samba/* (recreating private/
> there), /var/cache/samba/* /var/log/samba/log.*,
> /etc/samba/smb.conf and /run/samba. there's nothing
> in /var/lib/samba/ which might be needed before
> rejoin as a DC - samba-tool domain join foo DC will
> create everything in there (except of the private/
> subdir itself), with all the info populated from
> the AD (from active DCs).
> 
> If I follow you right, samba-tool domain join works,
> but when you start samba it fails to do the work, -
> it suggest either some configuration (in smb.conf?)
> which is not used by samba-tool join but is used
> when you start samba, or some cache or other "later"
> state file in one of the mentioned places.
> 
> Again, it'd be very interesting to find out what
> it is, but here we go.
thanks for clarifying this. Over the last hours I re-tried that stuff in 
variations ... got to take a break and breathe now.

Maybe someone points me at a way to fix this DSA-GUID issue or so.

For now I am scared to also break adc2 which would affect ~50 users ...

I would prefer to avoid renaming adc1, btw

Thanks for your help, Michael!

Stefan