# Die SUSE Familie: Das Chamäleon im Enterprise-Einsatz

TL;DR / Management Summary SUSE ist die europäische Antwort auf Red Hat. Die Produktpalette ist klar getrennt: SLES (SUSE Linux Enterprise Server) bietet Stabilität und zertifizierten Support. openSUSE Leap ist der 1:1 Community-Ableger (identische Binärbasis zu SLES), ideal für Non-Critical Server. openSUSE Tumbleweed ist das technologische Testfeld als Rolling Release. Empfehlung: SLES für SAP und Kern-Infrastruktur; Leap für Web-Frontends und interne Tools.

# 1. Einführung & Architektur

Die Basis-Philosophie.

SUSE nutzt wie Red Hat das RPM-Paketformat, unterscheidet sich aber massiv in der Konfigurations-Logik (YaST) und dem Paketmanagement (Zypper).

# Das Ökosystem (Mermaid)

graph TD
    A[openSUSE Tumbleweed: Rolling Release] -->|Snapshot / Stabilisierung| B[openSUSE Leap: Stable Community]
    B <-->|Binary 1:1 Match| C[SLES: Certified Enterprise]
    C --> D[SLES for SAP Applications]
    C --> E[SUSE Manager]
    
    subgraph "Production Ready"
        B
        C
    end

# 2. Die Versionen im Detail

Wann setze ich was ein?

# SLES (SUSE Linux Enterprise Server)

• Vorteil: Zertifiziert für SAP (Marktführer!), Oracle und komplexe Storage-Hardware.
• Support: Bis zu 13 Jahre Lifecycle (Long Term Service Pack Support).
• Einsatz: Mission-Critical Workloads im europäischen Enterprise-Markt.

# openSUSE Leap

• Vorteil: Nutzt die gleichen Binärpakete wie SLES. Ein Wechsel von Leap zu SLES ist ohne Neuinstallation möglich.
• Einsatz: Die erste Wahl für Admins, die SLES-Stabilität ohne Lizenzkosten für weniger kritische Systeme suchen.

# openSUSE Tumbleweed

• Vorteil: Immer aktuell (Kernel, Compiler, Tools).
• Risiko: Als Rolling Release für Server-Produktion zu instabil.
• Einsatz: Workstations für Software-Entwickler.

# 3. Besonderheit: Das Service-Pack Modell

Kein Major-Upgrade nötig.

Im Gegensatz zu RHEL oder Ubuntu gibt es bei SLES seltener neue Major-Versionen (z.B. SLES 15). Stattdessen kommen jährliche Service Packs (SP).

• Beispiel: SLES 15 SP1 -> SP2 -> SP3. Der Übergang ist nahtlos und wird wie ein normales Update behandelt.

# 4. Day-2 Operations: Der Wechsel (Leap to SLES)

Flexibilität bei steigenden Anforderungen.

Wenn ein Projekt auf Leap startet und später Enterprise-Support braucht:

# SUSE Connect Tool nutzen
sudo dnf install suse-connect-migration
# Das System erkennt die SLES-Basis und konvertiert die Repositories

# 5. Troubleshooting & “War Stories”

Praxisfallen.

# Story 1: “Der Version-Confusion”

Symptom: Ein Admin sucht Pakete für SLES 15 SP5, nutzt aber Repositories von openSUSE Tumbleweed. Ursache: Tumbleweed ist Rolling Release, SLES ist Fixed. Die Libraries passen nicht zusammen. Lösung: Nutzen Sie immer das offizielle SCC (SUSE Customer Center) oder den SUSE Manager, um Repository-Mischmasch zu verhindern.

# Story 2: “Das SAP-Zertifizierungs-Problem”

Symptom: Ein SAP-System auf einem Standard-SLES zeigt mysteriöse I/O-Hänger. Ursache: SLES for SAP Applications enthält spezielle Kernel-Tunings und Page-Cache-Optimierungen, die im Standard-SLES fehlen. Lösung: Für SAP immer die dedizierte “SLES for SAP” ISO nutzen. Der Mehrpreis lohnt sich durch die massiven Optimierungen.

# 6. Fazit & Empfehlung

• Zukunftssicherheit: SLES ist durch seine europäische Herkunft und SAP-Dominanz eine feste Größe.
• Struktur: Nutzen Sie Leap für alle Development- und Staging-Umgebungen, um 100% Kompatibilität zur SLES-Produktion zu haben.
• Wahl: Wer YaST liebt, wird mit SUSE glücklicher als mit jeder anderen Distribution.

# Anhang: Cheatsheet