Hello I will keep this in mind, but I am talking about different servers serving different functions, so it is not clustered. We have not implemented clustering, because at this point, CAS seems to be efficient and powerful enough to manage all the service requests coming to it, and in fact, appears to be waiting for client responses.
We do have failover implemented on production. What prompted the move to clustering for your environment? Linda Linda Toth University of Alaska - Office of Information Technology (OIT) - Identity and Access Management 910 Yukon Drive, Suite 103 907-450-8320 Fairbanks, Alaska 99775 [email protected] | www.alaska.edu/oit/ On Wed, Nov 6, 2013 at 1:25 PM, Danner, Mearl <[email protected]> wrote: > I’ve successfully moved all configuration parameters to /etc/cas for CAS > 3.5.2 (clustered behind a load balancer). It also uses an LDAP service > registry in openldap replicated between CAS nodes. Authentication is to > Active Directory. > > > > /etc/cas > > > > cas.properties – customize host.name for each node > > ehcache.xml – If replicated alter the rmiurls to point to the other node > > log4j.xml – set cas log path to /var/log/cas – make sure tomcat has > permissions to write > > attributes.properties – replaces the resultAttributeMapping map in the > attributeRepository bean. > > > > <LDAP attribute>=<CAS Attribute> > > > > cn=CN > > memberOf=Groups > > givenName=FirstName > > sn=LastName > > displayName=FullName > > > > I made up my own property names. If there is a convention for naming > properties in cas.properties please share and I’ll adjust mine. > > > > I was able to deploy the same cas.war on two cluster nodes using this > configuration. > > > > I’ll look into selection 2. That will keep the cas.properties file the > same for each node. > > > > > > Mearl Danner > > Senior Systems Programmer > > Samford University Technology Services > > http://www.samford.edu > > > > *From:* Misagh Moayyed [mailto:[email protected]] > *Sent:* Wednesday, November 06, 2013 8:39 AM > *To:* [email protected] > *Subject:* RE: [cas-user] Simple question re: global properties for CAS > > > > 1) That is a fair assumption. > > > > 2) As a first step, you’ll need to externalize the location of the > cas.properties file so it’s not embedded inside the CAS web application. > Take a look at this [1] please to see how that might be done. You might > also be able to take advantage of this extension [2] if you have CAS > deployed on multiple nodes. > > > > [1] https://github.com/Unicon/unicon-cas-overlay > > [2] > https://github.com/Unicon/cas-addons/wiki/Ticket-ID-generator-based-on-host-name > > > > -Misagh > > *From:* Linda Toth [mailto:[email protected] <[email protected]>] > *Sent:* Tuesday, November 05, 2013 3:26 PM > *To:* [email protected] > *Subject:* [cas-user] Simple question re: global properties for CAS > > > > Hello > > > > This seems implied by what I read, but I have found nothing specific, so > it is worth checking; my understanding on the order in which XML file > properties are loaded into the CAS configuration needs work .. > > > > I want to use a property to define the hostname in one place for each CAS > instance we have, which is translated across all files referring to a > specific server (cas.properties, protocol_view.properties, and > uniqueIdGenerator.xml). I have been assuming that the cas.properties file > is read first into the environment at load time so that all other > references to ${host.name} adhere to the definition in cas.properties. > Is that an accurate assumption? > > > > We have several instances of CAS across several testing and back up > environments and I would love to make changes to the cas.properties as the > only place where a host name is changed. Further along those lines, I > would like to be able to define registry DB connections, the CAS admin > user/password, and LDAP connections in the same file, so the > deployerConfigContext.xml file does not need to be altered. > > > > Linda > > > > -- > > Linda Toth > University of Alaska - Office of Information Technology (OIT) - Identity > and Access Management > > 910 Yukon Drive, Suite 103 > > 907-450-8320 > Fairbanks, Alaska 99775 > [email protected] | www.alaska.edu/oit/ > > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
