The best practice for maintaining a Linux server is to run the smallest optimal set of software. That is, there should be nothing running that isn’t being used, and ideally nothing should be installed that isn’t necessary. But the default installation will give you more than you need. The fat needs to be trimmed.
There are several good reasons for doing this:
- Minimize resource utilization – disk space, network bandwidth, CPU time and RAM are all finite; there is no reason to waste these quantities on processes which don’t have a purpose.
- Greater security – the fewer open ports and running processes, the few vulnerabilities there are likely to be on the system.
- Easier maintenance – with less software there are fewer dependencies to worry about, less to upgrade, and patching is less problematic.
- Elegant simplicity – management of a host is easier and cleaner if every component has its utility and nothing is extraneous.
A server freshly built from a Linux DVD – whatever distribution it is – will be automatically installed with a set of software suitable to its function. During the installation process, one selects “Basic Server” or “Desktop”, and a predetermined selection of software packages are selected accordingly. The thing to remember is that this selection is for a general case, and is rarely exactly applicable for any one host in particular. For example, if one were to select the “Web server” option for some distributions, one might by default get both Apache HTTPD and NGINX, although only one of these would probably be used at a time. It would be necessary to uninstall the extra package.
In Part 1
of this series, I delved into the installation of the
. In this, Part 2, I deal with data migration from a standalone system (the system being migrated into the virtual environment) to a newly created DomU (a new virtual machine which is going to replace the stand-alone system).
When it comes to data migration, it can be said that just like any other system admin’s tasks, only your imagination can pose limitations on how you may approach the assignment. This essentially means that your creativity in tackling this task depends on the following:
- Your understanding of the system being migrated and the environment around it.
- The tools that you have on hand.
Depending on the understanding I have, I pondered for a while on how to approach the task. Then, I concluded that I could either migrate the whole stand-alone system (migrate the whole system) as it is; or simply migrate fundamental roles’ related data (migrate only necessary services’ related data).
Several years ago I was hired as a Linux System Administrator to consolidate several network services into a Xen virtual environment. Even though Xen was already the incorporated virtual machine manager (VMM) distributed with Redhat Enterprise Linux 5 (rhel5), I could not find any quick guide to help me tackle the task. To this day, there are very few clear how-tos when it comes to virtualization using Xen. Therefore, I am writing this quick guide hoping that it’s going to be a valuable reference for anyone who opts to use Xen rather than any other VMM out there.
In case you are not familiar with Xen, it was a fruit of a research project conducted at the University of Cambridge back in the early 2000s. The first version came out in 2003. In 2007 Citrix Systems bought its source code and later the same year made the source public through Xen Project.
When one has decided to consolidate servers or services into a Xen’s virtual environment, one is faced with a couple of choices to make: 1) Select Virtual Machine Type; and 2) Select Migration Method.