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

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

Am 24.11.22 um 13:25 schrieb Stefan G. Weichinger via samba:
> Maybe someone points me at a way to fix this DSA-GUID issue or so.
If I understand this correctly, that wrong GUID might explain, why 
demoting doesn't work from the broken DC:

the final replication before the demote won't work either, right?

So it seems to me that this DC somehow has an identity issue ;-)