Before your migration, you (ideally) made a plan as to what your site’s requirements are, what software you are running, and if there are any extra programs or settings that your sites depend on.
But how do you do that? And, how do you get it set up on the new machine?
I’ll walk you through the general commands I use to determine whats going on in a server once I log in.
The first thing I like to gauge is the age of the OS. This gives me a general idea of the era in which the server was built, and some of the quirks I can expect. Learning these quirks comes down to intuition and experience, and much of it is also situational. Here are the commands I would use for CentOS/RHEL, Debian/Ubuntu, and a general method if either of those fail.
# cat /etc/redhat-release CentOS release 6.10 (Final) # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.5 (stretch) Release: 9.5 Codename: stretch # uname -a Linux hostname.domain.com 2.6.32-754.3.5.el6.x86_64 #1 SMP Tue Aug 14 20:46:41 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
The first command tells me I’m on CentOS 6, which is fairly recent as of this writing. CentOS 5 or below could introduce issues when moving to the latest available version, CentOS 7, since they use different default versions and applications for MySQL and Apache.
The second command shows me Debian 9.5, which is the latest available release. I would question at this point the reason for the migration, if we were not changing hosts, since the system is already running on the latest and most secure version.
The final command shows me that we are running a kernel intended for el6.x86_64, which is RHEL 6 variant (such as ScientificLinux).
I next like to get an idea of the resources on the source server, and make sure the target server is going to at least be able to perform the work the source was capable of (unless we are downgrading for cost). This involves checking the processing power, total RAM, and disk size and usage.
# cat /proc/cpuinfo | grep model\ name | wc -l 6 # free -m total used free shared buffers cached Mem: 837 699 138 12 33 233 -/+ buffers/cache: 431 405 Swap: 1999 414 1585 # df -h Filesystem Size Used Avail Use% Mounted on /dev/vda3 72G 57G 12G 84% / tmpfs 419M 0 419M 0% /dev/shm /dev/vda1 190M 59M 122M 33% /boot /usr/tmpDSK 3.1G 2.1G 946M 69% /tmp
I can see from this information that we are on a hex-core server. Leaving off the wc -l from that command will show you the processor type, which in my case was AMD FX(tm)-6100 Six-Core Processor. A bit old, but nothing to sneeze at at the moment.
The total memory on the server is 837MB, around 1GB. When accounting for cache and buffers, the system is currently using 431MB, so we would not want to downgrade from 1GB of RAM. We are also using some swap space, 414MB. So, the system ran out of RAM at some point. Moving up to 2GB or optimizing memory usage would be a good idea.
The primary disk is 72GB, and there is no alternate partition for backups, the home directories, or for databases. All backups, databases, site and OS files take up 57GB, which is 84% of the drive. This is not at a critical point yet, but perhaps the client wants to add more sites, which would increase disk usage. Changing to a bigger server is a good idea, as we would certainly not want to downgrade.
Here’s another example of disk usage analysis:
# df -h Filesystem Size Used Avail Use% Mounted on udev 7.8G 0 7.8G 0% /dev tmpfs 1.6G 58M 1.6G 4% /run /dev/sda1 9.2G 7.1G 2.0G 77% / /dev/sda2 906G 128G 778G 14% /home tmpfs 7.9G 277M 7.6G 4% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup /dev/sdb1 917G 836G 35G 97% /backup tmpfs 1.6G 76K 1.6G 1% /run/user/1000
In this case, there is a separate partition for /home, which shows 128G usage. I can guess that since it received its own partition, this holds the website files. I will want to make sure that whatever partition is used for site storage on the new server, be it /home or /, has sufficient space to store all these sites. There is no dedicated disk for mysql or /var, so the OS and databases are 7.1G, indicating that there are almost no databases on this machine, since the OS takes up at least about 5G on its own (assuming no logs exist).
Additionally, there is a /backup disk installed on a different drive: sdb. This has 97% usage and 35GB free, which is a critical state. I can tell that if the system tried to back up the 128GB /home partition or even just the site files, which likely take up the lion’s share of that disk usage, it won’t succeed, since there is not enough free space for a new copy on /backup. Likely, this system has not been backed up for some time as a result, so attention should be paid during the migration to correct the backup retention schedule and right-size the backup drive to match.
We already know the Linux (L) version. Let’s check the others:
# httpd -v Server version: Apache/2.4.34 (cPanel) Server built: Aug 6 2018 14:27:51 # mysql --version mysql Ver 15.1 Distrib 10.1.35-MariaDB, for Linux (x86_64) using readline 5.1 # php -v ea-php-cli Copyright 2017 cPanel, Inc. PHP 5.6.37 (cli) (built: Aug 21 2018 16:57:13) ...
Our Apache (A) is 2.4, and compiled by cPanel via EasyApache. This double whammy of info also tells me that we are running cPanel on this server, which lets me relax a bit. Now I know where and how to collect other information about the server from cPanel, and, unless we have an inventive developer, the locations of all of the site files, email, and databases.
MySQL (M) is actually MariaDB 10.1, which is a drop-in replacement for MySQL. The approximate identical version from that fork is MySQL 5.7. So, we should make sure that the new machine has at least this version, or higher. Data from MySQL and its various engines is normally very transportable, and I expect dumps from this version of MariaDB to work on MySQL 5.6 and higher. If the source were 5.1 or lower, I would take extra caution when copying databases, since 5.1 and lower have slightly different sql dump structures.
Our final LAMP version, PHP (P), is at 5.6. This is End Of Life, but currently still has security support from the upstream developers. Most PHP applications written for 5.4 and above will work well in the latest available PHP version, 7.2, but thorough testing should be performed if an upgrade is performed along with the migration. Ideally, I would try to install PHP 5.6 on the new server to get best compatibility. Again, the name of the game is a compatible environment on the new server.
Applications running on PHP 5.3 and below may need to have coding changes to work on later versions of PHP, especially since PHP 5.3 and below are no longer available for installation, at least on cPanel servers. I can tell from the first line of the PHP version output, ea-php-cli, that the system is using EasyApache 4, which has concurrent PHP versions available for different sites. I will want to investigate further and see what sites are using which versions, and make sure that the same (or compatible) versions are installed and used on the new machine.
Overall, from the versions I see on the command line, this server is highly migratable, since it is running modern versions which are still supported upstream with security updates, and are available for installation without much work.
I already know from the LAMP version output that this system is using cPanel, but you can check for this or Plesk using these commands:
# cat /usr/local/cpanel/version 22.214.171.124 # cat /usr/local/psa/version 17.8.11
At writing, these are both the latest available versions of cPanel or Plesk. I would be wary of cPanel versions older than 11.56, which are missing some core API calls, or Plesk older than 11, which has different backup methods from newer Plesk versions.
cPanel should keep itself up to date, so if you have an older version, your update settings may be different, or you might have an upgrade blocker. Check WHM to see if there are any warnings about the last upcp failing, and why it was blocked. The most common are an out-of-date OS (such as CentOS 5), or an out-of-date MySQL version (such as 5.0). You don’t need to run a upcp in order to migrate; you can still get all of the information you need directly from the server.
Plesk does not always auto-update to new major releases, so older versions will stay until you migrate or manually update. Again, an upgrade is not strictly necessary to migrate, since you can read your databases and site files right from the machine, as well as major versions and settings.
Many clients utilize non-default applications for serving sites, caching, or referencing data, such as NGINX, PostgreSQL, or Varnish. What’s the best way to tell if you are using one of these?
The simplest way is to ask the client. If they know they utilize any alternative technologies, we can read the appropriate configurations and install matching services on the new server.
But if they don’t have that information, or you are the server owner and don’t remember, we have to ask the server. With half a million inodes used, or more, and the ability to install anything anywhere on the filesystem in Linux, how are we to know?
I use a combination of knowledge of popular alternatives and checking for those services, and looking at port listeners.
# psql --version psql (PostgreSQL) 8.4.20 # ps aux | grep postgres ... postgres 2344 0.0 0.0 216048 620 ? Ss Aug22 1:12 \_ postgres: writer process # mongod -v -bash: mongod: command not found
Here, I know that the most popular alternative database applications are MongoDB and PostgreSQL. Checking for these gets 99% of cases. In the above example, PostgreSQL is installed and running, and MongoDB is not installed.
For the 1% of other edge cases, the client or developer is probably very aware of the software they are using, and can’t wait to tell me all about it.
# netstat -plunt | grep \:80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4285/httpd tcp 0 0 :::80 :::* LISTEN 4285/httpd
Our listener on port 80, used for web traffic, is httpd (Apache). Other programs you might see here are ‘nginx’, ‘varnish’, or ‘java’, which would indicate use of Tomcat or another alternative listener. In most of these cases, the client or developer are abreast of the technology they are running, as most uninvolved clients will use the default of Apache.
# ps acx | grep -E '(memcache|xcache|varnishd|nginx|mongod)' 1863 ? Ssl 0:16 memcached # which ffmpeg convert redis-server maldet node npm tomcat /usr/local/bin/ffmpeg /usr/local/bin/convert /usr/local/sbin/maldet /usr/local/bin/node
Again, I lean on my knowledge of popular programs and alternatives to search for running processes matching explicit program names, and specific system binaries.
The programs I detect with the above two commands, in order, are Memcache, XCache, Varnish, NGINX, MongoDB, FFMPEG, ImageMagick, Redis, Maldet, Node.JS, npm, and Tomcat.
In my case, I found Memcache, FFMPEG, ImageMagick, Maldet, and Node.JS, so I know to install these on the new machine as well, and look for their configuration files or runtime arguments.