Teil 1 — Saubere FQDN/PTR-Konfiguration & Grundinstallation von ISPConfig (mit NGINX)

Last updated on 17. August 2025

Ziel dieses Teils:

• Dem Server einen stabilen, korrekten FQDN geben (Hostname + /etc/hosts + PTR/rDNS).
• Verhindern, dass Cloud-Init diese Einstellungen beim Booten überschreibt.
• ISPConfig (NGINX) automatisch installieren und die Erreichbarkeit testen.
• (Die Umleitung auf Port 443 via Reverse-Proxy, HSTS, „Rescue“-Port usw. kommt in Teil 2.)

---

Voraussetzungen & Platzhalter

Wir verwenden Dokumentations-Platzhalter. Ersetze sie überall durch deine echten Werte:

# BITTE anpassen:
export FQDN="server.example.com"     # Vollqualifizierter Hostname deines Servers
export IPV4="198.51.100.10"          # Öffentliche IPv4
export IPV6="2001:db8::10"           # Öffentliche IPv6 (falls vorhanden)

Hinweis (rDNS/PTR beim Provider): Lege für IPv4 und IPv6 einen PTR-Eintrag auf server.example.com an. PTR (IP → Name) und A/AAAA (Name → IP) müssen zusammenpassen – wichtig u. a. für Mail & Zertifikate.

Hostname & /etc/hosts dauerhaft setzen

Hostname setzen

sudo hostnamectl set-hostname "$FQDN"

/etc/hosts pflegen

sudo nano /etc/hosts

Empfohlener Inhalt (FQDN + Kurzname auf 127.0.1.1):

127.0.1.1  server.example.com  server
127.0.0.1  localhost

# IPv6-Loopback:
::1        localhost ip6-localhost ip6-loopback
ff02::1    ip6-allnodes
ff02::2    ip6-allrouters

Cloud-Init am Zurücksetzen hindern

Auf vielen Debian-Images überschreibt cloud-init /etc/hostname und /etc/hosts beim Booten. Wähle eine der Varianten:

Variante A (einfach): Cloud-Init steuern/abschalten

sudo nano /etc/cloud/cloud.cfg

Sorge für diese Werte:

preserve_hostname: true
# Falls vorhanden:
manage_etc_hosts: false

Variante B (Alternative): Template korrigieren

Wenn du manage_etc_hosts: true behalten willst:

sudo nano /etc/cloud/templates/hosts.debian.tmpl

Passe an:

127.0.1.1 server.example.com server
127.0.0.1 localhost

Neustarten & prüfen

sudo systemctl reboot

Nach dem Login testen:

hostname
hostname -f
getent hosts "$(hostname -f)"

Erwartung:

• hostname -f → server.example.com
• getent zeigt eine Zeile wie 127.0.1.1 server.example.com server

---

DNS-A/AAAA setzen (bei Cloudflare „DNS only“)

Lege im Zonen-DNS an:

• A server.example.com 198.51.100.10
• AAAA server.example.com 2001:db8::10 (falls IPv6)

Cloudflare: Während der Installation/Validierung Proxy AUS (graue Wolke, „DNS only“). Danach kannst du wieder einschalten.

---

ISPConfig (NGINX) automatisch installieren

wget -O - https://get.ispconfig.org | \
  sudo sh -s -- --use-nginx --use-ftp-ports=40110-40210 --unattended-upgrades

Am Ende zeigt der Installer wichtige Zugangsdaten – sichern!

Basis-Checks

systemctl status nginx --no-pager
systemctl status php*-fpm --no-pager
systemctl status mariadb --no-pager      # oder mysql
systemctl status postfix --no-pager

sudo ss -ltnp | grep -E ':(80|443|8080|8081)\b'

• :8080 → ISPConfig-Panel (HTTPS)
• :8081 → App-Vhost (z. B. phpMyAdmin)
• :80/:443 → Websites

Testzugriff (nur vorübergehend): https://server.example.com:8080 sollte erreichbar sein. Der Browser warnt evtl. (selbstsigniert) – ist normal. In Teil 2 legen wir den Reverse-Proxy auf Port 443 samt Let’s-Encrypt-Zertifikat an.

(Optional) Erste Website & Let’s Encrypt vorbereiten

Im ISPConfig-Panel unter Sites deine Domain anlegen (z. B. example.com) und Let’s Encrypt aktivieren.
Voraussetzungen: DNS zeigt korrekt auf den Server, bei Cloudflare Proxy aus.

---

Kurze Fehleranalyse (Checkliste)

• hostname -f ≠ FQDN → Hostname/Hosts/Cloud-Init prüfen.
• /etc/hosts ändert sich nach Reboot → cloud.cfg/Template anpassen.
• :8080 nicht erreichbar → ss -ltnp | grep :8080, systemctl status nginx, evtl. Firewall.
• LE scheitert → DNS-Ziele/A/AAAA prüfen, Cloudflare-Proxy aus, Zugriff auf
  /.well-known/acme-challenge/... von außen testen.

---

Wie es in Teil 2 weitergeht

• Panel & phpMyAdmin sauber über Port 443 via NGINX-Reverse-Proxy bereitstellen.
• Korrektes SNI & Let’s-Encrypt-Zertifikat für server.example.com.
• HSTS & Security-Header.
• Optionaler „Rescue“-Zugang (4443) mit IP-SAN-Zertifikat.
• Konflikte durch Wildcard-listen vermeiden (pro VHost gezielt ans IP-Interface binden).

---

Fertig mit Teil 1. Wenn du willst, passe die Platzhalter an deinen Stil an , dann bauen wir in Teil 2 darauf auf und bringen alles sauber auf Port 443.

Teil 2 Link: Teil 2 – ISPConfig hinter Nginx auf Port 443 (Reverse-Proxy) mit Rettungszugang & Basic Auth & saubere Zertifikate

Quelle

ISPConfig Auto-Installer (Debian/Ubuntu) – HowtoForge