This is just mostly just random notes for myself, after yesterday’s server move, so when/if I have to do this again, I don’t miss these things.
- Make sure that php.ini is edited to have “register_globals” turned on, otherwise it totally screws up Sunray’s site.
- Make sure your root password for your old server doesn’t have a “+” sign in it as it totally screws up cPanel’s account transfer functions.
- Make sure you get rid of the zerobyte “/etc/eximmailtrap” file, as it conflicts with e-mail form scripts.
- Don’t rebuild Apache with SNMP support (at least not via cPanel) as it won’t build in curl.
- You need to manually setup hard-coded DNS subdomains, as cPanel’s transfer functions always seem to miss them unless they were created with cPanel.
- Fix Sunray’s internal server so it only allows logins from the new IP address.
- Symlink pico to nano (ln -s /usr/bin/nano /usr/bin/pico) so you don’t keep typing “pico” and wondering why it’s not working (yes, I’m not one of the cool kids, and I don’t use vi, emacs, or whatever else all you punks use).
- Added on 1/21: Make sure CRON jobs on old server are turned off so this doesn’t happen.
- More to come, I’m sure…
Feel free to contribute below if you can think of any gotchas that you’ve run into before.
Comments
Hey! You’ve pinched my notes!
Admittedly, I also run ELS (Easy Linux Security) from http://www.nsonetworks.com to install the Firewall, Brute Force Detection, MySQL tweaks, Zend Optimiser etc.
Actually, I use Platinum Server Management (my reseller uses it on her other servers) and they include all that kind of stuff in their package (along with great support).
But ELS looks pretty sweet, though — thanks!
Sorry Mailing List Readers
Add another to my to-do list when I move to a new server: turn off the automated sending of mailings from the old server. This has been fixed, so you…
“Make sure that php.ini is edited to have “register_globals” turned on, otherwise it totally screws up Sunray’s site.”
*Or* you could rewrite all the variables 😉
You could add a set_ini() line to Sunray’s site that will change the value in the local scope. If you constantly have to change your PHP settings, you might consider building PHP yourself and deploying the whole thing in one go when you move servers. Drop the database, and you should be good to go in about half an hour.
Why are you constantly moving your server, anyway?
When I said “drop the database”, I didn’t really mean DROP the database, but you know..
My reason for moving, Paul? Depends, but most economics.
The first time I moved, many years ago, was because I was out growing my shared hosting environment and they were threatening to kick me off because I was pushing it too hard with this site (and I was cheap). I thought by going to VPS, I’d be OK, but this site bulldozed that, too.
During the moves between those two companies, and into the third one (the company I’m still with now, just on my third server), I became friends with one of the help desk techs (she worked at both of those companies) so after my VPS died I moved onto one of her extra dedicated servers for dirt cheap if I helped her maintain it. Then she got a meatier server, and then moved me on to that.
This last move (last week) is with the same company, but it’s my own dedicated server this time — so I won’t have to worry about one of her clients bringing the server to the ground (which one of them was about to). It was a steal of a deal that I couldn’t pass up, and I took the opprotunity because a few companies here are helping me recover the costs.
This will, however, be the last move in quite a while.
Jake just wanted a new toy. 🙂 hahaha