wedwards at cyberfusion.nl
Sat Oct 22 09:27:28 UTC 2022
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
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
> 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
>> 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
With kind regards,
More information about the samba