You will need to be aware though that reduces your users protection from session hijacking tremendously. We really need to make fixing it a priority, without reducing security. Chris On 31 August 2016 6:40:39 AM NZST, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:

Magnus, there's been a lot of movement on the caching layer, and some of that work has been backported to the stable releases. Also, the RestrictSessionByIP setting was getting in the middle ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17050).

There's also a problem with memcached initialization in C4::Context that makes sessionStorage=memcache fail to persist sessions.

My suggestion would be to set sessionStorage to 'mysql' and disable the RestricSessionByIP syspref.

Regards

El mar., 30 ago. 2016 a las 8:24, Magnus Enger (<magnus@enger.priv.no>) escribió:

...

Dear Community,

I am seeing a strange problem, and I'm not sure where to start digging.

I have a (big) server with 30 odd Koha instances. One of these instances has been running under Plack for quite some time now, without any problems.

Two new instances have a problem where librarians get kicked out of the intranet more or less frequently, with a message like "Your session has expired, please log in again".

We had this problem on 3.22.x. After upgrading to 16.05.02 it went away. After upgrading to 16.05.03 last night it came back again.

It is not consistent. Earlier today it looked like you could log in, click on a link, get thrown out, login again and then things would work. Later users got kicked out every single time they clicked on a link in the intranet.

All sites are running off the official Debian packages, on the same server. Memcached is installed, enabled and used for storing sessions. Switching SessionStorage to the DB does not stop the problem. Stopping and disabling Plack for these two instances makes the problem go away.

I have not found anything interesting in Plack or Apache logs.

Anyone got a hunch what might be causing this? Or where to start digging?

Best regards, Magnus _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

------------------------------------------------------------------------

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

2016-08-30 19:40 GMT+01:00 Tomas Cohen Arazi <tomascohen@gmail.com>:

Magnus, there's been a lot of movement on the caching layer, and some of that work has been backported to the stable releases. Also, the RestrictSessionByIP setting was getting in the middle (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17050).

There's also a problem with memcached initialization in C4::Context that makes sessionStorage=memcache fail to persist sessions.

Please confirm and open a bug report if it's still the case. I don't recreate it.

My suggestion would be to set sessionStorage to 'mysql' and disable the RestricSessionByIP syspref.

Regards

El mar., 30 ago. 2016 a las 8:24, Magnus Enger (<magnus@enger.priv.no>) escribió:

...

Dear Community,

I am seeing a strange problem, and I'm not sure where to start digging.

I have a (big) server with 30 odd Koha instances. One of these instances has been running under Plack for quite some time now, without any problems.

Two new instances have a problem where librarians get kicked out of the intranet more or less frequently, with a message like "Your session has expired, please log in again".

We had this problem on 3.22.x. After upgrading to 16.05.02 it went away. After upgrading to 16.05.03 last night it came back again.

It is not consistent. Earlier today it looked like you could log in, click on a link, get thrown out, login again and then things would work. Later users got kicked out every single time they clicked on a link in the intranet.

All sites are running off the official Debian packages, on the same server. Memcached is installed, enabled and used for storing sessions. Switching SessionStorage to the DB does not stop the problem. Stopping and disabling Plack for these two instances makes the problem go away.

I have not found anything interesting in Plack or Apache logs.

Anyone got a hunch what might be causing this? Or where to start digging?

Best regards, Magnus _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

-- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

Maybe the rmaints should answer! El vie., 2 sept. 2016 4:12, Magnus Enger <magnus@enger.priv.no> escribió:

On 30 August 2016 at 20:40, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:

...

My suggestion would be to set sessionStorage to 'mysql' and disable the RestricSessionByIP syspref.

Yup, this made the problem with timed out sessions go away. Does that indicate it is related to caching/RestricSessionByIP and will be fixed in the next stable release?

Best regards, Magnus _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

Ok, yesterday I took some time to fill (and provide patches for): - Bug 17261 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17261> - Add memcached configuration info to about.pl - Bug 17262 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17262> - Plack on packages is not having memcached set properly Bug 17261 highlighted something we suspected: the Plack processes don't get the right configuration variables through ENV for setting the memcached backend (on packages setup). It was pretty obvious. That's why it is falling back to CGI::Session even when you set sessionStorage=memcached, and results in weird permission issues trying to write the session files somewhere we don't have control of. Bug 17262 does what is needed to get the Plack processes have the right MEMCACHED_SERVERS and MEMCACHED_NAMESPACE variables set. It does so by patching the koha-plack and koha-functions.sh scripts in an obvious way. The problem is that Plack explodes with 17262 alone. It looks like circular dependencies issues. But... This morning I passed QA on: - Bug 17189 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17189> - Add the ability to define several memcached namespaces - Bug 11921 <https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11921> - memcached configuration should be moved back to koha-conf.xml They both change the way memcached configuration is handled and better reorganize the code around it (basically moving the configuration back to koha-conf.xml, and removing memcached handling from C4::Context, solving the circ dep issue). As Chris mentioned on 17262, moving the memcached configuration back to koha-conf.xml is the right thing to do. That's why 17189 and 11921 should be pushed to master ASAP, and I belive they should be backported down to 3.22 if the rmaints agree and with proper testing. People supporting 3.22 and 16.05 deployments should get involved on testing in the stable branches to make sure no regression is introduced (is it really possible if it is not working at all?). The only problem is that current setups won't have the koha-conf.xml entries (memcached_servers and memcached_namespace)[1]. But this is handled nicely by the current logic, that allows ENV to overload koha-conf.xml values. So it will work, YAY! (already tested it) So, IMHO, they could be backported to the stable branches, along with 17262, which will make it effective use of memcached. It shouldn't be pushed to master as it would be a step backwards and is not needed. My two cents. Regards [1] This might deserve a warning entry in about page IMHO. El mar., 30 ago. 2016 a las 15:40, Tomas Cohen Arazi (<tomascohen@gmail.com>) escribió: Magnus, there's been a lot of movement on the caching layer, and some of that work has been backported to the stable releases. Also, the RestrictSessionByIP setting was getting in the middle ( https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17050). There's also a problem with memcached initialization in C4::Context that makes sessionStorage=memcache fail to persist sessions. My suggestion would be to set sessionStorage to 'mysql' and disable the RestricSessionByIP syspref. Regards El mar., 30 ago. 2016 a las 8:24, Magnus Enger (<magnus@enger.priv.no>) escribió: Dear Community, I am seeing a strange problem, and I'm not sure where to start digging. I have a (big) server with 30 odd Koha instances. One of these instances has been running under Plack for quite some time now, without any problems. Two new instances have a problem where librarians get kicked out of the intranet more or less frequently, with a message like "Your session has expired, please log in again". We had this problem on 3.22.x. After upgrading to 16.05.02 it went away. After upgrading to 16.05.03 last night it came back again. It is not consistent. Earlier today it looked like you could log in, click on a link, get thrown out, login again and then things would work. Later users got kicked out every single time they clicked on a link in the intranet. All sites are running off the official Debian packages, on the same server. Memcached is installed, enabled and used for storing sessions. Switching SessionStorage to the DB does not stop the problem. Stopping and disabling Plack for these two instances makes the problem go away. I have not found anything interesting in Plack or Apache logs. Anyone got a hunch what might be causing this? Or where to start digging? Best regards, Magnus _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

[1] This might deserve a warning entry in about page IMHO.

Done, see bug 17274. 2016-09-07 19:07 GMT+01:00 Tomas Cohen Arazi <tomascohen@gmail.com>:

Ok, yesterday I took some time to fill (and provide patches for): - Bug 17261 - Add memcached configuration info to about.pl - Bug 17262 - Plack on packages is not having memcached set properly

Bug 17261 highlighted something we suspected: the Plack processes don't get the right configuration variables through ENV for setting the memcached backend (on packages setup). It was pretty obvious. That's why it is falling back to CGI::Session even when you set sessionStorage=memcached, and results in weird permission issues trying to write the session files somewhere we don't have control of.

Bug 17262 does what is needed to get the Plack processes have the right MEMCACHED_SERVERS and MEMCACHED_NAMESPACE variables set. It does so by patching the koha-plack and koha-functions.sh scripts in an obvious way.

The problem is that Plack explodes with 17262 alone. It looks like circular dependencies issues. But...

This morning I passed QA on: - Bug 17189 - Add the ability to define several memcached namespaces - Bug 11921 - memcached configuration should be moved back to koha-conf.xml

They both change the way memcached configuration is handled and better reorganize the code around it (basically moving the configuration back to koha-conf.xml, and removing memcached handling from C4::Context, solving the circ dep issue).

As Chris mentioned on 17262, moving the memcached configuration back to koha-conf.xml is the right thing to do.

That's why 17189 and 11921 should be pushed to master ASAP, and I belive they should be backported down to 3.22 if the rmaints agree and with proper testing. People supporting 3.22 and 16.05 deployments should get involved on testing in the stable branches to make sure no regression is introduced (is it really possible if it is not working at all?).

The only problem is that current setups won't have the koha-conf.xml entries (memcached_servers and memcached_namespace)[1]. But this is handled nicely by the current logic, that allows ENV to overload koha-conf.xml values. So it will work, YAY! (already tested it)

So, IMHO, they could be backported to the stable branches, along with 17262, which will make it effective use of memcached. It shouldn't be pushed to master as it would be a step backwards and is not needed.

My two cents.

Regards

[1] This might deserve a warning entry in about page IMHO.

El mar., 30 ago. 2016 a las 15:40, Tomas Cohen Arazi (<tomascohen@gmail.com>) escribió:

Magnus, there's been a lot of movement on the caching layer, and some of that work has been backported to the stable releases. Also, the RestrictSessionByIP setting was getting in the middle (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17050).

There's also a problem with memcached initialization in C4::Context that makes sessionStorage=memcache fail to persist sessions.

My suggestion would be to set sessionStorage to 'mysql' and disable the RestricSessionByIP syspref.

Regards

El mar., 30 ago. 2016 a las 8:24, Magnus Enger (<magnus@enger.priv.no>) escribió:

Dear Community,

I am seeing a strange problem, and I'm not sure where to start digging.

I have a (big) server with 30 odd Koha instances. One of these instances has been running under Plack for quite some time now, without any problems.

Two new instances have a problem where librarians get kicked out of the intranet more or less frequently, with a message like "Your session has expired, please log in again".

We had this problem on 3.22.x. After upgrading to 16.05.02 it went away. After upgrading to 16.05.03 last night it came back again.

It is not consistent. Earlier today it looked like you could log in, click on a link, get thrown out, login again and then things would work. Later users got kicked out every single time they clicked on a link in the intranet.

All sites are running off the official Debian packages, on the same server. Memcached is installed, enabled and used for storing sessions. Switching SessionStorage to the DB does not stop the problem. Stopping and disabling Plack for these two instances makes the problem go away.

I have not found anything interesting in Plack or Apache logs.

Anyone got a hunch what might be causing this? Or where to start digging?

Best regards, Magnus _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

--

Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F -- Tomás Cohen Arazi Theke Solutions (https://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/