[mod_cluster-issues] [JBoss JIRA] (MODCLUSTER-401) EnableOptions and SSL configuration
Michal Babacek (JIRA)
issues at jboss.org
Fri May 2 15:47:56 EDT 2014
Michal Babacek created MODCLUSTER-401:
-----------------------------------------
Summary: EnableOptions and SSL configuration
Key: MODCLUSTER-401
URL: https://issues.jboss.org/browse/MODCLUSTER-401
Project: mod_cluster
Issue Type: Bug
Reporter: Michal Babacek
Assignee: Jean-Frederic Clere
As a follow up on MODCLUSTER-400 and a documentation effort for *EnableOptions* logic, I tried to add {{EnableOptions}} to the configuration so as to allow for a "cping/cpong" emulation of the famous AJP feature.
With the following {{mod_cluster.conf / httpd.conf}} (standalone-ha.xml being the same as in MODCLUSTER-400's description):
{code}
+++
Listen 10.16.92.191:2081
+++
MemManagerFile "/hell/workspace/hpws22/apache/cache/mod_cluster"
ServerName 10.16.92.191:2081
<IfModule manager_module>
Listen 10.16.92.191:8745
LogLevel debug
<VirtualHost 10.16.92.191:8745>
ServerName 10.16.92.191:8745
<Directory />
Order deny,allow
Deny from all
Allow from all
</Directory>
KeepAliveTimeout 60
MaxKeepAliveRequests 0
ServerAdvertise on
AdvertiseFrequency 5
ManagerBalancerName qacluster
AdvertiseGroup 224.0.3.47:23364
EnableOptions
EnableMCPMReceive
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
SSLHonorCipherOrder on
SSLCertificateFile /vault/server.crt
SSLCertificateKeyFile /vault/server.key
SSLCACertificateFile /vault/myca.crt
SSLProxyEngine On
SSLVerifyDepth 10
<Location /mcm>
SetHandler mod_cluster-manager
Order deny,allow
Deny from all
Allow from all
</Location>
</VirtualHost>
</IfModule>
{code}
one gets this [^hp-ux_error_log-EnableOptions.zip] log:
{code}
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received HTTP/1.1 200 OK
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Server: Apache-Coyote/1.1
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Content-Length: 0
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Date: Fri, 02 May 2014 17:22:46 GMT
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Connection: close
[debug] mod_proxy_cluster.c(1239): http_cping_cpong: Done
[debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191)
[debug] mod_manager.c(2666): manager_handler STATUS OK
[debug] proxy_util.c(2029): proxy: https: has acquired connection for (10.16.92.191)
[debug] proxy_util.c(2085): proxy: connecting https://10.16.92.191:8645/ to 10.16.92.191:8645
[debug] proxy_util.c(2211): proxy: connected / to 10.16.92.191:8645
[debug] proxy_util.c(2462): proxy: https: fam 2 socket created to connect to 10.16.92.191
[debug] mod_proxy_cluster.c(1384): proxy_cluster_try_pingpong: connected to backend
[error] [client 10.16.92.191] SSL Proxy requested for 10.16.92.191:2081 but not enabled [Hint: SSLProxyEngine]
[error] proxy: https: failed to enable ssl support for 10.16.92.191:8645 (10.16.92.191)
[debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191)
{code}
Why is the JBoss EAP residing on {{10.16.92.191:8645}} trying to request SSL Proxy on the virtual host {{10.16.92.191:2081}}? The result is {{Status: NOTOK}} on mod_cluser manager console.
I tried to remove that {{10.16.92.191:2081}}, so as the {{10.16.92.191:8745}} is the only one ([^hp-ux_error_log-EnableOptions-single-vhost.zip]):
{code}
- Listen 10.16.92.191:2081
- ServerName 10.16.92.191:2081
{code}
The result is a funny trial to request a proxy for the boxe's actual hostname and port 80 *no one* (netstat) is even listening on:
{code}
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received HTTP/1.1 200 OK
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Server: Apache-Coyote/1.1
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Content-Length: 0
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Date: Fri, 02 May 2014 17:39:33 GMT
[debug] mod_proxy_cluster.c(1223): http_cping_cpong: received Connection: close
[debug] mod_proxy_cluster.c(1239): http_cping_cpong: Done
[debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191)
[debug] mod_manager.c(2666): manager_handler STATUS OK
[debug] proxy_util.c(2029): proxy: https: has acquired connection for (10.16.92.191)
[debug] proxy_util.c(2085): proxy: connecting https://10.16.92.191:8645/ to 10.16.92.191:8645
[debug] proxy_util.c(2211): proxy: connected / to 10.16.92.191:8645
[debug] proxy_util.c(2462): proxy: https: fam 2 socket created to connect to 10.16.92.191
[debug] mod_proxy_cluster.c(1384): proxy_cluster_try_pingpong: connected to backend
[error] [client 10.16.92.191] SSL Proxy requested for eap-perf-hpux-03.mw.lab.eng.bos.redhat.com:80 but not enabled [Hint: SSLProxyEngine]
[error] proxy: https: failed to enable ssl support for 10.16.92.191:8645 (10.16.92.191)
[debug] proxy_util.c(2047): proxy: https: has released connection for (10.16.92.191)
{code}
I tried to add: {{RequestHeader set Front-End-Https "On"}} to the configuration without any luck.
Finally, I replicated the SSL configuration *outside* the VirtualHost:
{code}
MemManagerFile "/hell/workspace/hpws22/apache/cache/mod_cluster"
Listen 10.16.92.191:2081
ServerName 10.16.92.191:2081
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !S RP !DSS"
SSLHonorCipherOrder on
SSLCertificateFile /vault/server.crt
SSLCertificateKeyFile /vault/server.key
SSLCACertificateFile /vault/myca.crt
SSLProxyEngine On
SSLVerifyDepth 10
<IfModule manager_module>
+++ the same as above +++
</IfModule>
{code}
This configuration fixed the aforementioned {{failed to enable ssl support}} *and* actually helped to workaround the MODCLUSTER-400: (log: [^hp-ux_error_log-EnableOptions-SSL_everywhere.zip])
{code}
Fri, May 2, 2014 02:23:44 PM Request URI: /clusterbench/requestinfo
Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive}
Host header: 10.16.92.191:8645
Character encoding: null
JVM route: jboss-eap-6.3-2
Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2
Session isNew: false
Fri, May 2, 2014 02:23:47 PM Request URI: /clusterbench/requestinfo
Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive}
Host header: 10.16.92.191:8645
Character encoding: null
JVM route: jboss-eap-6.3-2
Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2
Session isNew: false
-- stop jboss-eap-6.3-2 -- (the same behavior with jvm kill) --
Fri, May 2, 2014 02:23:50 PM Request URI: /clusterbench/requestinfo
Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive}
Host header: 10.16.92.191:8544
Character encoding: null
JVM route: jboss-eap-6.3
Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3
Session isNew: false
Fri, May 2, 2014 02:23:53 PM Request URI: /clusterbench/requestinfo
Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive}
Host header: 10.16.92.191:8544
Character encoding: null
JVM route: jboss-eap-6.3
Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3
Session isNew: false
Fri, May 2, 2014 02:23:56 PM Request URI: /clusterbench/requestinfo
Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive}
Host header: 10.16.92.191:8544
Character encoding: null
JVM route: jboss-eap-6.3
Session ID: 2hC9ax9LGYDvQZtH0RXdBimf.jboss-eap-6.3
Session isNew: false
{code}
Why isn't the {{10.16.92.191:8745}} enough? Is it a configuration error or a ProxyPass/SSL integration bug?
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
More information about the mod_cluster-issues
mailing list