Netcup Server Control Panel (SCP) Handbuch: Cloud-Init, Edge-Firewall, CoW-Snapshots & REST-API

Anders als stark abstrahierte Cloud-Konsolen gewährt das Netcup Server Control Panel (https://www.servercontrolpanel.de) direkten Zugriff auf die QEMU/KVM-Hardwareemulation Ihrer Instanz. Moderne Netcup-Instanzen basieren auf dem PCIe-nativen QEMU-Maschinentyp pc-q35 (anstelle der älteren pc-i440fx PCI-Bridge-Emulation) und nutzen standardmäßig den CPU-Modus host-passthrough. Dadurch reicht der KVM-Hypervisor sämtliche Befehlssatzerweiterungen des Host-Prozessors – einschließlich Zen 5 avx512f, avx512_vnni, avx512_bf16, aes-ni sowie der exakten L1/L2/L3-Cache-Topologie – ohne Emulationsverluste direkt an den Linux-Gastkernel durch.

Bei der automatisierten Bereitstellung hängt das SCP ein schreibgeschütztes virtuelles CD-ROM-Laufwerk mit dem Volume-Label cidata (/dev/sr0, ISO9660-Dateisystem) ein, das vom Cloud-Init NoCloud-Datasource-Treiber ausgelesen wird und die über die SCP-Oberfläche oder REST-API definierten meta-data-, user-data- und network-config-Payloads bereitstellt. Unter Server → Einstellungen / Allgemein sollten Administratoren vor der Installation drei zentrale Hardware-Bus-Parameter prüfen:

• ▪ Festplatten-Controller (virtio-scsi vs. virtio-blk): Belassen Sie die Einstellung für moderne Linux-Kernel (Debian 12, Ubuntu 24.04, Rocky Linux 9, Proxmox VE) unbedingt auf virtio-scsi. Dies ermöglicht natives SCSI-UNMAP/TRIM-Passthrough (fstrim.timer) und verteilt I/O-Warteschlangen (num_queues) über alle dedizierten EPYC-Kerne.
• ▪ Netzwerkadapter (virtio-net mit mq=on): Stellt die paravirtualisierte 2,5-Gbit/s-Netzwerkkarte mit vhost_net-Kernelbeschleunigung, Hardware-Checksum-Offloading und parallelen RX/TX-Queues bereit, die sich im Gastsystem per ethtool -l eth0 und ethtool -L eth0 combined 4 prüfen und skalieren lassen.
• ▪ Boot-Firmware (OVMF UEFI vs. SeaBIOS): Alle offiziellen Netcup Cloud-Init-Images booten standardmäßig über OVMF UEFI mit GPT-Partitionstabelle. Wechseln Sie nur für spezielle ältere Recovery- oder BSD-ISOs auf Legacy-SeaBIOS.

Wenn Sie unter SCP → Medien → Offizielle Images ein Template mit Cloud-Init-Markierung auswählen, öffnet sich der YAML-Konfigurationseditor. Für produktive Deployments empfiehlt sich die Übergabe eigener user-data- und network-config-Manifeste.

Wichtig für das Netzwerk-Setup: Ihre primäre IPv4-Adresse liegt bei Netcup meist in einem geteilten /22-Subnetz, während Ihr dediziertes /64-IPv6-Subnetz statisch über das Link-Local-Gateway fe80::1 geroutet wird (SLAAC / Router Advertisements sind bewusst deaktiviert, damit Sie deterministische Adressen und volle rDNS-Kontrolle behalten).

Die folgenden zwei Manifeste richten einen gehärteten Ubuntu 24.04 / Debian 12 Server inklusive BBR-Staukontrolle und stabiler Dual-Stack-Netzwerkkonfiguration vollautomatisch ein:

#cloud-config
hostname: nc-prod-node01
fqdn: nc-prod-node01.example.com
manage_etc_hosts: true
timezone: UTC

package_update: true
package_upgrade: true
packages:
  - qemu-guest-agent
  - ufw
  - fail2ban
  - curl
  - jq
  - htop
  - iotop
  - unattended-upgrades

users:
  - name: opsadmin
    groups: [sudo, adm, systemd-journal]
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    lock_passwd: true
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIReplaceWithYourActualEd25519PublicKey opsadmin@secops

ssh_pwauth: false
disable_root: true

write_files:
  - path: /etc/ssh/sshd_config.d/99-netcup-hardening.conf
    permissions: '0600'
    content: |
      PermitRootLogin no
      PasswordAuthentication no
      KbdInteractiveAuthentication no
      X11Forwarding no
      MaxAuthTries 3
      AllowUsers opsadmin
  - path: /etc/sysctl.d/99-netcup-bbr.conf
    permissions: '0644'
    content: |
      net.core.default_qdisc = fq
      net.ipv4.tcp_congestion_control = bbr
      net.ipv4.tcp_fastopen = 3
      net.ipv6.conf.all.forwarding = 1

runcmd:
  - sysctl --system
  - systemctl enable --now qemu-guest-agent
  - systemctl enable --now fstrim.timer
  - systemctl restart ssh || systemctl restart sshd
  - ufw default deny incoming
  - ufw default allow outgoing
  - ufw allow 22/tcp comment 'SSH Admin'
  - ufw allow 80/tcp comment 'HTTP Ingress'
  - ufw allow 443/tcp comment 'HTTPS Ingress'
  - ufw allow 443/udp comment 'HTTP3 QUIC'
  - ufw --force enable
  - systemctl enable --now fail2ban

# Netcup Statisches IPv4 (/22) + Geroutetes /64 IPv6 über Link-Local-Gateway fe80::1
network:
  version: 2
  ethernets:
    eth0:
      match:
        macaddress: "aa:bb:cc:dd:ee:ff" # MAC-Adresse aus dem Reiter SCP -> Netzwerk eintragen
      set-name: eth0
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 152.53.xxx.xxx/22             # Eigene IPv4-Adresse & CIDR-Präfix aus dem SCP ersetzen
        - 2a0a:4cc0:xxxx:xxxx::1/64     # Primäre IPv6-Adresse aus Ihrem zugewiesenen /64-Subnetz
        - 2a0a:4cc0:xxxx:xxxx::2/64     # Optional: Zweite IPv6-Adresse für Mail-Relay oder Proxies
      nameservers:
        addresses:
          - 46.38.225.230               # Netcup Anycast DNS-Resolver 1
          - 46.38.252.230               # Netcup Anycast DNS-Resolver 2
          - 2a03:4000:0:1::e1e6         # Netcup IPv6 DNS-Resolver
      routes:
        - to: default
          via: 152.53.xxx.1             # IPv4-Standardgateway aus SCP -> Netzwerk
        - to: "::/0"
          via: "fe80::1"                # Standardisiertes Netcup IPv6 Link-Local-Gateway
          on-link: true

Ein zentrales Sicherheitsmerkmal des modernen Netcup SCP ist die Hypervisor Stateful Firewall unter SCP → Netzwerk → Firewall.

Auf einem klassischen Linux-Server mit Docker oder Kubernetes schreibt ein veröffentlichter Port wie -p 5432:5432 eigene DNAT-Regeln direkt in die PREROUTING- und DOCKER-Chains von iptables/nftables. Dadurch werden lokale ufw- oder firewalld-Regeln umgangen und Datenbank-Container ungewollt ins öffentliche Internet exponiert.

Da die SCP-Firewall außerhalb Ihrer VM direkt auf dem virtuellen Switch-Port (tap-Interface) des KVM-Hostsystems arbeitet, werden blockierte Pakete bereits am Hypervisor verworfen, bevor sie Ihre virtuelle Netzwerkkarte erreichen.

Auf Protokollebene verwaltet die SCP-Firewall auf dem KVM-Host eine zustandsbehaftete Connection-Tracking-Tabelle (conntrack) für jedes virtuelle Interface. Ausgehende TCP-, UDP- und ICMP-Verbindungen Ihrer VM schalten automatisch die zugehörigen Antwortpakete (ESTABLISHED,RELATED) frei, ohne dass dafür eingehende Ports geöffnet werden müssen (wobei inaktive TCP-Sitzungen ohne Keepalive nach Ablauf des Hypervisor-State-Timeouts geschlossen werden). Für IPv6 (::/0) gilt jedoch eine wichtige Besonderheit: Das Neighbor Discovery Protocol nach RFC 4861 (ICMPv6 Typ 135 Neighbor Solicitation und Typ 136 Neighbor Advertisement) wird vom Link-Local-Router fe80::1 unabhängig von bestehenden ausgehenden Verbindungen initiiert. Daher muss eingehendes ICMPv6 in der SCP-Firewall zwingend auf ACCEPT stehen, damit die Nachbarschaftstabelle zwischen Host-Gateway und VM regelmäßig erneuert werden kann:

Das Netcup SCP unterstützt sowohl Offline-Snapshots als auch Online (Live) Copy-on-Write-Snapshots im laufenden Betrieb sowie den direkten HTTPS-Export von Snapshots als komprimiertes Raw-Image für externe Backups.

Ist der qemu-guest-agent in Ihrem Linux-Gastsystem aktiv, sendet KVM beim Start eines Online-Snapshots den Befehl guest-fsfreeze-freeze über /dev/virtio-ports/org.qemu.guest_agent.0. Der Agent führt daraufhin alle Skripte in /etc/qemu/fsfreeze-hook.d/ mit dem Parameter freeze aus, friert das Dateisystem per Kernel-FIFREEZE-ioctl für wenige Millisekunden konsistent ein, setzt den atomaren CoW-Snapshot-Pointer und gibt das Dateisystem sofort per thaw wieder frei.

Achten Sie bei eigenen Hook-Skripten unter /etc/qemu/fsfreeze-hook.d/ darauf, dass die Ausführungszeit strikt unter 3 bis 5 Sekunden bleibt. Solange FIFREEZE aktiv ist, blockiert der Linux-Kernel sämtliche Schreibzugriffe (write(), fsync(), open(..., O_CREAT)) auf dem eingefrorenen Dateisystem im nicht-unterbrechbaren Schlafzustand (D-State). Hängt ein benutzerdefiniertes Skript – etwa durch eine blockierte Datenbankverbindung oder ein nicht erreichbares Netzwerk-Share –, überschreitet der QMP-Aufruf guest-fsfreeze-freeze das Hypervisor-Timeout. Das SCP bricht dann den applikationskonsistenten Freeze ab (bzw. fällt auf einen crash-konsistenten Snapshot zurück), oder Sie müssen das Dateisystem bei einem abgestürzten Guest-Agent manuell über die VNC-Konsole per sudo fsfreeze --unfreeze / wieder freigeben:

#!/usr/bin/env bash
# Pfad: /etc/qemu/fsfreeze-hook.d/10-postgresql-checkpoint.sh
# Berechtigungen: chmod 0755 /etc/qemu/fsfreeze-hook.d/10-postgresql-checkpoint.sh

set -euo pipefail

case "$1" in
  freeze)
    if systemctl is-active --quiet postgresql; then
      su - postgres -c "psql -U postgres -c 'CHECKPOINT;'" >/dev/null 2>&1 || true
      logger -t qemu-fsfreeze "PostgreSQL CHECKPOINT vor Netcup SCP CoW-Snapshot erfolgreich geschrieben"
    fi
    ;;
  thaw)
    logger -t qemu-fsfreeze "Dateisystem nach Netcup SCP CoW-Snapshot wieder freigegeben (thaw)"
    ;;
esac

Das moderne Server Control Panel stellt eine vollständige OpenAPI-v1-REST-Schnittstelle (https://www.servercontrolpanel.de/scp-core/api/v1) bereit, die über Keycloak OAuth2 / OpenID Connect Bearer-Tokens abgesichert ist. Die interaktive Swagger-Dokumentation erreichen Sie direkt unter https://www.servercontrolpanel.de/scp-core/api/v1/swagger-ui/index.html.

Mit dem folgenden Skript können DevOps-Teams vor einem Deployment vollautomatisch einen Pre-Upgrade-Snapshot über die REST-API anlegen:

#!/usr/bin/env bash
# Authentifizierung gegen Netcup SCP Keycloak OIDC & Abfrage von Server-Status + Snapshot-Erstellung
set -euo pipefail

SCP_TOKEN_URL="https://www.servercontrolpanel.de/realms/scp/protocol/openid-connect/token"
SCP_API_BASE="https://www.servercontrolpanel.de/scp-core/api/v1"

# 1. SCP Refresh-Token gegen einen kurzlebigen Bearer Access-Token tauschen:
ACCESS_TOKEN=$(curl -sS -X POST "$SCP_TOKEN_URL" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=scp" \
  -d "grant_type=refresh_token" \
  -d "refresh_token=${NETCUP_SCP_REFRESH_TOKEN}" | jq -r '.access_token')

# 2. Alle Root-Server und VPS-Instanzen des Kontos samt Status auflisten:
curl -sS -X GET "${SCP_API_BASE}/servers" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Accept: application/json" | jq '.[] | {id: .id, name: .name, hostname: .hostname, status: .status}'

# 3. Vor Wartungsarbeiten automatisch einen Online Copy-on-Write Snapshot anlegen:
SERVER_ID="123456"
curl -sS -X POST "${SCP_API_BASE}/servers/${SERVER_ID}/snapshots" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"name": "pre-upgrade-'$(date +%Y%m%d)'", "description": "Automatischer CoW-Snapshot vor Ansible-Deployment"}'