[LON-CAPA-admin] cookie invalid

[Stuart Raeburn]

Hi Hon-Kie,

> I am trying to verify that this bug has been fixed with 2.11 but I notice
> at least one instance where the lonbalancer is not hosting the session.

The code included with 2.11.0 to support the option:
"Session hosted on offload server, after re-authentication" is working  
for both SSO and non-SSO users.

The code included with 2.11.0 to support the option:
"Session hosted on Load Balancer, after re-authentication" was not  
working as intended for either SSO or non-SSO users because the  
session would *not* remain on the load balancer server following  
re-authentication on the load balancer.

> On a related issue, on the fsuK12 domain, there is an option to set SSO
> users but none for non-sso users. All the fsuK12 are non-sso. So is there a
> way to activate the option for non-sso users?

The option to set a non-SSO configuration was only offered for domains  
where the load balancer server was the default domain for that server.

So in your case when you set the option for "Non-SSO users with IP  
mismatch" from the domain configuration for the fsu domain, that would  
also have applied to fsuK12 domain users using the loncapa.fsu.edu  
load balancer (with the URL: https://k12.fsu.edu/)

> ... Does some daemon
> need to be restart or reload if there is a change in configuration?

When a change is made to how client IP address changes are handled  
following migration for a load balancer server, the load-balancing  
configuration cache needs to be expired on any of the domain's servers  
to which the load balancer offloads, which in 2.11.0 means either:

(a) waiting for up to 24 hours,
or
(b) restarting the memcached daemon on any potential offload servers.

Anyway, 2.11.1 will contain updates to support:

(a) Expiration of the cached load-balancing settings on all of the  
potentially affected domain's servers occurs when settings for  
handling client IP address changes are modified.
(b) Setting of options for both SSO and non-SSO users for whom a  
client IP change is detected during session migration from load  
balancer for *all* domains with the same "internet domain" (i.e., not  
just for the load balancer's default domain).
(c) The option: "Session hosted on Load Balancer, after  
re-authentication" is supported.
(d) An additional option is available to set session hosting on a  
specified server (following re-authentication on that server), when  
client IP change is detected during session migration from load  
balancer.
(e) An entry will be logged in /home/httpd/perl/logs/lonnet.log when a  
client IP change is detected during session migration from a load  
balancer server.

See: http://bugs.loncapa.org/show_bug.cgi?id=6675#c4


Stuart Raeburn
LON-CAPA Academic Consortium


Quoting "H. K. Ng" <hkng at fsu.edu>:

> Hi,
>
> I am trying to verify that this bug has been fixed with 2.11 but I notice
> at least one instance where the lonbalancer is not hosting the session.
> This is what I have set the configuration (as dc) -> Set domain
> configuration/Dedicated Load Balancer(s)/SSO users from fsu. with IP
> mismatch set to session hosted by load balancer, after re-authentication
> (same setting for non-sso users). However, I got a message from a student
> who claimed that he cannot access his course and checking the logs, it
> appears, the session is not hosted by the load balancer. Does some daemon
> need to be restart or reload if there is a change in configuration?
>
> On a related issue, on the fsuK12 domain, there is an option to set SSO
> users but none for non-sso users. All the fsuK12 are non-sso. So is there a
> way to activate the option for non-sso users?
>
> Thanks,
> -hk
>
>
>
>
> On Sat, Sep 21, 2013 at 1:05 PM, Stuart Raeburn <raeburn at msu.edu> wrote:
>
>> Hi,
>>
>>  Is it possible to have the lonbalancer hosts the session if different IP
>>> address is detected? The reason is so that I don't have add another server
>>> with SSO.
>>>
>>
>> Yes. That sounds like a reasonable option.
>>
>> I have included that as an additional option for incorporation in the
>> changes to address bug 6675; see -- http://bugs.loncapa.org/show_
>> bug.cgi?id=6675
>>
>>
>> Stuart Raeburn
>> LON-CAPA Academic Consortium