Shibboleth Developers

[Chad La Joie <>]

Scott Cantor wrote:
> > I need some advice on some thing.  The current configuration file for 
> > the intra-node replication mechanism is a bear, and I'm unsure how to 
> > make it easier.
>
>
> It's multi-cast, so like the Tomcat cluster stuff (which doesn't work
> reliably, BTW, I hope this does ;-) it can't really get much better.

It need not be multicast, TCP is supported too. While my experience with 
this has been that the multicast has been reliable I'd probably 
recommend TCP for production environments, though, because I believe 
it's more secure.

> > One thought I had was to put an element for each bit 
> > configuration data in the idp.xml NameMapping element (which I'd then 
> > read and use in the code) but I'm not sure I like that, I think it might 
> > be to confusing or cluttered.
>
>
> I think it depends because what you really have is a shared configuration
> between the NameMapper and ArtifactMapper plugins for handling the
> multicast, but then specific configuration that applies to each.
>
> If this was something supported in idp.xml itself, you'd want to create a
> separate element for the cluster config, and then reference it (or maybe
> not, since there'd only be one) in the plugin elements. Without that
> top-level support, I don't know how you could really do it, but I guess I'd
> maybe expect the cluster config to be in a separate file, at the very least,
> since it would be shared.

Yeah, actually I had thought about this when I started coding a month or 
so ago, but then forgot it when I wrote the note.  :)

> > Anyways, please take a look at the 
> > Configuring HA Shib, in the following document, and give me some 
> > feedback on what you'd like to see if you were deploying this at your 
> > university.
>
>
> What does the eviction timeout mean exactly? Is this the actual ttl for the
> mappings themselves in memory? If so, your example for handles seems low. It
> should match whatever handleTTL is set to, right?

Yep, it's the TTL of the in-memory data and yes it should be the same as 
(or I suppose greater than would be fine) the handleTTL.

> Also a JBoss question...if I'm using TCP, I assume the clustering system
> handles nodes that go down and then reinstates them when they reappear? In
> other words, do I need to reconfigure everything to take a machine down for
> maintanence or can I just let it drop out and then reappear?

Yeah, it deals with this just fine.  It picks up nodes that are down and 
ones that come back up.  The only thing the multicast does is allow for 
detection of nodes that have never been seen before.  With the TCP stuff 
you define the IPs of the nodes in the cluster and so if you want to add 
a new one you have to add the IP to the list, with UDP you just bring it 
up and put it on the same mulitcast address and it just joins the 
cluster (which is the exact reason I think it's a minor security risk).

Also, while my example file shows each node having the IP of every node 
this is, in fact, not needed.  There just has to be a path to each node. 
 So if A has B's address and B has the address for C and D then A can 
replicate to C and D.  If B goes down everything continues to work fine, 
and any new nodes that come up and have A, C, and/or D's address will 
join the cluster just fine.  If, however, a node comes up that only has 
B's address it will assume it's the first node in the cluster, since it 
can't find anyone else.  This will lead to the load balancing errors we 
see now with a client going from one node to another and state being 
missing.  The configuration file I have out there though does configure 
a service that resolves everything once B comes up (and the graph of 
nodes is thus navigable)  So, this is why I suggest you place each nodes 
IP address in every node's config.  It's not like the list should change 
all that often.  (Sorry for the very long winded side track there.)

--
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124