Item15020: Upgrading the server from 32bit to 64bit breaks Foswiki

I upgraded the server running a Foswiki instance from a 32bit Debian to a 64bit one, same version.

All the pages of the Foswiki became unavailable with the error:

Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information.

Long integer size is not compatible

This is becauses Foswiki stores some Session info in the cookie itself, but in a way that is dependent on the server architecture. Reading on a 64bit server a cookie made on a 32bit server fails. And I have not checked, but it may be also the case with changes in the big/little endian, etc...

It fails in CGI::Session::Serialize::storable::thaw from Foswiki::LoginManager::Session::load

Suggested remediation: make cookie storage encoding hardware-independant. And in the meantime, document it in the FAQ.

Workaround: Delete all cookies for the server in all the clients. I could not find a way to invalidate all the cookies from the server itself.

Severity: It should not happen frequently, but it is quite puzzling when it does. Logs do not give any indication, I had to add stack traces in the perl distributed modules to find the problem.

-- ColasNahaboo - 07 Mar 2021

Instead of making cookie storage hardware-independent I'd rather suggest to leverage the store API of CGI::Session to Foswiki to be able to plugin different ones, e.g. SQL, instead of Storable. This would help in other situations as well, say clustering multiple Foswiki engines, all of them reading session information from a central cookie store instead of having their own one locally each.

This would not directly have prevented you from having problems migrating to 64bit, but it does so in a more broader sense.

You actuall shipwreck is actually to be expected. Frankly, this is rather a mild one E.g. local perl packages need recompilation if they have XS parts, perlmagick for sure; a couple of plugins create caches using Storable or Sereal. These caches all need to be nuked before being able to restart on 64 pots.

-- MichaelDaum - 08 Mar 2021

Actually, I never use CPAN, and only rely on Debian perl packages, so the local perl packages were not an issue. (I re-installed on a fresh 64bit install) And I expected this problem, so I deleted working/work_areas/ anyways.

But I wasn't expecting non-portable data in the cookie itself. Again, I do not think it warrant a fix in the implementation, just a mention in the FAQ.

-- ColasNahaboo - 09 Mar 2021

Commenting is disabled while not logged in