-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We handle deployment to our servers as follows:
We have 8 servers total 2 dev (cas dev use only), 2 test (developer
dev/test), 2 stage (development stage), 2 prod (self explainitory). I
set an environment variable (TIER) on each tier appropriately, an
Our institution's ¢2:
We currently use the Maven 2 overlay, but have opted to modify the pom.xml and
add a few properties files to allow for multiple environments. This is done via
enabling a particular build profile that would filter multiple environment
specific variables accordingly.
We als
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
STOP READING MY SOURCE CODE.
Ok, it's open source, so carry on -- in fact, I would like to share.
I did not like using localhost for the services console, so I made the
following changes:
cas.securityContext.serviceProperties.service=${protocol.htt
On Wed, May 5, 2010 at 1:01 PM, Marvin Addison wrote:
> >> No. The host.name property is used in at least a couple of places and
> >> should be the valid FQDN of the server.
> >
> > It shouldn't be. We always named ours cas1 and cas2 :-)
>
> You're right. I grepped through the source and the on
Ah...ok I got ya...yeah I don't like creating extra files just to have extra
files unless there is a purpose...creating another file inside the war
doesn't make sense to me but reading the value in from something outside the
app does.
On Wed, May 5, 2010 at 12:02 PM, Scott Battaglia
wrote:
> If y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'll second this.
Marvin Addison wrote:
>> The benefit of the method described in the Clustering docs is that you pull
>> the configuration out of the war file, and make it host specific, and you
>> can roll the same war file to all servers in the cl
If you're using Maven2 WAR Overlay and you want to modify the value, you
would need to place a copy of the file in your overlay and edit that (which
is what I meant by new version).
Alternatives include changing the id generators to read that value from
somewhere else (as someone pointed out). At
>> No. The host.name property is used in at least a couple of places and
>> should be the valid FQDN of the server.
>
> It shouldn't be. We always named ours cas1 and cas2 :-)
You're right. I grepped through the source and the only configuration
references deal with ticket ID:
cas-server-webap
> The benefit of the method described in the Clustering docs is that you pull
> the configuration out of the war file, and make it host specific, and you
> can roll the same war file to all servers in the cluster.
+1 for this approach. We are _very_ happy using a single deployable
across 6 server
Marvin, I'm referring to the wiki page you referenced at
http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS and the section
"Guaranteeing Ticket Uniqueness" ...it seems like I should be able to
include the cas.properties in my maven overlay and update the value here
instead of creating a new f
Scott, shouldn't this file be part of my maven overlay anyway since it is
here that I would need to configure the services stuff?
On Wed, May 5, 2010 at 10:44 AM, Scott Battaglia
wrote:
> On Wed, May 5, 2010 at 11:36 AM, Curtis Garman wrote:
>
>> Marvin, do you mean the host.name in the cas.prope
On Wed, May 5, 2010 at 11:45 AM, Marvin Addison wrote:
>
>
> No. The host.name property is used in at least a couple of places and
> should be the valid FQDN of the server.
>
It shouldn't be. We always named ours cas1 and cas2 :-)
>
> M
>
> --
> You are currently subscribed to cas-user@list
On Wed, May 5, 2010 at 11:36 AM, Curtis Garman wrote:
> Marvin, do you mean the host.name in the cas.properties file? It looked
> like the documentation wanted you to create a whole new properties file and
> such (even for cas 3.3.5). Isn't it as easy as editing the default value of
> the host.nam
The benefit of the method described in the Clustering docs is that you
pull the configuration out of the war file, and make it host specific,
and you can roll the same war file to all servers in the cluster.
If in cas.properties, you need custom war files per server. (The var
name doesn't matter
> do you mean the host.name in the cas.properties file?
Yes. I was citing from memory, which is clearly hazy.
> It looked like
> the documentation wanted you to create a whole new properties file and such
> (even for cas 3.3.5).
What documentation are you referring to?
> Isn't it as easy as ed
Marvin, do you mean the host.name in the cas.properties file? It looked like
the documentation wanted you to create a whole new properties file and such
(even for cas 3.3.5). Isn't it as easy as editing the default value of the
host.name property already defined? Also, am I correct in assuming that
> Has anyone used CAS in multiple server environments?
I think lots of folks are doing HA CAS. We are.
> What keeps the tokens unique?
The server.name parameter in the cas.properties file. That string is
appended to the end of the service ticket by default to further
guarantee globally unique
Hi CAS users list,
Has anyone used CAS in multiple server environments? Like where you have more
than one CAS server? What keeps the tokens unique? And on the other hand, is
there any good articles on mutiple CA servers using the same token (high
availability).
Thanks in advance,
Jeremy
Jeremy
18 matches
Mail list logo
