letsencrypt.sh on CentOS 5 doesn't see curl

[dehydrated-io]

letsencrypt.sh on CentOS 5 doesn't see curl

[lukas2511]

Mh, looks like your sed version is too old to support the -E (Interpret regular expressions as extended (modern) regular expressions rather than basic regular expressions (BRE's).) option.
I added that option to the scripts dependency checks in 63ab72a.

Unfortunately I kinda need to use that option to get support for BSD and GNU versions of sed at the same time without duplicate code all over the place...

I'd suggest getting a newer version of sed. About the curl problem... I don't really understand why the check fails... Does curl -V return with an exit-code != 0 on your system? That seems a bit odd.

[danb35]

[root@sme8-test ~]# curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
[root@sme8-test ~]# echo $?
2
[root@sme8-test ~]#

I'll see if there's a well-supported way to update sed. This system has GNU sed version 4.1.5; a CentOS 6 system (which does work) has GNU sed 4.2.1.

[lukas2511]

Exit code 2 should be given if the initialization of libcurl failed, which should never happen on just asking for the version... i could probably build a workaround for this, but this seems weird.

You could just build sed from source, place it anywhere you like and set the PATH environment variable for letsencrypt.sh to use this location.

[reetp]

Re sed please see my comment 63ab72a#commitcomment-15485814

sed should be -E OR -r

-E is not a normal switch - http://blog.dmitryleskov.com/small-hacks/mysterious-gnu-sed-option-e/

If I swap to -r it works perfectly well.

No idea on the curl issue but if you hash out the check it works.

[lukas2511]

sed -r doesn't work on BSD versions of sed while sed -E works on both GNU and BSD versions, at least on newer versions of both.

[reetp]

Not on the one we are using, and we can't change that ! RHEL/CentOS 5 is still there and supported.

[reetp]

I was trying to figure if I could rewrite this a bit but this is way beyond my primitive bash skills.

I believe the issue lies with the way that set -e handles error codes.

On the version of sed being used 4.1.5 I get the following results

sed -r "" < /dev/null
echo $?
0

sed -E "" < /dev/null
echo $?
4

But quite clearly this version of sed does support extended regular expressions (as shown if we look at sed -r) so the error checking is at fault.

My guess there is a similar issue with curl - on CentOS 5 it gives a result of 2 but on CentOS 6 it results in 0. If the checks are removed the script functions as expected.

[danb35]

If the issue is that some versions of sed require the -r flag, and others require the -E flag, wouldn't it be possible (perhaps in the compatibility check section) to determine which (if any) is the appropriate flag for the version installed on the system on which the script is running, set a variable to contain that flag, and then call sed using "sed $SED_OPTS" rather than "sed -E"?

[mro]

or enable a hook via config.sh?

[danb35]

Since SME8 is customized in a number of ways, I installed a clean CentOS 5 system to test curl. Same thing:
[dan@pc-00226 ~]$ curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
[dan@pc-00226 ~]$ echo $?
2

Since RHEL5/CentOS5 is still an actively supported OS, it would be good to deal with this.

On sed, it looks like sed -E is called twice in the script. Surely there's a way of dealing with -r instead?

[danb35]

I note that what I thought was one issue (le.sh doesn't see curl) is actually two--le.sh doesn't see curl in CentOS 5, and le.sh uses sed -E, which isn't available in CentOS 5. Would it be beneficial to open a second issue for sed?

[lukas2511]

I'm working on the sed issue, about the curl issue i'll see later...

[lukas2511]

The sed issue should be fixed f7c7d8c

[lukas2511]

The curl issue should also be fixed 0af7f38

[danb35]

I'm afraid that didn't fix it:
[root@sme8-test letsencrypt.sh]# ./letsencrypt.sh
ERROR: This script requires sed with support for extended (modern) regular expressions.
[root@sme8-test ~]# uname
Linux

[lukas2511]

Moved OSTYPE check (was executed after dependency-checks) in c3c9ff4, try again.

[danb35]

It now runs without giving an error--no time to test extensively at the moment though.

[reetp]

Thanks Lukas !