Ebuild for the rfc2136 DNS certbot authenticator. Reproducible: Always
Created attachment 599466 [details] certbot-dns-rfc2136 certbot-dns-rfc2136 ebuild worked from -0.25 up to -1.0.0-r1 and does also try -9999 Version should be equal to certbot version.
This "plugin" is already distributed through app-crypt/certbot, but is not installed by the ebuilds that cover it. Wouldn't it make more sense to extend the app-crypt/certbot ebuilds to install those than to create new ebuilds?
the problem is that while it's in the certbot repo, the certbot repo actually contains MANY python libraries / projects. it contains acme/certbot and then all the plugins as separate sub-directories and installable python libraries. They are packaged as separate python libraries as I believe that even on pypi they are packaged separately.
All Certbot plugins are as a separate module. Certbot presumes anyone can load them using: pypi.org alas that is a no go area for gentoo core routines. Hence the ebuild for this package. The rfc2136 is usable for most DNS servers that are compliant to DNS RFC's. For other DNS infra there are other tools available more specific to the environment they run in. There is one note worthy exception, it is mentioned in the documentation. It is not part of the official certbot release as they are (re)thinking their DNS strategy due to testability of DNS plugins. It is the standalone dns authenticator, which can be used on a static DNS setup where there is a udp port 53 available on a free address. A separate ebuild has been provided for it. https://bugs.gentoo.org/702740
Same script still usable for certbot 1.8.0
If you use certbot auto renawal with dns-rfc2136 validation you need exact version of dns-rfc2136 python module with certbot. Otherwise renewal process exits with parse errors. Currently that caused my SSL's broken. Relying on pip is the solution for me. This simple script updates dns-rfc2136 python module with pip ACCORDING TO CERTBOT VERSION to prevent breaking certificate renew automations. Hope someone maintain this package soon. https://github.com/hsntgm/certbot-dns-rfc2136
(In reply to Hasan Calisir from comment #6) > If you use certbot auto renawal with dns-rfc2136 validation you need exact > version of dns-rfc2136 python module with certbot. It's not *that* bad. My latest renewal, less than two weeks ago, went without problems, running app-crypt/certbot-1.14.0 from the main repo and app-crypt/certbot-dns-rfc2136-1.8.0 from this bug. > Hope someone maintain this package soon. Agree. This package is one of very few ways of using Let's Encrypt for things that are not web servers.
@Hasan Calisir I gave up on "maintaining" this as no-one from gentoo had ANY interest at all. Maintenance exists in: copy "current ebuild" to "new ebuild" version number of certbot. ebuild "the new script" manifest and deploy. So the "guy" that "stabalises the new certbot" in gentoo could also copy this one... or not as it appears. (it can be scripted...). The rename/copy of the ebuild causes it to fetch from the certbot repos with the new version. So copying the ebuild to a new version DOES NOT copy the 1.1.0 dns interface to a the current version it actualy uses the current code from the current repo. The reason the package is tied to certbot itself is because it's internal interfaces are maintained by the certbot team. (it's one of the few extentions kept alive). They did announce a new DNS interface 2 years ago, i never saw that gain traction though.
Still works for 1.16.0
Still works for 1.29.0 (with minor tweaks to EAPI and PYTHON_COMPAT)
Hello, I just noticed this ticket, I didn’t notice it while I pushed to Gentoo’s Guru project this Certbot module: app-crypt/certbot-dns-rfc2136 https://gitweb.gentoo.org/repo/proj/guru.git/log/app-crypt/certbot-dns-rfc2136 Maybe you want to review it, I just pushed the current 1.32.0 version (still in branch "dev" currently).
Created attachment 843287 [details] Certbot 2.0 update, python version, EAPI. Slightly updated certbot. (python versions, EAPI).
See also the certbot-dns-standalone
@Nico Baggus @Thibaud CANALE @Karl-Johan Karlsson Any official permanent solution for certbot-dns-rfc2136? There are completely different structured ebuilds on overlays. For example; This is from Thibaud CANALE (guru) ---------------------------- BDEPEND=" test? ( dev-python/pytest ) " RDEPEND=" ${PYTHON_DEPS} >=app-crypt/acme-${PV}[${PYTHON_USEDEP}] >=app-crypt/certbot-${PV}[${PYTHON_USEDEP}] >=dev-python/pyopenssl-22.0.0[${PYTHON_USEDEP}] >=dev-python/pyparsing-3.0.9[${PYTHON_USEDEP}] >=dev-python/zope-interface-5.4.0[${PYTHON_USEDEP}] >=dev-python/dnspython-2.2.0[${PYTHON_USEDEP}] " This is from Nico Baggus. ------------------------- CDEPEND=">=dev-python/setuptools-1.0[${PYTHON_USEDEP}]" RDEPEND="${CDEPEND} ~app-crypt/certbot-$PV[${PYTHON_USEDEP}] ~app-crypt/acme-$PV[${PYTHON_USEDEP}] dev-python/mock[${PYTHON_USEDEP}] dev-python/zope-interface[${PYTHON_USEDEP}] dev-python/dnspython[${PYTHON_USEDEP}]" DEPEND="${CDEPEND}" This is from certbot-dns-plugins overlay. -------------------------- RDEPEND="${CDEPEND} >=app-crypt/certbot-${PV}[${PYTHON_USEDEP}] >=app-crypt/acme-${PV}[${PYTHON_USEDEP}] dev-python/dnspython[${PYTHON_USEDEP}]" ~Hasan
Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/certbot/_internal/renewal.py", line 493, in handle_renewal_request renewal_candidate = _reconstitute(lineage_config, renewal_file) File "/usr/lib/python3.10/site-packages/certbot/_internal/renewal.py", line 95, in _reconstitute _restore_plugin_configs(config, renewalparams) File "/usr/lib/python3.10/site-packages/certbot/_internal/renewal.py", line 165, in _restore_plugin_configs if config_item.startswith(plugin_prefix + "_") and not cli.set_by_cli(config_item): File "/usr/lib/python3.10/site-packages/certbot/_internal/cli/__init__.py", line 489, in set_by_cli if not isinstance(getattr(detector, var), _Default): AttributeError: 'Namespace' object has no attribute 'dns_rfc2136_credentials'
I'm still running the ebuild from this bug, currently attachment 843287 [details] renamed to 2.1.0. Last update was a week ago and went fine. I would be happy to test any proposed official ebuild.
Thank you for confirmation @Karl-Johan Karlsson. "...renamed to 2.1.0. Last update was a week ago and went fine." Nearly after two years we still manually version bumping for certbot-dns-rfc2136 after every certbot update! That is so funny :) I'm glad you survived the pandemic, man. It seems we will keep in touch with you forever cause certbot-dns-rfc2136.ebuild @Matthew Thode thank you dear certbot maintainer. We socialize because of you.
Hello, Sorry for the lack of reply, I finally was able to update my work around this module. About comment 14, I understood a bit late only to rely on the `setup.py` script concerning the target module, so basically the choice from certbot-dns-plugins is the correct one. So, enjoy the updates.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=455ebd3f5549687776d5ec039d93a13766411503 commit 455ebd3f5549687776d5ec039d93a13766411503 Author: Thibaud CANALE <thican@thican.net> AuthorDate: 2023-01-30 00:46:23 +0000 Commit: Thibaud CANALE <thican@thican.net> CommitDate: 2023-01-30 00:46:23 +0000 app-crypt/certbot-dns-rfc2136: add 2.0.0, 2.1.0, 2.2.0 Also fix dependencies based on `setup.py` content. Bug: https://bugs.gentoo.org/702744 Signed-off-by: Thibaud CANALE <thican@thican.net> app-crypt/certbot-dns-rfc2136/Manifest | 3 + .../certbot-dns-rfc2136-2.0.0.ebuild | 70 ++++++++++++++++++++++ .../certbot-dns-rfc2136-2.1.0.ebuild | 70 ++++++++++++++++++++++ .../certbot-dns-rfc2136-2.2.0.ebuild | 70 ++++++++++++++++++++++ .../certbot-dns-rfc2136-9999.ebuild | 12 ++-- 5 files changed, 218 insertions(+), 7 deletions(-)
I see the dependency from this plugin to acme & certbot is >=... Lets Encrypt makes no such assumptions of cross version compatibility. IMHO it should be =.... So the plugins from the official repo should depend on the acme / certbot builds of the same version. (this is not only for DNS plugins it extends also for nginx, apache etc. etc.)
I stopped using these from a gentoo system. Easier to run some debian env. inside an LXD container. And install the modules using pip there.
