Not sure what 'This is still happening...' means. This discussion from early 2015 was related to (at least on my part) a mis-configuration of my CAS Server DNS Name in my devstack environment, which broke the connectivity between my edX application and the CAS server.
Since the Dogwood release (including the Eucalyptus release) there have been other issues with CAS. See the discussion and my post here: https://groups.google.com/forum/#!topic/openedx-ops/XU0zcGH4S2o On Thursday, December 15, 2016 at 1:32:50 PM UTC-5, Eduardo Cuomo wrote: > > This is still happening... > > El miércoles, 29 de abril de 2015, 17:44:32 (UTC-3), Stuart O'Day escribió: >> >> Hi, >> >> I ran into the same error while configuring devstack, running >> named-release/birch in vagrant, IOError: [Errno socket error] [Errno >> 111] Connection refused, and it turned out to be a connectivity issue >> during the back-channel validation of the Ticket from my Open edX Server >> (running in the vagrant VM) to the CAS Server. (See step 6 in this >> diagram >> <http://www.developertutorials.com/wp-content/uploads/2004/01/52-1.gif>). >> My Open edX Server was incorrectly resolving the DNS Name in the CAS >> Server URL. Once that was fixed, everything started working. >> >> Not sure if this situation is related to yours, but I thought I would >> post anyways. >> >> Stuart >> >> >> >> On Wednesday, February 25, 2015 at 1:28:39 AM UTC-5, Eugene Medvedev >> wrote: >>> >>> On Wednesday, 25 February 2015 08:51:05 UTC+3, Nilesh Londhe wrote: >>> >>> My CAS server seems to work with a different CAS client I setup. Do you >>>> have success with birch as CAS client? Which git tag are you running CAS >>>> with? >>>> >>> >>> We don't use named releases, we track the upstream release branch in a >>> fork that contains local customizations and try to keep it up to date. >>> Right now I have the dev server which is current up to release-2015-02-19 >>> and two production servers *(long story)* which are two months out of >>> date or three *(whichever it was when TNL-726 >>> <https://openedx.atlassian.net/browse/TNL-726> happened, I forget)* and >>> I had a version forever stuck somewhere in spring of 2014 before, and they >>> all worked fine with the same CAS server >>> <https://github.com/jbittel/django-mama-cas>, although the mapper code >>> had to be different between them because of changes to CourseEnrollment >>> objects. >>> >>> The version of edX you're running is very unlikely to make a difference >>> for CAS login itself, since edX relies on a particular version of >>> django-cas library, patched to work with django 1.4, which hasn't changed >>> for quite a while: >>> https://github.com/edx/edx-platform/commit/189284ace6c8525dc739eff2f8a99216c735d83c >>> >>> and basically doesn't do anything about CAS itself other than feed the >>> library configuration parameters. >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/77f2fb30-c2b2-4a65-a73f-e4c55adf9a78%40googlegroups.com.
