Certbot-auto fails on Debian Jessie, hangs on “Installing Python packages…

Help
1

(The note about the Client Dev category tells me ‘please see the “Client Problems” category’. But there isn’t a “Client Problems” category.)
I already have several domains, and got certificates with earlier versions of certbot.
Now I want to add another domain, so the first step was just to do, as root:
apt-get update
apt-get upgrade
certbot-auto

  • to let it upgrade itself if necessary. I’m not even trying to add the new domain yet.
    Resulting output:
    Bootstrapping dependencies for Debian-based OSes… (you can skip this with --no-bootstrap)
    Ign http://ftp.debian.org jessie InRelease
    Hit http://ftp.debian.org jessie-updates InRelease
    Hit http://ftp.debian.org jessie-backports InRelease
    Hit http://ftp.debian.org jessie Release.gpg
    Hit http://ftp.debian.org jessie Release
    Get:1 http://ftp.debian.org jessie-updates/main amd64 Packages/DiffIndex [11.8 kB]
    Hit http://ftp.debian.org jessie-updates/contrib amd64 Packages
    Get:2 http://ftp.debian.org jessie-updates/non-free amd64 Packages/DiffIndex [736 B]
    Hit http://ftp.debian.org jessie-updates/contrib Translation-en
    Get:3 http://ftp.debian.org jessie-updates/main Translation-en/DiffIndex [3688 B]
    Get:4 http://ftp.debian.org jessie-updates/non-free Translation-en/DiffIndex [736 B]
    Get:5 http://ftp.debian.org jessie-backports/main amd64 Packages/DiffIndex [27.8 kB]
    Get:6 http://ftp.debian.org jessie-backports/main Translation-en/DiffIndex [27.8 kB]
    Hit http://ftp.debian.org jessie/main amd64 Packages
    Hit http://ftp.debian.org jessie/contrib amd64 Packages
    Hit http://ftp.debian.org jessie/non-free amd64 Packages
    Hit http://ftp.debian.org jessie/contrib Translation-en
    Hit http://ftp.debian.org jessie/main Translation-en
    Hit http://ftp.debian.org jessie/non-free Translation-en
    Hit http://security.debian.org jessie/updates InRelease
    Hit http://security.debian.org jessie/updates/main amd64 Packages
    Hit http://security.debian.org jessie/updates/contrib amd64 Packages
    Hit http://security.debian.org jessie/updates/non-free amd64 Packages
    Hit http://security.debian.org jessie/updates/contrib Translation-en
    Hit http://security.debian.org jessie/updates/main Translation-en
    Hit http://security.debian.org jessie/updates/non-free Translation-en
    Fetched 72.6 kB in 2min 6s (575 B/s)
    Reading package lists… Done
    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    augeas-lenses is already the newest version.
    libaugeas0 is already the newest version.
    ca-certificates is already the newest version.
    gcc is already the newest version.
    libffi-dev is already the newest version.
    python is already the newest version.
    python-dev is already the newest version.
    python-virtualenv is already the newest version.
    virtualenv is already the newest version.
    libssl-dev is already the newest version.
    openssl is already the newest version.
    0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
    Creating virtual environment…
    Installing Python packages…
    This hangs. When I ctrl-C out of it, the first few lines of the traceback are:
    ^CTraceback (most recent call last):
    File “/tmp/tmp.YumJ6Yaqo1/pipstrap.py”, line 184, in
    exit(main())
    File “/tmp/tmp.YumJ6Yaqo1/pipstrap.py”, line 165, in main
    for path, digest in PACKAGES]
    File “/tmp/tmp.YumJ6Yaqo1/pipstrap.py”, line 120, in hashed_download
    response = opener(using_https=parsed_url.scheme == ‘https’).open(url)
    File “/usr/lib/python2.7/urllib2.py”, line 437, in open
    response = meth(req, response)
    File “/usr/lib/python2.7/urllib2.py”, line 550, in http_response
    ‘http’, request, response, code, msg, hdrs)
    File “/usr/lib/python2.7/urllib2.py”, line 469, in error
    result = self._call_chain(*args)
    File “/usr/lib/python2.7/urllib2.py”, line 409, in _call_chain
    result = func(*args)
    File “/usr/lib/python2.7/urllib2.py”, line 656, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
    File “/usr/lib/python2.7/urllib2.py”, line 431, in open
    response = self._open(req, data)

A very similar result was reported by a user of a different version of Debian in the Help category.

2

Thanks for pointing this out! I just fixed that text and moved your post to the right area.

Certbot-auto was running the Python package installer pip, and pip was downloading files from the Internet (or at least trying to) when you cancelled it.

Did you try it again, in case there a was temporary network issue?

Is it possible that there is some sort of outbound firewall interfering with pip's Internet access?

Do you have any trouble downloading large files from pypi outside Python? e.g.

curl -O https://files.pythonhosted.org/packages/10/ce/fc69d9ab5b375104b651745bedc72b8645ae038705ea25626db17dc75b14/numpy-1.14.3-cp34-cp34m-manylinux1_x86_64.whl
1 Like
3

Did you try it again, in case there a was temporary network issue?
Not only that, but other users have reported exactly the same problem, as I pointed out. See https://community.letsencrypt.org/t/certbot-auto-fails-on-debian-wheezy-hangs-on-installing-python-packages/61061/4 This is no "temporary network issue" affecting one user.

Do you have any trouble downloading large files from pypi outside Python? e.g.
No, none whatsoever. After I installed curl, the line you suggested executed successfully, downloading the 12MB file in a couple of seconds.

1 Like
4

If the computer has broken IPv6 connectivity, the Python download would probably hang for a long time -- perhaps forever -- but curl falls back to IPv4 quickly.

curl -v would show what it's doing.

An IPv6 outage would also explain the Debian update download time.

2 Likes
5

curl -v indeed showed that it tried ipv6 first, then switched to ipv4. So I think you are right, it’s an IPv6 configuration problem, not a certbot-auto problem.
A search for “debian ipv6” finds a lot of Debian users who have IPv6 problems, and one popular solution seems to be to give up, and disable IPv6 altogether, which seems shortsighted. Debian obviously supports IPv6, it’s just a matter of finding out how to configure it.

Whatever: this isn’t a letsencrypt problem, it’s a Debian configuration problem, and I’ll seek a solution in a more appropriate place. Thanks for your comments.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.