July 2014 - mod_cluster-issues - Jboss List Archives

[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 resolved MODCLUSTER-417. --------------------------------------- Resolution: Rejected > 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)

9 years, 9 months

1
0
0 / 0

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

by Juan Manuel CABRERA (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-417?page=com.atlassian.jira.pl... ] Juan Manuel CABRERA commented on MODCLUSTER-417: ------------------------------------------------ Hello guys, and thanks for the detailed answers. I'm sorry for the late reply, I was very busy lately (work/home/holidays). Anyhow, I get your points, and hence I too end up thinking that this would not be a very helpful feature in the end... Kind regards, Juan Manuel > 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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-423) Proxy configuration to allow a desired address/interface to be specified for the AS side of the proxy connection

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-423?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-423: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/102 > Proxy configuration to allow a desired address/interface to be specified for the AS side of the proxy connection > ---------------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-423 > URL: https://issues.jboss.org/browse/MODCLUSTER-423 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core & Container Integration (Java) > Affects Versions: 1.3.0.Final, 1.2.9.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final, 1.2.10.Final > > > See > https://bugzilla.redhat.com/show_bug.cgi?id=954017 > https://issues.jboss.org/browse/WFLY-457 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-423) Proxy configuration to allow a desired address/interface to be specified for the AS side of the proxy connection

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-423?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-423: -------------------------------------- Summary: Proxy configuration to allow a desired address/interface to be specified for the AS side of the proxy connection (was: Proxy configuration to allow a desired address/interface to be specified for the Jboss side of the proxy connection) > Proxy configuration to allow a desired address/interface to be specified for the AS side of the proxy connection > ---------------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-423 > URL: https://issues.jboss.org/browse/MODCLUSTER-423 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core & Container Integration (Java) > Affects Versions: 1.3.0.Final, 1.2.9.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final, 1.2.10.Final > > > See > https://bugzilla.redhat.com/show_bug.cgi?id=954017 > https://issues.jboss.org/browse/WFLY-457 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-423) Proxy configuration to allow a desired address/interface to be specified for the Jboss side of the proxy connection

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-423?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-423: -------------------------------------- Description: See https://bugzilla.redhat.com/show_bug.cgi?id=954017 https://issues.jboss.org/browse/WFLY-457 was: https://bugzilla.redhat.com/show_bug.cgi?id=954017 > Proxy configuration to allow a desired address/interface to be specified for the Jboss side of the proxy connection > ------------------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-423 > URL: https://issues.jboss.org/browse/MODCLUSTER-423 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core & Container Integration (Java) > Affects Versions: 1.3.0.Final, 1.2.9.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final, 1.2.10.Final > > > See > https://bugzilla.redhat.com/show_bug.cgi?id=954017 > https://issues.jboss.org/browse/WFLY-457 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-423) Proxy configuration to allow a desired address/interface to be specified for the Jboss side of the proxy connection

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-423: ----------------------------------------- Summary: Proxy configuration to allow a desired address/interface to be specified for the Jboss side of the proxy connection Key: MODCLUSTER-423 URL: https://issues.jboss.org/browse/MODCLUSTER-423 Project: mod_cluster Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Core & Container Integration (Java) Affects Versions: 1.2.9.Final, 1.3.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 1.3.1.Final, 1.2.10.Final https://bugzilla.redhat.com/show_bug.cgi?id=954017 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-220) Extra ENABLE-APP/REMOVE-APP event after failover

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-220?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-220: ------------------------------------------------ https://github.com/modcluster/mod_cluster/commit/ba331d8060a8adb785149feb... the fix.for MOD_CLUSTER_1_0_10_GA_CP > Extra ENABLE-APP/REMOVE-APP event after failover > ------------------------------------------------ > > Key: MODCLUSTER-220 > URL: https://issues.jboss.org/browse/MODCLUSTER-220 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.0.8, 1.0.10, MOD_CLUSTER_1_0_10_GA_CP01, 1.1.2.Final > Environment: Deployment on Tomcat6 > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Fix For: MOD_CLUSTER_1_0_10_GA_CP02, 1.1.3.Final > > > I think there is an extra REMOVE-APP event happening after fail-over. The test scenario is simple - start a node with 6 context, kill the node and reconnect. The apps are unchanged but 5 are remembered as were and one is removed and added back? Since they happen at the same time it looks like it happens uselessly and can cause race condition. > {code} > 127.0.0.1 - - [04/Apr/2011:19:18:34 +0200] "INFO / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:18:34 +0200] "CONFIG / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:18:34 +0200] "ENABLE-APP / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:18:34 +0200] "ENABLE-APP / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:18:34 +0200] "ENABLE-APP / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:18:34 +0200] "ENABLE-APP / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:18:34 +0200] "ENABLE-APP / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:18:34 +0200] "ENABLE-APP / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:18:34 +0200] "STATUS / HTTP/1.0" 200 58 "-" "ClusterListener/1.0" > ... > 127.0.0.1 - - [04/Apr/2011:19:19:03 +0200] "GET /SessionTest/SessionTestServlet? HTTP/1.1" 200 1 "-" "Jakarta Commons-HttpClient/3.1" > ... > 127.0.0.1 - - [04/Apr/2011:19:20:44 +0200] "INFO / HTTP/1.0" 200 575 "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:20:44 +0200] "CONFIG / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:20:44 +0200] "ENABLE-APP / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:20:44 +0200] "REMOVE-APP / HTTP/1.0" 200 - "-" "ClusterListener/1.0" > 127.0.0.1 - - [04/Apr/2011:19:20:44 +0200] "STATUS / HTTP/1.0" 200 58 "-" "ClusterListener/1.0" > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 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 VERIFIED > 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)

9 years, 9 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 VERIFIED > 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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-398) mod_cluster deadlock in a jboss/windows environment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-398?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated MODCLUSTER-398: ----------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1080047, https://bugzilla.redhat.com/show_bug.cgi?id=1120466 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1080047) > mod_cluster deadlock in a jboss/windows environment > --------------------------------------------------- > > Key: MODCLUSTER-398 > URL: https://issues.jboss.org/browse/MODCLUSTER-398 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.2.6.Final > Environment: Windows 2008, EAP6 and EWS2.0.1 > Reporter: Marc Maurer > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Final, 1.2.9.Final > > > Under load Apache stops serving pages, with all threads are stuck in "W : Sending reply" state. With the windows Process Explorer we then got a stacktrace from a hanging thread. We don't have debug symbols, but it's easy enough to see what's happening: > ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a > ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x732 > ntoskrnl.exe!KeWaitForMutexObject+0x19f > ntoskrnl.exe!NtDeleteFile+0x3c4 > ntoskrnl.exe!PsDereferenceKernelStack+0x35358 > ntoskrnl.exe!KeSynchronizeExecution+0x3a23 > ntdll.dll!ZwLockFile+0xa > KERNELBASE.dll!LockFileEx+0xb2 > kernel32.dll!LockFileEx+0x1b > libapr-1.dll!apr_file_lock+0x69 <-- here > mod_slotmem.so+0x1318 <-- here > mod_manager.so+0x2a11 <-- here > mod_proxy_cluster.so+0x679e > mod_proxy.so!proxy_run_post_request+0x4e > mod_proxy.so!proxy_run_request_status+0x924 > libhttpd.dll!ap_run_handler+0x35 > libhttpd.dll!ap_invoke_handler+0x114 > libhttpd.dll!ap_die+0x2ea > libhttpd.dll!ap_psignature+0x1ae8 > libhttpd.dll!ap_run_process_connection+0x35 > libhttpd.dll!ap_process_connection+0x3b > libhttpd.dll!ap_regkey_value_remove+0x136e > msvcrt.dll!srand+0x93 > msvcrt.dll!ftime64_s+0x1dd > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > So mod_manager is requesting a filelock on one of the lockfiles in in the MemManagerFile path. In this case it was the "manager.sessionid.sessionid.lock" file. Removing the lockfile fixed the problem. > When bisecting the mod_cluster code, I think commit "74eeb9c026380deb8d833be53b09b3d808e02d10 - Lock in insert-update" in version 1.2.2 is the culprit. This would also explain why mod_cluster 1.2.1 is the last known working version. > What we don't know, is which process is already holding the lock when all Apache threads start blocking on it. We are trying to figure that out. There are no obviously wrong lock/unlock slotmem call pairs in the mod_manager module, and no locks are requested within other locks as far as we can see. Therefor our best guess would be a deadlock on a thread already holding the globalmutex_lock in combination with the slotmem file locks, but that's just a guess without debugging it. > More context can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1080047 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues July 2014