I filed a ticket to ask our IT folks to upgrade PHP on our virtual machine server. Turns out the easiest and safest way to do that was to upgrade the entire OS and all dependencies, so we scheduled that for this afternoon. They just finished upgrading the server, and we now have a shiny RHEL5 box running PHP5. That means next week I’ll be moving our TLC website onto the VM, as well as migrating wiki.ucalgary.ca (and finally upgrading it from 1.6.10 to 1.13.0) Woohoo! Our IT folks really are great. Thanks!
I’ve been using the WP-Cache 2 plugin for some time, as it offers pretty effective file-based caching of WordPress pages to help reduce the load on the database server and reduce page generation time. But the plugin has kind of languished without any real updates for months(?) or years(?).
Donncha O Caoimh, the WordPress guru who’s [...]
My blog often has fits of sucktacular performance. After digging around, and bugging DreamHost support for some ideas, I’ve made some progress.
I had been running wp-cache to enable file-based caching, thinking that would help optimize performance of the site (fewer database calls should equal better performance) – except that DreamHost apparently uses NFS-mounted storage for [...]
For a project I’m involved with, we’re setting up a shiny new server to handle hosting of lots (and lots) of Drupal sites in a shared hosting environment. We were able to pick up a decently speced Dell PowerEdge 2950 at a really good price. Dell wanted a tonne of cash to pre-install RedHat on the box. Um, no thanks. So, our friendly neighbourhood colocation provider installed Ubuntu Server on the box for me (I’m about 1000 km from the server, so couldn’t actually do the physical install myself). The PowerEdge is a 2xdual core Xeon, similarly speced as the new Xeon XServes, but not as nicely packaged. This one requires 2U of rackspace, where the XServe is shoehorned into a single 1U slot.
We hit a minor snag with the configuration – the onboard NICs weren’t properly lighting up. Some quick Googling, and I believe the solution was found in this thread, and involved running this:
chroot /target
# fix initrd
echo megaraid_sas >> /etc/mkinitramfs/modules
cp /boot/initrd.img-2.6.15-26-amd64-server /boot/initrd.img-2.6.15-26-amd64-server.old
mkinitramfs -o /boot/initrd.img-2.6.15-26-amd64-server 2.6.15-26-amd64-server
After that, everything came up roses. Once I had my admin account, it was pretty trivial to get the rest of the bits set up. I had some minor stumbling when trying to build httrack from source, but a tip from this thread led me to the quick command to install the full developer’s toolkit:
sudo apt-get install build-essential
The whole apt-get stuff is pretty sweet. It’s what Fink and darwinports on MacOSX aspire to, but don’t quite reach. Want to install emacs? It’s just a quick sudo apt-get install emacs away. Easy peasy. Databases, ImageMagick, etc… All trivially installed and updated.
So far, setting this server up has been absolutely trivial. And it’s so stinky fast that it should serve the project for quite some time. I might need to set up an Ubuntu client or server locally to play a bit more. It’s not quite MacOSX, but from a server perspective, it’s pretty close. Actually, having spent about 6+ years dabbling in MacOSX’s UNIXy innards, running an Ubuntu Server is not much of a stretch. The biggest adjustment is learning where all of the various bits are installed, but that’s easy. I’ll be spending a fair bit of time over the break, getting my feet wet in Ubuntu. Should be fun!
I just upgraded our TLC development/staging/small-deployment server from MySQL 4.0 to 5.0.22. I'd never upgraded a MySQL server before (always just installed a fresh copy on a new box, or updated along with MacOSX) so I wanted to do some testing before making the plunge on a deployment server. We've got a bunch of databases on that box, running everything from weblogs.ucalgary.ca to some custom apps written here.
I did a quick RTFM , but the MySQL manual recommended not jumping right from 4.0 to 5.0 using the normal upgrade process. It said to go to 4.1 first, then to 5.0. So, I did some more Googling, and realized that a full mysqldump and restore would do the trick, without requiring the milk run through 4.1.
I installed a fresh copy of MySQL 5.0.x on my desktop box, did a full mysqldump from the server using:
mysqldump -u root -p --opt -Q --add-drop-table > mysqldump.sql
That gave me a 400+MB SQL file, handy for a backup, or for migrating between copies of MySQL. I copied the file to my desktop, and ran this:
mysql -u root -p < mysqldump.sql
mysqladmin -u root -p --flush-privileges
And, it Just Worked™ – so the data should safely migrate this way. I did some testing with apps – Drupal etc… and thinks behaved as expected. It takes longer to dump/restore than just updating the MySQL server, but it's safe. And all database users and privileges were intact, so everything should hook up just fine.
Then, I did the same on the server. I killed MySQL, which was still running version 4.0. I ran the installer (both MySQL 5.0 and the StartupItem) via SSH (sudo installer…) and it took care of setting stuff up. But, the old MySQL didn't shutdown cleanly, so I had to do the unthinkable – reboot the box. I know there's a cleaner, more "official" way to clean stuff up, but the box had been up for a couple months, so a reboot wasn't the end of the world.
When the server came back up, MySQL was running as expected. Then, it was a simple. First, I told my shell to use the new copy of MySQL, then imported the data:
alias mysql=/usr/local/mysql/bin/mysql
alias mysqladmin=/usr/local/mysql/bin/mysqladmin
mysql -u root -p < mysql.sql
mysqladmin -u root -p --flush-privileges
And all of our apps are up and running on a shiny new copy of MySQL. The previous version of MySQL is still on the server (but not running) with all data still safe in its own directory, so if something catastrophic has happened, reverting will be trivial.
Now, to upgrade my copy of Moodle to 1.6, which is what prompted the whole MySQL upgrade process in the first place…
