[Samba] 4.17?

[William Edwards]

Kees van Vloten via samba schreef op 2022-10-22 11:43:
> On 22-10-2022 11:27, William Edwards wrote:
>> Kees van Vloten via samba schreef op 2022-10-22 10:36:
>>> 22.10.2022 00:23, Kees van Vloten via samba wrote:
>>>>> Louis has multiple versions in his repo, currently 4.14, 4.15, 
>>>>> 4.16. Which means I can decide when I want to upgrade to a newer 
>>>>> version by changing the sources.list. That way I can plan and test 
>>>>> the upgrades.
>>>> 
>>>> *That* is a good practical reason to have them indeed, thank you!
>>>> Tho, with a separate repository (like debian backports), you can
>>>> also do upgrade any time you prefer. You don't have that much
>>>> choice however.  And once new debian release is out, you can only
>>>> upgrade as a whole.
>>>> 
>>> Samba, the domain-controller, is a very critical infrastructure
>>> component. If it fails nobody (including myself) can login, that's 
>>> why
>>> I am careful with upgrades.
>> 
>> Depending on the environment, upgrading regularly could actually 
>> increase uptime.
>> 
>> Would you rather:
>> 
>> - Upgrade regularly, with a small version jump (e.g. 4.15 to 4.16), 
>> and figure out which change causes issues when there are issues?
>> - Upgrade incidentally, with a large version jump (e.g. 4.12 to 4.16), 
>> spend time figuring out which version causes issues when there are 
>> issues, then figure out which change in that version causes issues?
>> 
>> If you upgrade regularly, you could have issues more often. However, 
>> those issues would be solved more quickly. Bottom line: your uptime 
>> could actually be higher. Figuring out the difference between two 
>> versions is easier than figuring out the difference between multiple 
>> versions.
>> 
> I want security updates on standard debian packages asap, as I want to
> stay patched as much as possible.
> 
> The same is true for Samba, I want to follow the release cycle
> closely, to get fixes for security issues but also because new
> releases have functionality I am waiting for.
> At the same time, I clearly do not want availability disruptions on my
> systems (with getting locked out due to all DCs unavailable as the
> biggest risk).
> 
> The mechanism I described above with Louis' separate repos for
> releases and apt-pinning works/worked very well so far.
> 
> There is just one omission, if something fails badly on a new
> deb-package, I have not found an easy way to do a rollback to the
> previous known good version (the version before apt-get dist-upgrade).
> That package is no longer in the repo indexes and hence cannot be
> found (it still be in /var/cache/apt/archives but there is no
> guarantee).
> I would welcome advice at this point.

For a simple package without dependencies, `cd /tmp && apt download 
$name`.

For Samba, you could mirror only new packages from Louis's repository. 
And never purge them from your mirror.

> 
> 
>>> 
>>> I use Louis' separate repos to plan release upgrades, in combination
>>> with apt-pinning to fix the versions of samba, ldb and tevent 
>>> packages
>>> so that updates cannot get installed accidentally.
>>> 
>>> I tend to follow Louis' advice to wait at least until the 4.X.1
>>> release and to install a new version first on a fileserver and only
>>> then on the DCs. I have two DCs, I transfer the FSMO roles before I
>>> run apt-get dist-upgrade.
>>> 
>>> Being very careful is not always enough: the november 2021 update
>>> caused a ticket renew failure (a new smb.conf entry was introduced 
>>> and
>>> I misinterpreted the release notes). As a result user sessions would
>>> fail after 10 hours, luckily on this list there are a lot of helpful
>>> people :-)
>>> 
>>> My thinking is similar to Lorenzo: as Louis is unavailable, I would
>>> try to build the packages my self to keep control over the upgrade
>>> process. But then again, I do not like the extra work and I do not
>>> want to reinvent the wheel...
>>> 
>>> 
>>>> (btw, I think I'll continue provide current samba in 
>>>> bullseye-backports-sloppy
>>>> once bookworm is out, for some time anyway).
>>>> 
>>>> ..
>>>>> I asked him in the past (in 2020) to compile the packages with 
>>>>> "enable profiling", so that "smbstatus -P: will work. This is a 
>>>>> required of netdata to monitor Samba. And he added that to hist 
>>>>> packages, pretty cool.
>>>> 
>>>> It is enabled now in debian too.  The only feature enabled by him 
>>>> and not enabled
>>>> by debian (yet) is elasticsearch, - I yet to see what deps it brings 
>>>> us.
>>>> 
>>>> Thanks,
>>>> 
>>>> /mjt
>> 

-- 
With kind regards,

William Edwards