I recently discovered that two changes to the py27-certbot port cause the Let's Encrypt renewal script to break. The first issue is the name of the executable changed from /usr/local/bin/certbot to /usr/local/bin/certbot-2.7. This results in scripts and crontabs that call the script to not find the certbot executable.
The second, more serious, issue is running the new path of the script results in a Python traceback error and no certificates being fetched. This can be reproduced on each of my FreeBSD 11.2 machines by running "certbot renew".
The output from the crashed script indicates the error happens here:
"from pkg_resources import load_entry_point"
I found that the bug can be worked around by removing the Python 2.7 version of the Let's Encrypt certbot tool and installing the Python 3.6 version. With the updated version installed running "/usr/local/bin/certbot renew" works.
@jsmith Is this still an issue with the latest version of the port/package? If so, could you please provide:
- A full traceback as an attachment
- pkg version -v output (as an attachment)
(In reply to Kubilay Kocak from comment #1)
Since Python 2.7 is no longer supported, I think this bug can be closed. Certbot is working with Python 3, giving us a reasonable workaround.
(In reply to jsmith from comment #2)
Python is EoL (as of Jan 1 2020), but is in sunset with a final release still to come (April, 2020 )
Nevertheless, Python 2.7 is set to be deprecated December 2020 in FreeBSD, with work taking place to upgrade, or retire unmaintained an deprecated packages in the meantime.
What this means is that if an upstream package supports 2.7 and is maintained (upstream and downstream), that it still ought to work, work meaning: gets bugfixes if they are reproducible and resolvable
based on the description of the issue provided so far:
The first issue is the name of the executable changed from /usr/local/bin/certbot to /usr/local/bin/certbot-2.7
This sounds like the default version of Python on that system is not 2.7. Since only the default version of Python ports/packages get canonical (not version-suffixed script names, the lack of a certbot scriptname is intended. It is up to the administrator to either:
- Invoke python scripts using their script-X.Y version, OR
- Ensure that if/when invoking <script> without a version suffix, ensure that the systems configured default Python version is the one that's expected
On the second issue:
issue is running the new path of the script results in a Python traceback error and no certificates being fetched
If this is still an issue, in any Python version of the certbot port, a full command line invocation and traceback is what's required to isolate the issue, along with information about where exactly said command points to (if one is using 'certbot', not 'certbot-X.Y' as the invoking command
 "As a final service to the community, python-dev will bundle those fixes -- and only those fixes -- into a final 2.7.18 release," the Python Foundation noted in an update. "The release date for 2.7.18 will be in April 2020, because that allows time for the release managers to complete a release candidate and final release."