[Samba] Samba 4.16 and 4.17 ubuntu focal and jammy packages

[Kees van Vloten]

On 30-10-2022 06:52, Andrew Bartlett via samba wrote:
> On Sat, 2022-10-29 at 19:14 +0300, Michael Tokarev via samba wrote:
>> 29.10.2022 19:06, Rowland Penny via samba wrote:
>>> On 28/10/2022 11:28, Michael Tokarev via samba wrote:
>> ..
>>>> Now, there's one more question. Why it is so risky to upgrade
>>>> to a new samba "major" release?
>> ..
>>> Because Samba has an habit of removing, adding or changing things and this leads to old versions of things being left on disk and interfering with the
>>> smooth running of Samba. One that springs to mind is the python 'time', Samba had its own version and then removed it, but the distros didn't.
>>>
>>> Starting with a new OS, also ensures that everything is correct and nothing 'old' is there.
>> Well, I completely disagree with you here.
>>
>> I asked about real-life reasons why samba itself, - unrelated to
>> packaging errors - can not keep its own stuff up and running.
>> Not some theoretical issues and not obvious bug which happened
>> in the past, but something real.
> In-place upgrades are fully supported and many users successfully
> upgrade Samba including between major releases.
>
> Samba will self-upgrade the DB format when required.  There have been
> occasional bugs with the in-place upgrade, most are fixed with a
> 'samba-tool dbcheck --reindex', except where you have two spaces in a
> DN, and those need manual fixing (nobody wrote a dbcheck rule for
> that).
>
> Upgrading over DRS avoids some of those small risks but adds others,
> that is the DC is (unless newly added) first removed from the domain,
> then added back in.  An in-pace upgrade keeps the existing trust
> account and data.
>
>> Requiring to start anew each time something changes is completely
>> unreasonable. We cam and actually *do* better than that.
> The wiki https://wiki.samba.org/index.php/Upgrading_a_Samba_AD_DC has
> some collected wisdom on approaches.
>
> Oddly, it doesn't really address the main thing I suggest considering
> when upgrading Samba major versions, which is to build a new DC with
> whatever is now the new LTS release of your base OS, add this as new
> DC, check it is working then demote the old DCs, which avoids loss of
> redundancy during the upgrade and allows some checking before locking
> in the new version across the fleet.
>
> Andrew Bartlett
>
I fancy in-place upgrades. It is by far the easiest way to upgrade and 
generally it works fine.

As stated in another post, the impact of a broken domain is just too 
high, therefore I take measures to reduce the chances as much as 
possible: I want to plan to moment of upgrade per server independent of 
other distro (security-)upgrades.

This way I can do supervised and phased upgrades and analyze / fix stuff 
when one server's DC is broken (and the domain is still up and running 
on the others). It has already saved me a few times in the past!

- Kees.