Mostly about my amusement

Tag: vps (page 1 of 1)

The replacement VPS didn’t go BOOM!

Yesterday I moved my WordPress network from one VPS in Chicago to Atlanta (different VPS hosting company). I like using a VPS because it maintains my illusion of being in control of my server.

*Drinks more coffee*

Surprisingly it went well. Except for missing a couple of PHP modules I had no problems and the site has been stable overnight.

If you plan to do this then give this Codex article a read. Of course I didn’t read it myself, it’s much more fun for me just winging it.

Create and configure my new VPS

I installed an image of Ubuntu 13.04 and made sure SMTP was configured to work. Apache2, PHP, mysql and mod_ssl were added and activated as well.

That was a surprise for me. The default image installs a ton of stuff that I don’t think I’ll ever need or want. I would have preferred to use a 14.04 LTS image (not available, too new) but that one is still maintained so it’s all good.

Creating the new empty database was straight forward. I used the same database name and user from the original VPS setup. Configuring the vhosts was just a matter of copying the old config files and making sure the certs and directories are all preserved.

Set DNS TTL on stun

My default DNS TTL (time-to-live) is 1800 seconds. I wasn’t sure if this would go well or not so I made the TTL 300 seconds (5 minutes). I didn’t change any IP addresses but if I broke something and couldn’t fix it then I was looking at only 5 minutes for it to come back to life.

Copy the files and database

My WordPress network has around 1.4 GB of file data from the last 7 years or so and the mysqldump was about 70MB . The file copy was just scp -r and the mysqldump command was just for that one network database.

Importing the database was just

zcat dumpfile.sql.gz | mysql -u name -p databasename

Once that was all done I updated my DNS IP and waited.

And I waited. And waited some more.

I could see in my access log that my new site was getting hits but I was still hitting my old web server (I was tailing the old logs in another windows) well after 5 minutes.

What the heck? It’s DNS. Setting the TTL just works. Except when it doesn’t.

I was using Google Chrome and that has it’s own application level DNS cache. It has a DNS cache that apparently doesn’t honor the TTL on the record.

Once I cleared that cache then I could see myself hitting the new IP address.

Nothing broke! Fantastic.

Next steps

Once I’ve confirmed that I have moved everything off the old VPS and onto the new then I’ll rebuild the old one and might re-do this whole exercise in the other direction. I’m sure the unstable nature of the old one is due to some dumb thing I did code I installed that’s running amok.

In the meanwhile I’m going to enjoy some nice stability and uptime for my site.

Note: The CC image above was a result of my typing “controlled implosion” into the WP Inject WordPress plugin. It’s a very cool plugin for finding CC images and I plan on leaving a review on WordPress.org sometime.

Featured image photo by Savannah River Site

So far so good with Nginx

This blog is running on a VPS provided by Slicehost. It’s the 512MB package and I have no complaints. The network connectivity is pretty good too.

512MB is not what it used to be. When I run out of ram, mysql and Apache2 both go insane. My VPS becomes unusable and I end up hitting the remote hard reboot button. There is even a Slicehost iPhone app for that (which I have installed).

I can upgrade to 1GB of RAM but I’d prefer to create a smaller memory footprint. I am constantly floating between 1MB and 90MB free and adding a whole 512MB seems like overkill. Switching to Nginx is my attempt to take care of that. And besides, they have a really cool logo.

Installing it was a breeze. Go over to Donncha O Caoimh’s blog and read up on how to get WordPress, Nginx, and WP Super Cache working. I used his notes but made some changes to my installation. The only thing I did was disable the /etc/nginx/sites-available/default and created virtual server specific files. Also I don’t use WP Super Cache, I just don’t have the traffic. I started with a copy of the default file and added a few lines.

For example, blog.dembowski.net’s file looks like this:

server {
        listen   80;
        server_name  blog.dembowski.net;

        access_log  /var/log/nginx/blog.dembowski.net-access.log;

        # Hot-linking bad, expect when I let it.
        location ~* (.jpg|.png)$ {
                root   /srv/www/vhosts/$server_name;
                valid_referers server_names blocked none
                        *.dembowski.net
                        *.google.com
                        *.feedburner.com
                        *.pingdom.com;

                if ($invalid_referer) {
                        return 403;
                }
        }

        location / {
                root   /srv/www/vhosts/$server_name;
                index  index.php index.html index.htm;

        # if the requested file exists, return it immediately
               if (-f $request_filename) {
                       break;
               }
        # all other requests go to WordPress
               if (!-e $request_filename) {
                       rewrite . /index.php last;
               }

        }

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
                root   /var/www/nginx-default;
        }

        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        location ~ .php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /srv/www/vhosts/$server_name$fastcgi_script_name;
                include fastcgi_params;
        }

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        location ~ /.ht {
                deny  all;
        }
}

I am lazy efficient enough that all I need to do is replace the server_name and access_log lines for each virtual web host. I tried to use $server_name in the access_log line too, but it didn’t take. That created a file name called $server_name-access.log.

Each of my virtual hosts were already setup in Apache2 this way. All I had to do was get php5-cgi working, shutdown Apache2 and bring up Nginx. I made it permament by running these commands as root:

# update-rc -f apache2 remove
# update-rc -f nginx defaults

This hasn’t really made a big difference in my memory footprint but my blog is more responsive. See this Pingdom report for performance numbers. I may yet upgrade to the next size slice.

Upgrade of VPS from Ubuntu 6.06 LTS to 8.04 LTS

My upgrade from Ubuntu 6.06 LTS = FAIL.

Last week I created a VPS on Slicehost.  I’ve been using Tektonic for a while now and have no complaints.  The support is very good and I can backup my VPS for when I need to.

I’m using Slicehost because I don’t want both of my domain DNS servers on the same provider. They offer Ubuntu 8.04 LTS, runs on top of Xen, and provide console access via an Ajax web front end.  You need to pay extra for a backup option. Aside from that one little point, using Slicehost is ridiculously easy and very manageable. They eat their own dog food and it shows.

On my Tektonic VPS it’s running on top of Virtuozzo.  No console just ssh but I do get to make a backup of my VPS and re-installing is a breeze. My only complaint is that it’s running Ubuntu 6.06 LTS which is a little dated.  For example the subversion client is 1.3.2 and I’d like to see more current versions such as 1.5.x.  On Ubuntu 8.04 LTS I just added the backports repository and I get current versions of packages.

Switching to Ubuntu 8.04 LTS should be simple. As root I ran these commands:

apt-get update
apt-get upgrade
apt-get install update-manager-core
do-release-upgrade

This is a seamless process and aside from asking me some questions, I had no issues.  The only issue I had is when I rebooted my VPS, it left the VPS un-bootable.  The support tech that I chatted with had not seen that before.  My VPS would not even start and I had to re-install it.

I’m now restoring the VPS to the backup I made yesterday, so it’s not all a total wash.  Most likely I’ll work with Tektonic to get 8.04 LTS on that slice provided they offer it.  Ubuntu 6.06 LTS is still supported so aside from consistency across servers, this is not a big deal for me.

A brown out or “why DR planning is your friend”

My server is in the basement of my home. In Long Island. Where we have brown outs like the one we had today.

The clocks came back and had to be reset but my Linux server apparently did not, or maybe it’s the cable modem. Hard to tell exactly as I am not at home. Fortunately I backup my server every night to a VPS hosted by TekTonic. It’s $15 a month and and serves as a backup DNS server for my domains. It’s not the fastest but it’s good enough for my traffic.

So once again I updated my DNS record for blog.dembowski.net, ran the restore script on the VPS, updated my wp-config.php and poof I’m running.

The best part was that I did this using the ssh client on my Blackberry Pearl! It works but using vi on that small screen is not something I would recommend. I know where all the pieces are but if I we hunting and pecking I would not be able to get the blog up and running.

Once I figure out what is going on with my basement server I’ll do the process in reverse.

Webserver problems

I have been having some weird response times from my WordPress installation. I’m running Opensuse 10.0 which comes with PHP 5.0.4.

PHP caches like APC and XCache don’t work with 5.0.4. I can’t just upgrade the distribution since a) this is a VPS and only 10.0 is offered and b) that would be over the top.

First thing I tried was add the software repo at http://software.opensuse.org/download/server:/php/SUSE_Linux_10.0/. I ran yast, checked php5 and poof it installed. Now I was at php 5.2.1. I kept track of the RPM’s and kept the replaced ones in case the bad thing happened.

Both cache apps are built and installed the same way

Extract the tar.gz file
phpize
./configure –some-options
make && make install

And that’s it. Some php5.ini modification and I’m in business.

APC compiled but blew up php in strange ways. Xcache installed and worked well. Even came with an admin page for checking the stats.

WordPress and some of my plugins don’t seem to like 5.2.1 and even with Xcache I was not seeing an improvement. The problem is that the initial response from the web server is 3-10 seconds to get data. I’ve got WP-Cache installed to see if subsequent page loads are faster (they are) but I think the problem is either my VPS or the network.

I rolled php back to 5.0.4 and removed Xcache. Hopefully the problem will sort itself out.

Virtual Private Servers

According to Wikipedia:

“A virtual private server (also referred to as virtual dedicated server or virtual server, and abbreviated VPS or VDS) is a server run through virtualization in tandem with other virtualized servers on one physical computer.”

Which is a pretty good description. I use TekTonic as my VPS provider and I don’t have a complaint about their service since I get a good uptime. I pay a really good fee and definitely get what I pay for.

Serviceuptime

But I think with any VPS there are things you need to check on. I notice that processes that I need (oh say, my apache web server) will inexplicably die without any reason in the log.

Lately I have not been getting my mailed database backups. I have a cron job that backs up all my blog data and files, and another one on my basement for pulling down the gpg encrypted file so no data has been lost. The mail process died (postfix, only listens on localhost) and a weeks worth of automated mail got queued up. I also need named since this host is a back DNS server for my domain.

I was thinking of doing uber script magic then I realized I should just put the following into root’s crontab.

0,15,30,45 * * * * /usr/sbin/rcapache2 start >/dev/null 2>&1
0,15,30,45 * * * * /usr/sbin/rcnamed start >/dev/null 2>&1
0,15,30,45 * * * * /sbin/rcpostfix start >/dev/null 2>&1

It’s not elegant but it works. I don’t need to know if it was successful or not and this was a quick fix.

VPS Servers

My domain is managed by me on my own name servers. When I moved to Long Island I lost my static IP addresses from my DSL line. So I moved both my DNS servers to Stefan’s house via his DSL line.

Not a good idea for availability. Since both DNS servers were there, any connectivity issues meant my domain disappeared. I had setup my basement server to queue up mail, but if the name servers became unreachable then no one could figure out to send mail to the other box.

Yesterday I went to http://www.tektonic.net/ and ordered a virtual private server from them. I picked the UM1 which is 10GB of disk space, 256MB RAM, on a Dual AMD Opteron 246. I selected SUSE 10.0 paid online and I’m good to go.

It’s a little different. I selected SUSE because that is what I use. Once I setup the yast repository I added bind, apache, php5, etc. and ran the online update. It’s very easy to forget that this is all virtual and on a shared box. The responsiveness is very good. I contacted my domain registrar, updated the record and poof all done.

Just for kicks I moved this blog onto this new server. I’ll see how it goes, but so far there have been no surprises.