[Nextcloudpi] Another Letsencrypt Error

Hi folks,

I was surprised to get a renewal notice the other day from the Letsencrypt expiry bot informing me that my certificate was going to expire in 19 days. I had enabled the certificate using NCP, and thought that the renewal would be automatic (and automated) from here on in. Making sure everything on my NC client was up to date (including NCP), I ran the letsencrypt setup from NCP, and got an error.

I’ve listed the output below. Anyone know what’s going on? I can see the HTTP error, but I’m not sure what it means.

– DL

Bootstrapping dependencies for Debian-based OSes... (you can skip this with --no-bootstrap)
Hit:1 http://archive.raspberrypi.org/debian stretch InRelease
Get:2 http://mirrordirector.raspbian.org/raspbian stretch InRelease [15.0 kB]
Fetched 15.0 kB in 1s (7880 B/s)
Reading package lists...

Reading package lists...

Building dependency tree...

Reading state information...
augeas-lenses is already the newest version (1.8.0-1+deb9u1).
ca-certificates is already the newest version (20161130+nmu1).
gcc is already the newest version (4:6.3.0-4).
libaugeas0 is already the newest version (1.8.0-1+deb9u1).
libffi-dev is already the newest version (3.2.1-6).
libssl-dev is already the newest version (1.1.0f-3+deb9u1).
openssl is already the newest version (1.1.0f-3+deb9u1).
python is already the newest version (2.7.13-2).
python-dev is already the newest version (2.7.13-2).
python-virtualenv is already the newest version (15.1.0+ds-1).
virtualenv is already the newest version (15.1.0+ds-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Creating virtual environment...
Installing Python packages...
Had a problem while installing Python packages.

pip prints the following errors: 
Collecting argparse==1.4.0 (from -r /tmp/tmp.R5jqAKxHS0/letsencrypt-auto-requirements.txt (line 11))
Traceback (most recent call last):
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/commands/install.py", line 342, in run
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/req/req_set.py", line 380, in prepare_files
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/req/req_set.py", line 554, in _prepare_file
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/req/req_install.py", line 278, in populate_link
    self.link = finder.find_requirement(self, upgrade)
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/index.py", line 465, in find_requirement
    all_candidates = self.find_all_candidates(req.name)
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/index.py", line 423, in find_all_candidates
    for page in self._get_pages(url_locations, project_name):
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/index.py", line 568, in _get_pages
    page = self._get_page(location)
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/index.py", line 683, in _get_page
    return HTMLPage.get_page(link, session=self.session)
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/pip/index.py", line 795, in get_page
  File "/opt/eff.org/certbot/venv/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/models.py", line 893, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
HTTPError: 404 Client Error: Not Found for url: https://www.piwheels.hostedpi.com/simple/zope.components/argparse/

Certbot has problem setting up the virtual environment.

We were not be able to guess the right solution from your pip 

Consult https://certbot.eff.org/docs/install.html#problems-with-python-virtual-environment
for possible solutions.
You may also find some support resources at https://certbot.eff.org/support/ .

to me it seems a duplicate of

try to comment out (or delete/move?) /etc/pip.conf as per that thread

Yup, definitely the exact same issue. I’m travelling tomorrow, but will give your solution a try as soon as I am able, and will report back here. Many thanks!

I’ve commented out all the lines in /etc/pip.conf as described above. Unfortunately, I’m still out of town, so I can’t locally invoke NCP to update the letsencrypt script. Is there a simple way to do this remotely from the command line?

how about

sudo nextcloudpi-config

Hi. From experience with Letsencrypt I find the default renew process does not work.

I added a different script for the Certbot client and then added the cron job

0 1 1 */2 * /usr/local/letsencrypt/letsencrypt-auto renew >> /var/log/blog.com.log 2>&1


for me it does, but if it doesn’t for somebody I would be interested in feedback to fix it.

NCP install leaves the following in /etc/cron.d/letsencrypt-ncp

* 1 * * 1 root /etc/letsencrypt/certbot-auto renew --quiet

Okay, I have a bit of news to report. Once I commented out the contents of the /etc/pip.conf file, that seems to have done the trick! Eventually it appears that the cron job resumed, and it successfully renewed my certificate. Many thanks once again to @nachoparker

Interestingly, no cron logs were written (in /var/logs/letsencrypt) after December 4, which I am presuming is when the problem with the contents of the /etc/pip.conf file began. Log files have resumed as of last night, after my certificate was successfully renewed.

This raises a few questions in my mind:

  1. Shouldn’t the cron job have written failure notices to the log files? Seems like this would have been helpful information in trying to track this down, and particularly raising an alert that the process was failing.

  2. Apparently whatever those commented-out files in /etc/pip.conf had in them weren’t necessary to the proper renewal of the certificates; so if everything works fine after commenting them out, why do we even need the file at all?

cron logs are sent to /var/log/mail/root

Those lines in pip.conf were a workaround for this letsencrypt bug. Once the bug was fixed, I stopped altering that file, but now it seems like it’s affecting users.

Only a few people have that line edited. This is the people that were updating during the time that the bug lived unresolved.

That’s why it’s there

Knowing that it’s causing trouble, I will force back the original configuration in the next update so other people in the same situation don’t run into this issue

Thanks for reporting