Not the same Ehcache version. The same CAS version, at least the same release 
line. (4.1.x, 4.2.x, etc). The copy of the ticket in v4 is very different from 
v3, and so they are not compatible at a binary level. Thus, the cache rightly 
gets confused because it thinks all objects/tickets it receives are of the same 
type, and yet some (The v4 ones) are different. 

The limitations are that when you do a major upgrade going from 3 to 4, you can 
expect “major” changes across both API and implementations of those APIs (the 
latter being your specific issue here with ehcache). Things are allowed to 
“break” at the benefit of providing newer improvements, though the breaking 
part is certainly not intentional and we try to make the effort to remain 
compatible as much as possible.

-- 
Misagh

From: Ted Fisher <[email protected]>
Reply: Ted Fisher <[email protected]>
Date: April 4, 2016 at 2:27:02 PM
To: [email protected] <[email protected]>
Subject:  [cas-user] CAS 4.1.4 using ehcache shared with CAS 3.5.0  

I tried bringing up my new CAS 4.1.4 server with Ehcache set for MI replication 
with our existing test CAS 3.5.0 servers – using the same ST and TGT cache 
names.  I wanted to be able to send some users through our load balancer to the 
newer CAs while allowing our existing test env to use the old CAs servers. 

There are apparently compatibility issues with the ehcache versions since I get 
ths elogged:

WARN [Bootstrap Thread for cache org.jasig.cas.ticket.TicketGrantingTicket] 
[net.sf.ehcache.distribution.RMIBootstrapCacheLoader] - Error asynchronously 
performing bootstrap. The cause was: Error bootstrapping from remote peer. 
Message was: error unmarshalling return; nested exception is:

        java.io.InvalidClassException: 
org.jasig.cas.ticket.TicketGrantingTicketImpl; local class incompatible: stream 
classdesc serialVersionUID = -5197946718924166491, local class serialVersionUID 
= -8608149809180911599

net.sf.ehcache.distribution.RemoteCacheException: Error bootstrapping from 
remote peer. Message was: error unmarshalling return; nested exception is:

        java.io.InvalidClassException: 
org.jasig.cas.ticket.TicketGrantingTicketImpl; local class incompatible: stream 
classdesc serialVersionUID = -5197946718924166491, local class serialVersionUID 
= -8608149809180911599

 

Do I have to have all servers at the same exact Ehcache version?  Can I just 
use the newer ehcache version in my 3.5.0 CAS without breaking it?

I know you can share ehcache amongst different CAs versions in order to do 
rolling upgrades, but what are the lilmitations there?   Must be same major CAS 
version?

 

Thanks.


From: Ted Fisher <[email protected]>
Reply: Ted Fisher <[email protected]>
Date: March 31, 2016 at 3:37:02 PM
To: [email protected] <[email protected]>
Subject:  [cas-user] cas-mfa with CAS 4.1.4 and ehcache

 

We have gotten cas-mfa with CAS 4.1.4 running and configured with an ldap auth 
handler and duo authenticating OK and we are getting service tickets generated. 
 Our next step was to get ehcache configured to use the same cache as our 
existing 3.5.0 CAs servers so that ST’s would go there and apps with CAS 
clients doing ticket validation could validate them there (this is all in our 
test env right now).  From the looks of things STs and TGTs are the same so we 
should be able to share them like that.

I was pleased to see that the wiki docs explained ehcache config as very 
similar to our exsiting – we are doing RMI replication now.  I configured it 
pretty much the same as what we have now with the cache names changed to match 
our existing.  It builds and no errors logged when running and I see packets 
being sent to the other RMI addresses, so it looks like STs are being sent out 
to ehcache.  But, when the apps try to validate the ST they are not there.  I 
tried turning logging up to debug and still I see no indications of any issue.

Any pointers how to troubleshoot this ehcache issue?  Is there a way for me to 
dump the STs in cache?  It’s test and I can see that there are only a few 
there.  I’d like to verify that they are making it there/.

 

Thanks.

 

Ted F. Fisher

Information Technology Services



 

From: Ted Fisher
Sent: Thursday, March 17, 2016 9:43 AM
To: '[email protected]' <[email protected]>
Subject: cas-mfa with CAS 3.5.3

 

I haven’t been able to find any step-by docs for adding Unicon’s cas-mfa with 
duo to our CAS server.  I’ve tried following the instructions at 
https://github.com/Unicon/cas-mfa/ which results in a good build, but no duo 
authentication.  I would assume that is because those instructions are for CAS 
4.1.X.  

Is there anything that will tell me what I need to have in place and what 
settings are needed for CAS 3.5.3? 

I am trying to use cas-mfa version 1.0.0-RC2 since that looks to be the last 
that supported 3.5.X.  I’ve tried quite a few variations based on posts I found 
from others, but nothing is leading to any progress here.

README.md in 1.0.0-RC2 points to https://github.com/Unicon/cas-mfa/  which has 
instructions for 4.1.X, so I’m not finding anything on what this should look 
like.

 

Any help would be appreciated.

 

Environment:

CAS 3.5.3  on Tomcat 7,  2 RHEL 6 servers using java version "1.7.0_95"

 

Thanks.

 

Ted F. Fisher

Server Administrator

323 Hayes Hall

Information Technology Services

Email:  [email protected]

Phone: 419.372.1626



 

--
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.

--
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.

--
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/SN1PR0501MB201505290D704E32C198E0B9C09D0%40SN1PR0501MB2015.namprd05.prod.outlook.com.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

--
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/SN1PR0501MB2015BED90D24E6A634F6B07FC09D0%40SN1PR0501MB2015.namprd05.prod.outlook.com.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/etPan.57036bed.194e77.24ce%40mmoayyed-4.local.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

Reply via email to