[Samba] 4.17?

Kees van Vloten keesvanvloten at gmail.com
Sat Oct 22 09:43:26 UTC 2022


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.


>>
>> 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
>



More information about the samba mailing list