🖥 Webserver g50zeiten — Administrations-Doku

Diese Anleitung deckt zwei Hauptaufgaben ab: Die ipv64 DNS-Update-Skripte und das System-Update von Ubuntu. Sie ist als Schritt-für-Schritt-Anleitung geschrieben, sodass Sie sie auch noch nach Monaten Pause wieder benutzen können.

ssh root@192.168.178.122

# Verzeichnis anlegen
mkdir -p /var/www/meinedienst
chown -R www-data:www-data /var/www/meinedienst

# Test-Datei
echo "<h1>Hello meinedienst</h1>" > /var/www/meinedienst/index.html

# Apache-VirtualHost
cat > /etc/apache2/sites-available/meinedienst.conf <<'EOF'
<VirtualHost *:80>
    ServerName meinedienst.rusti.ipv64.net
    DocumentRoot /var/www/meinedienst
    DirectoryIndex index.html

    SetEnvIf X-Forwarded-Proto "https" HTTPS=on

    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    <Directory /var/www/meinedienst>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/meinedienst_error.log
    CustomLog ${APACHE_LOG_DIR}/meinedienst_access.log combined
</VirtualHost>
EOF

a2ensite meinedienst.conf
apache2ctl configtest
systemctl reload apache2

ssh root@192.168.178.132

# Backup nicht vergessen
cp /websitesscript/websites-upd-cronjob.sh \
   /websitesscript/websites-upd-cronjob.sh.bak

# Bearbeiten
nano /websitesscript/websites-upd-cronjob.sh

    "https://ipv4.ipv64.net/nic/update?key=DEIN_KEY&domain=rusti.ipv64.net"

bash -n /websitesscript/websites-upd-cronjob.sh && echo "✓ Syntax OK"
bash /websitesscript/websites-upd-cronjob.sh && echo "✓ Lief durch"

# Direkt-Test aller URLs
for url in $(grep '"https' /websitesscript/websites-upd-cronjob.sh | sed 's/.*"\(https[^"]*\)".*/\1/'); do
    key=$(echo "$url" | grep -oP "(?<=key=)[A-Za-z0-9]+" | head -1)
    echo -n "Key=...${key: -4}: "
    curl -sS "$url"
    echo ""
done

# DNS-Auflösung weltweit prüfen
dig +short meinedienst.rusti.ipv64.net @8.8.8.8

# HTTP-Header prüfen (sollte UTF-8 und HTTPS-Header zeigen)
curl -sI https://meinedienst.rusti.ipv64.net/

# Im Browser:
# https://meinedienst.rusti.ipv64.net

apachectl -t -D DUMP_VHOSTS

port 80 namevhost abos.rusti.ipv64.net (.../abos.conf:1)
port 80 namevhost stundng50.rusti.ipv64.net (.../stunden.conf:1)
port 80 namevhost tbrt.rusti.ipv64.net (.../treckertreff.conf:1)

# Backup
cp /etc/apache2/sites-available/STUNDEN.conf /root/STUNDEN.conf.bak

# ServerName direkt nach <VirtualHost *:80> einfügen
sed -i '/<VirtualHost \*:80>/a\    ServerName stundng50.rusti.ipv64.net' \
  /etc/apache2/sites-available/STUNDEN.conf

# Verifizieren + neu laden
apache2ctl configtest
systemctl reload apache2
apachectl -t -D DUMP_VHOSTS

System-Architektur — wer macht was?

Die Stundenabrechnung und andere Services sind weltweit über HTTPS erreichbar. Damit das funktioniert, arbeiten mehrere Komponenten zusammen:

Beteiligte VMs

Was machen die DNS-Update-Skripte?

Da Sie einen privaten Internetanschluss haben, ändert sich Ihre öffentliche IP gelegentlich (z.B. nach Router-Neustart, Provider-Reconnect). Wenn das passiert, würden Ihre Subdomains ins Leere zeigen — bis ein Update den DNS-Eintrag aktualisiert.

Auf der VM 132-Webserver-nginx liegen vier Cron-Skripte im Verzeichnis /websitesscript/, die diese Updates regelmäßig durchführen.

Jedes Skript enthält ein Array mit Update-URLs. Pro URL wird ein ipv64-DNS-Record aktualisiert.

Symbole im ipv64-Dashboard

Beim Record-Eintrag sehen Sie rechts 5 Symbole. Hier deren Bedeutung:

Token-Sicherheitsstufen bei ipv64

ipv64 bietet drei verschiedene Token-Typen mit unterschiedlichen Berechtigungen:

Skript-Syntax — exakte Form

Jedes der vier Update-Skripte hat dieselbe Struktur:

#!/bin/bash
# Update-URLs fuer ipv64.net DNS-Records
urls=(
    "https://ipv4.ipv64.net/nic/update?key=DERKEY&domain=rusti.ipv64.net"
    "https://ipv4.ipv64.net/nic/update?key=ANDERKEY&domain=rusti.ipv64.net"
)
for url in "${urls[@]}"; do
    curl -sS "$url" >/dev/null
done

Wichtige Syntax-Regeln

Anatomie der ipv64-Update-URL

https://ipv4.ipv64.net/nic/update?key=ABC123&domain=rusti.ipv64.net
        └──────────────┘└────────┘└───────┘└──────────────────────┘
              Host          Pfad      Key             Domain

Die URL bekommen Sie automatisch von ipv64, wenn Sie auf den Anker ⚓ klicken — sie steht dann in der Browser-Adresszeile.

📝 NEUE Website hinzufügen — Schritt für Schritt

Vorgehensweise wenn Sie eine neue Subdomain wie meinedienst.rusti.ipv64.net einrichten möchten und der DNS-Eintrag automatisch aktualisiert werden soll.

{"info":"nochg","status":"success","ip":{"ipv4":"84.149.178.189"}}

https://ipv4.ipv64.net/nic/update?key=ABC...XYZ&domain=rusti.ipv64.net

ssh root@192.168.178.132

cp /websitesscript/websites-upd-cronjob.sh \
   /websitesscript/websites-upd-cronjob.sh.bak

nano /websitesscript/websites-upd-cronjob.sh

    "https://ipv4.ipv64.net/nic/update?key=IHR_KEY&domain=rusti.ipv64.net"

bash -n /websitesscript/websites-upd-cronjob.sh
echo "Syntax-Exit: $?"

for url in $(grep '"https' /websitesscript/websites-upd-cronjob.sh | sed 's/.*"\(https[^"]*\)".*/\1/'); do
    key=$(echo "$url" | grep -oP "(?<=key=)[A-Za-z0-9]+" | head -1)
    echo -n "Key=...${key: -4}: "
    curl -sS "$url"
    echo ""
done

bash /websitesscript/websites-upd-cronjob.sh
echo "Exit: $?"

dig +short meinedienst.rusti.ipv64.net @8.8.8.8

Token neu generieren — wenn ein Key geleakt ist

Wenn Sie einen Key versehentlich veröffentlicht haben (z.B. in einer E-Mail, Forum, GitHub-Commit), müssen Sie ihn ungültig machen.

Website entfernen

Wenn Sie einen Service nicht mehr nutzen, sollten Sie sowohl den DNS-Record als auch das Cron-Skript bereinigen.

Wann werden die Skripte aufgerufen?

Die geplanten Ausführungszeiten sehen Sie mit:

crontab -l

Standardmäßig sind die vier Skripte zwischen 06:00 und 07:00 morgens CEST geplant.

Zeitzone überprüfen

Cron nutzt die Systemzeit der VM. Diese sollte Europe/Berlin sein:

timedatectl

Wenn dort UTC steht, läuft das System 1-2 Stunden „hinterher" — die 6:00-Skripte würden dann erst um 8:00 deutscher Zeit ausgeführt. Umstellen:

timedatectl set-timezone Europe/Berlin
systemctl restart cron

Cron-Job-Zeit ändern

crontab -e

Die Zeile entsprechend anpassen. Cron-Syntax:

m h dom mon dow command
│ │ │   │   │   └─ Befehl
│ │ │   │   └───── Wochentag (0-7, 0 oder 7 = Sonntag)
│ │ │   └───────── Monat (1-12)
│ │ └───────────── Tag im Monat (1-31)
│ └─────────────── Stunde (0-23)
└───────────────── Minute (0-59)

Beispiele:

Test-Workflow nach jeder Änderung

Nach jeder Änderung an einem Skript diese vier Tests durchlaufen:

Test 1: Syntax-Check

bash -n /websitesscript/websites-upd-cronjob.sh
echo "Syntax-Exit: $?"

Syntax-Exit: 0 = OK.

Test 2: Skript läuft

bash /websitesscript/websites-upd-cronjob.sh
echo "Exit: $?"

Exit: 0 = OK.

Test 3: ipv64-Antworten prüfen

for url in $(grep '"https' /websitesscript/websites-upd-cronjob.sh | sed 's/.*"\(https[^"]*\)".*/\1/'); do
    key=$(echo "$url" | grep -oP "(?<=key=)[A-Za-z0-9]+" | head -1)
    echo -n "Key=...${key: -4}: "
    curl -sS "$url"
    echo ""
done

Test 4: DNS-Auflösung

dig +short stundng50.rusti.ipv64.net @8.8.8.8

Sollte Ihre aktuelle öffentliche IP zeigen.

Cron-Simulation in 2 Minuten

Um zu testen, ob Cron das Skript wirklich ausführen kann:

date

Aktuelle Zeit notieren, z.B. 21:23. Dann:

crontab -e

Test-Zeile einfügen (2 Minuten in der Zukunft, also 21:25):

25 21 * * * /websitesscript/websites-upd-cronjob.sh

Speichern, dann warten. Um 21:25 prüfen:

grep CRON /var/log/syslog | tail -5

Sie sollten einen Eintrag wie CMD (/websitesscript/websites-upd-cronjob.sh) sehen.

Danach mit crontab -e die Test-Zeile wieder entfernen.

System-Update — Übersicht

Ubuntu erhält regelmäßig Sicherheits-Updates. Diese sollten Sie etwa einmal im Monat einspielen. Längere Pausen sind nicht ratsam, weil sich Sicherheits-Lücken ansammeln.

Was kann passieren?

🔄 Update Step-by-Step

ssh root@192.168.178.132

apt update

apt list --upgradable

apt upgrade -y

apt autoremove -y
apt autoclean

[ -f /var/run/reboot-required ] && echo "🔁 Reboot empfohlen" || echo "✅ Kein Reboot nötig"

systemctl is-active nginx ssh.socket cron apache2

Konfigurations-Konflikte richtig behandeln

Wenn das Update fragt:

Configuration file '/etc/...'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it?
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version (default)
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
*** ... (Y/I/N/O/D/Z) [default=N] ?

Immer „N" oder einfach Enter drücken (Default). Damit bleibt Ihre angepasste Konfiguration erhalten. Wenn Sie versehentlich „Y" wählen, wird Ihre Konfiguration durch die Standard-Version überschrieben — und Ihre Anpassungen (Sites, Cron-Skripte, etc.) sind weg.

Reboot oder nicht?

Folgende Updates erfordern einen Reboot:

• Kernel (linux-image-*)
• Standardbibliothek libc6 (technisch nicht zwingend, aber sicherheitshalber empfohlen)
• Systemd (manchmal)

Folgende Updates erfordern nur einen Service-Restart:

• nginx, apache2 — Webserver neu starten
• php8.3-fpm — PHP neu starten
• openssh-server — bestehende Session bleibt
• OpenSSL-Bibliotheken — abhängige Services brauchen Restart

Ubuntu sagt Bescheid, ob ein Reboot nötig ist:

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

Cron-Log lesen

Cron schreibt jede Ausführung in das System-Log:

grep CRON /var/log/syslog | tail -20

Beispielausgabe:

May 20 06:00:01 Webserver-nginx CRON[1759]: (root) CMD (/websitesscript/websites-upd-cronjob.sh)
May 20 06:15:01 Webserver-nginx CRON[1870]: (root) CMD (/websitesscript/websites2-upd-cronjob.sh)

Live mitschauen:

journalctl -u cron -f

Beenden mit Ctrl+C.

DNS-Auflösung prüfen

Aktuelle öffentliche IP des Anschlusses ermitteln:

curl -sS https://ifconfig.me
curl -sS https://api.ipify.org

ipv64-Antworten verstehen

Wenn Sie das Update-Skript testen, antwortet ipv64 mit JSON. Hier die häufigsten:

Services prüfen

Wichtige Services auf der Webserver-VM:

• nginx — Webserver
• ssh.socket — SSH (in Ubuntu 24.04)
• cron — Zeitgesteuerte Jobs
• ufw — Firewall

API-Keys richtig schützen

• Niemals Keys in öffentlichen Chats, Issue-Trackern, GitHub-Commits posten
• Wenn ein Key versehentlich öffentlich wurde: sofort regenerieren (siehe Token-Rotation)
• Skripte mit Keys nur für Root lesbar machen:

  chmod 700 /websitesscript/*.sh
  chown root:root /websitesscript/*.sh

• Backup-Dateien (.sh.bak) nicht in öffentliche Verzeichnisse legen

Notfall-Wiederherstellung

Skript versehentlich kaputt gemacht

Wenn Sie ein .bak-Backup haben:

cp /websitesscript/websites-upd-cronjob.sh.bak \
   /websitesscript/websites-upd-cronjob.sh
chmod +x /websitesscript/websites-upd-cronjob.sh

Apache-Konfig kaputt

Wenn nach einem Update Apache nicht mehr startet:

apache2ctl configtest

Zeigt die fehlerhafte Zeile. Reparieren mit nano /etc/apache2/sites-available/....

Nichts hilft mehr — Rollback der VM

Im Proxmox-Web-UI:

1. VM 132-Webserver-nginx auswählen
2. Links auf „Backup"
3. Das letzte funktionierende Backup auswählen
4. „Zurückspielen" klicken
5. VM startet neu auf dem Stand des Backups

⚠️ Achtung: Damit gehen ALLE Änderungen seit dem Backup verloren — auch Daten in Anwendungen, die seitdem entstanden sind.

Webserver-Doku Stand: 20.05.2026
Für IP 192.168.178.132 / Ubuntu 24.04 LTS / nginx + cron-Updates für ipv64.net