7 Minute Miles

Mavericks Remote Upgrade Tales


Tonight I decided to throw caution to the wind and finally clicked that tempting Mavericks upgrade button on one of my Mac mini servers located at the always excellent macminicolo.net in Las Vegas. After all, it’s free and packed with features – what could possibly go wrong?

A fair amount, it turns out. I had upgraded two other minis I have on site and knew the OS part of the upgrade takes about an hour. In hindsight, the two servers I have here are configured differently than the ones in Vegas (one is just a caching server, while the intranet box is using OS X Server, not the stock client Apache/MySQL/PHP web server).

I posted the outage announcements on social media, remoted into the mini using the Screen Sharing app and went to the Mac App Store to begin the download. The five-plus gig installer took a few minutes on their fast pipes and I authorized the installer to begin. Once you get to the restart portion and it’s like passing through the dark side of the moon.

Almost exactly an hour later, the screen finally reconnected and displayed another installer screen (with eight estimated minutes left). That part finished without issues and I was happy to see the normal login screen. Once logged in as the admin, the App Store launched again and had a few minor updates to install. All good so far. Went to check the website and…nothing.

First issue was Apache wasn’t running. Easy to fix with a quick apachectl command. Now the website loaded with the simple Apache default “It works!” page. A visit to the httpd.conf and httpd-vhosts.conf files in /etc/apache2/ and /etc/apache2/extra/ showed that both had been replaced with defaults. Restored the virtual host file first, then looked at the httpd.conf file, which required uncommenting of the virtual host and PHP5 sections.

The “It works!” page was now replaced with a “Error establishing a database connection” screen, which meant it was time to look at what Mavericks did to MySQL. I first looked at the System Preferences MySQL panel, which reported that the database was not running (duh) and that it couldn’t find MySQL. I checked in the usual /usr/local/ spot, which still had my older installation. I had a bit of a red herring with the old “mysql.sock” issue, but that was not the root cause of my database connection issues.

Since I was a version behind, I decided to backup the data directory to the desktop and went to the MySQL download site to get the DMG for Mac OS X 10.7 (x86, 64-bit), Community Server 5.6.16 (the most current version available today). I ran the main installer, then the startup item installer, followed by a new preference panel (which was able to successfully start up the database server). I then had to run the command to set the root user password (/usr/local/mysql/bin/mysqladmin -u root password 'yourpasswordhere'). At this point, I was able to use phpMyAdmin to get back into MySQL.

The next problem was that none of my WordPress tables were there. I stopped the server, copied the contents of the old data directory to the new one and restarted the server, which made all of the database names appear in phpMyAdmin. Unfortunately, none of them had any data in them. Once I realized that all data files needed to be owned by the _mysql user and not the local admin, a quick chown -R command resolved the final MySQL issue and all WordPress sites came back up. Big shout out to Coolest Guides on the Planet, which had a great post that helped me quickly track down many of these issues.

The only other major problem I had was with Rumpus 7.2, which wouldn’t launch (it would get stuck in an endless loop of requesting admin credentials). Turns out it just needed a free update to version 7.2.16 and all was well.

There is a newer version of phpMyAdmin that I should probably install, but there is only so much excitement I can take in one night…

Originally published by DK on March 13, 2014 at 12:41 am in Longform, Technology, Work


flourish icon