06 Aug 2011

cPanel Website Transfer – Part 2 – cPanel to cPanel Migration

Transferring a Website from One cPanel server to another

Skill Level : Beginner

In this post, I will explain how to transfer a website from one cPanel server to other.

Pre Requisites

Server Platform : Linux

User requires : cPanel and SSH access (root) to at-least the Destination server (where the account is restoring)

The Process

From the Target server, Generate a Full cPanel backup of the account using either cPanel or through root shell access.

(i) By cPanel

Click “Download or Generate a Full Website Backup”. Choose Backup Destination as “Home Directory” (Make sure you’ve enough Disk Space before you proceed) and a valid E-mail address to notify you once the Backup is generated.

Once the Backup is completed, a mail will arrive on the E-mail you’ve mentioned above (if specified) and the ‘Backups Available for Download’ will be populated with the name of the backup file generated like :

Do you know why the backup generated is the form tar.gz ? Its because, in the tar format all files are preserved with their appropriate permissions and then its compressed to gz (gzip) for obtaining the least possible file size.

The process in the Target server is finished. Now login as Root in the server which requires the account to be restored. We’ve to download the backup file generated there to this server. There are number of ways to do this. Some are weird

Method 1

If you have the cPanel details of that server, you can use it for FTP access. And since the Backup is generated on the Home directory there, its all about downloading the backup.

# root@server [/home]# ftp oldserver.com or IP

Connected to oldserver.com.
220———- Welcome to Pure-FTPd [privsep] [TLS] ———-
220-You are user number 3 of 50 allowed.
220-Local time is now 17:28. Server port: 21.
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
Name (oldserver.com:root): user
331 User user OK. Password required
Password:
230 OK. Current restricted directory is /
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> get backup-6.2.2011_06-23-57_account.tar.gz

This will download the backup. You need root access to restore it. Before you restore you need to check whether there is an account or domain which already exists by the name which you intend to restore.

cPanel script to check whether the domain/account name exists

# grep account /etc/userdomains

Method 2

Generating a cPanel backup through Remote FTP (Passive Mode transfer)

It is possible to generate a Remote backup of the account in a server, where the backup has to be restored. Go to cPanel -> Backups -> Download or Generate a Full website backup. Select the Backup Destination as Remote FTP Server (passive mode transfer). Follow the screenshot :

cPanel script to restore the account

# nice -n 19 /scripts/restorepkg –skipres <username>

For the script to run, the backup should be in any of the following locations in the server : /, /home, /home2, /home3, /misc, /net, /root, /usr, /usr/home, /var/lib/nfs/rpc_pipefs, /var/tmp, /web

This feature will restore full backups, cPanel backups and cPanel move files in one of the following formats:

cpmove-{USER}
cpmove-{USER}.tar
cpmove-{USER}.tar.gz
USER.tar
USER.tar.gz
backup-{BACKUP-DATE_TIME}_{USER}.tar
backup-{BACKUP-DATE_TIME}_{USER}.tar.gz

Tweet This Post

Comments

03 Jun 2011

Worried about email migrations and mail syncing – get getmail for the rescue

Most of the hosting providers offer free server migration. The free website migration started as early as 2005, in the industry. But only a few providers offer the email migration for a website transfer involving different control panels. So using getmail is the easiest way to transfer emails. All we need is to create the email account in the new server and configure the getmail to transfer the emails.

Download getmail at http://pyropus.ca/software/getmail/old-versions/getmail-4.20.3.tar.gz


wget http://pyropus.ca/software/getmail/old-versions/getmail-4.20.3.tar.gz
tar xzf getmail-4.20.3.tar.gz
cd getmail*
python setup.py install

Now you have to create a getmailrc , the getmail configuration file inside the home folder of the user. getmailrc need not be inside the home directory. You have to create the folder .getmail where getmail keeps a log of the emails retrieved based on each configuration file you may have.You can have multiple destination and retriever sections in one single getmailrc as well.

I must say getmail is so much flexible and rightly coded when the mailsync or imapsync didn’t do their job right or up to the mark. And is an excellent replacement for fetchmail. It supports POP, POP3S, IMAP4 and IMAPS, and also can store the mails retrieved in mbox or maildir format at the destination.

An extremely simple getmailrc file will look like this

[retriever]
type = SimpleIMAPRetriever
server = mail.domain.com
username = direct@domain.com
password = direct

[destination]
type = Maildir
path = /home/cpusername/mail/.direct@domain_com/

The file format should be pretty self-explanatory. You’re telling getmail to fetch your email from server, mail.domain.com by logging to it using the mentioned username and password. The destination section mentions where to store the retrieved email and in which format (Maildir or mbox or mboxrd). Make sure that the cur, new and tmp are there inside those folder though. However getmail may create those folders automatically though.

Finally to get this going, just run “getmail –rcfile getmailrc”

Once you run it, assuming that the getmailrc is properly configured, you will be welcomed by a below output.

getmail version 4.20.3
Copyright (C) 1998-2009 Charles Cazabon.  Licensed under the GNU GPL version 2.
SimpleIMAPRetriever:direct@domain.com@mail.domain.com:143:
 msg    1/3983 (299328 bytes) delivered
 msg    2/3983 (2815 bytes) delivered

Tweet This Post

Comments

25 May 2011

Applying wildcards in GRANT option of MySQL

We had this particular requirement of creating a database user to be used to backup only the cPanel databases. Only recently the database mapping has been introduced by cPanel which allows the clients to create databases without the _ . However on all our client servers, we insist to have the old style with every database has Prefixing On.

Creating the database user to backup only the cPanel databases, means matching the databases with an underscore (_) in its name and that resulted in this particular SQL command to be executed as root user.

GRANT ALL PRIVILEGES ON `%\_%`.* TO `cpdbbackups`@`re.mo.te.ip` IDENTIFIED BY 'p@ssw0Rd' WITH GRANT OPTION;

Read more about the cPanel’s DB mapping at http://www.cpanel.net/blog/integration/2010/05/more-details-about-db-mapping.html

Tweet This Post

Comments

22 May 2011

History of Domain Names

What is a domain name? A domain name is a unique name, kind of like an e-mail address is unique, which is registered in a database called WHOIS through an organization called Network Solutions, Inc. (NSI). The domain name corresponds to a unique set of numbers called an IP (Internet Protocol) address. The reason we use domain names instead of IP addresses is that they are closer to our language. It would be difficult to market a site like this: “Go to 64.233.167.99 or 216.109.112.135 to search the internet!” A much easier way to do this is to say “Go to www.Google.com or www.yahoo.com to search the internet!” (Both Google and Yahoo are trade marked by Google, Inc., and Yahoo, Inc., respectively).

A domain name points to a computer called a “name server”. The name server knows that your domain name corresponds to your web hosting server’s IP address and it routes the person who typed in your domain name to your web hosting server – to your web site. That is how people anywhere in the world can see your web site by typing your domain name.

In 1992, the National Science Foundation granted an exclusive contract to NSI to be the sole registrar of top level domain names. NSI also had a cooperative agreement with United States Department of Commerce (“DoC”). With no competition, consumers were at the mercy of NSI.

In 1998, NSI and the DoC amended their cooperative agreement to allow for competing registrars. NSI was forced to provide domain name registration to the competing registrars at wholesale prices, rather than the standard $34.99 annual fee. NSI still charges $34.99 per year.

In late 1998, the DoC assigned the responsibility of overseeing the transition to a competitive market for domain names and accreditation of new registrars to a new organization called the Internet Corporation for Assigned Names and Numbers (ICANN).

In 1999, ICANN began taking applications from companies who wanted to become registrars – and then capitalism took over: companies had to compete for business. Prices came down and service improved, however some are better than others. For a more detailed history of this transition, visit www.icann.org/registrars/accreditation-history.htm.

Even with the positive effects of competition in the domain name marketplace, the process of internet domain name registration remains a mystery for many.

There are a lot of companies that want to charge you hundreds of dollars to do the simple task of domain name registration for you. There are some registration companies who will charge you $35 just to register a domain. And there are web site consultants who charge over $100 to do the work for you. But you can do it yourself in about 15 minutes and it can cost as little as $1.99 for a year. If you do some research, learn a little and work smart, you can save yourself some money – and some headaches.

Tweet This Post

Comments

09 Nov 2010

How to interpret traceroute results and knowing how traceroute works

How many times have you been asked for providing a ‘traceroute’ output by your Hosting provider, or if you are an admin working with a hosting provider, how many times you’ve asked for the results of traceroute to your client ? Here is an article which explains all about how to intrepret a traceroute results.

What is Traceroute ?

Traceroute is the program that shows you the route over the network between two systems, listing all the intermediate routers a connection must pass through to get to its destination. It can help you in analyzing why the connections from your end to a server is poor, and can often help you to spot what exactly is the problem. It always shows you how your machine is connected to ISP and ISP to the rest of the network, collectively the connection between your end and server.

When we initiate Traceroute, it sends a sequence of Internet Control Message Protocol (ICMP) packets addressed to a destination host. It passes through a series of intermediate routers, which involves a TTL (Time-to-Live) value. TTL refers to how many routers your packet can go through before its expires. Routers will discard a packet when the TTL has reached zero, returning an ICMP error message Code 11 (ICMP Time Exceeded) to the sender.

Executing traceroute

The only required parameter is the name or IP address of the destination host . The optional packet length is the total size of the probing packet (default 60 bytes for IPv4 and 80 for IPv6).

In Unix machines : traceroute server-name (traceroute supportsages.com)
In Windows machines : tracert server-name (tracert supportsages.com)

We will be discussing in detail about traceroute in IPv4, Unix environment

In general, traceroute can be found in /usr/sbin. So the traceroute command can be also run as

/usr/sbin/traceroute server-name

You can check where traceroute is located using the command :

root@server:~$ which traceroute
/usr/sbin/traceroute

Traceroute main options

traceroute [-m] [-q] [-w]

-m : Specifies the maximum number of hops (max Time-To-Live value). The default is 30.
-q : Sets the number of UDP packets per hop. The default is 3
-w : Set the time (in seconds) to wait for a response to a probe. Default 5 seconds

Reading the Output

When a traceroute command is executed, generally it will go for a maximum of 30 hops. On the Internet, most data packets need to go through several routers before they reach their final destination. Each time the packet is forwarded to the next router, a Hop occurs. The more hops, the longer it takes for data to go from source to destination. So the fewer hops it takes to get your data, the faster your access will be. Such 30 hops are counted when executing a traceroute command.

Syntax of the result of a traceroute command

linx-1.init7.net (195.66.224.175) 252.199 ms 253.216 ms 253.359 ms
(Target Server) (IP address) (RTT 1) (RTT 2) (RTT 3)

Here is the full result of a traceroute command :

root@server:~$ traceroute supportsages.com
traceroute to supportsages.com (188.40.112.243), 30 hops max, 60 byte packets
1  192.168.1.1 (192.168.1.1)  24.361 ms  24.371 ms  24.394 ms
2  ABTS-KK-dynamic-001.0.172.122.airtelbroadband.in (122.172.0.1)  38.161 ms  39.415 ms  40.911 ms
3  ABTS-KK-Static-093.32.166.122.airtelbroadband.in (122.166.32.93)  43.195 ms  43.587 ms  48.054 ms
4  ABTS-KK-Static-009.32.166.122.airtelbroadband.in (122.166.32.9)  48.304 ms  49.512 ms  51.947 ms
5  122.175.255.29 (122.175.255.29)  53.312 ms  55.444 ms  57.223 ms
6  59.145.36.230 (59.145.36.230)  235.823 ms  212.100 ms  212.298 ms
7  linx-1.init7.net (195.66.224.175)  252.199 ms  253.216 ms  253.359 ms
8  r1ams2.core.init7.net (77.109.128.34)  252.791 ms  253.008 ms  255.776 ms
9  r1ams1.core.init7.net (77.109.128.145)  255.973 ms  256.212 ms  256.592 ms
10  r1fra1.core.init7.net (77.109.128.153)  345.600 ms  345.906 ms  346.151 ms
11  gw-hetzner.init7.net (77.109.135.18)  358.110 ms  358.565 ms  358.808 ms
12  hos-bb1.juniper2.fs.hetzner.de (213.239.240.243)  359.089 ms hos-bb1.juniper1.fs.hetzner.de (213.239.240.242)  233.990 ms hos-bb1.juniper2.fs.hetzner.de (213.239.240.243)  233.347 ms
13  hos-tr4.ex3k10.rz10.hetzner.de (213.239.227.235)  235.315 ms hos-tr2.ex3k10.rz10.hetzner.de (213.239.227.171)  233.554 ms hos-tr4.ex3k10.rz10.hetzner.de (213.239.227.235)  242.239 ms
14  main.supportsages.com (188.40.112.203)  235.676 ms  241.867 ms  242.565 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Analyzing the Output

The first line shows the target server, that server’s IP address, the maximum number of hops that will be allowed, and the size of the packets being sent. The following line for each system or router in the path between your machine and the target server. Each line shows the name of the server (as determined from DNS, if it cannot perform a Reverse DNS, only the IP address is shown), the system’s IP address, and three Round Trip Times (RTTs) in milliseconds. These RTTs shows the time it took a packet to get from your machine to the server and back again, called the latency between the two systems. By default, three packets are sent to each system along the route, so it shows three RTTs.

Understanding the issues

1) Some times the output may have one or two of the RTTs missing

linx-1.init7.net (195.66.224.175) 252.199 ms * *

In this case, the server is up and responding, but for some reason it did not respond to the second and third packets. This does not necessarily indicate a problem; in fact, it is usually normal, and just means that the system discarded the packet for some reason. These are most often computers, rather than dedicated routers. Systems running Solaris routinely show an asterisk instead of the second RTT.

It’s important to remember that timeouts are not necessarily an indication of packet loss.

2) Sometimes you will see an entry with just an IP address and no server name :

77.109.128.153 255.973 ms 256.212 ms 256.592 ms

This simply means that a reverse DNS lookup on the address failed, so the name of the server could not be determined.

3) If your traceroute ends in all timeouts, like this:

12 gw-hetzner.init7.net (77.109.135.18) 358.110 ms 358.565 ms 358.808 ms
13 * * *
14 * * *
15 * * *

This means that the target host could not be reached. Precisely, it means that the packets could not reach there and back. They may actually be reaching the target system but encountering problems on the return. This is possibly due to some kind of problem, but it may also be an intentional block due to a firewall or other security measures, and the block may affect traceroute but not real server connections.

After the trip time, some additional annotation can be printed

!H Host unreachable

!N Network unreachable

!P Protocol unreachable

!S Source route failed

!F Fragmentation needed

!X Communication administratively prohibited

!V Host precedence violation

!C Precedence cutoff in effect

!<num> ICMP unreachable code <num>.

If almost all the probes result in some kind of unreachable, traceroute will give up and exit.

How it Works

As mentioned earlier, Routers will discard a packet when the TTL has reached zero, returning an ICMP error message Type 11 (ICMP Time Exceeded) to the sender. This is the basic principle behind Traceroute command. This ICMP error message will give more information about each hop in the path.

root@server:~$ traceroute supportsages.com
traceroute to supportsages.com (188.40.112.243), 30 hops max, 60 byte packets
1  192.168.1.1 (192.168.1.1)  24.361 ms  24.371 ms  24.394 ms
2  ABTS-KK-dynamic-001.0.172.122.airtelbroadband.in (122.172.0.1)  38.161 ms  39.415 ms  40.911 ms
3  ABTS-KK-Static-093.32.166.122.airtelbroadband.in (122.166.32.93)  43.195 ms  43.587 ms  48.054 ms
4  ABTS-KK-Static-009.32.166.122.airtelbroadband.in (122.166.32.9)  48.304 ms  49.512 ms  51.947 ms
5  122.175.255.29 (122.175.255.29)  53.312 ms  55.444 ms  57.223 ms
6  59.145.36.230 (59.145.36.230)  235.823 ms  212.100 ms  212.298 ms
7  linx-1.init7.net (195.66.224.175)  252.199 ms  253.216 ms  253.359 ms
8  r1ams2.core.init7.net (77.109.128.34)  252.791 ms  253.008 ms  255.776 ms
9  r1ams1.core.init7.net (77.109.128.145)  255.973 ms  256.212 ms  256.592 ms
10  r1fra1.core.init7.net (77.109.128.153)  345.600 ms  345.906 ms  346.151 ms
11  gw-hetzner.init7.net (77.109.135.18)  358.110 ms  358.565 ms  358.808 ms
12  hos-bb1.juniper2.fs.hetzner.de (213.239.240.243)  359.089 ms hos-bb1.juniper1.fs.hetzner.de (213.239.240.242)  233.990 ms hos-bb1.juniper2.fs.hetzner.de (213.239.240.243)  233.347 ms
13  hos-tr4.ex3k10.rz10.hetzner.de (213.239.227.235)  235.315 ms hos-tr2.ex3k10.rz10.hetzner.de (213.239.227.171)  233.554 ms hos-tr4.ex3k10.rz10.hetzner.de (213.239.227.235)  242.239 ms
14  main.supportsages.com (188.40.112.203)  235.676 ms  241.867 ms  242.565 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

In the first step, an ICMP request was sent from the router (Here it is 192.168.1.1) to 188.40.112.243 with TTL 1. Since the server was not directly connected to the router, an ICMP Error message, Code 11 (TTL Exceeded) was returned along with it’s source address. It is clear that the very first hop to 188.40.112.243 is from our local router. Thus the router IP (192.168.1.1) is shown along with three RTTs.

Traceroute will always search for a Server Name, if possible. So the server name is displayed along with its IP address (if it cannot perform a Reverse DNS, the IP addres is only shown)

Traceroute will again send 3 more packets, with TTL 2. The same thing will happen, the next router will respond with its IP address and RTTs. This will go on until the target server or maximum hop count is reached. If the target server is reached, the ICMP Code 0, Echo Reply will be sent and thus Traceroute knows the job is finished. In this case the target server is reached well before the maximum hop counts. So what we saw is a successful traceroute attempt. No issues at all !

The image explains it all – A series of Routers are skipped for the sake of representation