Server Installation · 3 min read · Sep 30, 2025

Installation eines Web-, E-Mail- und MySQL-Datenbankclusters auf Debian 8.4 Jessie mit ISPConfig 3.1

Dieses Tutorial beschreibt die Installation eines clusterbasierten Web-, E-Mail-, Datenbank- und DNS-Servers, der für Redundanz, hohe Verfügbarkeit und Lastverteilung auf Debian 8 mit dem ISPConfig 3-Steuerfeld verwendet wird. MySQL Master/Master-Replikation wird verwendet, um die MySQL-Clientdatenbanken zwischen den Servern zu replizieren, Unison wird verwendet, um das /var/www (Websites) zu synchronisieren und die E-Mails werden mit Dovecot synchronisiert.

1 Allgemeine Hinweise

In diesem Setup wird es einen Master-Server (der die ISPConfig-Steuerfeldschnittstelle ausführt) und einen Slave-Server geben, der die Web- (apache), E-Mail- (postfix und dovecot), DNS- (bind) und Datenbank- (MySQL oder MariaDB) Dienste des Master-Servers spiegelt.

Um das clusterbasierte Setup zu installieren, benötigen wir zwei Server mit einer minimalen Debian 8.4-Installation und der gleichen ISPConfig-Version.

In meinem Beispiel verwende ich die folgenden Hostnamen und IP-Adressen für die beiden Server:

Master-Server

Hostname: server1.example.tld
IP-Adresse: 192.168.0.105
IPv6-Adresse: 2001:db8::1

Slave-Server

Hostname: server2.example.tld
IP-Adresse: 192.168.0.106
IPv6-Adresse: 2001:db8::2

Wo auch immer diese Hostnamen oder IP-Adressen in den nächsten Installationsschritten vorkommen, müssen Sie sie an die IPs und Hostnamen Ihrer Server anpassen.

Alle Befehle müssen als Root-Benutzer ausgeführt werden. Wenn Sie Änderungen in MySQL vornehmen müssen, melden Sie sich mit dem Root-Passwort für MySQL bei MySQL an:

mysql -u root -p

2 Installieren des Master-Servers

Zuerst müssen wir ISPConfig auf dem Master-Server installieren. Wenn Sie ISPConfig bereits auf diesem Server installiert haben, können Sie die Installation überspringen (stellen Sie sicher, dass die vorhandene Installation auf dem neuesten Stand ist).

Installieren Sie ISPConfig auf dem Master-Server gemäß The Perfect Server - Debian 8.4 Jessie (Apache2, BIND, Dovecot, ISPConfig 3.1).

Fügen Sie den Slave-Server zur Datei /etc/hosts hinzu

vi /etc/hosts

sodass es so aussieht:

127.0.0.1       localhost
192.168.0.105   server1.example.tld server1  
2001:db8::1     server1.example.tld server1
192.168.0.106   server2.example.tld  
2001:db8::2     server2.example.tld

# Die folgenden Zeilen sind wünschenswert für IPv6-fähige Hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

3 Vorbereiten des Slave-Servers

Führen Sie die Schritte 1 - 19 aus The Perfect Server - Debian 8.4 Jessie (Apache2, BIND, Dovecot, ISPConfig 3.1).

Installieren Sie noch nicht ISPConfig auf server2.

Fügen Sie den Master-Server zur Datei /etc/hosts hinzu

vi /etc/hosts

sodass es so aussieht:

127.0.0.1       localhost
192.168.0.105   server1.example.tld  
2001:db8::1     server1.example.tld
192.168.0.106   server2.example.tld server2  
2001:db8::2     server2.example.tld server2

# Die folgenden Zeilen sind wünschenswert für IPv6-fähige Hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

4 Passwortloses Login von Server1 zu Server2

Auf server2:

Wir erlauben vorübergehend den Root-Login auf server2 mit einem Passwort. Öffnen Sie /etc/sshd_config:

vi /etc/ssh/sshd_config

und ändern Sie

PermitRootLogin without-password

in

PermitRootLogin yes

Starten Sie anschließend den SSH-Daemon neu:

service ssh restart

Auf server1:

Erstellen Sie ein privates/öffentliches Schlüsselpaar:

ssh-keygen
Generiere ein öffentliches/privates rsa-Schlüsselpaar.  
Geben Sie die Datei an, in der der Schlüssel gespeichert werden soll (/root/.ssh/id_rsa): <-- ENTER  
Verzeichnis '/root/.ssh' erstellt.  
Geben Sie eine Passphrase ein (leer für keine Passphrase): <-- ENTER  
Geben Sie dieselbe Passphrase erneut ein: <-- ENTER  
Ihre Identifikation wurde in /root/.ssh/id_rsa gespeichert.  
Ihr öffentlicher Schlüssel wurde in /root/.ssh/id_rsa.pub gespeichert.  
Der Schlüssel-Fingerabdruck ist:  
f3:d0:62:a7:24:6f:f0:1e:d1:64:a9:9f:12:6c:98:5a root@server1  
Das zufällige Kunstwerk des Schlüssels ist:  
+---[RSA 2048]----+  
|                 |  
|           .     |  
|          +      |  
|       + *       |  
|      E S +      |  
|    o O @ .      |  
|   .   B +       |  
|       o o       |  
|        .        |  
+-----------------+  

Es ist wichtig, dass Sie keine Passphrase eingeben, da die Spiegelung sonst nicht ohne menschliches Eingreifen funktioniert, also drücken Sie einfach ENTER!

Als nächstes kopieren wir unseren öffentlichen Schlüssel nach server2.example.tld:

ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]
Die Authentizität des Hosts '192.168.0.106 (192.168.0.106)' kann nicht festgestellt werden.  
ECDSA-Schlüsselfingerabdruck ist 25:d8:7a:ee:c2:4b:1d:92:a7:3d:16:26:95:56:62:4e.  
Sind Sie sicher, dass Sie die Verbindung fortsetzen möchten (ja/nein)? <-- ja (dies sehen Sie nur, wenn Sie zum ersten Mal eine Verbindung zu server2 herstellen)   
/usr/bin/ssh-copy-id: INFO: versucht, sich mit dem neuen Schlüssel(n) anzumelden, um alle zu filtern, die bereits installiert sind  
/usr/bin/ssh-copy-id: INFO: 1 Schlüssel(n) bleiben zu installieren -- wenn Sie jetzt aufgefordert werden, geschieht dies, um die neuen Schlüssel zu installieren
[email protected]'s Passwort: <- geben Sie das Root-Passwort von server2 ein

Versuchen Sie nun, sich bei der Maschine anzumelden:

ssh [email protected]

Und überprüfen Sie /root/.ssh/authorized_keys, um sicherzustellen, dass wir keine zusätzlichen Schlüssel hinzugefügt haben, die Sie nicht erwartet haben.

cat /root/.ssh/authorized_keys
ssh-dss AAAAB3NzaC1kc3MAAACBAPhiAexgEBexnw0rFG8lXwAuIsca/V+lhmv5lhF3BqUfAbL7e2sWlQlGhxZ8I2UnzZK8Ypffq6Ks+lp46yOs7MMXLqb7JBP9gkgqxyEWqOoUSt5hTE9ghupcCvE7rRMhefY5shLUnRkVH6hnCWe6yXSnH+Z8lHbcfp864GHkLDK1AAAAFQDddQckbfRG4C6LOQXTzRBpIiXzoQAAAIEAleevPHwi+a3fTDM2+Vm6EVqR5DkSLwDM7KVVNtFSkAY4GVCfhLFREsfuMkcBD9Bv2DrKF2Ay3OOh39269Z1rgYVk+/MFC6sYgB6apirMlHj3l4RR1g09LaM1OpRz7pc/GqIGsDt74D1ES2j0zrq5kslnX8wEWSHapPR0tziin6UAAACBAJHxgr+GKxAdWpxV5MkF+FTaKcxA2tWHJegjGFrYGU8BpzZ4VDFMiObuzBjZ+LrUs57BiwTGB/MQl9FKQEyEV4J+AgZCBxvg6n57YlVn6OEA0ukeJa29aFOcc0inEFfNhw2jAXt5LRyvuHD/C2gG78lwb6CxV02Z3sbTBdc43J6y [email protected]

Verhindern Sie den Root-Login mit einem Passwort. Öffnen Sie /etc/sshd_config:

vi /etc/ssh/sshd_config

und ändern Sie

PermitRootLogin yes

in

PermitRootLogin without-password

Starten Sie anschließend den SSH-Daemon neu:

service ssh restart

Melden Sie sich von server2 ab:

exit
logout  
Verbindung zu 192.168.0.106 geschlossen.

Wir sind jetzt wieder auf server1.

Share: X/Twitter LinkedIn

Erhalte neue Beiträge in deinem Posteingang.

Kein Spam. Jederzeit abmelden.