[Samba] Samba 4.16 and 4.17 ubuntu focal and jammy packages
abartlet at samba.org
Sun Oct 30 05:56:01 UTC 2022
On Sun, 2022-10-30 at 18:52 +1300, 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
> 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.
explains things well.
Andrew Bartlett (he/him) https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Developer, Catalyst IT https://catalyst.net.nz/services/samba
More information about the samba