Alakazam is now up and running, and houses several folks that moved as well as several new sign ups. Since this are running smoothly there it’s time to address the rest of you antiquated folks.
We’re going to step each thing up slowly so that we can narrow down what upgrade is causing what problem, should you have any problems.
June 16, 2008
On June 16th, we’re going to cease offering PHP4 across all 4 remaining servers and move exclusively to PHP5 only. This is for security reasons, both for the server and because any php scripts that aren’t compatible with PHP yet aren’t really going to be scripts we want on the servers. You have had many, many months with both to prepare for the move over where you had both available to you and we feel it’s now time.
July 7, 2008
We’ll upgrade to MySQL 5 from MySQL 4. Again, we have a box with 5 now - if you have any question or concern that your site will not work with MySQL 5 or that you’ll need to do work on it to make it compatible, you need to speak up now. After July 7th, everyone will have 5 and if you need 4, you won’t be able to find it here.
August 4, 2008
Finally, we’ll be upgrading Apache. The only real issue will be that your password protection will need to be redone after the upgrade. If you have password protected directories, you may want to submit them to us so we can make sure they are re-secured.
Please note that the following programs have no need to be tested and are compatible with standard installations:
We wanted to let everyone know that there are more tutorials on the support page - we’ve newly added flash tutorials showing you how to do the most common functions in Drupal. Thanks to a comment on one of our blog posts, we’ve become aware that Drupal is somewhat of a bear in the “how the heck do I do this” department, and we thought we’d add them as we know we have a quite few people using it.
We have two announcements - one, “we can has a new server”. We’re going to be working out the specs and likely bringing it to roaring life at the end of this month or the beginning of next.
This will also coincide with our MySQL5 implementation plan. (everyone shiver and make appropriate groaning noises).
We’ll bring the new server online with MySQL5, and anyone that wishes to move to the new box at that time will be more than welcome to pick up and go over there - just submit a support ticket when you see the announcement (and which Pokemon its likely to be named after) and we’ll get you over there lickety split.
For the rest of you? Well, you have a choice - we’ll provide a mirror of your site without changing your DNS so that you can test at no charge on the new server. You’ll need to use that time to work out the kinks, make any upgrades, check out compatibilities and lack thereof during that one week. If you take advantage of it, that’s great, and you’ll be better prepared.
If you don’t, we’re upgrading the four “old” servers a month or two after that, and if you didn’t test and your stuff doesn’t work, we’ll have lots of comforting sympathy for you but we will not, under any circumstances, downgrade the servers because a few old programs have some issues. We may decide to leave one server at four, but that will depend entirely on how widespread the problem is, and we’re not promising anything - and the only way we will know is if you test. If you don’t test, we’ll upgrade ‘em all if there are very few people with issues.
Watch the blog feed for more information as it becomes available, and let us know if you have any questions.
For those folks wondering about the empty database in their cPanel (should they have it), the following explanation was provided by cPanel:
Build 21703 provided two fixes that create the behavior being described in this thread. Earlier I posted these, but here is a more thorough description.
Prior to build 21565:
1. And any all accounts restored from backup (and transfers) would have an empty database created. This database name was the same name as the user (e.g. user name is cpken, database name thus is cpken). This database creation was not intentional, it was a bug.
2. Databases that were the same name as the user (user name is cpken, database name is cpken) were not accounted for in the tally of databases used by an account, nor were they displayed in the interface.
Builds 21565 and newer:
1. No longer creation the empty database upon account restoration/transfer
2. Display and account for all databases associated with a user name.
With that said, users currently cannot delete a database whose name matches the user name (db name of cpken as opposed to cpken_name). This matter should be attended to in the next build(s).
In other words, it’s a woops, and you are unable to delete the database yourselves. Just submit a support ticket, and we’ll nuke the little sucker for you.
Part of why people like hosting here is that we tend to listen to our clients … and we have to admit, the barn door blew in when we announced the upgrade to MySQL 5. Seems a bunch of you don’t know how to test, don’t know how to do database dumps, and don’t know what to do if, when the upgrade comes, things crash.
We need to get on up into modern times (and ya’ll did live through the PHP upgrade, you know), but we don’t want to simply shove everyone into 2008 with no paddles. We’re going to hold off on doing the upgrades for those who want to do some testing, and we’re going to work on providing a way for you to test, as we do have a spare server laying around with MySQL 5 on it.
Once we get the testing situation, and how we’re going to manage it, set up, we’ll post it on the chat list. We’re not sure at this point whether we’ll be charging a small fee to do it or not, but we will let you know as soon as we find the easiest way to do it.
Due to popular demand, we will begin upgrades on MySQL 4.1 to bring it to version 5 starting the week of Monday, March 31st, 2008 and continuing throughout the week until all shared and fully managed dedicated servers are completed. If you have a semi-managed dedicated server or a fully managed dedicated server, you must request this upgrade, it will not be done automatically for you.
This upgrade will entail a brief period of database inaccessibility due to the fact the we need to shut the database server down to perform the upgrade. Once it has been upgraded we will restart the database server.
This will not affect any other services on your machine. Mail and web services should run fine. PHP and other scripts that rely on MySQL for functionality will be temporarily disrupted.
This should only take 15-30 minutes to complete per server if all goes well.
Please make certain that your scripts are up to date and compatible with mysql 5.0.