Product SiteDocumentation Site

3.2. Migrationsvorgang

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. Überprüfen und Identifizieren der Dienste

So einfach es auch scheint, dieser Schritt ist entscheidend. Ein professioneller Administrator kennt die primären Aufgaben jedes Servers genau. Solche Aufgaben können sich jedoch ändern, und manchmal haben erfahrene Nutzer vielleicht auch "wilde" Dienste installiert. Wenn man über sie Bescheid weiß, kann man zumindest entscheiden, was man mit ihnen machen will, anstatt sie nur einfach zu löschen.
Zu diesem Zweck ist es sinnvoll, Ihre Benutzer vor der Servermigration über das Projekt zu informieren. Um sie an dem Projekt zu beteiligen, könnte es nützlich sein, vor der Migration die am häufigsten verwendete freie Software auf denjenigen Desktops zu installieren, mit denen die Benutzer nach der Migration zu Debian später wieder arbeiten; LibreOffice und die Mozilla-Suite sind dafür die besten Beispiele.

3.2.1.1. Netzwerk und Prozesse

Das nmap Werkzeug (im gleichnamigen Paket) identifiziert schnell Internetdienste, die auf einer Maschine laufen und die über das Netzwerk verbunden sind, ohne dass ein Login benötigt wird. Man braucht nur das folgende Kommando auf einem anderen Rechner aufzurufen, der mit demselben Netzwerk verbunden ist:
$ nmap mirwiz
Starting Nmap 7.93 ( https://nmap.org ) at 2024-05-20 00:15 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 Abschnitt 9.7, „Aufgaben mit cron und atd zeitlich festlegen“).
In jedem Fall ist es absolut unerlässlich, Sicherheitskopien des eigenen Servers anzulegen. Dadurch ist es möglich, Informationen wiederherzustellen, falls Benutzer Probleme aufgrund der Migration melden.

3.2.2. Konfiguration sichern

Es wird empfohlen, die Konfiguration jedes verwendeten Dienstes zu sichern, um ihn identisch auf dem aktualisierten Server einrichten zu können. Zumindest sollte eine Datensicherung der Konfigurationsdateien vorliegen.
Für Unix-Maschinen befinden sich die Konfigurationsdateien gewöhnlich in /etc/. Sie können sich aber auch in einem Unterverzeichnis von /usr/local/ befinden. Dies ist der Fall, wenn ein Programm durch Kompilieren des Quellcodes installiert wird. In einigen Fällen sind die Dateien auch unter /opt/ zu finden.
Bei Diensten, die Daten verwalten (wie zum Beispiel Datenbanken), wird dringend empfohlen, die Daten in ein standardisiertes Format zu exportieren, das durch die neue Software problemlos wieder importiert werden kann. Ein solches Format ist üblicherweise dokumentiert und liegt als Textdatei vor. So kann es beispielsweise als SQL Dump bei einer Datenbank oder als LDIF-Datei für einen LDAP-Server vorliegen.
Datenbanksicherungen

Abbildung 3.2. Datenbanksicherungen

Jede Serversoftware ist unterschiedlich, und es ist unmöglich, alle denbaren Fälle im Detail zu beschreiben. Lesen Sie die Dokumentation der vorhandenen und von der neuen Software, um herauszufinden, welche Teile exportiert (und damit wieder reimportiert) werden können und welche manuelle Eingriffe erfordern. Das Ziel dieses Buches ist es, die Konfiguration der wichtigsten Serverprogramme unter Linux zu veranschaulichen.

3.2.3. Übernahme eines vorhandenen Debianservers

Um die Wartung erfolgreich zu übernehmen, kann man einen bereits mit Debian laufenden Server analysieren.
Die erste Datei, die man kontrollieren sollte, ist /etc/debian_version, welche üblicherweise die Versionsnummer des installierten Debian-Systems enthält (sie ist Teil des base-files-Pakets). Falls sie codename/sid beinhaltet, bedeutet dies, dass das System mit Paketen aktualisiert wurde, welche aus einem der beiden Entwicklungszweige (testing oder unstable) stammen.
Mit dem Kommando apt-show-versions (aus dem gleichnamigen Debian-Paket) überprüfen Sie die Liste der installierten Pakete und identifizieren die verfügbaren Versionen. Für diesen Zweck kann auch aptitude benutzt werden, wenn auch in einer weniger systematischen Art und Weise.
Ein kurzer Blick auf die Datei /etc/apt/sources.list (und das Verzeichnis /etc/apt/sources.list.d/ ) zeigt, woher die installierten Debian-Pakete kamen. Falls viele unbekannte Quellen erscheinen, könnte es der Administrator vorziehen, das Betriebssystem komplett neu zu installieren, um die optimale Kompatibilität zu gewährleisten, welche durch die Software von Debian sichergestellt wird.
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.). Below are two examples, showcasing unusual version suffixes and a third-party package without a source.
$ dpkg -l
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                          Version                        Architecture Description
+++-=============================-==============================-============-===================
[..]
ii  docker-buildx-plugin          0.14.0-1~debian.12~bookworm    amd64        Docker Buildx cli plugin.
ii  docker-ce                     5:26.1.3-1~debian.12~bookworm  amd64        Docker: the open-source application container engine
ii  docker-ce-cli                 5:26.1.3-1~debian.12~bookworm  amd64        Docker CLI: the open-source application container engine
ii  docker-ce-rootless-extras     5:26.1.3-1~debian.12~bookworm  amd64        Rootless support for Docker.
[..]
$ apt-show-versions | grep No
hc-utils:all 0.0.4-1 installed: No available version in archive
Genauso interessant ist es, den Inhalt des Verzeichnisses /usr/local/ zu analysieren. Dieses Verzeichnis ist gedacht für Programme, die manuell kompiliert und installiert wurden. Eine Auflistung von Software, die auf diese Weise installiert wurde, ist lehrreich, denn es stellt sich die Frage nach den Gründen, warum nicht das entsprechende Debian-Paket benutzt wurde (falls ein solches existiert).

3.2.4. Installation von Debian

Da nun alle Informationen über den bestehenden Server bekannt sind, können wir ihn herunterfahren und dann Debian darauf installieren.
Um die passende Version auszuwählen, müssen wir die Systemarchitektur kennen. Wenn es ein einigermaßen aktueller PC ist, dann wird es sehr wahrscheinlich ein amd64 (bei älteren PCs eher ein i386)-Prozessor sein. In anderen Fällen können wir die Möglichkeiten entsprechend dem zuvor genutzten System eingrenzen.
Es ist nicht vorgesehen, dass Tabelle 3.1 vollständig ist, aber es kann hilfreich sein. Beachten Sie, dass es Debian-Architekturen auflistet, die in der aktuellen stabilen Version nicht mehr unterstützt werden. In jedem Fall ist die Originaldokumentation die verlässlichste Quelle, um diese Informationen zu finden.

Tabelle 3.1. Passende Betriebssysteme und Architektur

BetriebssystemArchitektur(en)
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 2003-2008i386, amd64, ia64
Windows RTarmel, armhf, arm64
Windows Vista / Windows 7-8-10-11 / Windows Server 2010-amd64

3.2.5. Installation und Einrichtung der ausgewählten Dienste

Nach der Installation von Debian müssen wir Stück für Stück die Dienste installieren und einrichten, die auf diesem Computer laufen müssen. Die neue Konfiguration muss sich an der vorherigen orientieren, um einen reibungslosen Übergang zu gewährleisten. Alle in den beiden ersten Schritten gesammelten Informationen werden nützlich sein, um diesen Teil erfolgreich abzuschließen.
Installation der ausgewählten Dienste

Abbildung 3.3. Installation der ausgewählten Dienste

Bevor man sich Hals über Kopf auf diese Aufgabe stürzt, sollte man unbedingt den Rest dieses Buches lesen. Danach wird man ein genaueres Verständnis davon haben, wie die erwarteten Dienste einzurichten sind.