Product SiteDocumentation Site

3.2. How To Migrate

In order to guarantee continuity of the services, each computer migration must be planned and executed according to the plan. This principle applies regardless of which operating system is used.

3.2.1. Survey and Identify Services

As simple as it seems, this step is essential. A serious administrator truly knows the principal roles of each server, but such roles can change, and sometimes experienced users may have installed “wild” services. Knowing that they exist will at least allow you to decide what to do with them, rather than delete them haphazardly.
For this purpose, it is wise to inform your users of the project before migrating the server. To involve them in the project, it may be useful to install the most common free software programs on their desktops prior to migration, which they will come across again after the migration to Debian; LibreOffice and the Mozilla suite are the best examples here.

3.2.1.1. Network and Processes

The nmap tool (in the package with the same name) will quickly identify Internet services hosted by a network connected machine without even requiring to log in to it. Simply call the following command on another machine connected to the same network:
$ nmap mirwiz
Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-29 14:41 CEST
Nmap scan report for mirwiz (192.168.1.104)
Host is up (0.00062s latency).
Not shown: 992 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
5666/tcp open  nrpe
9999/tcp open  abyss

Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
If the server is a Unix machine offering shell accounts to users, it is interesting to determine if processes are executed in the background in the absence of their owner. The command ps auxw displays a list of all processes with their user identity. By checking this information against the output of the who or w commands, which give a list of logged in users, it is possible to identify rogue or undeclared servers or programs running in the background. Looking at crontabs (tables listing automatic actions scheduled by users) will often provide interesting information on functions fulfilled by the server (a complete explanation of cron is available in Odjeljak 9.7, “Scheduling Tasks with cron and atd).
In any case, it is essential to backup your servers: this allows recovery of information after the fact, when users will report specific problems due to the migration.

3.2.2. Backing up the Configuration

It is wise to retain the configuration of every identified service in order to be able to install the equivalent on the updated server. The bare minimum is to make a backup copy of the configuration files.
For Unix machines, the configuration files are usually found in /etc/, but they may be located in a sub-directory of /usr/local/. This is the case if a program has been installed from sources, rather than with a package. In some cases, one may also find them under /opt/.
For data managing services (such as databases), it is strongly recommended to export the data to a standard format that will be easily imported by the new software. Such a format is usually in text mode and documented; it may be, for example, an SQL dump for a database, or an LDIF file for an LDAP server.
Database backups

Slika 3.2. Database backups

Each server software is different, and it is impossible to describe all existing cases in detail. Compare the documentation for the existing and the new software to identify the exportable (thus, re-importable) portions and those which will require manual handling. Reading this book will clarify the configuration of the main Linux server programs.

3.2.3. Taking Over an Existing Debian Server

To effectively take over its maintenance, one may analyze a machine already running with Debian.
The first file to check is /etc/debian_version, which usually contains the version number for the installed Debian system (it is part of the base-files package). If it indicates codename/sid, it means that the system was updated with packages coming from one of the development distributions (either testing or unstable).
The apt-show-versions program (from the Debian package of the same name) checks the list of installed packages and identifies the available versions. aptitude can also be used for these tasks, albeit in a less systematic manner.
A glance at the /etc/apt/sources.list file (and /etc/apt/sources.list.d/ directory) will show where the installed Debian packages likely came from. If many unknown sources appear, the administrator may choose to completely reinstall the computer's system to ensure optimal compatibility with the software provided by Debian.
The sources.list file is often a good indicator: the majority of administrators keep, at least in comments, the list of APT sources that were previously used. But you should not forget that sources used in the past might have been deleted, and that some random packages grabbed on the Internet might have been manually installed (with the help of the dpkg command). In this case, the machine is misleading in its appearance of being a “standard” Debian system. This is why you should pay attention to any indication that will give away the presence of external packages (appearance of deb files in unusual directories, package version numbers with a special suffix indicating that it originated from outside the Debian project, such as ubuntu or lmde, etc.).
Likewise, it is interesting to analyze the contents of the /usr/local/ directory, whose purpose is to contain programs compiled and installed manually. Listing software installed in this manner is instructive, since this raises questions on the reasons for not using the corresponding Debian package, if such a package exists.

3.2.4. Installing Debian

Once all the required information on the current server is known, we can shut it down and begin to install Debian on it.
To choose the appropriate version, we must know the computer's architecture. If it is a reasonably recent PC, it is most likely to be amd64 (older PCs were usually i386). In other cases, we can narrow down the possibilities according to the previously used system.
Tablica 3.1 is not intended to be exhaustive, but may be helpful. Note that it lists Debian architectures which are no longer supported in the current stable release. In any case, the original documentation for the computer is the most reliable source to find this information.

Tablica 3.1. Matching operating system and architecture

Operating SystemArchitecture(s)
DEC Unix (OSF/1)alpha, mipsel
HP Unixia64, hppa
IBM AIXpowerpc
Irixmips
OS Xamd64, powerpc, i386
z/OS, MVSs390x, s390
Solaris, SunOSsparc, i386, m68k
Ultrixmips
VMSalpha
Windows 95/98/MEi386
Windows NT/2000i386, alpha, ia64, mipsel
Windows XP / Windows Server 2008i386, amd64, ia64
Windows RTarmel, armhf, arm64
Windows Vista / Windows 7-8-10i386, amd64

3.2.5. Installing and Configuring the Selected Services

Once Debian is installed, we need to individually install and configure each of the services that this computer must host. The new configuration must take into consideration the prior one in order to ensure a smooth transition. All the information collected in the first two steps will be useful to successfully complete this part.
Install the selected services

Slika 3.3. Install the selected services

Prior to jumping into this exercise with both feet, it is strongly recommended that you read the remainder of this book. After that you will have a more precise understanding of how to configure the expected services.