Availability primarily. Sent from my Android phone using TouchDown (www.nitrodesk.com)
-----Original Message----- From: Linda Toth [[email protected]] Received: Wednesday, 06 Nov 2013, 5:07pm To: [email protected] [[email protected]] Subject: Re: [cas-user] Simple question re: global properties for CAS 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]<mailto:[email protected]> | www.alaska.edu/oit/<http://www.alaska.edu/oit/> On Wed, Nov 6, 2013 at 1:25 PM, Danner, Mearl <[email protected]<mailto:[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<http://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<http://www.samford.edu/> From: Misagh Moayyed [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, November 06, 2013 8:39 AM To: [email protected]<mailto:[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]] Sent: Tuesday, November 05, 2013 3:26 PM To: [email protected]<mailto:[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<http://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<tel:907-450-8320> Fairbanks, Alaska 99775 [email protected]<mailto:[email protected]> | www.alaska.edu/oit/<http://www.alaska.edu/oit/> -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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
