June 2014 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-421) Document LoadModule mod_cluster_slotmem.so change

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-421: ----------------------------------------- Summary: Document LoadModule mod_cluster_slotmem.so change Key: MODCLUSTER-421 URL: https://issues.jboss.org/browse/MODCLUSTER-421 Project: mod_cluster Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Documentation & Demos Affects Versions: 1.3.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar #LoadModule slotmem_module /opt/jboss/httpd/lib/httpd/modules/mod_slotmem.so LoadModule cluster_slotmem_module /opt/jboss/httpd/lib/httpd/modules/mod_cluster_slotmem.so That change is need for httpd-2.4.x which brings a different mod_slotmem.so than the one mod_cluster is using. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-420) Consider dropping support for very old versions of httpd

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-420?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-420: ------------------------------------------------ Actually for master (1.3.x) it might make sense to drop httpd.2.2.x support the code would be a lot simpler. > Consider dropping support for very old versions of httpd > -------------------------------------------------------- > > Key: MODCLUSTER-420 > URL: https://issues.jboss.org/browse/MODCLUSTER-420 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Native (httpd modules) > Affects Versions: 1.3.0.Final > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > > The EWS is built on 2.2.24 and further on when productizing modcluster, this version might even increase. Lets consider dropping older versions prior to this one. > If the decision is made, you can assign to me to remove the support. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-420) Consider dropping support for very old versions of httpd

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-420: ----------------------------------------- Summary: Consider dropping support for very old versions of httpd Key: MODCLUSTER-420 URL: https://issues.jboss.org/browse/MODCLUSTER-420 Project: mod_cluster Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Native (httpd modules) Affects Versions: 1.3.0.Final Reporter: Radoslav Husar Assignee: Jean-Frederic Clere The EWS is built on 2.2.24 and further on when productizing modcluster, this version might even increase. Lets consider dropping older versions prior to this one. If the decision is made, you can assign to me to remove the support. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-54) Use slotmems from httpd-trunk

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-54?page=com.atlassian.jira.plu... ] Radoslav Husar commented on MODCLUSTER-54: ------------------------------------------ We could maybe open this issue to community contributors? Since in 2.4 it is shipped by default IIUC. Do we know what are the main differences or is that a whole lot different API? > Use slotmems from httpd-trunk > ----------------------------- > > Key: MODCLUSTER-54 > URL: https://issues.jboss.org/browse/MODCLUSTER-54 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Native (httpd modules) > Environment: mod_cluster httpd-trunk > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Priority: Minor > > My old code of httpd-proxy-scoreboard has been moved to httpd-trunk we should stop using our own "forked" version of slotmems. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-54) Use slotmems from httpd-trunk

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-54?page=com.atlassian.jira.plu... ] Radoslav Husar updated MODCLUSTER-54: ------------------------------------- Component/s: Native (httpd modules) > Use slotmems from httpd-trunk > ----------------------------- > > Key: MODCLUSTER-54 > URL: https://issues.jboss.org/browse/MODCLUSTER-54 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Native (httpd modules) > Environment: mod_cluster httpd-trunk > Reporter: Jean-Frederic Clere > Assignee: Jean-Frederic Clere > Priority: Minor > > My old code of httpd-proxy-scoreboard has been moved to httpd-trunk we should stop using our own "forked" version of slotmems. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-404) ModClusterService stop commands are always draining sessions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-404?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-404: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1098576|https://bugzilla.redhat.com/show_bug.cgi?id=1098576] from ON_QA to VERIFIED > ModClusterService stop commands are always draining sessions > ------------------------------------------------------------ > > Key: MODCLUSTER-404 > URL: https://issues.jboss.org/browse/MODCLUSTER-404 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Final, 1.2.9.Final > > > Using the ModClusterService stop or stopContext commands via CLI always fails to move a context to the STOPPED state after failing to drain the active sessions. So these commands then aren't very useful for quickly stopping the context when desired if you can't do it without draining. > I think it'd make sense for any draining done by manual stops to also follow the session draining strategy used by typical stops from undeploy events. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-235) Support hot-standby worker nodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-235?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-235: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 987259|https://bugzilla.redhat.com/show_bug.cgi?id=987259] from ON_QA to ASSIGNED > Support hot-standby worker nodes > -------------------------------- > > Key: MODCLUSTER-235 > URL: https://issues.jboss.org/browse/MODCLUSTER-235 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.1.2.Final > Reporter: Samuel Mendenhall > Assignee: Jean-Frederic Clere > > Like in mod_proxy and mod_jk, mod_cluster should support the ability to keep a worker node in hot-standby. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-391) mod_cluster and mod_proxy integration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-391?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-391: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 987259|https://bugzilla.redhat.com/show_bug.cgi?id=987259] from ON_QA to ASSIGNED > mod_cluster and mod_proxy integration > ------------------------------------- > > Key: MODCLUSTER-391 > URL: https://issues.jboss.org/browse/MODCLUSTER-391 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.2.6.Final > Environment: All platforms we build mod_cluster for. > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Labels: native_libraries > Fix For: 1.3.1.Final, 1.2.10.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.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-417) Obfuscating jvmRoute as to hide topology

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-417?page=com.atlassian.jira.pl... ] Radoslav Husar edited comment on MODCLUSTER-417 at 6/18/14 8:42 AM: -------------------------------------------------------------------- Hm, I am afraid it is not going to help with WildFly 8 and above anyway. If you proceed as an attacker such as: # create a request, remember the session id (somehow including the obfuscated route) # let the http session expire # spawn DOS attack with the same session id but since LB has no idea that is has already expired, it will be *always* routed to the same node # the node is going to create a new session and use key affinity service so that the session is local to that node # you can use all the new created sessions knowing they are all routed to the same node anyway # to DOS multiple different nodes at once, you can do the same and observe response rate degradation So the suggested approach is probably not going to help at all. was (Author: rhusar): Hm, I am afraid it is not going to help with WildFly 8 and above anyway. If you proceed as an attacker such as: # create a request, remember the session id (somehow including the obfuscated route) # let the http session expire # spawn DOS attack with the same session id but since LB has no idea that is has already expired, it will be *always* routed to the same node # the node is going to create a new session and use key affinity service so that the session is local to that node So the suggested approach is probably not going to help at all. > Obfuscating jvmRoute as to hide topology > ---------------------------------------- > > Key: MODCLUSTER-417 > URL: https://issues.jboss.org/browse/MODCLUSTER-417 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Native (httpd modules) > Affects Versions: 1.3.0.Final, 1.2.9.Final > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Priority: Minor > > Feature request from https://github.com/jmcabrera > Hello guys. > First of all, this is a feature request and not a bug. > I would like to "obfuscate" the jvmRoute so that an external attacker cannot "guess" the topology of my internal infrastructure. > The "strong" way would be to have a symmetrical cipher with a configurable key. > mod_cluster could then cipher the jsessionid before exposing it to the external world, and decipher it to recover the jvmRoute and properly redirect the request. > But I guess that this would have very undesirable consequences on performance. > The "weak" way would be just obfuscate, i.e. let's say that the jsessionid is alea + '.' + jvmRoute. We could take a part of the alea to alter the jvmroute in a reversible way (XORing for instance). > Anyhow, the expected effect would be that the jvmroute would be externally different for each and every request. > Unfortunately, I have close to no C skills, hence I cannot make this myself. > (as a side note, coming from mod_jk, I'm quite impressed by the features mod_cluster offers! Thanks for the good work :) ) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-417) Obfuscating jvmRoute as to hide topology

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-417?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-417: ------------------------------------------- Hm, I am afraid it is not going to help with WildFly 8 and above anyway. If you proceed as an attacker such as: # create a request, remember the session id (somehow including the obfuscated route) # let the http session expire # spawn DOS attack with the same session id but since LB has no idea that is has already expired, it will be *always* routed to the same node # the node is going to create a new session and use key affinity service so that the session is local to that node So the suggested approach is probably not going to help at all. > Obfuscating jvmRoute as to hide topology > ---------------------------------------- > > Key: MODCLUSTER-417 > URL: https://issues.jboss.org/browse/MODCLUSTER-417 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Native (httpd modules) > Affects Versions: 1.3.0.Final, 1.2.9.Final > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Priority: Minor > > Feature request from https://github.com/jmcabrera > Hello guys. > First of all, this is a feature request and not a bug. > I would like to "obfuscate" the jvmRoute so that an external attacker cannot "guess" the topology of my internal infrastructure. > The "strong" way would be to have a symmetrical cipher with a configurable key. > mod_cluster could then cipher the jsessionid before exposing it to the external world, and decipher it to recover the jvmRoute and properly redirect the request. > But I guess that this would have very undesirable consequences on performance. > The "weak" way would be just obfuscate, i.e. let's say that the jsessionid is alea + '.' + jvmRoute. We could take a part of the alea to alter the jvmroute in a reversible way (XORing for instance). > Anyhow, the expected effect would be that the jvmroute would be externally different for each and every request. > Unfortunately, I have close to no C skills, hence I cannot make this myself. > (as a side note, coming from mod_jk, I'm quite impressed by the features mod_cluster offers! Thanks for the good work :) ) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues June 2014