I downloaded letsencrypt (using git) at /opt/letsencrypt. Then tried ./letsencrypt_auto per document.
This appears to attempt to downgrade my python install, then gives up with “could not install python dependencies”. My server has:
Package python-2.7.5-34.el7.x86_64 already installed and latest version
Package python-libs-2.7.5-34.el7.x86_64 already installed and latest version
What else do I need to run letsencrypt certonly --webroot?
maybe related https://github.com/certbot/certbot/issues/2921
I do think this is related to our other issue (at #2921 on GitHub), but I’m wondering why we have so many people using our client successfully on CentOS and are only now starting to get this Python package conflict issue.
@schoen the letsencrypt-auto code for detecting and installing python has changed compared to earlier versions of the script see CentOS python-tools conflict · Issue #2921 · certbot/certbot · GitHub
The real answer to my question (What else do I need?) appears to be in one of your posts on the related topic. Mainly, it appears I need (at least) “python-pip”. No such yum package exists on any yum repo currently set up on my system. Therefore, no matter how many times, or in what fashion, letsencrypt using yum to find pip is a non-starter.
Early this morning, I learned what pip is. No, I am not expert in python. (I have never used python and as of this minute have no python script anywhere on my system, except possibly in the python installation itself)
I am not new to computers. In fact, I have no doubt at all that I was programming computers before anyone on this forum was even born, and the personal variety since they existed, and have run a series of LAMP servers since that notion existed. And Centos servers since about 2003, if memory serves. Whatever. I ran Fedora systems before that.
The authors of letsencrypt need to understand that not everyone is knee deep in python, and that flavors of linux exist other than Debian.
I have now spent the better part of a day trying to even understand how to reliably install pip in RHEL 7 of any flavor. Google eventually helped.
Wherefore art thou python-pip?
led me to:
http://python-packaging-user-guide.readthedocs.io/en/latest/install_requirements_linux/
which led me to instructions on fedoraproject dot org (having to fight link limits as a newbie in these parts)
which instructed me to try:
yum install epel-release
which resulted in:
Package epel-release-7-6.noarch already installed and latest version
But, as instructed by fedoraproject, I also tried
yum install /var/tmp/yum-root-uUHFbh/epel-release-latest-7.noarch.rpm
which resulted in:
Examining /var/tmp/yum-root-uUHFbh/epel-release-latest-7.noarch.rpm: epel-release-7-6.noarch
/var/tmp/yum-root-uUHFbh/epel-release-latest-7.noarch.rpm: does not update installed package.
Error: Nothing to do
And I then tried (as instructed):
yum install python-pip
which begat:
Loaded plugins: fastestmirror
base | 3.6 kB 00:00:00
centosplus | 3.4 kB 00:00:00
extras | 3.4 kB 00:00:00
updates | 3.4 kB 00:00:00
Loading mirror speeds from cached hostfile
Exasperation setting in at that point. Have lunch and ponder results.
Finally, while trying to find out why there is no epel-release repo in yum.repos.d, despite yum resolutely insisting that epel-release is in fact an installed repo on my system, I have learned from a different web page that EPEL is in fact now included in the Centos Base repo under the heading [extras].
Or, so it is claimed. That would seem to be the explanation as to why yum’s insistence the epel-release repo is installed.
Therefore, I finally conclude (until someone reliably explains to me how to install the repo that constains it into Centos 7) that there is no Centos 7 compatible yum package named “python-pip”.
However: Another page found via googling (located at a VPS provider that I don’t use, http://www.liquidweb.com/kb/how-to-install-pip-on-centos-7/) provides instructions for a different way to install pip on Centos 7 that actually works for my installation. To wit:
curl “https://bootstrap.pypa.io/get-pip.py” -o "get-pip.py"
python get-pip.py
pip -V
which results in
pip 8.1.1 from /usr/lib/python2.7/site-packages (python 2.7)
WHEW! pip is finally installed and appears to work (at least trivially).
Sometime this week, perhaps I will eventually have letsencrypt working. However, I shudder at the maintenance nightmare that letsencrypt presents on my distro. There are reasons I chose Centos over other linux distros. Eas of maintenance and stability rank at the top of that list. At this point I sincerely doubt letsencrypt in its present form will remain installed on my system.
Why don’t they simply state that letsencrypt is nice little package for python devotees on Debian?
There are lots of alternative clients, many of which are much more lightweight than the official one. I use letsencrypt.sh, but acme.sh also seems to be popular. Both of those are pretty light on system requirements.
That is not the case - the client works well on recent versions of CentOS. There are some problems with CentOS 6 when certain python packages are preinstalled, but I don't think this applies to CentOS 7.
No package python-pip available. is expected output on CentOS 7. There's no need to install that package.
Could you provide the full output of your ./letsencrypt-auto run, i.e. everything before could not install python dependencies? I feel like that's where the actual error is hiding.
@pfg:
After completing all essential “real work” this morning, I started over from scratch with a complete new install of letsencrypt (using git clone http…). Except this time I installed as a subfolder of /root instead of /opt. Again, probably not significant.
Abbreviated story version:
“letsencrypt-auto” worked this time, without any hitch!
I haven’t tried to run any actual tests against it yet. First I want to look at configuring options. I have no stomach at all for the fully automated version due to my very custom apache VirtualHost setups. Therefore, I settled on the certonly --webroot approach as the closest thing to automation I care to attempt.
I can’t provide the output from my previous install that you requested, simply because the xterm console history on my Win7 desktop wrapped (several times) since then. (It was set for only 300 lines, which I increased to 1000 today.) The bash history on the server doesn’t record any command output so that is no help. If letsencrypt-auto writes its own log under its main folder that is also gone because I completely wiped the letsencrypt folder yesterday in anticipation of starting over from scratch. The (perhaps) good news on that score is this time I did capture and save the entire output of letsencrypt-auto.
A somewhat longer story of the reinstall follows. It may or may not help to understand the issue reported yesterday.
Preliminary note: One thing I neglected to mention yesterday is my VPS runs on a KVM base. It is pretty much like a standalone server, with full root access. Probably not anything your script would have any problem with, but wanted to mention this for completeness.
(1) I cleaned up etc/yum.repos.d/ yesterday to make sure no issues there. (Got rid of two repos that no longer exist, replacing one of them that moved to new location, commented all baseurl that pointed to my VPS provider’s mirror cache. Made sure I have all “normal” Centos repos present.) I sincerely doubt any of that was to blame, but who knows? The cleanup happened after the letesencrypt failures.
(2) I did a yum update this morning, just in case your script might have dependencies on particular package versions. (I normally apply only security updates unless something has an issue.) The result of the update:
(a) Centos-release.x86_64 was updated
old: 7-1.1503.el7.centos.2.8
new: 7-2.1511.el7.centos.2.10
(b) 78 packages in all were updated, but most were very minor updates.
© A few python-related packages were updated.
(3) I left the python installation alone (as updated), including the pip code I installed yesterday outside the yum framework.
(4) Before reinstalling letsencrypt, I rebooted to make sure all services were running the newest code.
This time, there was looooong pause while letsetsencrypt-auto checked the python installation. In fact, so long I began to wonder if it was hung. It eventually determined it needed to install two packages:
…
Installed:
python-devel.x86_64 0:2.7.5-34.el7
python-virtualenv.noarch 0:1.10.1-2.el7
Then:
…
Installed:
augeas-libs.x86_64 0:1.4.0-2.el7
dialog.x86_64 0:1.2-4.20130523.el7
gcc.x86_64 0:4.8.5-4.el7
libffi-devel.x86_64 0:3.0.13-16.el7
redhat-rpm-config.noarch 0:9.1.0-68.el7.centos
Then:
…
Dependency Installed:
cpp.x86_64 0:4.8.5-4.el7
dwz.x86_64 0:0.11-3.el7
libmpc.x86_64 0:1.0.1-3.el7
mpfr.x86_64 0:3.1.1-4.el7
perl-srpm-macros.noarch 0:1-8.el7
zip.x86_64 0:3.0-10.el7
And finally:
…
Package 1:mod_ssl-2.4.6-40.el7.centos.x86_64 already installed and latest version
Nothing to do
Checking for new version…
Creating virtual environment…
Installing Python packages…
Installation succeeded.
Requesting root privileges to run letsencrypt…
/root/.local/share/letsencrypt/bin/letsencrypt --help
…
[quote=“danb35, post:6, topic:15523, full:true”]
There are lots of alternative clients, many of which are much more lightweight than the official one. I use letsencrypt.sh, but acme.sh also seems to be popular. Both of those are pretty light on system requirements.
[/quote] Noted. I will definitely look into those.