Eine detaillierte Anleitung zur Konfiguration von Shared Hosting Servern unter Debian 10

Debian 10 vorbereiten und den Server sicher aktualisieren

Prüfen Sie zuerst, ob Debian 10 wirklich benötigt wird. Die Version erhält seit dem 30. Juni 2024 keine reguläre LTS-Unterstützung mehr. Für einen neuen Produktivserver ist eine aktuelle Debian-Version im Jahr 2026 die bessere Wahl. Diese Anleitung eignet sich vor allem für bestehende Systeme, Migrationen und abgeschottete Testumgebungen.

Erstellen Sie vor Änderungen einen Snapshot oder ein vollständiges Abbild des Servers. Prüfen Sie außerdem, ob Sie noch über eine Konsole des Hosters auf das System zugreifen können. Das ist wichtig, falls ein Netzwerkdienst nach einem Neustart nicht mehr läuft. Arbeiten Sie zunächst nicht als direkter Root-Benutzer über SSH, sondern legen Sie einen Administrationsbenutzer an:

sudo adduser admin
sudo usermod -aG sudo admin

Kopieren Sie anschließend den SSH-Schlüssel des bisherigen Kontos:

sudo mkdir -p /home/admin/.ssh
sudo cp /root/.ssh/authorized_keys /home/admin/.ssh/
sudo chown -R admin:admin /home/admin/.ssh
sudo chmod 700 /home/admin/.ssh
sudo chmod 600 /home/admin/.ssh/authorized_keys

Öffnen Sie eine zweite SSH-Sitzung mit dem neuen Konto und testen Sie den Zugriff. Beenden Sie die aktuelle Root-Sitzung erst danach. So bleibt ein Rettungsweg offen, falls die Berechtigungen nicht stimmen.

Setzen Sie nun einen eindeutigen Rechnernamen. Verwenden Sie dafür einen vollständigen Namen wie Server1.example.net:

sudo hostnamectl set-hostname server1.example.net

Ergänzen Sie den Namen in /etc/hosts. Die öffentliche Serveradresse muss dabei zur tatsächlichen IPv4-Adresse passen:

203.0.113.10 server1.example.net server1

Prüfen Sie die Auflösung mit hostname --fqdn. Gibt der Befehl nicht den vollständigen Namen zurück, sollten Sie die Hostdatei vor der Installation von Verwaltungssoftware korrigieren. Viele Hosting-Panels reagieren empfindlich auf einen fehlenden oder widersprüchlichen Hostnamen.

Aktualisieren Sie danach die Paketlisten und installieren Sie zunächst alle verfügbaren Sicherheitskorrekturen:

sudo apt-get update
sudo apt-get -y upgrade

Falls dabei ein neuer Kernel oder zentrale Bibliotheken installiert werden, starten Sie den Server kontrolliert neu:

sudo reboot

Verbinden Sie sich nach dem Neustart erneut und prüfen Sie den Zustand:

uname -a
cat /etc/debian_version
systemctl --failed

Ein leerer Fehlerbericht bei systemctl --failed ist ein gutes Zeichen. Kontrollieren Sie zusätzlich den freien Speicher. Für Panel, Protokolle, Datenbanken und Websites sollten auf der Systempartition nicht nur wenige Gigabyte frei sein:

df -h
free -h

Entfernen Sie alte Paketdateien erst nach erfolgreicher Aktualisierung:

sudo apt-get clean
sudo apt-get autoremove

Prüfen Sie vor einer späteren Panel-Installation, ob noch Konfigurationsdialoge oder Paketprozesse laufen:

ps aux | grep -E 'apt|dpkg'

Warten Sie, bis diese Prozesse beendet sind. Ein abgebrochener dpkg-Vorgang kann die gesamte Installation blockieren. Falls ein Vorgang tatsächlich unterbrochen wurde, reparieren Sie die Paketverwaltung mit:

sudo dpkg --configure -a
sudo apt-get -f install

Prüfen Sie zum Abschluss Datum, Zeitzone und Systemzeit. Eine falsche Uhrzeit führt später oft zu Problemen mit TLS-Zertifikaten, Protokollen und geplanten Aufgaben:

timedatectl status
sudo timedatectl set-timezone Europe/Berlin

Aktivieren Sie die Zeitsynchronisation, sofern sie noch deaktiviert ist:

sudo timedatectl set-ntp true

Der Server ist für den nächsten Konfigurationsschritt bereit, wenn der Hostname eindeutig ist, die Paketverwaltung fehlerfrei arbeitet, ausreichend Speicher vorhanden ist und der Zugang über den neuen Administrationsbenutzer funktioniert.

Statische IP-Adresse und Hostnamen einrichten

Die Netzwerkschnittstelle muss eine feste öffentliche IPv4-Adresse nutzen, damit Domains, Maildienste und Verwaltungszugänge dauerhaft denselben Server erreichen. Ermitteln Sie zuerst den Namen der Schnittstelle:

ip -br link
ip -4 addr

Auf Debian 10 wird die klassische Konfiguration meist in /etc/network/interfaces verwaltet. Öffnen Sie die Datei und tragen Sie die Werte Ihres Anbieters ein. Die folgenden Angaben sind ein Beispiel und müssen ersetzt werden:

auto ens3
iface ens3 inet static
  address 203.0.113.10
  netmask 255.255.255.0
  gateway 203.0.113.1

Die Namen sind leicht zu verwechseln: address bezeichnet die Serveradresse, netmask das Netz und gateway den Ausgang ins Internet. Manche VPS-Anbieter verwenden statt einer Netzmaske eine CIDR-Angabe wie /24. Übernehmen Sie stets die Werte aus dem Serverbereich des Anbieters.

Ergänzen Sie funktionierende DNS-Resolver in /etc/resolv.conf. Bei einer vom System verwalteten Datei sollten Sie nicht dauerhaft direkt darin arbeiten. Prüfen Sie zunächst, ob ein Resolver-Dienst aktiv ist:

systemctl status systemd-resolved

Ist kein solcher Dienst eingerichtet, kann die Datei zum Beispiel folgende Einträge enthalten:

Nameserver 1.1.1.1
nameserver 9.9.9.9

Verwenden Sie nur Resolver, die in Ihrer Umgebung erlaubt sind. Prüfen Sie die Verbindung danach mit:

ip route
ping -c 3 203.0.113.1
getent hosts deb.debian.org

Aktivieren Sie die neue Netzwerkkonfiguration nur über eine vorhandene Konsolensitzung oder einen zweiten Zugang. Je nach eingesetztem Netzwerkdienst funktioniert einer dieser Befehle:

sudo ifdown ens3 && sudo ifup ens3

Alternativ:

sudo systemctl restart networking

Eine laufende SSH-Verbindung kann bei einem Fehler sofort abbrechen. Prüfen Sie deshalb nach der Änderung die Adresse, das Routing und die Erreichbarkeit erneut:

ip -4 addr show dev ens3
ip route get 1.1.1.1
ping -c 3 1.1.1.1

Für den Hostnamen sollte ein eigener FQDN verwendet werden, etwa server1.example.net. Setzen Sie ihn mit:

sudo hostnamectl set-hostname server1.example.net

Der Hostname muss lokal und im öffentlichen DNS zusammenpassen. Prüfen Sie den lokalen Wert:

hostname
hostname --fqdn

Im DNS-Panel der Domain legen Sie dafür einen A-Eintrag an:

• Host: server1
• Typ: A
• Ziel: öffentliche IPv4-Adresse des Servers
• TTL: zunächst 300 Sekunden für schnelle Korrekturen

Falls IPv6 aktiv ist, darf kein fehlerhafter AAAA-Eintrag auf eine nicht erreichbare Adresse zeigen. Prüfen Sie beide Protokolle:

getent ahosts server1.example.net

Ein PTR-Eintrag, auch Reverse-DNS genannt, wird meist beim Serveranbieter eingerichtet. Er sollte von der öffentlichen IP auf denselben Hostnamen zeigen. Kontrollieren Sie ihn mit:

host 203.0.113.10

Stimmen A- und PTR-Auflösung nicht zusammen, können Mailserver und manche Hosting-Panels Warnungen ausgeben. Nach der DNS-Änderung prüfen Sie die Antwort von mehreren Resolvern:

dig +short A server1.example.net
dig +short -x 203.0.113.10

Erst wenn lokale Adresse, Gateway, FQDN, A-Eintrag und Reverse-DNS konsistent sind, sollte die Panel-Installation beginnen.

Repositorys für Debian 10 korrekt konfigurieren

Debian 10 verwendet für die Paketverwaltung APT. Die Quellen liegen meist in /etc/apt/sources.list und zusätzlichen Dateien unter /etc/apt/sources.list.d/. Für einen stabilen Shared-Hosting-Server sollten dort nur passende, vertrauenswürdige und signierte Quellen stehen.

Erstellen Sie zunächst eine Sicherung der vorhandenen Konfiguration:

sudo cp -a /etc/apt/sources.list /etc/apt/sources.list.bak
sudo mkdir -p /root/apt-sources-backup
sudo cp -a /etc/apt/sources.list.d /root/apt-sources-backup/

Prüfen Sie anschließend alle aktiven Einträge:

grep -Rhv '^[[:space:]]*#' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Für Debian 10 lautet die klassische Grundkonfiguration:

deb http://deb.debian.org/debian buster main contrib non-free
deb http://deb.debian.org/debian buster-updates main contrib non-free
deb http://security.debian.org/debian-security buster/updates main contrib non-free
deb http://deb.debian.org/debian buster-backports main contrib non-free

Die regulären Debian-10-Spiegel sind heute jedoch nicht mehr der richtige Ort für ältere Pakete. Da Debian 10 archiviert wurde, müssen bestehende Systeme in der Regel auf den Debian-Archivdienst umgestellt werden. Verwenden Sie dafür:

deb http://archive.debian.org/debian buster main contrib non-free
deb http://archive.debian.org/debian buster-updates main contrib non-free
deb http://archive.debian.org/debian-security buster/updates main contrib non-free

Die Backports-Quelle sollten Sie nur eintragen, wenn das Hosting-Panel oder eine bestimmte Anwendung sie ausdrücklich benötigt. Alte Backports-Pakete können Abhängigkeiten verändern und dadurch eine bestehende Hosting-Umgebung destabilisieren.

Archivquellen liefern keine aktuellen Sicherheitskorrekturen. Für öffentlich erreichbare Shared-Hosting-Systeme ist das ein erhebliches Risiko. Die saubere Lösung besteht in einer Migration auf eine unterstützte Debian-Version. Die Archivkonfiguration ist vor allem für Wartung, Datenrettung oder eine geplante Übergangsphase gedacht.

Da Archivsignaturen abgelaufen sein können, kann APT die Aktualisierung mit einer Zeitfehler-Meldung ablehnen. Prüfen Sie zuerst die Systemzeit und lesen Sie die konkrete Fehlermeldung. Setzen Sie keine pauschale Option wie AllowInsecureRepositories, nur damit der Befehl durchläuft. Damit würden Sie eine wichtige Vertrauenskontrolle abschwächen.

Nach der Anpassung aktualisieren Sie den lokalen Paketindex:

sudo apt-get clean
sudo apt-get update

Bei Problemen helfen diese Prüfungen:

• 404 Not Found: Der Spiegel ist für die alte Distribution nicht mehr zuständig.
• Release-Datei nicht gefunden: Der Codename oder der Pfad ist falsch.
• NO_PUBKEY: Ein benötigter Signaturschlüssel fehlt.
• InRelease abgelaufen: Das Archiv enthält keine aktuelle Signatur.
• Hash Sum mismatch: Der lokale Index oder ein zwischengeschalteter Cache ist inkonsistent.

Entfernen Sie fremde Paketquellen für Control Panels, PHP-Builds oder Datenbanken, wenn deren Debian-10-Unterstützung nicht eindeutig dokumentiert ist. Besonders gefährlich sind Quellen, die Pakete aus verschiedenen Debian-Generationen mischen. Prüfen Sie die Herkunft eines Pakets mit:

apt-cache policy paketname

So erkennen Sie, welcher Ursprung und welche Version bevorzugt werden. Eine Paketquelle mit höherer Priorität kann unbeabsichtigt zentrale Komponenten ersetzen. Für einen Shared-Hosting-Server sollten Sie deshalb keine Pinning-Regeln oder Drittquellen einsetzen, bevor deren Auswirkungen auf Webserver, PHP und Datenbankpakete geprüft wurden.

Kontrollieren Sie nach dem erfolgreichen Indexlauf, ob APT noch zurückgehaltene oder beschädigte Pakete meldet:

apt-mark showhold
sudo dpkg --audit
apt list --upgradable

Die Repository-Konfiguration ist korrekt, wenn alle Quellen zum gleichen Debian-Codename gehören, keine unerwarteten Drittanbieter auftauchen und apt-get update ohne Signatur-, Pfad- oder Abhängigkeitsfehler endet. Für den späteren Produktivbetrieb sollte der Server dennoch auf eine unterstützte Debian-Version migriert werden.

DNS-Zonen und Nameserver für Hosting-Domains anlegen

Für eine Hosting-Domain brauchen Sie eine klare DNS-Struktur. Eine einzelne Zone für die Hauptdomain reicht oft aus. Zusätzliche Einträge steuern Webzugriff, E-Mail, Zertifikate und die Delegation eigener Nameserver.

Entscheiden Sie zuerst, wo die autoritative DNS-Zone verwaltet wird. Es gibt zwei saubere Varianten:

• Der Domainanbieter verwaltet die Zone. Der Server erhält nur die benötigten A-, AAAA-, MX- und TXT-Einträge.
• Der Debian-Server betreibt eigene autoritative Nameserver. Dafür benötigen Sie mindestens zwei getrennte DNS-Server mit unterschiedlichen IP-Netzen.

Ein einzelner Server sollte nicht allein als autoritativer Nameserver dienen. Fällt er aus, kann die Domain nicht mehr aufgelöst werden. Für ein kleines Hosting-Projekt ist die erste Variante meist sinnvoller. Eigene Nameserver lohnen sich erst, wenn die DNS-Verwaltung bewusst auf dem Server liegen soll.

Eine typische Zone für example.net enthält diese Datensätze:

• SOA: legt primären Nameserver, Kontaktadresse und Seriennummer fest.
• NS: nennt die autoritativen Nameserver der Zone.
• A: verweist einen Namen auf eine IPv4-Adresse.
• AAAA: verweist einen Namen auf eine IPv6-Adresse.
• CNAME: bildet einen Alias auf einen bestehenden Namen.
• MX: bestimmt den zuständigen Mailserver.
• TXT: speichert unter anderem SPF-, DKIM- und Verifizierungswerte.

Für eine Website können die Einträge so aussehen:

• @ A 203.0.113.10
• www CNAME example.net.
• mail A 203.0.113.10
• @ MX 10 mail.example.net.
• @ TXT "v=spf1 mx -all"

Der Punkt am Ende eines vollständigen DNS-Namens ist wichtig. Ohne Punkt kann ein DNS-Programm den Namen als relativ zur Zone behandeln. Aus mail.example.net könnte dann versehentlich mail.example.net.example.net werden.

Wenn mehrere Kunden auf demselben Shared-Hosting-Server liegen, erhält jede Domain eine eigene Zone oder wird beim DNS-Anbieter getrennt verwaltet. Vermischen Sie Kundenbereiche nicht. Eine Zone darf keine versehentlichen Einträge für eine fremde Domain enthalten.

Für eigene Nameserver benötigen Sie zuerst Host-Records beim Registrar. Beispiel:

• ns1.example.net zeigt auf die erste DNS-IP.
• ns2.example.net zeigt auf die zweite DNS-IP.

Danach tragen Sie beim Registrar die beiden Nameserver ein. Diese Reihenfolge verhindert eine Delegationsschleife. Der Nameserver muss außerdem UDP und TCP auf Port 53 erreichen können. DNS verwendet meist UDP, wechselt bei großen Antworten oder Zonentransfers aber auf TCP.

Verwenden Sie keine offenen Rekursionseinstellungen auf einem autoritativen Server. Rekursion sollte nur für interne Verwaltungsnetze erlaubt sein. Sonst kann der Server als Verstärker für DNS-Angriffe missbraucht werden.

Bei einer manuellen Zonendatei sollten Sie die Seriennummer nach jeder Änderung erhöhen. Ein verbreitetes Format ist 2026100401. Die nachfolgenden Ziffern kennzeichnen weitere Änderungen am selben Tag. Ohne neue Seriennummer übernehmen sekundäre DNS-Server die Änderung möglicherweise nicht.

Stellen Sie für E-Mail-Domains zusätzlich einen passenden PTR-Eintrag bereit. Der PTR-Wert der Mail-IP sollte zum Mail-Hostnamen passen. Für den Empfang allein genügt ein MX-Eintrag; für den Versand brauchen Sie meist außerdem SPF, DKIM und DMARC. Ein möglicher DMARC-Eintrag lautet:

_dmarc.example.net TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.net"

Starten Sie zunächst mit p=none, sammeln Sie Berichte und verschärfen Sie die Richtlinie erst nach einer Prüfung. Ein sofortiges p=reject kann legitime Nachrichten blockieren, wenn SPF oder DKIM noch nicht korrekt eingerichtet sind.

Prüfen Sie die fertige Zone von außen:

• dig A example.net
• dig MX example.net
• dig TXT example.net
• dig NS example.net
• dig +trace example.net

Achten Sie auf die TTL. Werte zwischen 300 und 3.600 Sekunden eignen sich für die Einrichtungsphase. Vor einem geplanten Umzug senken Sie die TTL mindestens einen vollständigen alten TTL-Zeitraum vorher. Dadurch verbreiten sich neue Zieladressen schneller, auch wenn einzelne Resolver ihre Daten länger zwischenspeichern.

Eine DNS-Zone ist fertig, wenn die Delegation stimmt, A- und AAAA-Einträge erreichbar sind, der MX auf einen gültigen Host zeigt und keine unbeabsichtigte Rekursion offensteht. Erst danach sollten Domains im Hosting-Panel angelegt werden.

i-MSCP herunterladen und die Installationsdateien entpacken

i-MSCP sollte auf Debian 10 nur in einer dafür geeigneten, sauberen Umgebung eingesetzt werden. Die Version ist veraltet und erhält keine regulären Sicherheitsupdates mehr. Für ein bestehendes System dient die folgende Vorgehensweise daher vor allem der kontrollierten Wartung oder einer Migration. Eine neue Produktivinstallation sollte auf einer unterstützten Debian-Version erfolgen.

Prüfen Sie vor dem Download die offiziell unterstützte i-MSCP-Version. Verwenden Sie keine beliebige Kopie aus Foren oder fremden Dateiablagen. Der Installationsstand muss zur Debian-Version passen. Notieren Sie die Versionsnummer und die Prüfsumme der Datei. So lässt sich später feststellen, ob Download und Archiv unverändert sind.

Legen Sie ein separates Arbeitsverzeichnis an und wechseln Sie hinein:

mkdir -p /root/imscp-download
cd /root/imscp-download

Für den Abruf können Sie wget oder curl verwenden. Das folgende Muster zeigt den Ablauf. Ersetzen Sie die Adresse durch den geprüften Download-Link der offiziellen Projektseite:

wget --https-only 'https://beispiel.tld/imscp-installer.tar.gz'

Falls eine Signaturdatei angeboten wird, laden Sie auch diese herunter:

wget --https-only 'https://beispiel.tld/imscp-installer.tar.gz.asc'

Prüfen Sie zuerst die Dateigröße und den Dateityp:

ls -lh
file imscp-installer.tar.gz

Eine Datei mit der Endung .tar.gz muss als gzip-komprimiertes Tar-Archiv erkannt werden. Ist sie stattdessen eine HTML-Datei, wurde meist eine Fehlerseite gespeichert. Entpacken Sie ein solches Ergebnis nicht blind.

Vergleichen Sie anschließend die veröffentlichte SHA-256-Prüfsumme mit der lokal berechneten:

sha256sum imscp-installer.tar.gz

Wenn eine Prüfsummendatei vorliegt, können Sie sie so prüfen:

sha256sum -c SHA256SUMS

Bei einer GPG-Signatur benötigen Sie den öffentlichen Projektschlüssel. Importieren Sie ihn nur aus einer nachvollziehbaren Quelle und vergleichen Sie dessen Fingerabdruck mit der offiziellen Dokumentation:

gpg --import projekt-schluessel.asc
gpg --verify imscp-installer.tar.gz.asc imscp-installer.tar.gz

Eine gültige Signatur beweist, dass die Datei mit dem passenden Schlüssel signiert wurde. Sie beweist nicht automatisch, dass die gewählte Version für Debian 10 geeignet ist. Versionsprüfung und Signaturprüfung gehören deshalb zusammen.

Erstellen Sie für die Entpackung ein eigenes Zielverzeichnis:

mkdir -p /root/imscp-source
tar --extract --gzip --file imscp-installer.tar.gz --directory /root/imscp-source

Listen Sie danach die entpackten Dateien auf:

find /root/imscp-source -maxdepth 2 -type f -printf '%p\n' | sort

Starten Sie keine Datei, bevor Sie den Inhalt geprüft haben. Suchen Sie nach einer README-, INSTALL- oder Dokumentationsdatei:

find /root/imscp-source -maxdepth 3 -type f \( -iname 'readme*' -o -iname 'install*' -o -iname '*.md' \) -print

Lesen Sie die Installationshinweise mit:

less /root/imscp-source/README

Die Installationsdatei sollte nicht unnötig ausführbar sein. Prüfen Sie ihre Rechte:

stat /root/imscp-source/*

Falls das Archiv ein Skript enthält, vergleichen Sie zunächst die im Dokument genannten Optionen mit dem tatsächlichen Aufruf. Verwenden Sie keine Parameter aus einer Anleitung für eine andere i-MSCP-Generation. Bei alten Hosting-Panels können sich Pfade, Paketnamen und unterstützte Dienste deutlich unterscheiden.

Bewahren Sie das Originalarchiv und die Prüfsumme getrennt vom entpackten Verzeichnis auf. Entfernen Sie temporäre Dateien erst, wenn die Installation erfolgreich abgeschlossen und der verwendete Versionsstand dokumentiert ist. So bleibt der genaue Ausgangspunkt für eine Wiederholung oder Fehleranalyse erhalten.

Der Download ist vorbereitet, wenn die Datei aus einer verifizierten Quelle stammt, die Prüfsumme passt, das Archiv den erwarteten Typ besitzt und die Installationsdokumentation zur verwendeten Debian-Version gehört. Erst dann sollte das eigentliche Installationsprogramm ausgeführt werden.

i-MSCP als Verwaltungspanel für Shared Hosting installieren

Installieren Sie i-MSCP nur auf einem frischen System oder auf einem Server, dessen vorhandene Web-, Mail- und Datenbankdienste vollständig entfernt wurden. Das Installationsprogramm richtet zentrale Dienste selbst ein. Bereits vorhandene Konfigurationen können dadurch überschrieben werden.

Beachten Sie außerdem: Debian 10 ist seit dem 30. Juni 2024 aus dem regulären LTS-Support. i-MSCP kann je nach Veröffentlichung und Installationszweig unterschiedliche Debian-Versionen unterstützen. Prüfen Sie daher vor dem Start die offizielle Kompatibilitätsliste. Eine nicht passende Kombination aus Betriebssystem und Panel führt schnell zu Paketkonflikten.

Wechseln Sie in das zuvor entpackte Verzeichnis und suchen Sie nach dem eigentlichen Installationsskript:

cd /root/imscp-source
find . -maxdepth 2 -type f -perm -u+x -print

Lesen Sie die verfügbaren Optionen, bevor Sie das Skript ausführen:

./imscp-autoinstaller --help

Der genaue Dateiname kann je nach i-MSCP-Version abweichen. Verwenden Sie deshalb den Namen aus dem entpackten Archiv und nicht blind einen Befehl aus einer älteren Anleitung.

Starten Sie das Programm erst nach einer letzten Prüfung der Systemressourcen. Für ein kleines Hosting-System sind mindestens 2 GB RAM sinnvoll; mehrere Websites, Datenbanken und Mailkonten benötigen deutlich mehr. Prüfen Sie die Werte mit:

free -h
df -h /

Das Installationsprogramm fragt typischerweise nach Angaben wie Hauptdomain, Administrationsadresse, Datenbankzugang und gewünschtem Dienstumfang. Halten Sie diese Daten bereit:

• vollständiger Hostname des Servers
• gültige Administratoradresse
• starkes Passwort für das Panel
• eindeutiges Passwort für den Datenbankadministrator
• Zeitzone des Servers
• zu installierende Web-, DNS-, Mail- und Datenbankdienste

Verwenden Sie für das Panelkonto ein langes, zufällig erzeugtes Passwort. Speichern Sie es nicht in der Shell-Historie. Passwörter als Kommandozeilenparameter können über Prozesslisten oder Protokolle sichtbar werden.

Führen Sie den Installer mit den Rechten aus, die das Projekt verlangt. Bei vielen i-MSCP-Versionen geschieht dies direkt als Root:

sudo ./imscp-autoinstaller

Falls das Skript keine Ausführungsrechte besitzt, setzen Sie diese nur für die geprüfte Datei:

chmod 700 ./imscp-autoinstaller

Folgen Sie dem Dialog sorgfältig. Wählen Sie nur Dienste, die tatsächlich benötigt werden. Ein Mailserver ist beispielsweise nicht erforderlich, wenn E-Mails extern verarbeitet werden. Jeder zusätzliche Dienst vergrößert die Angriffsfläche und den Wartungsaufwand.

Brechen Sie die Installation nicht ab, sobald Pakete entfernt, ersetzt oder Dienste neu gestartet werden. Beobachten Sie jedoch die Meldungen. Bei einem Paketfehler sollten Sie nicht mehrfach neu starten, sondern zuerst die konkrete Ursache notieren. Ein zweiter Installationslauf auf einem halb eingerichteten System kann die Lage verschlimmern.

Nach dem Abschluss prüfen Sie die wichtigsten Dienste:

systemctl --type=service --state=failed
systemctl status apache2
systemctl status mariadb

Die genannten Dienstnamen können je nach gewählter i-MSCP-Konfiguration abweichen. Entscheidend ist, dass der Installer ohne Fehler beendet wurde und die vorgesehenen Komponenten aktiv sind.

Rufen Sie das Panel danach über seine dokumentierte HTTPS-Adresse auf. Akzeptieren Sie ein selbst signiertes Zertifikat nur für den ersten Test. Für den dauerhaften Betrieb muss später ein gültiges Zertifikat für den Panel-Hostnamen verwendet werden.

Prüfen Sie im Panel, ob die Grunddaten stimmen:

• Servername und Zeitzone
• verfügbare IP-Adressen
• aktive Webserver- und PHP-Komponenten
• Datenbankdienst und Verbindungstest
• Mail- und DNS-Module, sofern ausgewählt
• Speicherplatz und Statusmeldungen

Ändern Sie zentrale Webserver- oder Datenbankdateien nicht direkt, wenn i-MSCP diese verwaltet. Das Panel kann manuelle Änderungen bei einer späteren Aktualisierung überschreiben. Verwenden Sie bevorzugt die vorgesehenen Verwaltungsfunktionen oder dokumentierte Erweiterungspunkte.

Die Installation gilt als erfolgreich, wenn das Panel erreichbar ist, die ausgewählten Dienste ohne Fehler starten und ein Testkonto angelegt werden kann. Erst danach sollten Sie Hosting-Pakete und Kundendomains einrichten.

Webserver, PHP-Versionen und Datenbanken konfigurieren

Nach der i-MSCP-Installation sollten Sie Webserver, PHP und Datenbanken nur über die vom Panel vorgesehenen Funktionen verwalten. Direkte Änderungen an automatisch erzeugten Virtual-Host- oder Pool-Dateien werden bei einer späteren Aktualisierung oft überschrieben.

Öffnen Sie im Panel zunächst die Dienstübersicht. Aktivieren Sie nur die Komponenten, die Ihre Hosting-Konten wirklich benötigen. Für klassische Websites genügt meist ein Webserver mit PHP und MariaDB. Einen Mail- oder DNS-Dienst sollten Sie nicht zusätzlich einschalten, wenn diese Aufgaben extern laufen.

Prüfen Sie danach die Webserver-Grundwerte:

• HTTP und HTTPS müssen auf die richtige IP-Adresse zeigen.
• Jede Domain benötigt einen eigenen Virtual Host.
• Das Webroot-Verzeichnis darf nicht auf den Speicher anderer Kunden zeigen.
• Verzeichnisauflistung sollte standardmäßig deaktiviert bleiben.
• Fehlerseiten dürfen keine internen Pfade oder Zugangsdaten verraten.

Verwenden Sie für neue Websites nach Möglichkeit PHP 8.2 oder eine neuere, vom Panel unterstützte Version. PHP 7.3 und ältere Zweige sind für öffentlich erreichbare Anwendungen nicht mehr vertretbar. Debian 10 liefert von Haus aus ältere PHP-Pakete; zusätzliche PHP-Versionen sollten deshalb nur aus einer vertrauenswürdigen und ausdrücklich kompatiblen Quelle stammen.

Weisen Sie die PHP-Version pro Hosting-Konto oder Domain zu. Eine alte Anwendung kann vorübergehend eine ältere Version benötigen, sollte aber getrennt von modernen Projekten laufen. Nutzen Sie bevorzugt PHP-FPM statt des eingebetteten Modus. Jeder Pool kann dadurch mit eigenen Ressourcen und Rechten betrieben werden.

Begrenzen Sie die wichtigsten PHP-Werte passend zur Anwendung:

• memory_limit: oft 128 bis 256 MB für normale CMS-Installationen
• upload_max_filesize: nur so groß wie tatsächlich nötig
• post_max_size: mindestens so groß wie die Upload-Grenze
• max_execution_time: häufig 30 bis 120 Sekunden
• max_input_vars: erhöhen Sie den Standardwert nur bei konkretem Bedarf

Deaktivieren Sie nicht benötigte Funktionen wie exec, shell_exec oder proc_open, sofern keine Anwendung sie verlangt. Erstellen Sie Änderungen über die PHP-Einstellungen des jeweiligen Kontos. Eine globale Abschaltung kann andere Kundenwebsites stören.

Kontrollieren Sie die tatsächlich verwendete PHP-Version mit einer temporären Testdatei:

Löschen Sie die Datei sofort nach dem Test. Eine öffentlich erreichbare Versionsanzeige erleichtert Angreifern die technische Einordnung des Servers.

Für Datenbanken ist MariaDB eine passende Wahl, sofern die gewählte i-MSCP-Version sie unterstützt. Legen Sie für jede Website eine eigene Datenbank und einen eigenen Datenbankbenutzer an. Verwenden Sie niemals ein gemeinsames Administratorkonto für mehrere Kunden.

Ein Datenbankbenutzer sollte nur die Rechte seiner eigenen Datenbank erhalten. Typischerweise genügen:

• SELECT
• INSERT
• UPDATE
• DELETE
• CREATE
• ALTER
• INDEX
• DROP

Administrative Rechte wie GRANT OPTION, globale Prozessrechte oder Zugriff auf fremde Datenbanken gehören nicht in ein normales Hosting-Konto. Prüfen Sie die Berechtigungen nach jeder Kontoerstellung.

Setzen Sie die Datenbank nicht dem öffentlichen Internet aus. Der Dienst sollte nur auf der lokalen Adresse oder einem privaten Verwaltungsnetz lauschen. Kontrollieren Sie den Listener mit:

ss -lntp | grep 3306

Konfigurieren Sie außerdem die maximale Anzahl gleichzeitiger Verbindungen passend zum verfügbaren Arbeitsspeicher. Zu hohe Werte führen bei vielen PHP-Prozessen schnell zu Speicherdruck. Bei kleinen VPS-Systemen sind konservative Limits meist stabiler als theoretische Spitzenwerte.

Testen Sie jede neue Domain mit einer kleinen HTML-Datei und einer separaten PHP-Datei. Prüfen Sie danach den Datenbankzugriff über die Anwendung selbst. Entfernen Sie die Testdateien und kontrollieren Sie die Logdateien auf Konfigurationsfehler, Berechtigungsprobleme und fehlende PHP-Erweiterungen.

Ein sauber konfigurierter Dienst ist erreicht, wenn jede Domain den richtigen Virtual Host lädt, PHP die gewünschte Version verwendet, Datenbanken getrennte Konten besitzen und kein nicht benötigter Dienst öffentlich lauscht.

Hosting-Pakete, Kundenkonten und Webspaces erstellen

Ein Hosting-Paket legt fest, welche Ressourcen ein Kundenkonto verwenden darf. Erstellen Sie zuerst ein kleines Standardpaket und passen Sie es später anhand echter Nutzung an. Zu großzügige Limits führen auf einem Shared-Hosting-Server schnell zu Engpässen.

Definieren Sie pro Paket mindestens:

• Speicherplatz und monatliches Traffic-Limit
• Anzahl der Domains und Subdomains
• Anzahl der Datenbanken und E-Mail-Postfächer
• maximale PHP-Prozesse und gleichzeitige Verbindungen
• Zugriff auf Cronjobs, SSH und externe Dienste
• zulässige PHP-Versionen und Erweiterungen

Ein einfacher Startwert für eine kleine Website kann etwa 2 GB Speicher, 10 GB Traffic, eine Domain, drei Datenbanken und fünf Postfächer umfassen. Diese Werte sind keine festen Anforderungen. Entscheidend ist, dass jedes Limit zur verfügbaren CPU-, RAM- und Speicherleistung passt.

Legen Sie im i-MSCP-Panel zuerst das Paket an. Verwenden Sie einen eindeutigen Namen wie web-standard-2026. Tragen Sie danach die Ressourcenlimits ein und speichern Sie das Paket. Vermeiden Sie Sonderzeichen und wechselnde Bezeichnungen. Klare Namen erleichtern spätere Zuordnung und Abrechnung.

Erstellen Sie anschließend ein Kundenkonto. Verwenden Sie keine Sammelkonten für mehrere unabhängige Betreiber. Ein eigenes Konto trennt Webspace, Protokolle, Datenbanken und E-Mail-Daten besser voneinander. Erfassen Sie nur notwendige Kundendaten und vergeben Sie ein einmaliges, zufälliges Passwort.

Ordnen Sie dem Konto danach das zuvor erstellte Paket zu. Prüfen Sie besonders:

• Speicher- und Traffic-Grenzen
• erlaubte Diensttypen
• Standard-PHP-Version
• SSH- oder SFTP-Zugriff
• automatische Erstellung von Verzeichnissen

Fügen Sie nun die Hauptdomain über die Domainverwaltung des Kundenkontos hinzu. i-MSCP legt dabei normalerweise das Webspace-Verzeichnis, den Virtual Host und die erforderlichen Verwaltungsobjekte an. Laden Sie die Website nicht in ein fremdes Kundenverzeichnis. Das verhindert falsche Besitzrechte und ungewollte Datenfreigaben.

Verwenden Sie für jeden Kunden einen eigenen Systembenutzer. Der Webspace sollte diesem Benutzer gehören und nicht dem globalen Webserverkonto. Schreibrechte für das gesamte Dokumentenverzeichnis sind problematisch, weil ein kompromittiertes Skript dann leichter fremde Dateien verändern kann.

Eine sinnvolle Struktur sieht zum Beispiel so aus:

• htdocs für öffentlich erreichbare Website-Dateien
• private für Konfigurationen und nicht öffentliche Daten
• logs für Zugriffs- und Fehlerprotokolle
• tmp für temporäre Anwendungsdateien

Legen Sie Konfigurationsdateien mit Passwörtern niemals unterhalb des öffentlichen Webroots ab. Bei modernen Anwendungen gehört der öffentliche Einstiegspunkt oft in ein Unterverzeichnis wie public. Prüfen Sie, ob das Panel diese Struktur unterstützt, bevor Sie den Dokumentenstamm ändern.

Richten Sie für jede Datenbank einen Namen und Benutzer ein, die dem Kundenkonto eindeutig zugeordnet sind. Vermeiden Sie kurze Standardnamen wie test oder admin. Eine Kombination aus Kundenkennung und Projektname ist übersichtlicher.

Testen Sie das neue Konto mit einer kleinen Startseite. Prüfen Sie dabei:

• Aufruf der Domain
• Upload und Download per SFTP
• Schreibzugriff auf vorgesehene Verzeichnisse
• Verbindung der Anwendung zur eigenen Datenbank
• Erreichen des Paketlimits mit einer ungefährlichen Testdatei

Löschen Sie Testdateien nach der Prüfung. Kontrollieren Sie außerdem, ob das Konto nicht auf Verzeichnisse anderer Kunden zugreifen kann. Dieser Trennungstest ist wichtiger als eine bloß funktionierende Startseite.

Ändern Sie Limits nicht direkt in automatisch erzeugten Systemdateien. Nutzen Sie die Paketverwaltung im Panel und dokumentieren Sie Sonderfreigaben. So bleiben Änderungen nachvollziehbar, und ein späterer Dienstlauf kann die Einstellungen korrekt übernehmen.

Domains, Subdomains und E-Mail-Dienste einrichten

Fügen Sie jede Domain im i-MSCP-Panel dem richtigen Kundenkonto zu. Legen Sie danach fest, ob sie als Hauptdomain, Alias oder eigenständige Website dienen soll. Ein Alias zeigt auf eine bestehende Website; eine eigenständige Domain erhält dagegen ein eigenes Webroot und getrennte Protokolle.

Für Subdomains wie shop.example.net oder blog.example.net erstellen Sie einen separaten Eintrag im Domainbereich des Kontos. Verwenden Sie eigene Verzeichnisse, wenn Inhalte und Berechtigungen getrennt bleiben sollen. Eine Subdomain für eine Anwendung sollte nicht automatisch auf das Stammverzeichnis der Hauptdomain zeigen.

Prüfen Sie nach jeder Anlage den vollständigen Namensraum:

• Hauptdomain: example.net
• Webalias: www.example.net
• Shop: shop.example.net
• Verwaltung: admin.example.net

Aktivieren Sie HTTPS für jede Domain und Subdomain, die öffentlich erreichbar ist. Ein Zertifikat muss alle verwendeten Namen abdecken. Eine Weiterleitung von HTTP auf HTTPS verhindert, dass Besucher unverschlüsselte Verbindungen nutzen. Prüfen Sie außerdem, ob Anwendungen absolute HTTP-Links erzeugen oder unsichere Inhalte nachladen.

Richten Sie E-Mail-Adressen nur ein, wenn der Server tatsächlich als Mailserver betrieben werden soll. Für jedes Kundenkonto können Sie anschließend Postfächer wie kontakt@example.net oder rechnung@example.net anlegen. Verwenden Sie keine catch-all-Adresse im Produktivbetrieb. Sie nimmt auch Nachrichten an, die an nicht existierende Empfänger gehen, und zieht dadurch viel Spam an.

Ein Mailkonto benötigt ein eigenes, langes Passwort. Legen Sie Weiterleitungen sparsam an. Automatische Weiterleitungen an externe Anbieter können Datenschutz- und Zustellprobleme verursachen. Für Funktionsadressen wie noreply sollte der Versand ausdrücklich gewollt sein; ein unbeaufsichtigtes Postfach ist sonst schnell ein vergessener Speicherplatz.

Konfigurieren Sie für den Maildienst mindestens:

• IMAP über Port 993 mit TLS für den Empfang
• SMTP-Submission über Port 587 mit Authentifizierung
• kein offenes Relay für fremde Absender
• korrekte Mailbox- und Quotenlimits
• Spam- und Virenprüfung nach den verfügbaren Panel-Modulen

Verwenden Sie Port 25 nicht als normalen Benutzerzugang. Er dient vor allem der Server-zu-Server-Zustellung. Für Mailprogramme ist Port 587 die bessere Wahl, weil dort eine Anmeldung und Verschlüsselung vorgesehen sind.

Ergänzen Sie neben dem MX-Eintrag die erforderlichen Richtlinien für den Versand. SPF beschreibt erlaubte Versandserver. DKIM signiert ausgehende Nachrichten. DMARC prüft, ob Absenderdomain und Signatur zusammenpassen. Die drei Verfahren müssen zur tatsächlichen Versandarchitektur passen. Ein falscher SPF-Eintrag mit zwei widersprüchlichen v=spf1-Records ist ungültig.

Testen Sie eine neue Domain mit mindestens drei Nachrichten:

• von einem externen Konto an das neue Postfach
• vom neuen Postfach an einen externen Empfänger
• an eine nicht vorhandene Adresse, um das Verhalten der Rückmeldung zu prüfen

Kontrollieren Sie bei ausgehenden Nachrichten die Header. Achten Sie auf SPF=pass, DKIM=pass und ein passendes DMARC-Ergebnis. Ein erfolgreicher Versand allein beweist keine gute Zustellbarkeit. Reverse-DNS, Hostname, TLS und Absenderkonfiguration müssen ebenfalls zusammenpassen.

Für eine Subdomain, die keinen Maildienst verwenden soll, kann ein gezielter MX-Eintrag oder eine passende Richtlinie verhindern, dass fremde Systeme dort Zustellung erwarten. Dokumentieren Sie solche Sonderfälle.

Prüfen Sie abschließend die Domainverwaltung im Panel, die HTTPS-Aufrufe, die Postfachquoten und die Zustellprotokolle. Entfernen Sie ungenutzte Subdomains und Testpostfächer. So bleiben Kundenkonten übersichtlich und alte Zugangspunkte verschwinden nicht unbemerkt.

Dateirechte, Firewall und Serverzugriff absichern

Setzen Sie für jede Website und jeden Dienst nur die Rechte, die wirklich nötig sind. In einer Shared-Hosting-Umgebung verhindert das, dass ein kompromittiertes Skript auf Dateien anderer Kunden zugreift.

Prüfen Sie zunächst Besitzer und Rechte der Webverzeichnisse:

find /var/www -maxdepth 3 -type d -printf '%u:%g %m %p\n'
find /var/www -maxdepth 3 -type f -printf '%u:%g %m %p\n'

Für normale Website-Dateien sind 0644 und für Verzeichnisse 0755 ein brauchbarer Ausgangspunkt. Schreibrechte für „others“ sollten grundsätzlich fehlen. Dateien mit Passwörtern verdienen strengere Rechte, oft 0600 oder 0640. Entscheidend ist, dass der Webserver nur auf die vorgesehenen Pfade zugreifen kann.

Setzen Sie Besitzrechte nicht pauschal auf das gesamte System. Falsche Befehle wie ein rekursives chown auf /var können Datenbanken, Protokolle und Systemdienste beschädigen. Arbeiten Sie immer mit dem konkreten Kundenverzeichnis und prüfen Sie die Änderung anschließend:

namei -l /var/www/kunde1
getfacl /var/www/kunde1

Verhindern Sie, dass Kundenverzeichnisse über symbolische Links ausbrechen. Prüfen Sie Upload-Ordner besonders sorgfältig. Dort sollten keine ausführbaren Skripte liegen, wenn die Anwendung das nicht zwingend verlangt. Eine per Upload eingeschleuste PHP-Datei ist sonst schnell mehr als nur eine harmlose Datei.

Schützen Sie sensible Dateien zusätzlich über die vom Panel erzeugten Webserver-Regeln. Dazu gehören Umgebungsdateien, Sicherungen, Versionskontrollordner und interne Protokolle. Verlassen Sie sich nicht allein auf einen Dateinamen mit führendem Punkt.

Beschränken Sie den Serverzugriff auf wenige Konten. Deaktivieren Sie ungenutzte lokale Benutzer und prüfen Sie deren Anmeldeshell:

awk -F: '$7 !~ /(nologin|false)$/ {print $1, $7}' /etc/passwd

Erlauben Sie SSH nur für die vorgesehenen Administrationskonten. Eine zusätzliche Einschränkung auf bekannte Quellnetze ist sinnvoll, sofern sich diese Netze nicht häufig ändern. Verwenden Sie für privilegierte Aufgaben sudo statt dauerhafter Root-Sitzungen.

Konfigurieren Sie die Firewall nach dem Prinzip „alles sperren, was nicht gebraucht wird“. Für einen typischen Webserver bleiben meist diese Dienste erreichbar:

• TCP 22 nur aus erlaubten Verwaltungsnetzen
• TCP 80 für HTTP und Zertifikatsprüfungen
• TCP 443 für HTTPS
• TCP 25, 465 oder 587 nur bei aktivem Mailbetrieb
• TCP und UDP 53 nur bei einem eigenen DNS-Dienst

Mit iptables oder einer darüber liegenden Verwaltungsoberfläche können Sie die Regeln setzen. Bei SSH-Änderungen muss die bestehende Sitzung offen bleiben, bis eine neue Verbindung erfolgreich getestet wurde. Eine voreilige Sperre auf Port 22 ist ein klassischer Eigentor-Moment.

Prüfen Sie danach die tatsächlich offenen Ports:

ss -lntup

Vergleichen Sie die Ausgabe mit den Regeln. Ein Dienst, der auf 0.0.0.0 oder :: lauscht, ist grundsätzlich von außen erreichbar, sofern die Firewall ihn nicht blockiert. Interne Datenbanken und Verwaltungsdienste sollten an eine lokale oder private Adresse gebunden sein.

Für Brute-Force-Schutz kann ein Dienst wie Fail2ban wiederholte Fehlversuche zeitweise sperren. Aktivieren Sie nur passende Filter und kontrollieren Sie die Protokollpfade. Ein falsch eingestellter Filter erzeugt entweder unnötige Sperren oder schützt kaum.

Überwachen Sie die wichtigsten Sicherheitsereignisse mit:

• journalctl -u ssh für SSH-Anmeldungen
• journalctl -p warning..alert für ernste Systemmeldungen
• last für erfolgreiche Sitzungen
• lastb für fehlgeschlagene Anmeldeversuche, sofern aktiviert

Speichern Sie Protokolle nicht unbegrenzt. Eine überfüllte Partition kann Webserver, Maildienste und Datenbanken zugleich stoppen. Legen Sie eine passende Logrotation fest und bewahren Sie sicherheitsrelevante Protokolle bei Bedarf außerhalb des Servers auf.

Führen Sie abschließend einen externen Porttest und einen Zugriffstest mit einem normalen Kundenkonto durch. Der Kunde darf seine eigenen Dateien verwalten, aber weder Systemverzeichnisse noch fremde Webspaces lesen. Genau dieser Trennungstest zeigt, ob die Rechte wirklich greifen.

Beispiel: Eine Website mit Domain und Datenbank bereitstellen

Für den Test verwenden wir die Domain example.net, den Kunden kunde1 und die Datenbank kunde1_shop. Die Namen sind Beispiele. Ersetzen Sie sie durch Ihre echten Werte.

Öffnen Sie zuerst im i-MSCP-Panel das Kundenkonto und legen Sie die Domain example.net an. Wählen Sie als Dokumentenstamm das vom Panel vorgeschlagene Webverzeichnis. Erstellen Sie anschließend die Datenbank kunde1_shop und den Benutzer kunde1_app. Verwenden Sie ein langes, zufälliges Passwort und speichern Sie es außerhalb des öffentlich erreichbaren Webverzeichnisses.

Laden Sie eine kleine Testseite in den Webspace. Eine einfache Datei namens index.php kann so aussehen:

Rufen Sie danach https://example.net auf. Erscheint die Meldung, stimmt die Verbindung zwischen Domain, Webspace und Webserver. Bei einem Fehler prüfen Sie zuerst das passende Kundenkonto und nicht sofort die PHP-Konfiguration.

Für einen Datenbanktest erstellen Sie eine Datei außerhalb des öffentlichen Bereichs, zum Beispiel db-test.php. Verwenden Sie eine minimale Verbindung und geben Sie keine Zugangsdaten aus:

Rufen Sie die Datei nur kurz auf. Wenn die Verbindung funktioniert, löschen Sie sie sofort und speichern Sie die Zugangsdaten in der vorgesehenen Anwendungskonfiguration. Ein Testskript mit Passwort darf nicht online bleiben.

Für einen realistischeren Test legen Sie eine Tabelle an. Verwenden Sie dabei UTF-8:

CREATE TABLE status (id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, text VARCHAR(100) NOT NULL);

Schreiben Sie einen Datensatz, lesen Sie ihn über die Anwendung aus und löschen Sie die Tabelle anschließend wieder. Damit prüfen Sie nicht nur die Anmeldung, sondern auch die tatsächlich erteilten Datenbankrechte.

Kontrollieren Sie nun die Trennung der Ressourcen. Melden Sie sich mit kunde1_app an und versuchen Sie nicht, auf eine fremde Datenbank zuzugreifen. Dieser Zugriff muss abgelehnt werden. Prüfen Sie außerdem, ob die Website keine Dateien außerhalb ihres eigenen Webspaces lesen kann.

Testen Sie danach typische Anfragen:

• / lädt die Startseite.
• Eine unbekannte URL liefert eine kontrollierte Fehlerseite.
• Eine statische Datei wird mit dem richtigen Inhaltstyp ausgeliefert.
• Eine nicht erlaubte PHP-Datei im Upload-Verzeichnis wird nicht ausgeführt.
• Ein Formular kann keine ungefilterten Datenbankbefehle einschleusen.

Überprüfen Sie die Protokolle des Kundenkontos. Ein erfolgreicher Test enthält keine Warnungen zu fehlenden PHP-Erweiterungen, falschen Besitzrechten oder Datenbankabbrüchen. Vermeiden Sie es, vollständige Passwörter oder Sitzungsdaten in Fehlermeldungen zu schreiben.

Wenn die Website produktiv gehen soll, ersetzen Sie die Testseite durch die echte Anwendung und importieren Sie die Datenbank über den vorgesehenen Panel- oder Datenbankweg. Legen Sie die Konfigurationsdatei erst nach dem Import ab und testen Sie danach Anmeldung, Schreibvorgänge, Uploads und geplante Aufgaben.

Zum Abschluss entfernen Sie alle Testdateien, temporären Tabellen und ungenutzten Datenbankbenutzer. Ändern Sie das während des Tests verwendete Passwort, falls es in einer Datei, einem Terminal oder einem Bildschirmmitschnitt sichtbar war. Damit endet der Funktionstest nicht nur erfolgreich, sondern auch ohne vergessene Hintertür.

Fazit: Debian-10-Server prüfen und kontrolliert betreiben

Ein Debian-10-Server ist erst dann produktionsbereit, wenn nicht nur Website und Panel funktionieren, sondern auch Betrieb, Fehlererkennung und Wiederherstellung geplant sind. Prüfen Sie daher den Zustand aus Sicht des Betreibers: Welche Dienste laufen, welche Ressourcen werden verbraucht und wie lässt sich ein Ausfall nachweisen?

• Funktionsprüfung: Rufen Sie jede aktive Domain auf, testen Sie Anmeldung, Uploads, Formulare und geplante Aufgaben. Prüfen Sie auch absichtlich fehlerhafte Anfragen. Eine kontrollierte 404- oder 500-Antwort ist besser als eine sichtbare Systemmeldung.
• Ressourcenprüfung: Beobachten Sie CPU-Last, Arbeitsspeicher, I/O und Dateisystemfüllstand während normaler Nutzung. Ein Server mit dauerhaft mehr als 80 Prozent Speicherauslastung hat kaum Reserve für Spitzen.
• Dienstprüfung: Erstellen Sie eine Liste aller laufenden Einheiten und begründen Sie jeden Eintrag. Was nicht benötigt wird, gehört nicht in den Produktivbetrieb.
• Wiederherstellungstest: Ein Backup gilt erst als brauchbar, wenn sich daraus eine Datei, eine Datenbank und im Notfall ein kompletter Dienst wiederherstellen lassen.

Richten Sie eine einfache Überwachung ein. Prüfen Sie nicht nur, ob ein Prozess läuft, sondern ob die Anwendung antwortet. Ein Webdienst kann aktiv sein und trotzdem Datenbankfehler liefern. Sinnvoll sind getrennte Prüfungen für HTTPS, Datenbankzugriff, Speicherplatz und Zertifikatslaufzeit.

Definieren Sie für jeden Alarm eine konkrete Handlung. Eine Meldung ohne Zuständigkeit bringt wenig. Bei vollem Speicher muss klar sein, ob zuerst alte Protokolle entfernt, ein Limit erhöht oder ein Dienst kontrolliert beendet wird. Kleine Runbooks sparen im Ernstfall Zeit.

Planen Sie die Migration weg von Debian 10 jetzt, nicht erst nach dem nächsten Sicherheitsproblem. Das System ist im Jahr 2026 für neue öffentliche Hosting-Projekte nicht mehr zeitgemäß. Erstellen Sie eine Zielumgebung mit einer unterstützten Debian-Version, übertragen Sie Kundenkonten und Datenbanken schrittweise und testen Sie jede Domain vor der DNS-Umschaltung. So bleibt der alte Server zunächst als Rückfalloption erhalten.

Dokumentieren Sie dabei vor allem Abweichungen vom Standard:

• manuell installierte Pakete und zusätzliche Paketquellen
• angepasste PHP-Werte und Sonderversionen
• eigene Cronjobs, Skripte und geplante Importe
• besondere DNS-, Mail- oder TLS-Einstellungen
• Abhängigkeiten zwischen Websites und Datenbanken

Ein Hosting-Server sollte nicht nach Gefühl verwaltet werden. Legen Sie feste Prüftermine fest: monatlich für Konten und Dienste, nach jeder Änderung für Funktions- und Zugriffstests sowie vor jeder Migration für eine vollständige Inventur. Halten Sie Ergebnisse und offene Fehler in einem Änderungsprotokoll fest.

Die Anbieterwahl ändert an diesen Betriebsaufgaben nichts. Ein Debian-VPS mit Root-Zugriff, NVMe-Speicher, Backups, Snapshots und Firewall-Verwaltung kann die technische Basis erleichtern. Für kleine Shared-Hosting-Umgebungen kann ein Tarif mit 4 GB RAM ausreichen; mehrere PHP-Anwendungen, Maildienste und Datenbanken benötigen jedoch schnell 8 GB oder mehr. Entscheidend sind die tatsächliche Last, die Zahl der Kunden und ein getesteter Wiederanlauf, nicht allein der beworbene Tarif.

Fazit: Betreiben Sie Debian 10 nur kontrolliert, mit klarer Inventur, messbaren Prüfungen und einem festen Migrationsplan. Für neue Installationen im Jahr 2026 ist eine unterstützte Debian-Version die vernünftige Wahl. Damit wird aus einer funktionierenden Panel-Installation ein nachvollziehbar betreibbarer Hosting-Dienst.

Nützliche Links zum Thema

• Chapter 02. Konfigurasi Shared Hosting | PDF - Scribd
• Upgrade/Install Debian 10 to/or Debian 11 inside OpenVZ servers.
• Setup a minimal Debian 10 "buster" server as a Linode VPS

FAQ zur Einrichtung eines Shared-Hosting-Servers mit Debian 10