Description of problem: I'm trying to use the smart proxy to manage certificates but it is failing using curl: $ curl -vv -k -H "Accept: application/json" https://localhost:8443/puppet/ca * About to connect() to localhost port 8443 (#0) * Trying ::1... Connection refused * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 8443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * warning: ignoring value of ssl.verifyhost * skipping SSL peer certificate verification * NSS: client certificate not found (nickname not specified) * SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA * Server certificate: * subject: CN=foreman2.example.com * start date: Aug 11 21:42:30 2013 GMT * expire date: Aug 11 21:42:30 2018 GMT * common name: foreman2.example.com * issuer: CN=Puppet CA: foreman2.example.com > GET /puppet/ca HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: localhost:8443 > Accept: application/json > < HTTP/1.1 406 Not Acceptable < Content-Type: application/json;charset=utf-8 < Content-Length: 74 < X-Content-Type-Options: nosniff < Server: WEBrick/1.3.1 (Ruby/1.9.3/2013-05-15) OpenSSL/1.0.0 < Date: Thu, 15 Aug 2013 04:47:08 GMT < Connection: Keep-Alive < * Connection #0 to host localhost left intact * Closing connection #0 Failed to list certificates: Execution of puppetca failed, check log files strace tells me: 10833 writev(2, [{"/opt/rh/ruby193/root/usr/bin/ruby", 33}, {": ", 2}, {"error while loading shared libraries", 36}, {": ", 2}, {"libruby.so.1.9", 14}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10) = 147 Version-Release number of selected component (if applicable): ruby193-foreman-proxy-1.1.10001-4.el6ost.noarch
I'm not able to reproduce this in RHOS 4.0 using foreman-proxy-1.3.0-1. The GET works fine there, correctly returning the list of hosts and certs.
Rob, note that we don't use 8443 currently for the proxy, as it conflicted with mod_ssl. We are using port 9090. I ran your above command with localhost:9090 successfully just now against the latest. If you could verify your result is the same perhaps we can close this as not a bug? The config file that shows the port is: /etc/foreman-proxy/settings.yml Look for the lines: # port used by the proxy :port: 9090 The output of running the command is: [root@rhosneutforeman ~]# curl -vv -k -H "Accept: application/json" https://localhost:9090/puppet/ca * About to connect() to localhost port 9090 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 9090 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * warning: ignoring value of ssl.verifyhost * skipping SSL peer certificate verification * NSS: client certificate not found (nickname not specified) * SSL connection using TLS_DHE_RSA_WITH_AES_256_CBC_SHA * Server certificate: * subject: CN=rhosneutforeman.example.com * start date: Dec 16 16:07:21 2013 GMT * expire date: Dec 16 16:07:21 2018 GMT * common name: rhosneutforeman.example.com * issuer: CN=Puppet CA: rhosneutforeman.example.com > GET /puppet/ca HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Host: localhost:9090 > Accept: application/json > < HTTP/1.1 200 OK < Content-Length: 415 < X-Content-Type-Options: nosniff < Server: WEBrick/1.3.1 (Ruby/1.8.7/2011-06-30) OpenSSL/1.0.0 < Date: Tue, 17 Dec 2013 19:12:27 GMT < Content-Type: application/json;charset=utf-8 < Connection: Keep-Alive < * Connection #0 to host localhost left intact * Closing connection #0 {"rhosneutforeman.example.com":{"serial":2,"not_before":"2013-12-16T16:07:21GMT","not_after":"2018-12-16T16:07:21GMT","fingerprint":"SHA256","state":"valid"}, "rhosneutcontroller.example.com":{"serial":6,"not_before":"2013-12-16T18:06:12GMT","not_after":"2018-12-16T18:06:12GMT","fingerprint":"SHA256","state":"valid" },"Puppet":{"serial":1,"not_before":"2013-12-16T16:07:20GMT","not_after":"2018-12-16T16:07:20GMT"}}
I guess it depends. It isn't a bug in RHOS 4 so I'd be ok with closing, but not as NOTABUG since it definitely was a bug in RHOS 3 :-) My output in 4.0 looks similar to yours and yeah, I had to change the port too. I'll let you decide the resolution but I'd prefer CURRENTRELEASE I guess.
Actually looks like CLOSED_CURRENTRELEASE is the right thing to do here.