Migration, Pt. II: The Cryptographic Hash Conundrum

2014-02-13 00:00
ehowton: (Default)

"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.
  • ◾ Current Location: 67114
◾ Tags:
  • Memory
  • Share
  • Link

Migration, Pt. I: The Database Dance

2014-02-12 00:00
ehowton: (Default)

For a veritable laundry list of reasons, I'm migrating my documentation server at work from one VM farm to another, and in doing so, moving from Ubuntu 10.04 LTS (uptime 370 days) to openSUSE 13.1. Sadly, I'm also wading hip-deep into the bane of my professional preference, the database. Yes, I prefer flat files. Its a shortcoming of which I'm painfully aware.

How my mind works fascinates even me. I've often wondered if I'm just dumber than my co-workers (most probable given I work amongst geniuses), or if I have some elusive, yet-to-be-discovered gift (less likely given my age) which offsets the fact that I have to re-learn the same highly-technical things (As opposed to, say simple physics) over and over and over when I don't utilize them. There is one affably-hyper-super-smart coworker who can remember detailed, nuanced configurations he worked on once, years ago. I remind him often not all of us have the mind of an engineer. Then there is the architect who is visibly aghast when I don't recall building a specific server from the countless servers I've built over the many, many years I've been building servers. Personally I like to think its because I reserve that area of my brain for having things like, "a personality." That said, it takes a diverse group of skills and personalities to do what we, as a group, succeed at day in and day out. Nothing at all would ever get done if everyone was exactly like me.

So each time I have to delve into mysql (now MariahDB) its like a brand-new experience. Granted, that's a little tongue-in-cheek. I remember how to log in, and to create databases. But that's usually about it...until I start working with them again, then I seem to remember more commands. A little more is retained each time, and the learning curve less steep. Databases look like they'd be a lot of fun actually, were it not for the forlorn DBAs wearing pickled faces they keep in jars on the shelves of their respective homes each day.

Migrating smf (my documentation platform) is as easy as upgrading the application, upgrading the database, manually backing up the database, moving it and the application to an upgraded system, restoring the database, and changing all the absolute paths within the tablespaces. What could go wrong?
  • ◾ Current Location: 67114
◾ Tags:
  • Memory
  • Share
  • Link

Frankfurt

2013-05-10 00:00
ehowton: (Default)

The last time I was in Frankfurt I was awaiting a flight back to my home at Langley, Virginia. I was recently returned from a tour in Saudi Arabia where I'd simply gotten off the plane in Frankfurt to spend a week with friends in Germany, after which I had 3 days to kill awaiting the next military flight out.

I considered spending my days on the walkplatz shopping and people watching. I considered exploring parts of Frankfurt I had never before been. But would those have been the best use of what was probably going to be my last trip to Germany in a long while?

I settled on buying three cases of Schöfferhofer kristallweizen and locking myself in my room not unlike Captain Willard from Apocolypse Now. Looking back, that was a fantastic use of my time in Frankfurt and I have no regrets. That was in 1995.

Fast forward to The Year of Our Lord Twenty-Thirteen and no stateside vps is offering the month-old openSUSE 12.3 Dartmouth. So once again I turn to our Deutsch friends; the birthplace of SUSE. Sure enough, 64-bit 12.3 vps with half a gig of RAM and a 25GB slice of disk for $5/mo and I am cresting the green wave! (Although it was humorous putting a .us domain in Frankfurt after agreeing to that citizenship affidavit.)

It wasn't until I went to install MySQL that I noticed further repercussions of Oracle's asininity - MariaDB. Distros are dropping MySQL as default (much as we now have LibraOffice to replace Oracle's unholy dismemberment of OpenOffice). It supposed to be a "drop-in" replacement for MySQL (Maria is the daughter of the original MySQL delveloper or somesuch) but my favorite forum software, smf would not load. A fantastic (and uber-prolific) support engineer codenamed, "Arantor" (who bemusingly reminded me of our own [livejournal.com profile] swashbuckler332) deftly sorted me out with the following code, only AFTER reminding me that just because you may be 3rd level support for your specific and narrow area of expertise, doesn't mean you make a good end user to other 3rd level support personnel :D

MariaDB [smf]> UPDATE smf_settings SET value = 0 WHERE variable = `databaseSession_enable` ;

Then there were the Indian script-kiddies polling my new server for vulnerabilities from none other than Kansan News Private Limited - a North India media initiative. What the hell? So I found them on Facebook and asked them to stop trying to hack my site and sent them the relevant portions of my log file.

And installed blockhost to pwn them.
  • ◾ Current Location: 67114
◾ Tags:
  • Memory
  • Share

Profile

ehowton: (Default)
ehowton
ehowton photography

August 2025

S M T W T F S
     12
345678 9
1011 121314 1516
17 181920212223
24252627282930
31      

Page Summary

Most Popular Tags

Expand Cut Tags

No cut tags