[Samba] accidentally upgraded DC to 4.17.3 ... didn't work
Stefan G. Weichinger
lists at xunil.at
Thu Nov 24 12:25:53 UTC 2022
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
More information about the samba
mailing list