Torqzone

Some times it happens, that the server time zone or time is set incorrectly. Normally this doesn’t affect web applications, however for certain types of servers, that deal with external data this is very important. An example is a mail server. If time zone data is set incorrectly it will be specifying invalid data in sent messages causing email clients to show emails from the future or way back from the past.

Changing time zones on a server is easy. First you need to check which zone is configured now. This is done through the date application. It should return something like this:

Mon Nov  3 12:02:24 EET 2008

The TZ data files are located in /usr/share/zoneinfo. To change the TZ on the server you need to create a link from the respective TZ and replace the /etc/localtime symlink.

For example you could use

ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

This will set the TZ to Berlin/Europe. After this the time will probably be broken, so you need to synchronize the time with an external server to make sure it is configured properly.

This is done with the rdate utility. You could type something like this (rdate needs to be installed first):
rdate -s time-a.nist.gov

After this you need to sync the system clock with the HW (Hardware) clock. This is done as follows:

hwclock –systohc

And now you should be done. Use the date application to verify the time and TZ.

Abstract

This article will explain how to move a live and running site from one server to another with minimal downtime. Please note, that in order to follow you will need ssh permissions on both servers and high-level permissions (root) on the server to which you are transferring.

Overview of the procedure

When transferring a live site from one server (a shared hosting account for example) to another server (a VPS or dedicated) a major concern is downtime of the live website. In order for the website to get transferred you would need to copy the webite over to the new server and change the DNS pointers to the new server for the domain your website uses. For a static website this is as easy as that, but what if your website is dynamic and users can change database records and upload images to the website. A simple copy of the website will not work, because some images and database records will be lost.

To avoid this problem we are going to mount all the directories, that users are able to update using NFS and will allow network access to the mysql database from the old server.

For the example I will be using the debian operating system. You will be able to follow easily using other setups as well.

Preparing the new server

Ok, so you received a new server and now you need to prepare it for the website. I will not discuss the process f configuring Apache/PHP/MySQL or any other technology your website uses, as this is very user specific.

First you need to install the NFS tools. On Debian the packages you will need are nfs-server and nfs-client. You need to install them. After they are installed you will see, that an /etc/exports file appeared. This is where you will be adding mountable directories.

Let’s say I want to transfer a domain name example.com from the old server with IP of 62.62.62.62 and on the new server (63.63.63.63) I plan to use it at /home/admin/domains/example.com/public_html . Basically all the web-accessible files will be stored in the public_html directory.

I would recommend, for testing purposes to try and make this directory mountable and mount it on the old server. To do this add the following line to /etc/exports file

/home/admin/domains/example.com/public_html 62.62.62.62(rw,no_root_squash)

then type

/etc/init.d/nfs-kernel-server restart

Note, that  your nfs restart script could be different.

This will allow the old server with IP 62.62.62.62 to mount the public_html directory.

Now, log in to the old server and mount this directory somewhere. I would like to mount it into /tmp/example.com

mkdir /tmp/example/com

mount 63.63.63.63:/home/admin/domains/example.com/public_html /tmp/example.com

At this point the folder will be mounted and ready. Now, you should put a maintenance notice on the website, so that users do not update it anymore while you are copying the website and the database to avoid any corruption of the system.

Start copying your website to the new server (copy the website to the /tmp/example.com directory. Since this is an NFS share it could take a while to copy, so use cp with -v parameter, so you could see the files being copied.

Database Copy

While the website is being copied you need to create a database dump on the old server. To do this simply login through the shell and type

mysqldump –user USERNAME –password DATABASE > database_dump.sql

This will dump all your data into the database_dump.sql file.

Copy this file to the new server using any method you prefer. Then on the new server type:

mysql –user USERNAME –password DATABASE < database_dump.sql

 This will restore the database on the new server. It may take a long time to restore depending on your MySQL settings and the size of the database itself.

Enabling remote access to the new database server

By default MySQL does not allow remote connections and all users are created to be able to login only from the local server. To fix this you will need to grant all permissions to the database you use to the user, who could connect from the old server (62.62.62.62 in our case). To do this from the command line use:

grant all on DATABASE.* to USER@’62.62.62.62′ identified by ‘PASSWORD’

Now your old server can access the database at the new server.

Also, please check the mysql configuration file /etc/my.cnf or /etc/mysql/my.cnf and comment the line which says

skip-networking

otherwise you will not be able to use the networking at all with mysql.

Mounting updatable directories 

Ok, so your website is now copied to the new server and you are ready to configure mountable directories.

Let’s assume, that in our case we have 1 updatable directory, which is images and it is in the root of the website.

You need to update the /etc/exports file with the following:

 /home/admin/domains/example.com/public_html/images 62.62.62.62(rw,no_root_squash)

And commend out the other line we added previously to stop mounting the public_html folder and restart the nfs server.

Then go to the 62.62.62.62 server. I will assume, that the website was in /var/www/htdocs/example.com

You will need to type the following in order to mount the images directory:

mv /var/www/htdocs/example.com/images /var/www/htdocs/example.com/img_bkp

mkdir /var/www/htdocs/example.com/images

mount 63.63.63.63:/home/admin/domains/example.com/public_html/images /var/www/htdocs/example.com/images

Assign your permissions to the directory (depending on your setup you might need to change the owner of the directory as well).

Restarting the website and waiting

Now, you need to reconfigure the old website at 62.62.62.62 to use the new database server at 63.63.63.63. Configure the website respectively and fill in the username and password of the new mysql server and then remove the maintenance mode from the webite. It should continue working as normal, but the database and user updatable directories are now at the new server.

After this you can point the dns to the new server and once it propagates your website will be running off the new server. This usually takes 12-48 hours.

Overselling is a term that is being thrown around in hosting related forums and articles way too often. It means, that someone is selling more, then they can provide. Generally, this refers to bandwidth and disk space, however recently this is also the case with CPU as well. So why overselling is bad and why it is good?

First off overselling is great for web hosting companies. When someone vists a website and sees there 500GB of disk at 15TB transfer for $5, they think: nice, what value for money. And yes, it would have been were it true. This is great for web hosts though, as customers usually fall for this and buy the package.

Now, lets look at this from the customer perspective:

Good things

1. It is common, that people over estimate their hopes in terms of website planning: You might think initially, that ok, I think my website will need 500GB transfer per month, but end up using up only 500MB. The same goes for disk space: on average people use 50MB of space for their websites. Sometimes, however 1 person decides to use those 500GB and if the host has,say 1TB of space in the server that one person can get away with using all the limit completely. So this is good for that one person.
2. Also, it’s great because you are getting more for less (especially, that happy person with 500GB for $5)

Bad Things

1. It is not fair to customers. Basically hosting providers are lying in a sense, that they cannot possibly deliver what they are advertising (to everyone).
2. Servers are usually overloaded. If you used such hosting providers previously, then you surely know how slow cPanel was loading or how slow your website was at times.
3. You might get suspended for using too much resources easily: suppose your site was digged (digg effect) and you started receiving thousands of visitors. You will be instantly suspended for this, as the server was working on it’s limit even before this happened.
4. It’s also unethical: every customer get’s taken for a ride by the hosting provider.