mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-11 22:30:44 +01:00
letsencrypt.sh on CentOS 5 doesn't see curl #32
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @danb35 on GitHub (Jan 15, 2016).
I've pulled a copy of the letsencrypt.sh script from github earlier today on my CentOS 5-based system (SME Server 8.2; see contribs.org). I've created a config.sh and a domains.txt file. But when I run letsencrypt.sh, I get this:
[root@sme8-test letsencrypt.sh]# ./letsencrypt.sh -c
ERROR: This script requires curl.
curl is installed and is in $PATH:
[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 ~]# which curl
/usr/bin/curl
So I figured I'd comment out the line in letsencrypt.sh that checks for curl and run it again. That didn't work at all:
[root@sme8-test bin]# letsencrypt.sh -c
INFO: Using config file /etc/letsencrypt.sh/config.sh
Generating account key...
sed: invalid option -- E
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
-n, --quiet, --silent
suppress automatic printing of pattern space
-e script, --expression=script
add the script to the commands to be executed
-f script-file, --file=script-file
add the contents of script-file to the commands to be executed
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if extension supplied)
-c, --copy
use copy instead of rename when shuffling files in -i mode
(avoids change of input file ownership)
-l N, --line-length=N
specify the desired line-wrap length for the `l' command
--posix
disable all GNU extensions.
-r, --regexp-extended
use extended regular expressions in the script.
-s, --separate
consider files as separate rather than as a single continuous
long stream.
-u, --unbuffered
load minimal amounts of data from the input files and flush
the output buffers more often
--help display this help and exit
--version output version information and exit
If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret. All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.
E-mail bug reports to: bonzini@gnu.org .
Be sure to include the word
sed'' somewhere in theSubject:'' field.sed: invalid option -- E
Usage: sed [OPTION]... {script-only-if-no-other-script} [input-file]...
-n, --quiet, --silent
suppress automatic printing of pattern space
-e script, --expression=script
add the script to the commands to be executed
-f script-file, --file=script-file
add the contents of script-file to the commands to be executed
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if extension supplied)
-c, --copy
use copy instead of rename when shuffling files in -i mode
(avoids change of input file ownership)
-l N, --line-length=N
specify the desired line-wrap length for the `l' command
--posix
disable all GNU extensions.
-r, --regexp-extended
use extended regular expressions in the script.
-s, --separate
consider files as separate rather than as a single continuous
long stream.
-u, --unbuffered
load minimal amounts of data from the input files and flush
the output buffers more often
--help display this help and exit
--version output version information and exit
If no -e, --expression, -f, or --file option is given, then the first
non-option argument is taken as the sed script to interpret. All
remaining arguments are names of input files; if no input files are
specified, then the standard input is read.
E-mail bug reports to: bonzini@gnu.org .
Be sure to include the word
sed'' somewhere in theSubject:'' field.Details:
{"type":"urn:acme:error:serverInternal","status":500}[root@sme8-test bin]#
I'm not sure what to try from here--thoughts?
@lukas2511 commented on GitHub (Jan 15, 2016):
Mh, looks like your
sedversion 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
63ab72a521.Unfortunately I kinda need to use that option to get support for BSD and GNU versions of
sedat 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... Doescurl -Vreturn with an exit-code != 0 on your system? That seems a bit odd.@danb35 commented on GitHub (Jan 15, 2016):
[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 commented on GitHub (Jan 15, 2016):
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
sedfrom source, place it anywhere you like and set thePATHenvironment variable for letsencrypt.sh to use this location.@reetp commented on GitHub (Jan 15, 2016):
Re sed please see my comment
63ab72a521 (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 commented on GitHub (Jan 16, 2016):
sed -rdoesn't work on BSD versions ofsedwhilesed -Eworks on both GNU and BSD versions, at least on newer versions of both.@reetp commented on GitHub (Jan 16, 2016):
Not on the one we are using, and we can't change that ! RHEL/CentOS 5 is still there and supported.
@reetp commented on GitHub (Jan 16, 2016):
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 commented on GitHub (Jan 16, 2016):
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 commented on GitHub (Jan 16, 2016):
or enable a hook via
config.sh?@danb35 commented on GitHub (Jan 16, 2016):
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 commented on GitHub (Jan 16, 2016):
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 commented on GitHub (Jan 16, 2016):
I'm working on the sed issue, about the curl issue i'll see later...
@lukas2511 commented on GitHub (Jan 16, 2016):
The sed issue should be fixed
f7c7d8c599@lukas2511 commented on GitHub (Jan 16, 2016):
The curl issue should also be fixed
0af7f388d6@danb35 commented on GitHub (Jan 16, 2016):
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 commented on GitHub (Jan 16, 2016):
Moved OSTYPE check (was executed after dependency-checks) in
c3c9ff4c75, try again.@danb35 commented on GitHub (Jan 16, 2016):
It now runs without giving an error--no time to test extensively at the moment though.
@reetp commented on GitHub (Jan 16, 2016):
Thanks Lukas !