Bug 227289 - security/py-certbot-nginx: Wrong nginx configuration path set
Summary: security/py-certbot-nginx: Wrong nginx configuration path set
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-python mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-04 23:56 UTC by Christer
Modified: 2018-12-11 04:42 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (python)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christer 2018-04-04 23:56:21 UTC
Installing nginx, py-certbot and py-certbot-nginx results in wrong behaviour when running certbot:

# certbot
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Error while running nginx -c /etc/nginx/nginx.conf -t.

nginx: [emerg] open() "/etc/nginx/nginx.conf" failed (2: No such file or directory)
nginx: configuration file /etc/nginx/nginx.conf test failed

Certbot doesn't know how to automatically configure the web server on
this system. However, it can still get a certificate for you. Please run
"certbot certonly" to do so. You'll need to manually configure your web
server to use the resulting certificate.

Digging through the system, I eventually came across this file:

/usr/local/lib/python2.7/site-packages/certbot_nginx/constants.py

In constants.py, the server_root for nginx is set:

CLI_DEFAULTS = dict(
    server_root="/etc/nginx",
    ctl="nginx",
)

This should be set to /usr/local/etc/nginx, which is where nginx' config files reside on FreeBSD.

Changing server_root to /usr/local/etc/nginx and recompiling constants.py to constants.pyc and constants.pyo solves the problem and certificate requests and renewals work as expected.


System: FreeBSD 11.1-RELEASE-p9 amd64
Nginx: www/nginx-devel (1.13.10)
Certbot: security/py-certbot (0.22.2,1)
Certbot-nginx: security/py-certbot-nginx (0.22.2)
Comment 1 Christer 2018-04-08 16:56:31 UTC
Followup; seems I was a bit too fast on the "renewals work" trigger. Automatic renewal didn't work when ran from cron. Certbot threw an error (domain name obfuscated for privacy):

---
Attempting to renew cert (sub.domain.net) from /usr/local/etc/letsencrypt/renewal/sub.domain.net.conf produced an unexpected error: The nginx plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError(). Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /usr/local/etc/letsencrypt/live/sub.domain.net/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
---

Deleting the port and reinstalling it, and also recreating the symlink from /usr/local/etc/nginx to /etc/nginx restores expected working behavior:

-------------------------------------------------------------------------------
Processing /usr/local/etc/letsencrypt/renewal/sub.domain.net.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for sub.domain.net
Waiting for verification...
Cleaning up challenges

-------------------------------------------------------------------------------
new certificate deployed with reload of nginx server; fullchain is
/usr/local/etc/letsencrypt/live/sub.domain.net/fullchain.pem
-------------------------------------------------------------------------------

So apparently there's more to this than "just" changing the path in constants.py and recompiling the .py into .pyc/.pyo files.
Comment 2 p5B2E9A8F 2018-05-15 14:47:33 UTC
(In reply to Christer from comment #0)
Same problem here with 
# pkg info py27-certbot-nginx
py27-certbot-nginx-0.24.0
Name           : py27-certbot-nginx
Version        : 0.24.0
Installed on   : Sun May  6 13:37:05 2018 UTC
Origin         : security/py-certbot-nginx
Architecture   : FreeBSD:11:*
Prefix         : /usr/local

I suspect that this bugreport never got addressed by maintainer/upstream.
Looks like that someone needs to ring the bell.