cas cluster, stickiness or registry cache problem?
Claudio Tassini
claudio.tassini at gmail.com
Thu Aug 23 05:22:47 EDT 2007
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.ProxyTicketValidator
> proxyList=[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:serviceResponse
> xmlns:cas='http://www.yale.edu/tp/cas' >
> <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20070823/40537e1e/attachment.html
More information about the cas
mailing list