[JBoss JIRA] (MODCLUSTER-391) mod_cluster and mod_proxy integration
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-391?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-391:
--------------------------------------
Fix Version/s: 1.2.13.Final
(was: 1.2.12.Final)
> mod_cluster and mod_proxy integration
> -------------------------------------
>
> Key: MODCLUSTER-391
> URL: https://issues.jboss.org/browse/MODCLUSTER-391
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.6.Final
> Environment: All platforms we build mod_cluster for.
> Reporter: Michal Karm Babacek
> Assignee: Jean-Frederic Clere
> Labels: native_libraries
> Fix For: 1.3.3.Final, 1.2.13.Final
>
> Attachments: error_log, mod_cluster.conf, mod_proxy.conf, standalone-ha.xml
>
>
> This Jira encapsulates all concerns regarding mod_cluster - mod_proxy integration. For instance, while basic {{ProxyPass}} settings work just fine, e.g. serving some files on {{/static}} from the Apache HTTP itself:
> {code}
> ProxyPassMatch ^/static/ !
> ProxyPass / balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on
> ProxyPassReverse / balancer://qacluster
> ProxyPreserveHost on
> {code}
> there are more complex setups, involving {{BalancerMember}} configurations, that do not work as expected. In the following example, one wanted to have {{/clusterbench}} application managed by mod_cluster, dynamically, while at the same time, in a different VirtualHost, having {{/tses}} application handled by manually created mod_proxy balancer settings.
> Attached [^mod_cluster.conf], [^mod_proxy.conf], [^standalone-ha.xml](modcluster subsystem element only) and [^error_log].
> The aforementioned setup resulted in:
> |HTTP 200|(From worker)|http://10.16.88.19:8847/clusterbench/requestinfo/|OK|(/)|
> |HTTP 404|(From httpd)|http://10.16.88.19:8847/tses/session.jsp|Expected fail|(/)|
> |HTTP 503|(From httpd)|http://10.16.88.19:2182/tses/session.jsp|Unexpected fail|(x)|
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 12 months
[JBoss JIRA] (MODCLUSTER-401) EnableOptions and SSL configuration
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-401?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-401:
--------------------------------------
Fix Version/s: 1.2.13.Final
(was: 1.2.12.Final)
> EnableOptions and SSL configuration
> -----------------------------------
>
> Key: MODCLUSTER-401
> URL: https://issues.jboss.org/browse/MODCLUSTER-401
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.2.8.Final
> Environment: HP-UX Apache HTTP Server 2.2.15, RHEL Apache HTTP Server 2.2.22, perhaps platform independent...
> Reporter: Michal Karm Babacek
> Assignee: Jean-Frederic Clere
> Fix For: 1.2.13.Final
>
>
> 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.4.11#64026)
7 years, 12 months
[JBoss JIRA] (MODCLUSTER-430) CreateBalancers behave the same with option 0 or 2
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-430?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-430:
--------------------------------------
Fix Version/s: 1.2.13.Final
(was: 1.2.12.Final)
> CreateBalancers behave the same with option 0 or 2
> --------------------------------------------------
>
> Key: MODCLUSTER-430
> URL: https://issues.jboss.org/browse/MODCLUSTER-430
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.3.0.Final, 1.2.9.Final
> Environment: RHEL 6.4.0
> Apache HTTPD 2.4.10
> JBoss 6.1.1
> Mod_cluster 1.3.0 Final
> Reporter: John Jerome
> Assignee: Michal Karm Babacek
> Fix For: 1.3.3.Final, 1.2.13.Final
>
>
> The directive CreateBalancers with directive 0 or 2 creates the balancers on all httpd vhosts.
> With option 2, the balancers should be created on the main server only, not in the vhosts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 12 months
[JBoss JIRA] (MODCLUSTER-463) UpperCase Alias never matches any context
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-463?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-463:
--------------------------------------
Fix Version/s: 1.2.13.Final
(was: 1.2.12.Final)
> UpperCase Alias never matches any context
> -----------------------------------------
>
> Key: MODCLUSTER-463
> URL: https://issues.jboss.org/browse/MODCLUSTER-463
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.11.Final, 1.3.1.Final
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Fix For: 1.3.3.Final, 1.2.13.Final
>
> Attachments: simplecontext-examples.zip
>
>
> h3. Problem
> h4. JBossWeb
> Regardless the upper/lower case of an Alias one configured in _JBossWeb (EAP 6.4.3, mod_cluster subsystem 1.2.11.Final)_, it has always been reported to Apache HTTP Server in lower case. For example, the following configuration:{code:xml}
> <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="workerXXX" native="false">
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> <virtual-server name="web1" default-web-module="simplecontext-web1">
> <alias name="web1.rhel7GAx86-64"/>
> </virtual-server>
> <virtual-server name="web2" default-web-module="simplecontext-web2">
> <alias name="web2.rhel7GAx86-64"/>
> </virtual-server>
> </subsystem>
> {code}sends this message with aliases actually being reported in lower case: {{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7gax86-64&Context=%2F}}. Having {{aliases}} stored in lower case on the Apache HTTP Server side enables both these URLs to work perfectly:{noformat}curl http://web2.rhel7GAx86-64:6666/
> curl http://web2.rhel7gax86-64:6666/{noformat}. The balancer configuration is just a simple [UseAlias 1|http://fpaste.org/251417/86985831/].
> h4. Undertow
> _Undertow (JBossWeb's successor in EAP 7.0.0.DR7, mod_cluster subsystem 1.3.1.Final)_ behaves differently; it reports verbatim what one sets as an alias, so with the following configuration:{code:xml}<subsystem xmlns="urn:jboss:domain:undertow:3.0" instance-id="workerXXX">
> <buffer-cache name="default"/>
> <server name="default-server">
> <ajp-listener name="ajp" socket-binding="ajp"/>
> <http-listener name="default" redirect-socket="https" socket-binding="http"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> <host name="web1" alias="web1.rhel7GAx86-64">
> <location name="/" handler="web1-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> <host name="web2" alias="web2.rhel7GAx86-64">
> <location name="/" handler="web2-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> <websockets/>
> </servlet-container>
> <handlers>
> <file name="web1-content" path="${jboss.home.dir}/simplecontext-web1"/>
> <file name="web2-content" path="${jboss.home.dir}/simplecontext-web2"/>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
> </handlers>
> <filters>
> <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
> <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
> </filters>
> </subsystem>{code}, the message reported to Apache HTTP Server actually is:{{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7GAx86-64&Context=%2F}}. Due to the fact that aliases are being compared byte-by-byte for equality (because pumping of slash characters takes place) and the accessed domain is always in lower case and alias is stored as it was received, there is never match between these.
> The result is that while these work:{{http://web2:6666/}}, {{http://web1:6666/}}, one of the upper case containing ones work at all: {{http://web1.rhel7GAx86-64:6666}} and {{http://web2.rhel7gax86-64:6666/}} neither. By not working I actually mean they return the root of Apache HTTP Server Welcome page instead of correctly forwarding to one of the Application server's virtual host contexts.
> Last but not least, while EAP 6.4.3 with JBossWeb itself treats aliases as case-insensitive, EAP 7.0.0.DR7 with Undertow does not; i.e. {{web1.rhel7GAx86-64:8080/}} returns correctly web application content whereas {{web1.rhel7gax86-64:8080/}} returns EAP7 Welcome page.
> While the aforementioned is clearly a bug (or a weird feature :)) in Undertow, we must make the Apache HTTP Server code resilient to such behaviour.
> h3. Solution
> I suggest converting aliases to lower case in mod_manager on ENABLE-APP arrival. According to my preliminary tests, this approach works for both JBossWeb and Undertow equipped workers. I think it's cool to do that: [RFC 1035|https://tools.ietf.org/html/rfc1035#section-2.3.3].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 12 months
[JBoss JIRA] (MODCLUSTER-458) Add JVMRoute or node identifier to httpd/mod_cluster errors
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-458?page=com.atlassian.jira.pl... ]
Radoslav Husar closed MODCLUSTER-458.
-------------------------------------
Fix Version/s: 1.2.12.Final
Resolution: Done
This made it to 1.2.12.Final release, fixing.
> Add JVMRoute or node identifier to httpd/mod_cluster errors
> -----------------------------------------------------------
>
> Key: MODCLUSTER-458
> URL: https://issues.jboss.org/browse/MODCLUSTER-458
> Project: mod_cluster
> Issue Type: Feature Request
> Components: Native (httpd modules)
> Reporter: Coty Sutherland
> Assignee: Michal Karm Babacek
> Fix For: 1.2.12.Final, 1.3.2.Final
>
>
> Messages such as:
> [Tue Apr 14 10:38:56 2015] [warn] manager_handler STATUS error: MEM: Can't read node
> are very difficult to troubleshoot given the limited context provided. It would be great if we could add some sort of node identifier or the JVMRoute of the node to the message above.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 12 months