# Arch for Servers: Das Hochleistungs-Minimal-OS

TL;DR / Management Summary Wer Arch Linux auf einem Server einsetzt, sucht maximale Performance und Kontrolle. Ein Headless-Setup verzichtet auf jeglichen Grafik-Overhead (X11/Wayland) und beschränkt sich auf die reinen Applikations-Dienste. Das Ergebnis ist ein Server, der im Leerlauf weniger als 100MB RAM verbraucht und blitzschnell auf Anfragen reagiert. Wichtig: In dieser Umgebung ist der Admin für das Patch-Management und die Security-Audits allein verantwortlich.

# 1. Einführung & Architektur

Warum Arch im Rechenzentrum?

Arch auf Servern ist kein Standard, aber in spezifischen Nischen (z.B. High-Frequency Trading, spezialisierte Router oder Build-Nodes) unschlagbar.

# Die Server-Struktur (Mermaid)

graph TD
    A[Arch Core] --> B[systemd: Init & Services]
    A --> C[SSH: Remote Access Only]
    A --> D[App: Docker / Nginx / DB]
    subgraph "No GUI Layer"
        E[No X11]
        F[No Wayland]
        G[No Desktop Services]
    end
    B --- E
    B --- F
    B --- G

# 2. Das Headless-Setup

Vom pacstrap zum Server.

Nutzen Sie bei der Installation (Artikel 182) nur die absolut notwendigen Pakete.

# Paketauswahl

# Kein 'linux-firmware' wenn in VM (spart Platz)
pacstrap /mnt base linux openssh sudo htop

# SSH-Zugriff sichern

Ohne Monitor ist SSH Ihre einzige Lebensader.

systemctl enable sshd
# Härtung (siehe Artikel 027)
# PasswordAuthentication no
# PermitRootLogin no

# 3. Optimierung für den Dauerbetrieb

Stabilität im Rolling Release.

# LTS-Kernel nutzen

In der Produktion ist der “Bleeding Edge” Kernel oft zu riskant. Nutzen Sie den Long-Term-Support (LTS) Kernel.

sudo pacman -S linux-lts linux-lts-headers
# GRUB aktualisieren
sudo grub-mkconfig -o /boot/grub/grub.cfg

# Microcode-Updates

Vergessen Sie nicht die CPU-Security-Fixes:

# Intel
sudo pacman -S intel-ucode
# AMD
sudo pacman -S amd-ucode

# 4. Day-2 Operations: Remote Monitoring

Das System im Blick behalten.

# Resource-Checks via CLI

Nutzen Sie glances oder btop für eine schnelle Übersicht auf der Konsole.

sudo pacman -S glances
glances

# Logs analysieren

Da Sie keine GUI haben, ist journalctl Ihr bester Freund (siehe Artikel 008).

# 5. Troubleshooting & “War Stories”

Wenn der Remote-Server schweigt.

# Story 1: “Der hängende Boot nach Kernel-Panic”

Symptom: Der Server kommt nach einem pacman -Syu nicht mehr hoch. SSH ist tot. Ursache: Ein inkompatibles Kernel-Modul oder ein Fehler im Initramfs. Lösung: Nutzen Sie die Proxmox-Konsole oder IPMI. Falls das System im Grub-Rescue landet, booten Sie das LTS-Kernel (Fallback).

# Story 2: “Das volle Log-Loch”

Symptom: Der Server reagiert träge, df zeigt 100% Belegung in /var/. Ursache: Das systemd-Journal ist nicht limitiert und speichert Millionen von unwichtigen Meldungen. Lösung: Limitieren Sie das Journal in /etc/systemd/journald.conf: SystemMaxUse=500M. Führen Sie journalctl --vacuum-size=500M aus.

# 6. Fazit & Empfehlung

• Wahl: Nutzen Sie Arch auf Servern nur, wenn Sie die neuesten Software-Versionen (z.B. Kernel-Features für NVMe oder eBPF) zwingend benötigen.
• Stabilität: Nutzen Sie immer den linux-lts Kernel für Server-Workloads.
• Backup: Snapshots vor jedem Update sind bei Arch Servern Pflicht!

# Anhang: Cheatsheet