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
>