Forum archive
Certbot update 1.7.0...any impact / upgrade recommendation necessary?
LetsEncrypt released an upgrade notice w.r.t. Certbot as follows:
We deprecated support for Python 3.5 in Certbot and its ACME library. Support for Python 3.5 will be removed in the next major release of Certbot.https://community.letsencrypt.org/t/certbot-1-7-0-release/130210 So if we need upgrade certbot / ACME library combo and it forces an upgrade of the python, will that impact the console (eg. adjusted path settings...Python version for LE and another Python version for console )? We haven't had this type of co-upgrade issue in the pre-LE days so I'm not sure what the go-forward plan is. In the past we could choose to update VM tools (eg. webmin) at our discretion. But, since LE refreshes the cert multiple times per year, it likely needs to remain fresh even if other TKLX VM tools may get stale. I'm not suggesting this is an issue but rather I'm raising a flag for general documentation for continuously life-cyle managing Certbot / Acme.
Replies (2)
Confconsole v16.x is compatible with python3 (3.5 -> 3.8)
Reply 1Cheers...in depth answer as always
Reply 2Cheers Jed. An excellent in-depth answer as always. Much appreciated :-)
I was actually referring to past, present and future versions with a sanity check on the current version 16. Thanks for the update.
TKLX VMs historically have not been life-cycled at the app tier. The versions of all the app code are locked to the TKLX release version with a reliance on Debian security updates to keep the VM software secure.
TKLX VM tools historically have always been administrative in nature and installed so app updates were optional since the tools are mature products.
With the addition of LE-components TKLX has moved into the "needs life-cycling" category. Unlike the other TKLX admin tools, LE-components are part of a SaaS configuration and as such will evolve on a timeline that cannot be synched with the legacy TKLX release-centric update model.
What might be useful is to open a GitHub issue related to the life-cycling of this component and you keep an eye on the evolution of the LE-components and update the issue when the LE-components are updated from the TKLX release perspective as in...no impact / Low|Medium|High impact.
Just a suggestion :-)
I was actually referring to past, present and future versions with a sanity check on the current version 16. Thanks for the update.
TKLX VMs historically have not been life-cycled at the app tier. The versions of all the app code are locked to the TKLX release version with a reliance on Debian security updates to keep the VM software secure.
TKLX VM tools historically have always been administrative in nature and installed so app updates were optional since the tools are mature products.
With the addition of LE-components TKLX has moved into the "needs life-cycling" category. Unlike the other TKLX admin tools, LE-components are part of a SaaS configuration and as such will evolve on a timeline that cannot be synched with the legacy TKLX release-centric update model.
What might be useful is to open a GitHub issue related to the life-cycling of this component and you keep an eye on the evolution of the LE-components and update the issue when the LE-components are updated from the TKLX release perspective as in...no impact / Low|Medium|High impact.
Just a suggestion :-)
I assume you are referring to upgrading a v15.x appliance to Debian 10/Buster? I ask because v16.x (based on Debian 10/Buster) has Python 3.7 OOTB (v15.x / Stretch has Python 3.5). So to upgrade, I would assume that you are doing an "in place" Debian upgrade? Migrating the data (to a v16.x appliance) is another option (and probably one I would prefer personally - but obviously YMMV).
FWIW if you have installed Certbot in v15.x, then Confconsole is probably broken already (Confconsole v1.x in v15.x depended on our own really old fork of python-dialog - installing certbot would have upgraded to the Debian package and effectively breaking Confconsole already).
For v16.x we ported Confconsole to Python3 - namely 3.7 as provided by Buster (it should also be compatible with Python3.5, although that's a moot point now anyway). It also now uses the default Debian python-dialog package (so installing certbot won't break it).
It's worth noting that v16.x / Debian Buster still includes Python2 (2.7) but will be the last Debian release to include it (the upcoming Debian 11/Bullseye will only include Python3; likely 3.8, but perhaps 3.9). In Debian (and most Linux distros, Arch is the only exception AFAIK) the "python" executable explictly points to python2 (2.7), whereas python3 points to v3 (3.5 or 3.7 depending on which release). Once Python2 is retired, there will no longer be a 'python' command (it will be python3 or python4 once that's released).
An alternate path to upgrading/migrating would be to ditch Certbot on your v15.x appliance and use the TurnKey Let's Encrypt integration. That leverages Dehydrated instead. That will likely only work if Confconsole still works (which I noted above, my not be the case), although could be resolved/worked around if need be. Assuming that LE don't change their API again in the near future, one set up, that should "just work" (although the same possibly applies to certbot - FWIW we chose not to use certbot partially because of it's size, but also partially because of how much information it leaks). Unfortunately I don't have push access to the v15.x TurnKey apt repos, so it involves a bit of a manual painful process, but leverages the Debian packagve of Dendyrated (although as it's only a single bash script, manually updating it is as simple as a wget if ever needed). The latest (and almost certainly last) v1.x Confconsole release (v1.1.2) and the release notes are on GItHub.
If you choose the "in place upgrade" path, it's worth noting that we didn't extensively test it to ensure that it works flawlessly. But we've had reports from others that it works fine.
Hope that helps. If I missed or misunderstood something, please feel free to elaborate.