Bootstrap error running letsencrypt-auto on Centos5 server, cause not specified


#1

After running ./letsencrypt-auto I get:
[root@server letsencrypt]# ./letsencrypt-auto
Bootstrapping dependencies for RedHat-based OSes…
yum is /usr/bin/yum
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile

  • base: mirror.lug.udel.edu
  • epel: mirror.cogentco.com
  • extras: mirror.cogentco.com
  • ius: iad.mirror.rackspace.com
  • rpmforge: mirror.us.leaseweb.net
  • updates: mirror.atlanticmetro.net
    Excluding Packages in global exclude list
    Finished
    Setting up Install Process
    Package python-2.4.3-56.el5.x86_64 already installed and latest version
    Package python-devel-2.4.3-56.el5.x86_64 already installed and latest version
    Package python-devel-2.4.3-56.el5.i386 already installed and latest version
    Package 1:python-virtualenv-1.7.2-2.el5.noarch already installed and latest version
    Package python-tools-2.4.3-56.el5.x86_64 already installed and latest version
    No package python-pip available.
    Nothing to do
    Loaded plugins: fastestmirror
    Loading mirror speeds from cached hostfile
  • base: reflector.westga.edu
  • epel: mirror.us.leaseweb.net
  • extras: mirror.cogentco.com
  • ius: iad.mirror.rackspace.com
  • rpmforge: mirror.us.leaseweb.net
  • updates: mirror.atlanticmetro.net
    Excluding Packages in global exclude list
    Finished
    Setting up Install Process
    Package gcc-4.1.2-55.el5.x86_64 already installed and latest version
    Package dialog-1.0.20051107-1.2.2.x86_64 already installed and latest version
    Package openssl-devel-0.9.8e-37.el5_11.x86_64 already installed and latest version
    Package openssl-devel-0.9.8e-37.el5_11.i386 already installed and latest version
    Package libffi-devel-3.0.9-1.el5.rf.x86_64 already installed and latest version
    Package redhat-rpm-config-8.0.45-32.el5.centos.noarch already installed and latest version
    No package ca-certificates available.
    Resolving Dependencies
    –> Running transaction check
    —> Package augeas-libs.i386 0:1.2.0-1.el5 set to be updated
    —> Package augeas-libs.x86_64 0:1.2.0-1.el5 set to be updated
    —> Package libffi-devel.i386 0:3.0.5-1.el5 set to be updated
    –> Processing Dependency: libffi = 3.0.5-1.el5 for package: libffi-devel
    –> Processing Dependency: libffi.so.5 for package: libffi-devel
    –> Running transaction check
    —> Package libffi.i386 0:3.0.5-1.el5 set to be updated
    –> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size

Installing:
augeas-libs i386 1.2.0-1.el5 epel 360 k
libffi-devel i386 3.0.5-1.el5 epel 16 k
Updating:
augeas-libs x86_64 1.2.0-1.el5 epel 362 k
Installing for dependencies:
libffi i386 3.0.5-1.el5 epel 21 k

Transaction Summary

Install 3 Package(s)
Upgrade 1 Package(s)

Total size: 759 k
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test

Transaction Check Error:
package libffi-3.0.9-1.el5.rf.x86_64 (which is newer than libffi-3.0.5-1.el5.i386) is already installed
package libffi-devel-3.0.9-1.el5.rf.x86_64 (which is newer than libffi-devel-3.0.5-1.el5.i386) is already installed

Error Summary

Could not install additional dependencies. Aborting bootstrap!
[root@server letsencrypt]#


#2

Could it be this error somewhere in the middle?: No package python-pip available.

I recon it’s one of the dependencies, but not available in your package manager apparently…


#3

That is probably one of the major issues. Also, EL5 had some interesting problems in the x86_64 version with installing i386 packages as well. I don’t recall if that was intended behavior or an actual bug. Either way, based on the errors, that’s part of what’s causing some of the errors.

I have no idea if the official client will run on something with packages so old. Letsencrypt is packaged in EPEL for version 7, but nothing lower. It’s very likely that this is because of dependencies on packages newer than either system is packaging. The auto script works around this by making a virtualenv and installing some newer stuff locally.

The best bet is to first try to manually install the packages that the auto script is attempting. You can manage installation errors a bit better in that case, which will help.

If you’re running into too many issues, some of the community-contributed tools use a lot less dependencies (they manage a lot less) and are more likely to work on older systems.


#4

[root@server letsencrypt]# which pip
/usr/bin/pip
[root@server letsencrypt]#


#5

Do you have any suggestion as to which installer to use instead of letsencrypt-auto? I am no Unix expert and I run an internet radio station on that server, it will take a lot of work to install Shoutcast 2 and Icecast KH on a newer version and get them to work, for which reason I would prefer to avoid it, if possible.
The instructions I read said that it would work on Centos5, it even gave me a script that, although did not work itself, gave me the sources of dependencies to install for Centos5.


#6

I’m a little biased and use bash :wink: if you want to run it on the server itself I’d suggest https://github.com/lukas2511/letsencrypt.sh (which has few dependencies and runs nicely in bash).

Alternatively I’d use https://github.com/srvrco/getssl which is again a simple bash script that can be run on any linux computer and remotely connect ( via ssh) to automate the process - hence relies on nothing more than an ssh connection to the server. ( I wrote this one with the specific purpose of automating deployment on severs where I couldn’t / didn’t want to install anything.

If you want a full list of alternate clients - see List of Client Implementations


#7

Sure, you’ve got pip installed… But that’s not why the le-auto script complains: it’s searching for a package named python-pip… Not for the binary /usr/bin/pip

So if the package is named differently on your setup, things won’t work.

By the way, you can edit the letsencrypt-auto script yourself if you really want to make it work… If you’re confident pip is installed correctly, just delete python-pip from the dependency list :stuck_out_tongue:

Now, you could complain about the above stap with “but this shouldn’t be necessary!”, but remember, the letsencrypt-auto script is even more beta than the client itself… It’s a temporary solution for distributions who don’t yet deliver the Let’s Encrypt client with a package of its own… So… I don’t see just editing the script yourself to suit your needs as a problem :wink: