Debian vs. Ubuntu – Server Setup: RAID1, LVM, iptables

Kontext und Philosophie

Beide Distributionen teilen dieselbe Basis (dpkg, apt, systemd), unterscheiden sich aber in Standardkonfigurationen, Release-Zyklen und Tooling erheblich – besonders relevant im Rechenzentrum.

Installer-Unterschiede

Debian Netinstall (d-i)

Vorteile:
+ Minimaler Footprint von Anfang an
+ RAID1 + LVM direkt im Installer konfigurierbar
+ Keine versteckten Dienste nach Installation
+ Volle Kontrolle über Paketauswahl
+ Funktioniert stabil über IPMI/Serial-Konsole

Nachteile:
- Text-Interface (gewöhnungsbedürftig)
- Mehr manuelle Schritte
- Netzwerkkonfiguration muss vorab bekannt sein

Ubuntu 24 LTS Subiquity

Vorteile:
+ Modernes UI
+ Automatische LVM-Einrichtung möglich
+ cloud-init Integration

Nachteile:
- IPMI: Installationsmedium kann bei Session-Übergabe verloren gehen
  → Bootreihenfolge kritisch: Install-Medium muss ERSTE Boot-Option bleiben
  → Nach Konfigurationsschritten prüfen ob Medium noch aktiv
- Snap wird für core-Pakete (z.B. lxd) aufgezwungen
- Nach Install: snap-Pakete manuell entfernen für kleinen Footprint
- Netplan statt /etc/network/interfaces

⚠️ IPMI-Erkenntnis: Beim Ubuntu Subiquity Installer über IPMI kann das Installationsmedium nach Netzwerk-/Konfigurationsschritten als Boot-Device verloren gehen. Vor jedem Reboot im Installer die Bootreihenfolge im BIOS/IPMI prüfen!

RAID1 Setup – Debian vs. Ubuntu

Gemeinsamkeiten

Beide nutzen mdadm – die Befehle sind identisch. Der Unterschied liegt im Installer-Workflow und der Post-Install-Konfiguration.

# Identisch auf beiden Systemen
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
update-initramfs -u

Doppeltes /boot/EFI – RAID1 auf UEFI-Systemen

Auf UEFI-Systemen kann die EFI-Partition nicht direkt Teil eines mdadm-RAID1 sein (FAT32-Einschränkung). Die Lösung: zwei separate EFI-Partitionen, die synchron gehalten werden.

Disk Layout (beide Disks identisch):
/dev/sda1  →  EFI  (512 MB, FAT32)   ← EFI Partition 1
/dev/sda2  →  /boot/efi Mirror A
/dev/sda3  →  PV für RAID1 → md0

/dev/sdb1  →  EFI  (512 MB, FAT32)   ← EFI Partition 2 (Backup)
/dev/sdb2  →  /boot/efi Mirror B
/dev/sdb3  →  PV für RAID1 → md0

EFI-Sync zwischen beiden Disks einrichten

# /boot/efi ist auf /dev/sda1 gemountet (primär)
# /dev/sdb1 ist die Backup-EFI

# Backup-EFI einmalig synchronisieren
dd if=/dev/sda1 of=/dev/sdb1

# Oder mit rsync nach Updates
mkdir -p /boot/efi2
mount /dev/sdb1 /boot/efi2
rsync -av /boot/efi/ /boot/efi2/
umount /boot/efi2

# Automatischer Sync nach Kernel-Update (Debian/Ubuntu)
# /etc/apt/apt.conf.d/99-efi-sync
DPkg::Post-Invoke {"rsync -av /boot/efi/ /boot/efi2/ 2>/dev/null || true";};

GRUB auf beide EFI-Partitionen installieren

# Primäre EFI (sda)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian /dev/sda

# Backup EFI (sdb) – gleiche Konfiguration
grub-install --target=x86_64-efi --efi-directory=/boot/efi2 --bootloader-id=debian /dev/sdb

# GRUB-Konfiguration neu generieren
update-grub

Unterschied: mdadm.conf Pfad

# Debian UND Ubuntu: identisch!
/etc/mdadm/mdadm.conf

# Nach Änderungen immer:
update-initramfs -u

✅ Hier sind Debian und Ubuntu identisch – beide nutzen /etc/mdadm/mdadm.conf

LVM Setup – Debian vs. Ubuntu

LVM im Installer

Typisches RZ-Layout: einzelne LVs pro Verzeichnis

# VG auf RAID1-Device erstellen
pvcreate /dev/md0
vgcreate vg0 /dev/md0

# Einzelne LVs für kritische Verzeichnisse
lvcreate -L 10G  -n lv_root    vg0   # /
lvcreate -L 2G   -n lv_tmp     vg0   # /tmp
lvcreate -L 10G  -n lv_var     vg0   # /var
lvcreate -L 5G   -n lv_var_log vg0   # /var/log
lvcreate -L 2G   -n lv_var_tmp vg0   # /var/tmp
lvcreate -L 5G   -n lv_home    vg0   # /home
lvcreate -L 4G   -n lv_swap    vg0   # swap
lvcreate -l 100%FREE -n lv_data vg0  # /data (Rest)

Warum einzelne LVs pro Verzeichnis?
- /tmp und /var/tmp voll → kein Root-Fullness
- /var/log voll → keine Systemauswirkung
- Snapshots gezielt pro Volume möglich
- Sicherheitsoptionen pro Mount (noexec, nosuid)

/etc/fstab mit Sicherheitsoptionen

# /etc/fstab – RZ-Härtung
/dev/vg0/lv_root     /         ext4  defaults,errors=remount-ro  0 1
/dev/vg0/lv_tmp      /tmp      ext4  defaults,noexec,nosuid,nodev 0 2
/dev/vg0/lv_var      /var      ext4  defaults                    0 2
/dev/vg0/lv_var_log  /var/log  ext4  defaults,noexec,nosuid,nodev 0 2
/dev/vg0/lv_var_tmp  /var/tmp  ext4  defaults,noexec,nosuid,nodev 0 2
/dev/vg0/lv_home     /home     ext4  defaults,noexec,nosuid,nodev 0 2
/dev/vg0/lv_swap     none      swap  sw                          0 0

Unterschied: Ubuntu 24 LTS Default-LVM

# Ubuntu legt bei automatischer LVM-Installation an:
ubuntu-vg/ubuntu-lv   → /    (oft nur 50% des verfügbaren Platzes!)

# Häufiges Problem: Nur 50% genutzt
lvdisplay ubuntu-vg/ubuntu-lv
# → "Current LE: 12800" obwohl doppelt verfügbar

# Lösung: Rest zuweisen
lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

⚠️ Ubuntu's Installer lässt standardmäßig ~50% des LVM-Platzes ungenutzt!
Debian's d-i nutzt in der Regel den gesamten verfügbaren Platz.

Netzwerkkonfiguration

Debian – /etc/network/interfaces

# /etc/network/interfaces
auto lo
iface lo inet loopback

# Primäres Interface
auto enp1s0
iface enp1s0 inet static
    address 10.0.1.10
    netmask 255.255.255.0
    gateway 10.0.1.1

# IPMI/Management Interface (separates /19 Netz)
auto enp2s0
iface enp2s0 inet static
    address 10.0.0.10
    netmask 255.255.224.0
    gateway 10.0.0.1

# DNS
dns-nameservers 10.0.0.53 10.0.0.54
dns-search example.com

# Netzwerk neu starten
systemctl restart networking

# Interface neu starten
ifdown enp1s0 && ifup enp1s0

Ubuntu – Netplan (/etc/netplan/)

# /etc/netplan/00-installer-config.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      addresses:
        - 10.0.1.10/24
      routes:
        - to: default
          via: 10.0.1.1
      nameservers:
        addresses: [10.0.0.53, 10.0.0.54]
        search: [example.com]
    enp2s0:
      addresses:
        - 10.0.0.10/19
      nameservers:
        addresses: [10.0.0.53]

# Netplan anwenden (trocken testen!)
netplan try              # 120s Timeout – bei Fehler automatisch zurück
netplan apply            # Permanent anwenden

# Netplan debuggen
netplan --debug apply

⚠️ netplan try ist dein bester Freund im RZ – gibt 120 Sekunden zum Bestätigen,
sonst automatischer Rollback. Immer netplan try vor netplan apply!

Debian zu Ubuntu Netplan migrieren (oder umgekehrt)

# Ubuntu: auf /etc/network/interfaces wechseln (optional)
apt install ifupdown
# Netplan deaktivieren:
echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
# Dann /etc/network/interfaces manuell erstellen

iptables – Debian vs. Ubuntu

Default-Zustand nach Installation

✅ Beide starten mit offenem Regelwerk – Unterschied ist nur ufw auf Ubuntu

iptables vs. nftables – Empfehlung

iptables:  Legacy, aber überall bekannt, stabil, gut dokumentiert
nftables:  Moderner Nachfolger, seit Debian 10 / Ubuntu 20 Standard-Backend
ip6tables: Separates Tool für IPv6 (bei iptables)
nft:       Unified (IPv4 + IPv6 in einer Syntax)

Empfehlung RZ:
→ iptables-nft (nftables Backend, iptables Syntax) – beste Kompatibilität
→ KEIN ufw parallel zu iptables – führt zu Konflikten!

# Prüfen welches Backend aktiv ist
iptables --version
# iptables v1.8.x (nf_tables)  ← nftables Backend
# iptables v1.8.x (legacy)     ← legacy iptables

# Auf nftables-Backend wechseln (Debian)
update-alternatives --set iptables /usr/sbin/iptables-nft
update-alternatives --set ip6tables /usr/sbin/ip6tables-nft

Basis-Regelwerk für RZ-Server

#!/bin/bash
# /etc/iptables/rules.sh – RZ Basis-Härtung

IPT="iptables"

# Alle Chains leeren
$IPT -F
$IPT -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X

# Default-Policy: alles verwerfen
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT

# Loopback erlauben
$IPT -A INPUT -i lo -j ACCEPT

# Established/Related Verbindungen erlauben
$IPT -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# ICMP (ping) erlauben
$IPT -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# SSH – nur aus Management-Netz
$IPT -A INPUT -p tcp --dport 22 -s 10.0.0.0/19 -j ACCEPT

# IPMI-Interface: Management-Netz komplett erlauben
$IPT -A INPUT -i enp2s0 -s 10.0.0.0/19 -j ACCEPT

# Monitoring (z.B. NRPE/Icinga)
$IPT -A INPUT -p tcp --dport 5666 -s 10.0.0.0/19 -j ACCEPT

# Alles andere loggen und verwerfen
$IPT -A INPUT -j LOG --log-prefix "iptables-DROP: " --log-level 4
$IPT -A INPUT -j DROP

echo "Firewall-Regeln geladen."

Regeln persistent machen

# Debian UND Ubuntu – identisch:
apt install iptables-persistent

# Regeln speichern
netfilter-persistent save
# oder
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6

# Automatisch beim Boot laden
systemctl enable netfilter-persistent

ufw auf Ubuntu deaktivieren (empfohlen bei manuellem iptables)

# ufw komplett deaktivieren
ufw disable
systemctl disable ufw
systemctl mask ufw

# Prüfen ob ufw noch Regeln hat
ufw status verbose
iptables -L | grep ufw     # Sollte leer sein

⚠️ ufw und manuelles iptables gleichzeitig führt zu unerwartetem Regelwerk!
Entscheidung treffen: eines von beiden, nicht beides.

Snap entfernen (Ubuntu RZ-Härtung)

# Installierte Snaps anzeigen
snap list

# Snaps entfernen (Reihenfolge beachten!)
snap remove --purge lxd
snap remove --purge core22
snap remove --purge snapd

# snapd deinstallieren
apt purge snapd
apt-mark hold snapd            # Verhindert Neuinstallation durch apt

# Snap-Verzeichnisse bereinigen
rm -rf /snap /var/snap /var/lib/snapd /var/cache/snapd ~/snap

# Snap-Mount-Points aus /etc/fstab entfernen (falls vorhanden)
# Zeilen mit "squashfs" und "/snap" prüfen
cat /etc/fstab | grep snap

✅ Debian hat dieses Problem nicht – kein Snap im Netinstall

AppArmor – Debian vs. Ubuntu

# AppArmor Status prüfen
aa-status
apparmor_status

# Profil in Beschwerdemodus setzen (nicht blockieren, nur loggen)
aa-complain /etc/apparmor.d/usr.sbin.sshd

# Profil deaktivieren
aa-disable /etc/apparmor.d/usr.sbin.nginx

# Ubuntu: AppArmor komplett deaktivieren (nur wenn bewusste Entscheidung!)
systemctl disable apparmor
# GRUB: apparmor=0 in GRUB_CMDLINE_LINUX

Post-Install Checkliste: Debian vs. Ubuntu

Debian Netinstall – Post-Install

# 1. System aktualisieren
apt update && apt full-upgrade

# 2. Basis-Tools installieren
apt install vim tmux htop net-tools curl wget git \
            sudo openssh-server fail2ban \
            mdadm lvm2 iptables-persistent \
            rsync tree ncdu

# 3. sudo für Admin-User konfigurieren
usermod -aG sudo adminuser

# 4. SSH härten (siehe SSH-Knowlegde Base)
vim /etc/ssh/sshd_config

# 5. iptables Regelwerk laden
bash /etc/iptables/rules.sh
netfilter-persistent save

# 6. mdadm monitoring aktivieren
systemctl enable mdmonitor

# 7. RAID-Status prüfen
cat /proc/mdstat
mdadm --detail /dev/md0

Ubuntu 24 LTS – Post-Install (Zusatzschritte)

# Zusätzlich zu Debian-Schritten:

# 1. Snap entfernen
snap remove --purge lxd core22 snapd
apt purge snapd
apt-mark hold snapd

# 2. ufw deaktivieren (wenn eigenes iptables)
ufw disable
systemctl mask ufw

# 3. cloud-init deaktivieren (wenn kein Cloud-Einsatz)
systemctl disable cloud-init cloud-init-local cloud-config cloud-final
touch /etc/cloud/cloud-init.disabled

# 4. Netplan prüfen und anpassen
netplan try    # IMMER try vor apply!
netplan apply

# 5. Ubuntu Pro / ESM prüfen
pro status
# Falls nicht benötigt: ubuntu-advantage-tools kann bleiben, kostet nichts

# 6. LVM-Platz prüfen (Ubuntu lässt oft 50% frei!)
vgs
lvdisplay ubuntu-vg/ubuntu-lv
# Falls nicht voll: lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

# 7. motd-news deaktivieren (vermindert Login-Delay)
systemctl disable motd-news.timer
chmod -x /etc/update-motd.d/10-help-text
chmod -x /etc/update-motd.d/50-motd-news

Warum Debian für das RZ?

Ubuntu 22.04 LTS:  Support bis April 2027 (gratis)
Ubuntu 24.04 LTS:  Support bis April 2029 (gratis)
                   + 5 Jahre mit Ubuntu Pro (kostenpflichtig!)
                   → Für langjährige RZ-Server problematisch

Debian 12 (Bookworm): Support bis ~2028 (LTS)
                       Kein kostenpflichtiges Extended Support Modell
                       Klare, freie Lifecycle-Politik

AppArmor CVE Beispiel:
→ Ubuntu patcht schnell (gut) aber erzwingt Pro für Langzeit-Support (schlecht für RZ)
→ Debian patcht im stable Backports-Modell, voller Support ohne Kosten

Fazit für RZ:
✅ Debian: Vorhersehbarer Lifecycle, kein Vendor Lock-in, minimaler Footprint
⚠️ Ubuntu: Schnellere Updates, aber kommerzielle Support-Abhängigkeit bei langen Laufzeiten

Wichtige Dateien und Pfade – Vergleich

Quellen / Weiterführend

• Debian Installer Handbuch: https://www.debian.org/releases/stable/amd64/
• Ubuntu Server Guide: https://ubuntu.com/server/docs
• man interfaces (Debian Netzwerk)
• man netplan (Ubuntu Netzwerk)
• man iptables, man nft
• Debian Wiki: Software RAID
• Debian Wiki: LVM