Migration, Pt. II: The Cryptographic Hash Conundrum

"What could go wrong?" I asked. What an enormous pain in my ass that was.

BEFORE	AFTER
Ubuntu 10.04 -->	openSUSE 31.1
(2.6.32)	(3.11.10)
Apache 2.2.14 -->	Apache 2.4.6
MySQL 5.1.7 -->	MariaDB 5.5.33
PHP 5.3.2 -->	PHP 5.4.20
SMF 2.0 RC1 -->	SMF 2.0.7

This conversion did not complete without its challenges, but the reason I'm documenting it here boils down to the one thing which made all of this like, not work the first five times:

PHP 5.4.20 is configured to use sha256 which results in session IDs being 64 characters long. SMF 2.0.7 doesn't support session IDs longer than 32 characters, so when SMF goes to check the one from PHP with what's in the database, they won't match.

Either edit php.ini and replace [session.hash_function = sha256] with [session.hash_function = 0] to cause PHP to default to md5 for session IDs (resulting in standard 32-character session IDs), or alter the following tables in the database:

ALTER TABLE smf_log_errors CHANGE session session char(64) NOT NULL;
ALTER TABLE smf_log_online CHANGE session session char(64) NOT NULL;
ALTER TABLE smf_sessions CHANGE session_id session_id char(64) NOT NULL;

I've got to hand it to the hardcore support volunteers over at http://simplemachines.org who seriously know their code, despite the answer almost never being easy to find.

Additionally, saving uncompressed flat files (*.sql) rather than compressed files prior to importing them elsewhere seemed to add junk in the file header () visible in vi but not Notepad; exporting to a compressed file then importing solved that, and so did naming the exported file the same name as the database, which needs to be created prior to importation.

I ended up creating a virtual machine locally in which to perform all the upgrades and manipulate the data for testing purposes prior to exporting to the new server. It took me far longer than I expected.