[JBoss JIRA] (MODCLUSTER-459) mod_cluster subsystem remains silent if connector set to http
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-459?page=com.atlassian.jira.pl... ]
Michal Babacek moved JBEAP-224 to MODCLUSTER-459:
-------------------------------------------------
Project: mod_cluster (was: JBoss Enterprise Application Platform)
Key: MODCLUSTER-459 (was: JBEAP-224)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 1.3.1.Final
(was: EAP 7.0.0.DR2)
Fix Version/s: 1.3.2.Alpha1
(was: EAP 7.0.0.DR3)
Target Release: (was: EAP 7.0.0.GA)
> mod_cluster subsystem remains silent if connector set to http
> -------------------------------------------------------------
>
> Key: MODCLUSTER-459
> URL: https://issues.jboss.org/browse/MODCLUSTER-459
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.3.1.Final
> Reporter: Michal Babacek
> Assignee: Paul Ferraro
> Fix For: 1.3.2.Alpha1
>
>
> If one sets mod_cluster subsystem {{connector="http"}} there is nothing in the log about any mod_cluster subsystem being initialized, no warning, nothing. It appears to be dead silent even with log level DEBUG.
> When switched back to {{connector="ajp"}}, there are the well known comforting messages:
> {noformat}
> INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000001: Initializing mod_cluster version 1.3.1.Final
> INFO [org.jboss.modcluster] (ServerService Thread Pool -- 62) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
> {noformat}
> Weird. Any obvious misconfiguration or explanation? The config is the default standalone-ha.xml otherwise.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (MODCLUSTER-458) Add JVMRoute or node identifier to httpd/mod_cluster errors
by Coty Sutherland (JIRA)
Coty Sutherland created MODCLUSTER-458:
------------------------------------------
Summary: 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: Jean-Frederic Clere
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.3.15#6346)
9 years, 6 months
[JBoss JIRA] (MODCLUSTER-457) Tomcat mod_cluster integration does not allow one to choose a connector
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-457?page=com.atlassian.jira.pl... ]
Michal Babacek moved JWS-114 to MODCLUSTER-457:
-----------------------------------------------
Project: mod_cluster (was: JBoss Web Server)
Key: MODCLUSTER-457 (was: JWS-114)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 1.3.1.Final
1.2.11.Final
(was: JWS 3.0.0 ER2.1)
Component/s: Core & Container Integration (Java)
(was: mod_cluster)
Fix Version/s: 1.3.2.Alpha1
(was: JWS 3.0.1)
> Tomcat mod_cluster integration does not allow one to choose a connector
> -----------------------------------------------------------------------
>
> Key: MODCLUSTER-457
> URL: https://issues.jboss.org/browse/MODCLUSTER-457
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.1.Final, 1.2.11.Final
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Fix For: 1.3.2.Alpha1
>
>
> Configuring mod_cluster to leverage {{ws://}} with {{EnableWsTunnel}} (mod_proxy_wstunnel) requires the Tomcat to use *http* instead of *ajp* connector.
> Unlike [AS7/WildFly/EAP|https://github.com/wildfly/wildfly/blob/master/mod_cluste...] mod_cluster integration, the Tomcat one ignores such option, i.e. there is nothing about selecting a particular connector with a *connector* attribute in [mbeans-descriptors.xml|https://github.com/modcluster/mod_cluster/blob/b3a...].
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener"
> loadMetricClass="org.jboss.modcluster.load.metric.impl.BusyConnectorsLoadMetric"
> loadMetricCapacity="1" loadHistory="9" loadDecayFactor="2" stickySession="true"
> stickySessionForce="false" stickySessionRemove="true" advertise="true"
> {color:red}*connector="http"*{color} advertiseGroupAddress="224.0.5.12" advertisePort="61217"
> />
> Suggestion: Let's add the option to the catalina integration as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 6 months
[JBoss JIRA] (MODCLUSTER-453) It is possible to inject JavaScript into mod_cluster manager console via MCMP messages
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-453?page=com.atlassian.jira.pl... ]
Michal Babacek commented on MODCLUSTER-453:
-------------------------------------------
This is public now. [CVE-2015-0298|https://access.redhat.com/security/cve/CVE-2015-0298]
> It is possible to inject JavaScript into mod_cluster manager console via MCMP messages
> --------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-453
> URL: https://issues.jboss.org/browse/MODCLUSTER-453
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.6.Final, 1.2.9.Final, 1.2.11.Final, 1.3.1.Beta2
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.3.2.Alpha1
>
> Attachments: MODCLUSTER-453_master-better_one.patch, MODCLUSTER-453_master-mbabacek.patch, MODCLUSTER-453_master-offensive_approach.patch, patch.new.best.patch, patch.new.txt, patch.txt
>
>
> This is a nasty one indeed :-)
> h3. Steps to reproduce
> * start Apache HTTP Server with mod_cluster
> * send these messages (provided you test instance listens on 127.0.0.1)
> {code}
> { echo "CONFIG / HTTP/1.1"; echo "Host: localhost.localdomain:6666"; echo "Content-Length: 95"; echo "User-Agent: Prdel"; echo ""; echo "JVMRoute=fake-1&Ho5t=127.0.0.1&Maxattempts=1&Port=8009&StickySessionForce=No&Type=ajp&ping=10"; sleep 1;} | telnet 127.0.0.1 6666
> { echo "ENABLE-APP / HTTP/1.1"; echo "Host: localhost.localdomain:6666"; echo "Content-Length: 102"; echo "User-Agent: ClusterListener%2F1.0"; echo ""; echo 'JVMRoute%3Dfake-1%26Alias%3Ddefault-host%26Context%3D%2FX%3Cscript%3Ealert(%27X%27)%3B%3C%2Fscript%3E'; sleep 1;} | telnet 127.0.0.1 6666
> {code}
> * Open http://localhost:6666/mod_cluster_manager and enjoy JavaScript pop-up Alert being executed.
> h3. Impact
> * Anyone with access to the (hopefully only internal) network from which MCMP messages are allowed to come from could send these messages and execute arbitrary JavaScript code.
> h3. Suggestion
> * Leverage {{apr_escape*}} to sanitize MCMP messages.
> h3. Proposed patch
> * [^patch.new.best.patch]: MCMP messages containing suspicious characters are discarded.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (MODCLUSTER-453) It is possible to inject JavaScript into mod_cluster manager console via MCMP messages
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-453?page=com.atlassian.jira.pl... ]
Michal Babacek updated MODCLUSTER-453:
--------------------------------------
Security: (was: Security Issue)
> It is possible to inject JavaScript into mod_cluster manager console via MCMP messages
> --------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-453
> URL: https://issues.jboss.org/browse/MODCLUSTER-453
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.2.6.Final, 1.2.9.Final, 1.2.11.Final, 1.3.1.Beta2
> Reporter: Michal Babacek
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.3.2.Alpha1
>
> Attachments: MODCLUSTER-453_master-better_one.patch, MODCLUSTER-453_master-mbabacek.patch, MODCLUSTER-453_master-offensive_approach.patch, patch.new.best.patch, patch.new.txt, patch.txt
>
>
> This is a nasty one indeed :-)
> h3. Steps to reproduce
> * start Apache HTTP Server with mod_cluster
> * send these messages (provided you test instance listens on 127.0.0.1)
> {code}
> { echo "CONFIG / HTTP/1.1"; echo "Host: localhost.localdomain:6666"; echo "Content-Length: 95"; echo "User-Agent: Prdel"; echo ""; echo "JVMRoute=fake-1&Ho5t=127.0.0.1&Maxattempts=1&Port=8009&StickySessionForce=No&Type=ajp&ping=10"; sleep 1;} | telnet 127.0.0.1 6666
> { echo "ENABLE-APP / HTTP/1.1"; echo "Host: localhost.localdomain:6666"; echo "Content-Length: 102"; echo "User-Agent: ClusterListener%2F1.0"; echo ""; echo 'JVMRoute%3Dfake-1%26Alias%3Ddefault-host%26Context%3D%2FX%3Cscript%3Ealert(%27X%27)%3B%3C%2Fscript%3E'; sleep 1;} | telnet 127.0.0.1 6666
> {code}
> * Open http://localhost:6666/mod_cluster_manager and enjoy JavaScript pop-up Alert being executed.
> h3. Impact
> * Anyone with access to the (hopefully only internal) network from which MCMP messages are allowed to come from could send these messages and execute arbitrary JavaScript code.
> h3. Suggestion
> * Leverage {{apr_escape*}} to sanitize MCMP messages.
> h3. Proposed patch
> * [^patch.new.best.patch]: MCMP messages containing suspicious characters are discarded.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (MODCLUSTER-449) Implement ramp-up when starting new nodes
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-449?page=com.atlassian.jira.pl... ]
Radoslav Husar commented on MODCLUSTER-449:
-------------------------------------------
[~casele], that does not really fix the problem since it cannot be reasonably combined with other metrics. It could mitigate the problem, but this is not the proper fix. Though, you can surely create a repo on github and post a link.
> Implement ramp-up when starting new nodes
> -----------------------------------------
>
> Key: MODCLUSTER-449
> URL: https://issues.jboss.org/browse/MODCLUSTER-449
> Project: mod_cluster
> Issue Type: Feature Request
> Components: Core & Container Integration (Java)
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 1.3.2.Alpha1
>
>
> IIUC this has been a problem since inception. The problem is that the initial load stays in effect for performing load-balancing decisions until a new stat interval kicks in.
> This effect is mitigated by load decay over time, but for the time a new node joins in, it can get overloaded upon startup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (MODCLUSTER-449) Implement ramp-up when starting new nodes
by Casey Lee (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-449?page=com.atlassian.jira.pl... ]
Casey Lee commented on MODCLUSTER-449:
--------------------------------------
I've developed a new load metric that has a "warm up" period where the capacity starts at 0 and then grows linearly to the true capacity over a configurable number of seconds (default 120). Would this be something you'd be interested in me submitted a pull request for?
> Implement ramp-up when starting new nodes
> -----------------------------------------
>
> Key: MODCLUSTER-449
> URL: https://issues.jboss.org/browse/MODCLUSTER-449
> Project: mod_cluster
> Issue Type: Feature Request
> Components: Core & Container Integration (Java)
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 1.3.2.Alpha1
>
>
> IIUC this has been a problem since inception. The problem is that the initial load stays in effect for performing load-balancing decisions until a new stat interval kicks in.
> This effect is mitigated by load decay over time, but for the time a new node joins in, it can get overloaded upon startup.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months