cas cluster, stickiness or registry cache problem?
Scott Battaglia
scott.battaglia at gmail.com
Thu Aug 23 07:44:53 EDT 2007
Claudio,
If you have an account in Confluence, you can add your updates to that page
if you'd like! It should be writable by everyone.
Thanks!
-Scott
On 8/23/07, Claudio Tassini <claudio.tassini at gmail.com> wrote:
>
> Ok I found the solution so I'm going to post it... I think it could be
> added to the clustering cas howto.
>
> My problem was that I'm using bonding with several aliases on the same
> machine, so I needed to add a bind_addr property in the ClusterConfig
> section of jbossTicketCacheReplicationConfig.xml :
>
> <UDP mcast_addr="239.255.0.2" mcast_port="48866"
> ip_ttl="64" ip_mcast="true" bind_addr="192.168.10.31"
> mcast_send_buf_size="150000"
> mcast_recv_buf_size="80000"
> ucast_send_buf_size="150000"
> ucast_recv_buf_size="80000"
> loopback="false"/>
>
> setting it to the main address of the server. Now I see the 48866 udp port
> correcly binded to * at the kernel level, while the startup of TreeCache
> service logs this:
>
> 2007-08-23 10:44:10,193 INFO [org.jasig.cas.util.JBossCacheFactoryBean] -
> <Starting TreeCache service.>
>
> -------------------------------------------------------
> GMS: address is 192.168.10.31:32868
> -------------------------------------------------------
>
> instead of the strange IPV6-like address i used to see before.
>
> Don't know if it's a malfunctioning at the jboss (application) side, a
> bonding (kernel) fault, or if it is a problem with my own particular
> configuration that no-one else will ever face, but a reference to this could
> be added in the clustering cas guide.
>
> Hope this helps someone else.
>
> 2007/8/23, Claudio Tassini <claudio.tassini at gmail.com >:
> >
> > Hi all!
> >
> > I'm spamming a bit on this list these days but I'm going mad to
> > configure this cas platform. The only problem that's still open is about
> > ticket registry replication (I've had a discussion here in the last days
> > about this).
> >
> >
> > I'm using jboss-cache as specified in the clustering cas guide, the only
> > difference is that I put the jboss-cache jars in
> > $CATALINA_HOME/webapps/cas/WEB-INF/lib instead of putting them in the
> > localPlugins/lib and rebuilding/redeploying cas, but I don't think this is
> > the problem.
> >
> >
> > I'm not quite sure if the problem is session stickiness on the load
> > balancers, or if it actually is a jboss-cache misconfiguration, so I'll try
> > to explain my platform.
> >
> >
> > Two hw servers, identically configured. Apache 2.2.4, Tomcat 5.5.23 ,
> > CAS 3.07 , jboss-cache 1.4.1SP4, JDK 1.6.0_02 . All the client
> > connections are received by apache, which only listen on the SSL port 443
> > and has a virtualhost configured with mod_jk to proxy connections to tomcat.
> > In tomcat, as a consequence, I have no HTTP/HTTPS connectors active, only
> > the AJP connector.
> > The application using cas is a java webapp (running in the same tomcat)
> > and the cas client is cas filter .
> >
> >
> > The two apache are balanced through an F5 BIG-IP load balancer, with a
> > virtual server configured with session persistence based on SSL ID . I'm
> > running all in the intranet, so the same virtual server is also used by the
> > cas client for the login and validation URLs. That is:
> >
> >
> > -the browser connects to the url "https://portale.inca.it/WebMail" ,
> > -the request is received by one of the apaches , which then proxies the
> > connection to one of the two tomcats via mod_jk (which has sticky_sessions
> > enabled) to reach the WebMail content
> > -the receiving tomcat reads the web.xml , and redirects the user to the
> > cas login page, https://portale.inca.it/cas
> > <https://portale.inca.it/cas/login>/login<https://portale.inca.it/cas/login>
> > -again, the browser points to portale.inca.it/cas/login, so connects to
> > apache and then to tomcat
> > -user logs in to cas. The TGT ticket is generated. The browser is
> > redirected to the original context /WebMail
> > -the same apache as before manages the connection, and because of
> > session stickiness the connection is dropped to the same tomcat as before.
> > -Now, the tomcat serving the /WebMail context makes a connection to the
> > validationUrl to check if the ticket is valid. This connection will not
> > necessarily be handled by the same tomcat that granted the ST, and I imagine
> > that this is what jboss-cache should do: replicate those tickets so that
> > they are always identical on both servers. But if the connection is taken by
> > the other server, it says that the ticket does not exists and the ticket is
> > not validated.
> >
> >
> > This is what happens in the catalina.out after enabling debugging:
> >
> >
> > on the first server:
> > 2007-08-23 03:28:48,502 INFO [
> > org.jasig.cas.web.flow.AutomaticCookiePathSetterAction] - <Setting
> > ContextPath for cookies to: /cas>
> > 2007-08-23 03:29:00,008 DEBUG [
> > org.jasig.cas.CentralAuthenticationServiceImpl] - <Attempting to create
> > TicketGrantingTicket for c.tassini at inca.it>
> > 2007-08-23 03:29:00,068 INFO [
> > org.jasig.cas.authentication.AuthenticationManagerImpl] -
> > <AuthenticationHandler:
> > org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler successfully
> > authenticated the user which provided the following credentials:
> > c.tassini at inca.it>
> > 2007-08-23 03:29:00,068 DEBUG [
> > org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver] - <Creating SimplePrincipal for [
> > c.tassini at inca.it]>
> > 2007-08-23 03:29:00,072 DEBUG [org.jasig.cas.ticket.registry.JBossCacheTicketRegistry] - <Adding ticket to registry for:
> > TGT-2-MjrcydZIn1DsV1KeSNcdUKSES<http://TGT-2-MjrcydZIn1DsV1KeSNcdUKSESC0MEDYVHO5-inca-portal1.inca.it>C0MEDYVHO5-inca-portal1.inca.it<http://TGT-2-MjrcydZIn1DsV1KeSNcdUKSESC0MEDYVHO5-inca-portal1.inca.it>
> > >
> > 2007-08-23 03:29:00,074 DEBUG [
> > org.jasig.cas.ticket.registry.JBossCacheTicketRegistry ] - <Retrieving
> > ticket from registry for: TGT-2-MjrcydZIn1DsV1KeSNcdUKSES
> > <http://TGT-2-MjrcydZIn1DsV1KeSNcdUKSESC0MEDYVHO5-inca-portal1.inca.it>
> > C0MEDYVHO5-inca-portal1.inca.it<http://TGT-2-MjrcydZIn1DsV1KeSNcdUKSESC0MEDYVHO5-inca-portal1.inca.it>
> > >
> > 2007-08-23 03:29:00,076 DEBUG [
> > org.jasig.cas.ticket.registry.JBossCacheTicketRegistry] - <Adding ticket
> > to registry for: ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>7fF6BYfA1-inca-portal1.inca.it
> > <http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>>
> > 2007-08-23 03:29:00,077 INFO [
> > org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service
> > ticket [ ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>7fF6BYfA1-inca-portal1.inca.it
> > <http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>]
> > for service [https://portale.inca.it<https://portale.inca.it/WebMail/LoginManagerServlet?action=login>/WebMail/LoginManagerServlet?action=login<https://portale.inca.it/WebMail/LoginManagerServlet?action=login>]
> > for user [c.tassini at inca.it ]>
> > 2007-08-23 03:34:01,475 DEBUG [
> > org.apache.catalina.cluster.session.DeltaManager] - <Notifying cluster
> > of expiration primary=/cas sessionId [true]>
> >
> >
> > And then, on the second server:
> > 2007-08-23 03:29:00,569 DEBUG [
> > org.jasig.cas.ticket.registry.JBossCacheTicketRegistry] - <Retrieving
> > ticket from registry for: ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>
> > 7fF6BYfA1-inca-portal1.inca.it<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>>
> >
> > 2007-08-23 03:29:00,571 DEBUG [
> > org.jasig.cas.CentralAuthenticationServiceImpl] - <ServiceTicket [ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>
> > 7fF6BYfA1-inca-portal1.inca.it<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>]
> > does not exist.>
> > Aug 23, 2007 3:29:00 AM edu.yale.its.tp.cas.client.CASReceipt getReceipt
> > SEVERE: validation of [[edu.yale.its.tp.cas.client.ProxyTicketValidatorproxyList=[null] [
> > edu.yale.its.tp.cas.client.ServiceTicketValidator casValidateUrl=[https://portale.inca.it/cas
> > <https://portale.inca.it/cas/proxyValidate>/proxyValidate<https://portale.inca.it/cas/proxyValidate>]
> > ticket=[ ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>
> > 7fF6BYfA1-inca-portal1.inca.it<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>]
> > service=[https%3A%2F%2Fportale
> > .inca.it%2FWebMail%2FLoginManagerServlet%3Faction%3Dlogin]
> > errorCode=[INVALID_TICKET] errorMessage=[ticket 'ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>
> > 7fF6BYfA1-inca-portal1.inca.it<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>'
> > not recognized] renew=false entireResponse=[<cas:serviceRes ponse
> > xmlns:cas='http://www.yale.edu/tp/cas' <http://www.yale.edu/tp/cas%27>>
> > <cas:authenticationFailure code='INVALID_TICKET'>
> > ticket ' ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg<http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>7fF6BYfA1-inca-portal1.inca.it
> > <http://ST-2-cEYswXNAwUw2Ith36JfR4Tw5Gg7fF6BYfA1-inca-portal1.inca.it>'
> > not recognized
> > </cas:authenticationFailure>
> > </cas:serviceResponse>
> > ]]]] was not successful.
> >
> > Am I somehow wrong in the theory? Is jboss-cache working properly and I
> > must change the session stickiness configuration on the balancer or on
> > mod_jk? Are there alternative methods to replicate the session registry to
> > jboss-cache?
> >
> >
> > One thing I've noticed in the starting log is this:
> >
> >
> > 2007-08-23 03:25:58,166 INFO [org.jasig.cas.util.JBossCacheFactoryBean ]
> > - <Starting TreeCache service.>
> >
> >
> > -------------------------------------------------------
> > GMS: address is fe80:0:0:0:214:4fff:fe8d:d186:32862
> > -------------------------------------------------------
> >
> >
> > In the guides and examples I've seen this is an IPV4 address, while this
> > seems to be in IPV6... could this be normal?
> >
> >
> > I'm sorry for the long post but I really can't figure it out. It's 4am
> > here in Italy and I'm working on this almost without rest from 3 days
> > now...
> >
> >
> > Any help would be _really_ appreciated.
> >
> >
> > Thanks in advance.
> >
> > --
> > Claudio Tassini
> >
>
>
>
> --
> Claudio Tassini
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
--
-Scott Battaglia
LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20070823/97559a8e/attachment.html
More information about the cas
mailing list