Ubuntu 24.04 LTS auf einem Netcup VPS oder Root-Server einrichten & absichern (Produktions-Runbook)
Sobald ein frisch bereitgestellter Netcup VPS oder Root-Server die Installation von Ubuntu 24.04 LTS im Server Control Panel (SCP) abgeschlossen hat, entscheiden die ersten 25 Minuten des System-Engineerings darüber, ob Ihr Server über Jahre hinweg stabil läuft oder unter inkonsistenten Live-Snapshots, SSH-Brute-Force-Wellen und suboptimalem TCP-Durchsatz leidet. Dieses Produktions-Runbook führt Sie Schritt für Schritt durch die Überprüfung der paravirtualisierten KVM-Treiber (virtio_scsi und virtio_net), die Installation des QEMU Guest Agents für konsistente SCP-Live-Snapshots (fsfreeze), das Anlegen eines unprivilegierten Administratorkontos, das Tuning von NVMe-Swap und Google TCP BBR (fq qdisc) für 1 Gbit/s- und 2,5 Gbit/s-Interfaces sowie die Härtung von OpenSSH (ssh.socket) und UFW.
VORAUSSETZUNGEN // ANFORDERUNGEN
CHECKLISTE- ✓ Ein aktiver Netcup VPS (z. B. VPS 1000 G12.5 mit 8 GB ECC-RAM) oder Root-Server (z. B. RS 1000 G12.5 mit dedizierten AMD EPYC Zen 5 Kernen)
- ✓ Zugang zum Netcup Server Control Panel (SCP) unter servercontrolpanel.de
- ✓ Ein OpenSSH-Client (Linux/macOS-Terminal oder Windows 11 PowerShell) mit einem lokal generierten Ed25519-SSH-Schlüsselpaar
Wichtige Erkenntnisse (Key Takeaways)
KURZFAZIT-
01 Installieren und aktivieren Sie sofort den
qemu-guest-agent, damit der Netcup-SCP-Hypervisor während laufender Copy-on-Write-Snapshotsfsfreeze-Hooks (FIFREEZE) ausführen und saubere ACPI-Shutdowns auslösen kann. -
02 Stellen Sie sicher, dass Ihr Block-Storage-Gerät
virtio_scsiodervirtio_blkverwendet und der wöchentlichefstrim.timeraktiviert ist, damit gelöschte Blöcke an das Ceph/NVMe-Storage-Backend von Netcup zurückgegeben werden. -
03 Erstellen Sie einen dedizierten sudo-Benutzer und testen Sie den Ed25519-Public-Key-Login in einem zweiten Terminalfenster, bevor Sie die Root-Passwort-Authentifizierung über
/etc/ssh/sshd_config.d/99-netcup-hardening.confdeaktivieren. -
04 Konfigurieren Sie eine kapazitätsgerechte Swap-Datei mit
vm.swappiness = 10und aktivieren Sie Google TCP BBR (net.ipv4.tcp_congestion_control = bbr), um den Durchsatz auf den 1 Gbit/s- und 2.5 Gbit/s-Interfaces von Netcup zu maximieren.
📑 Inhaltsverzeichnis (4 Abschnitte) ▼
- 01 Schritt 1: KVM-Paravirtualisierung prüfen, Pakete aktualisieren & QEMU Guest Agent aktivieren
- 02 Schritt 2: Unprivilegierten Admin-Benutzer anlegen & Chrony-Zeitsynchronisation konfigurieren
- 03 Schritt 3: NVMe-Swap-Speicher bereitstellen & Kernel-Netzwerk-/VM-Parameter (sysctl) optimieren
- 04 Schritt 4: OpenSSH absichern, UFW-Firewall aktivieren & Unattended Upgrades einrichten
Schritt 1: KVM-Paravirtualisierung prüfen, Pakete aktualisieren & QEMU Guest Agent aktivieren
Prüfen Sie zunächst im Netcup Server Control Panel (SCP) unter Settings → General, dass als Storage-Treiber virtio-scsi (oder virtio) und als Netzwerkkarte virtio ausgewählt ist. Paravirtualisierte VirtIO-Treiber umgehen den Emulations-Overhead klassischer IDE/e1000-Hardware in QEMU und ermöglichen dem Linux 6.8+ Kernel von Ubuntu 24.04 LTS die direkte Kommunikation mit dem Host-Hypervisor über gemeinsame Ringpuffer (virtqueue). Auf Root-Servern mit mehreren dedizierten EPYC-Kernen weist virtio-scsi jedem virtuellen CPU-Kern eine eigene Multi-Queue (virtio-scsi-pci) zu, sodass parallele Datenbank-Lese- und Schreibzugriffe sich nicht gegenseitig in einem einzigen I/O-Thread blockieren. Verbinden Sie sich nach Abschluss der Image-Installation per SSH als root (oder mit Ihrem Cloud-Init-Benutzer), um das Basissystem zu aktualisieren und das Paket qemu-guest-agent zu installieren.
Warum ist der qemu-guest-agent auf Netcup zwingend erforderlich? Ohne diesen Dienst erfasst ein Online-Snapshot im SCP lediglich einen absturzkonsistenten Rohzustand der Festplatte, während sich noch ungeschriebene Dirty Pages im Linux-Page-Cache und offene Transaktionen im RAM von PostgreSQL oder MariaDB befinden. Läuft hingegen der qemu-guest-agent über den Charakter-Socket /dev/virtio-ports/org.qemu.guest_agent.0, weist das SCP den Gast-Kernel vor dem Snapshot an, alle Dateisystempuffer auf die NVMe-SSD zu schreiben (sync) und Einhängepunkte für den Bruchteil einer Sekunde einzufrieren (ioctl FIFREEZE) – das garantiert 100 % konsistente Live-Backups ohne korrupte Datenbank-Write-Ahead-Logs.
Darüber hinaus sollten Sie auf jedem KVM-Gastsystem den systemd-Timer fstrim.timer aktivieren. Wenn Sie innerhalb von Ubuntu 24.04 große Logdateien, alte Docker-Image-Layer oder Datenbank-Dumps löschen, markiert das ext4-Dateisystem die entsprechenden Inodes lediglich intern als frei, informiert aber standardmäßig nicht den darunterliegenden Ceph- oder NVMe-Storage-Controller des Hypervisors. Durch den wöchentlichen Versand von SCSI UNMAP / TRIM-Kommandos über den virtio-scsi-Bus kann das Storage-Backend gelöschte Blöcke sofort bereinigen (Garbage Collection), was Write Amplification verhindert und die IOPS-Latenz bei zufälligen Schreibzugriffen dauerhaft niedrig hält.
# Verbindung zur öffentlichen IPv4-Adresse Ihres Netcup-Servers herstellen
ssh [email protected]
# APT-Paketlisten aktualisieren und alle Kernel-/Sicherheitsupdates einspielen
export DEBIAN_FRONTEND=noninteractive
apt update && apt full-upgrade -y
# Wichtige Systemwerkzeuge sowie den QEMU Guest Agent installieren
apt install -y qemu-guest-agent chrony curl wget git ufw fail2ban htop iotop sysstat jq unattended-upgrades
# QEMU Guest Agent für die Kommunikation mit dem Netcup SCP aktivieren und prüfen
systemctl enable --now qemu-guest-agent
systemctl status qemu-guest-agent --no-pager
# Wöchentlichen SSD/NVMe TRIM-Discard-Timer aktivieren
systemctl enable --now fstrim.timer Befehlserklärung: Aktualisiert alle Ubuntu 24.04 LTS Pakete nicht-interaktiv, installiert wichtige Diagnosewerkzeuge sowie den qemu-guest-agent und aktiviert den fstrim.timer zur regelmäßigen Blockfreigabe auf dem Netcup-Storage-Array.
● qemu-guest-agent.service - QEMU Guest Agent
Loaded: loaded (/usr/lib/systemd/system/qemu-guest-agent.service; enabled)
Active: active (running) SICHERHEITSHINWEIS: Falls apt full-upgrade -y ein neues Linux-Kernel-Image installiert, wird die Datei /var/run/reboot-required angelegt. Führen Sie zuerst die Schritte 2 bis 4 vollständig aus und starten Sie den Server anschließend sauber mit sudo reboot neu.
Durch die Aktivierung von systemd fstrim.timer sendet Ubuntu jede Woche SCSI UNMAP / TRIM-Befehle über virtio-scsi. Dies verhindert Write Amplification und hält die zufälligen IOPS auf Netcup SSD- und NVMe-Volumes dauerhaft auf Höchstniveau.
Schritt 2: Unprivilegierten Admin-Benutzer anlegen & Chrony-Zeitsynchronisation konfigurieren
Tägliche Wartungsarbeiten, CI/CD-Deployments oder Container-Orchestrierung direkt als root (UID 0) auszuführen, birgt das Risiko katastrophaler Dateisystemfehler und setzt das höchste Systemkonto permanent automatisierten SSH-Brute-Force-Angriffen aus. Erstellen Sie stattdessen ein dediziertes Administratorkonto (deployadmin), weisen Sie es der Gruppe sudo zu und übertragen Sie Ihre autorisierten SSH-Public-Keys mit strikten POSIX-Berechtigungen (0700 für ~/.ssh und 0600 für authorized_keys). Die OpenSSH-Prüfung StrictModes yes verweigert die Schlüsselauthentifizierung sofort, falls Gruppen- oder Welt-Schreibrechte auf diesen Pfaden existieren.
Die Arbeit über sudo sorgt zudem für eine lückenlose Nachvollziehbarkeit im systemd-journald: Jeder privilegierte Befehl wird samt ausführender Benutzerkennung (SUDO_USER), Terminal-TTY, Arbeitsverzeichnis und vollständiger Befehlszeile protokolliert. Wenn mehrere Administratoren oder automatisierte Ansible-Playbooks auf denselben Netcup-Server zugreifen, lässt sich anhand von journalctl _COMM=sudo jederzeit sekundengenau nachvollziehen, wer welche Konfigurationsänderung vorgenommen hat.
Setzen Sie gleichzeitig einen sauberen FQDN-Hostnamen, stellen Sie die Zeitzone auf UTC und aktivieren Sie chrony, um die Systemuhr gegen die paravirtualisierte KVM-Hardwareuhr (/dev/ptp_kvm bzw. kvm-clock) und europäische NTP-Pools zu synchronisieren. Im Gegensatz zum einfachen systemd-timesyncd-Client gleicht chronyd Frequenzdrifts der virtuellen Uhr kontinuierlich über fein abgestufte adjtimex()-Kernel-Aufrufe aus, ohne Zeitsprünge zu verursachen. Eine präzise Systemzeit im Sub-Millisekundenbereich ist unverzichtbar für TLS-Zertifikatsprüfungen, TOTP-2FA-Codes, verteilte Datenbank-Transaktionszeitstempel und die Auswertung von Sicherheitslogs.
# 1. FQDN-Hostnamen und UTC-Zeitzone setzen
hostnamectl set-hostname prod-nc-01.example.com
timedatectl set-timezone UTC
systemctl enable --now chrony
chronyc tracking
# 2. Administratives Benutzerkonto anlegen und der Gruppe sudo hinzufügen
adduser --gecos "" deployadmin
usermod -aG sudo deployadmin
# 3. Vorhandene authorized_keys von root übernehmen (oder Ed25519-Key eintragen)
install -d -m 0700 -o deployadmin -g deployadmin /home/deployadmin/.ssh
if [ -f /root/.ssh/authorized_keys ]; then
install -m 0600 -o deployadmin -g deployadmin /root/.ssh/authorized_keys /home/deployadmin/.ssh/authorized_keys
else
cat << 'EOF' > /home/deployadmin/.ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleReplaceWithYourRealPublicKey admin@workstation
EOF
chown deployadmin:deployadmin /home/deployadmin/.ssh/authorized_keys
chmod 0600 /home/deployadmin/.ssh/authorized_keys
fi Befehlserklärung: Richtet die UTC-Zeitsynchronisation über chrony ein, legt das Konto deployadmin an und erzwingt die Berechtigungen 0700/0600 für /home/deployadmin/.ssh/authorized_keys.
Reference ID : C0A80101 (ntp1.netcup.net)
Stratum : 2
System time : 0.000041231 seconds fast of NTP time SICHERHEITSHINWEIS: Bevor Sie Ihre aktuelle root-Sitzung beenden, öffnen Sie unbedingt ein zweites Terminalfenster auf Ihrer Workstation und testen Sie ssh [email protected] gefolgt von sudo whoami, um sicherzustellen, dass der administrative Zugriff reibungslos funktioniert.
Schritt 3: NVMe-Swap-Speicher bereitstellen & Kernel-Netzwerk-/VM-Parameter (sysctl) optimieren
Standard-Cloud-Images auf Netcup werden häufig ohne oder nur mit einer minimalen Swap-Partition ausgeliefert. Selbst auf einem Server mit 8 GB ECC-RAM wie dem VPS 1000 G12.5 oder dem RS 1000 G12.5 führt das vollständige Fehlen von Swap dazu, dass der Linux-Kernel ungenutzte anonyme Speicherseiten (Anonymous Pages, z. B. selten genutzte Worker-Heaps) nicht aus dem RAM auslagern kann. Kommt es während eines mehrstufigen Docker-Image-Builds, einer apt-Paketdekomprimierung oder eines pg_dump-Backups zu einer kurzzeitigen Arbeitsspitze, ruft der Kernel sofort den Out-Of-Memory-Killer (oom-killer) auf den Plan, der den Prozess mit dem höchsten oom_score – meist MariaDB, PostgreSQL oder Java/Node.js – hart per SIGKILL beendet.
Durch das Anlegen einer 4 GB großen /swapfile auf dem schnellen NVMe-Storage in Kombination mit vm.swappiness = 10 und vm.vfs_cache_pressure = 50 schaffen Sie einen wichtigen Sicherheitspuffer, ohne die Datenbank-Performance zu schmälern. Mit vm.swappiness = 10 weist der Kernel den Memory-Scheduler an, Anwendungsprozesse so lange wie möglich im physischen DDR4/DDR5-ECC-RAM zu halten und erst bei echtem Speicherdruck inaktive Speicherseiten auszulagern. Gleichzeitig sorgt vm.vfs_cache_pressure = 50 dafür, dass Verzeichnis- und Datei-Metadaten (dentries und inodes) länger im Kernel-Cache verbleiben, was Dateisystem-Lookups bei Webservern und Git-Repositories spürbar beschleunigt.
Auf Netzwerkebene verwendet Ubuntu 24.04 standardmäßig den verlustbasierten Algorithmus cubic. Während cubic sein Sendefenster (cwnd) bereits bei einem einzelnen verworfenen Paket an einem Internet-Peering-Knoten drastisch drosselt, misst Google TCP BBR (net.ipv4.tcp_congestion_control = bbr gepaart mit net.core.default_qdisc = fq) kontinuierlich die tatsächliche Engpass-Bandbreite und minimale Umlaufzeit (RTT). Auf den 1 Gbit/s- und 2,5 Gbit/s-virtio-net-Ports von Netcup verbessert BBR den HTTPS- und API-Durchsatz zu mobilen Clients und interkontinentalen Besuchern erheblich. Zusätzlich deaktivieren wir net.ipv4.tcp_slow_start_after_idle = 0, damit persistente Upstream- und Keepalive-Verbindungen nach kurzen Sendepausen nicht wieder im langsamen Slow-Start-Modus beginnen.
| Netcup Server-Modell | CPU- & RAM-Ausstattung | Empfohlene Swapfile-Größe | VM-Cache & Dirty-Page-Ratio | Ziel-vm.swappiness & Netzwerk-Profil |
|---|---|---|---|---|
| VPS pico G11.5s / VPS nano G11.5s | 1–2 vCPU / 1 GB – 2 GB ECC-RAM | 2 GB Swapfile | vfs_cache_pressure = 50, dirty_ratio = 10 | vm.swappiness = 20, BBR + 4096 somaxconn |
| VPS 500 G12.5 | 4 vCPU / 4 GB ECC-RAM | 4 GB Swapfile | vfs_cache_pressure = 50, dirty_ratio = 15 | vm.swappiness = 10, BBR + 8192 somaxconn |
| VPS 1000 G12.5 | 6 vCPU / 8 GB ECC-RAM | 4 GB Swapfile | vfs_cache_pressure = 50, dirty_ratio = 15 | vm.swappiness = 10, BBR + 8192 somaxconn |
| RS 1000 G12.5 | 4 Dedizierte EPYC Zen 5 Kerne / 8 GB DDR5 ECC | 4 GB – 8 GB Swapfile | vfs_cache_pressure = 50, dirty_ratio = 15 | vm.swappiness = 10, BBR + 2.5G fq Pacing |
# 1. Eine 4 GB große Swap-Datei erstellen und aktivieren, falls noch kein Swap aktiv ist
if [ "$(swapon --show | wc -l)" -eq 0 ]; then
sudo fallocate -l 4G /swapfile
sudo chmod 0600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
fi
# 2. VM- und TCP-BBR-Netzwerktuning für Netcup 1G / 2.5G virtio-net-Ports anwenden
cat << 'EOF' | sudo tee /etc/sysctl.d/99-netcup-tuning.conf
# Virtueller Speicher & Dateisystem-Cache-Tuning
vm.swappiness = 10
vm.vfs_cache_pressure = 50
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
# Netzwerk-Warteschlangen & Google TCP BBR Congestion Control
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.somaxconn = 8192
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_slow_start_after_idle = 0
EOF
sudo sysctl --system
free -h && sysctl net.ipv4.tcp_congestion_control Befehlserklärung: Erstellt eine persistente 4 GB /swapfile (chmod 0600), konfiguriert zurückhaltendes Swapping (vm.swappiness = 10), deaktiviert TCP Slow-Start nach Leerlaufphasen und aktiviert das bbr Packet-Pacing.
total used free shared buff/cache available
Mem: 7.8Gi 412Mi 6.9Gi 8.0Mi 640Mi 7.2Gi
Swap: 4.0Gi 0B 4.0Gi
net.ipv4.tcp_congestion_control = bbr Schritt 4: OpenSSH absichern, UFW-Firewall aktivieren & Unattended Upgrades einrichten
Beachten Sie eine wichtige Besonderheit unter Ubuntu 24.04 LTS: OpenSSH nutzt das Drop-in-Verzeichnis /etc/ssh/sshd_config.d/, in dem Cloud-Init standardmäßig die Datei /etc/ssh/sshd_config.d/50-cloud-init.conf mit PasswordAuthentication yes anlegt. Da der OpenSSH-Parser nach dem Prinzip „First-Match Wins“ arbeitet und die Anweisung Include /etc/ssh/sshd_config.d/*.conf ganz oben in der /etc/ssh/sshd_config steht, werden Einstellungen am Ende der Hauptdatei ignoriert, solange ein früher geladenes Drop-in denselben Parameter bereits gesetzt hat. Entfernen Sie daher 50-cloud-init.conf, hinterlegen Sie Ihre Härtungsregeln in /etc/ssh/sshd_config.d/99-netcup-hardening.conf und prüfen Sie die effektiv wirksame Konfiguration immer mit sudo sshd -T.
Auch bei der Prozessarchitektur hat sich Ubuntu 24.04 geändert: Der SSH-Daemon wird über systemd Socket-Aktivierung (ssh.socket) verwaltet. Für Änderungen an der Authentifizierung (PasswordAuthentication no, PermitRootLogin no) genügt ein sudo systemctl reload ssh; möchten Sie hingegen den TCP-Lauschport von 22 auf einen benutzerdefinierten Port verlegen, muss dies über ein systemd-Drop-in für ssh.socket erfolgen. Nach der Beschränkung von SSH auf reine Public-Key-Authentifizierung aktivieren wir die Dual-Stack-Firewall ufw (sodass eingehend ausschließlich die Ports 22/tcp, 80/tcp, 443/tcp und 443/udp für HTTP/3 QUIC geöffnet sind).
Den Abschluss des Basis-Runbooks bildet das automatische Einspielen sicherheitskritischer Updates über unattended-upgrades. Wenn das Ubuntu-Sicherheitsteam einen Patch für openssl, glibc, curl oder den Linux-Kernel veröffentlicht, lädt der tägliche apt-daily-upgrade.timer die aktualisierten Pakete automatisch herunter und installiert sie im Hintergrund, ohne dass Ihre benutzerdefinierten Konfigurationsdateien (--force-confdef --force-confold) überschrieben werden.
# 1. Reinen SSH-Key-Login erzwingen und direkten Root-SSH-Zugriff abschalten
sudo rm -f /etc/ssh/sshd_config.d/50-cloud-init.conf
cat << 'EOF' | sudo tee /etc/ssh/sshd_config.d/99-netcup-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
X11Forwarding no
EOF
# SSH-Konfigurationssyntax vor dem Neuladen validieren
sudo sshd -t && sudo systemctl reload ssh
# 2. Dual-Stack-Firewall UFW konfigurieren
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'OpenSSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw allow 443/udp comment 'HTTP/3 QUIC'
sudo ufw --force enable
sudo ufw status verbose
# 3. Tägliche automatische CVE-Sicherheitsupdates aktivieren
sudo dpkg-reconfigure -f noninteractive unattended-upgrades Befehlserklärung: Entfernt den Cloud-Init-Passwort-Override, deaktiviert Root- und Passwort-Logins per Drop-in-Datei, öffnet nur die Ports 22, 80 und 443 (TCP/UDP) in UFW und aktiviert unattended-upgrades.
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed) Häufige Fehlerbehebung
DIAGNOSE-GUIDE [SYMPTOM] Passwort-Authentifizierung funktioniert trotz Anpassung der /etc/ssh/sshd_config weiterhin
Ursache: Unter Ubuntu 24.04 LTS bindet /etc/ssh/sshd_config gleich zu Beginn /etc/ssh/sshd_config.d/*.conf ein, wobei der erste Treffer gewinnt. Steht in 50-cloud-init.conf noch PasswordAuthentication yes, werden Zeilen am Ende der sshd_config ignoriert.
Lösung: Löschen Sie /etc/ssh/sshd_config.d/50-cloud-init.conf und prüfen Sie die effektiv wirksame Laufzeitkonfiguration mit sudo sshd -T | grep -E "passwordauthentication|permitrootlogin".
[SYMPTOM] SCP-Snapshot-Erstellung meldet einen Fehler oder Timeout beim Einfrieren des Dateisystems (fsfreeze)
Ursache: Entweder ist qemu-guest-agent in Ubuntu nicht installiert/aktiv, oder der VirtIO-Serial-Channel wurde in den SCP-Einstellungen deaktiviert.
Lösung: Prüfen Sie den Dienst mit sudo systemctl status qemu-guest-agent in der VM und vergewissern Sie sich, dass /dev/virtio-ports/org.qemu.guest_agent.0 existiert.
[SYMPTOM] Ausgesperrt aus SSH nach dem Aktivieren von UFW oder Bearbeiten der sshd_config
Ursache: Port 22 (oder Ihr benutzerdefinierter SSH-Port) wurde in UFW vergessen, oder authorized_keys hat falsche Dateirechte (0644 statt 0600).
Lösung: Öffnen Sie das Netcup Server Control Panel (SCP) → Screen (HTML5-VNC-Konsole), melden Sie sich lokal am TTY-Prompt an, korrigieren Sie die Berechtigungen von /home/deployadmin/.ssh/authorized_keys bzw. führen Sie sudo ufw allow 22/tcp aus und laden Sie SSH neu.
Häufig gestellte Fragen (FAQ)
GEPRÜFTE ANTWORTENSollte ich im Netcup SCP das minimale Ubuntu-Image oder das Cloud-Init-Ubuntu-Image wählen?
Beide Images installieren offizielle Ubuntu 24.04 LTS Pakete. Wählen Sie das Cloud-Init-Image, wenn Sie beim ersten Booten vollautomatisches YAML-Bootstrapping und SSH-Key-Injektion wünschen; wählen Sie das Standard-Minimal-Image für eine klassische interaktive Einrichtung.
Muss ich unter Ubuntu 24.04 spezielle VirtIO-Treiber für Netcup nachinstallieren?
Nein. Der mit Ubuntu 24.04 LTS ausgelieferte Linux 6.8+ Kernel enthält die Module virtio_scsi, virtio_blk, virtio_net und virtio_balloon bereits ab Werk.
Wie viel Speicherplatz belegen System-Logs im Laufe der Zeit auf einer Netcup SSD/NVMe?
Standardmäßig kann systemd-journald bis zu 4 GB anwachsen. Sie können das Journal mit sudo mkdir -p /etc/systemd/journald.conf.d && printf "[Journal]\nSystemMaxUse=500M\n" | sudo tee /etc/systemd/journald.conf.d/size.conf && sudo systemctl restart systemd-journald dauerhaft auf 500 MB begrenzen.
Sollte ich zusätzlich zu UFW auch die Netcup SCP Firewall aktivieren?
Ja, unbedingt! Die zustandsbehaftete SCP-Firewall verwirft unerwünschten Scan-Traffic bereits am Hypervisor-Switch, bevor er Ihren Gast-Kernel erreicht – und schützt Sie zuverlässig davor, dass Docker-Container lokale UFW-Regeln umgehen.
Welcher Netcup VPS- oder Root-Server-Tarif eignet sich am besten für produktive Ubuntu 24.04 Workloads?
Für schlanke Reverse-Proxies, VPN-Gateways oder kleinere Dienste eignen sich der VPS nano G11.5s (2 vCPU, 2 GB ECC-RAM) oder der VPS 500 G12.5 (4 vCPU, 4 GB ECC-RAM). Für Multi-Container-Docker-Stacks, relationale Datenbanken und CI/CD-Runner empfehlen wir den VPS 1000 G12.5 (6 vCPU, 8 GB ECC-RAM) oder den RS 1000 G12.5 mit 4 dedizierten AMD EPYC Zen 5 Kernen und 8 GB DDR5 ECC-RAM.
QUELLEN // GEPRÜFTE TECHNISCHE DOKUMENTATION
- [1] Ubuntu 24.04 LTS Server Administration Documentation (https://ubuntu.com/server/docs)
- [2] Netcup Helpcenter — Server Control Panel (SCP) & Images (https://helpcenter.netcup.com/)