[jboss-dev-forums] [Clustering Development] New message: "Re: Partition and Node identities"
David Lloyd
do-not-reply at jboss.com
Tue Mar 2 14:30:46 EST 2010
JBoss development,
A new message was posted in the thread "Partition and Node identities":
http://community.jboss.org/message/529464#529464
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> mailto:bstansberry at jboss.com wrote:
> Re: the extra properties; what you say makes sense: jboss.host.qualified.name and jboss.host.name are useful whether or not they end up as part of the server identity.
OK, then pending a final review in jboss-dev I'll plan on setting this up.
> mailto:bstansberry at jboss.com wrote:
>
> A problem with using defaults is the node name leaks outside the data center, and if the default is used that means information about the server configuration is leaking. For example, the node name would become the logical value for the jvmRoute used by mod_jk and mod_cluster, and that ends up being appended to the session id for web sessions, which anyone can look at in a browser.
This is a good point. If we make jvmRoute configurable and default to node.name (yeah, that's a lot of defaulting) then at least it can be "hardened". Alternately, using a short hex- or base64-encoded hash of the node name plus a configurable (cluster-wide?) salt might be workable too. Or some combination thereof? In the meantime we can "punt" the issue and just force manual configuration until/unless a satisfactory solution is found.
> So, defaults are convenient but leak information. Part of my thinking on requiring their configuration once the domain configuration is in place is the inconvenience is less -- you set up your configuration once and re-use it; you don't have to retype -Djboss.node.name=xxx every time.
That seems like a reasonable plan to me. For 6, set up all the properties in bootstrap; for 7, generate them from the domain configuration.
> The previous discussion around this basic topic is at http://community.jboss.org/thread/91830?tstart=60
>
> Besides the use cases listed on that thread, JBossTS also needs a unique integer id for each server on the same host: http://community.jboss.org/thread/145892?start=0&tstart=0
I don't think we can solve the JBossTS case with a node name solution. A hash wouldn't suffice, because administrators may want more direct control over the port and we probably can't avoid collisions in any case. Apart from that, there's not a lot of options for getting from a node name to a port number, let alone an unbound one.
JBM is a similar issue, though it's possible we could get away with a hash in this case. Maybe JBM won't matter though. Not yet sure if HornetQ uses a peer ID of some sort, but I'm inclined to take the same approach: if they use a name *and* the name isn't security sensitive, default to the node name, otherwise, solve later.
Otherwise, everything I'm reading in these other threads indicates that I should be able to move forward with this idea, would you agree?
P.S. I also found http://community.jboss.org/thread/90161?tstart=0
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529464#529464
More information about the jboss-dev-forums
mailing list