civetweb defaults to libssl.so and libcrypto.so when versions not passed
Hit this on our performance test box when attempting to test civetweb with SSL using fedora20 packages of hammer from gitbuilder.
[nhm@burnupiX log]$ ceph --version ceph version 0.93-186-g836fdc5 (836fdc512dcae6724c72e52cb84ee2a364f0d261)
RGW section from ceph.conf:
[client.radosgw.gateway] host = burnupiX rgw frontends = civetweb port=443s ssl_certificate=/home/nhm/tmp/server.pem keyring = /tmp/cbt/ceph/keyring rgw socket path = /tmp/cbt/ceph/radosgw.sock log file = /tmp/cbt/ceph/radosgw.log debug rgw = 0 admin socket = /tmp/cbt/ceph/radosgw.asok
2015-03-25 18:29:43.536944 7fdbb7ba5940 0 starting handler: civetweb 2015-03-25 18:29:43.537221 7fdbb7ba5940 0 civetweb: 0xa8d820: load_dll: cannot load libssl.so 2015-03-25 18:29:43.537319 7fdbb7ba5940 0 civetweb: 0xa8d820: load_dll: cannot load libcrypto.so
#if !defined(SSL_LIB) #define SSL_LIB "libssl.so" #endif #if !defined(CRYPTO_LIB) #define CRYPTO_LIB "libcrypto.so" #endif
Normally these are passed via the makefile:
#2 Updated by Tim Serong about 2 years ago
It should work if you create a couple of symlinks:
# ln -s /lib64/libssl.so.1.0.0 /usr/lib64/libssl.so # ln -s /lib64/libcrypto.so.1.0.0 /usr/lib64/libcrypto.so
Also, turns out the
strict_strtoll error is purely cosmetic, i.e. it doesn't actually break anything (and, indeed, the 's' is necessary to enable SSL).
The libssl.so and libcrypto.so symlinks will be present if the openssl devel package is installed, BTW, but I'm guessing requiring this is undesirable.
#5 Updated by Russell Islam over 1 year ago
Any idea on the flowing bug?
[root@ceph-us-west tls]# radosgw-admin realm pull --url=https://ceph-us-east-1:443 --access-key=$SYSTEM_ACCESS_KEY --secret=$SYSTEM_SECRET_KEY
request failed: (22) Invalid argument
2016-07-11 15:35:30.360412 7fc7a20099c0 0 curl_easy_perform returned error: Peer's certificate issuer has been marked as not trusted by the user.
#11 Updated by Marcus Watts 12 months ago
I've updated https://github.com/ceph/ceph/pull/11571
It now needs to be applied after https://github.com/ceph/civetweb/pull/14 which contains a necessary change to civetweb.
This version of the fix will not complain about 443s, and will allow multiple ports, such as "80+443s" or "8000+8443s" or etc. It also works with s3 v4 and with swift preauth.