SUSE Linux Enterprise Server 16 installieren: Vom ISO zum produktionsnahen Linux-Server

Worum es in dieser Anleitung geht

Diese Anleitung baut SUSE Linux Enterprise Server 16 aus einem echten ISO in einem KVM-Lab auf. Sie ist bewusst praktisch: ISO prüfen, VM starten, Agama bedienen, System registrieren, Admin-Benutzer anlegen, Storage, Netzwerk, SELinux, Firewall, Cockpit und Updates validieren. Das Ziel ist kein Marketing-Überblick, sondern ein reproduzierbarer Installationspfad für Admins.

Die Installation wurde mit dem SLES 16 Online-Installationsmedium in einer Disposable-VM geprüft. Die Lab-Registrierung nutzt eine Test-Subscription. Wichtig ist die Unterscheidung: Eine Subscription kann bereits aktiviert sein, während ein einzelnes SLES-System erst noch gegen diese Entitlement registriert werden muss. Erst wenn `SUSEConnect --status-text` das installierte System als registriert zeigt und Repositories nutzbar sind, gilt die Registrierung als bestanden.

SLES 16: Mehr als ein neuer Installer

SLES 16 modernisiert mehrere langjährige SUSE-Administrationskonzepte gleichzeitig. Agama ist dabei nur der sichtbarste Einstiegspunkt. Im Betrieb verschiebt sich das Modell weg von einer stark YaST-zentrierten Denkweise hin zu Installation über Agama, interaktiver Day-2-Administration über Cockpit und CLI, reproduzierbarer Konfiguration über Ansible sowie Fleet- und Lifecycle-Management über SUSE Multi-Linux Manager, wo das organisatorisch passt.

Das macht SLES 16 nicht zu einer anderen Distribution und auch nicht austauschbar mit RHEL. Aber viele tägliche Werkzeuge sind modernen Enterprise-Linux-Admins vertrauter: `systemctl`, `journalctl`, `nmcli`, `firewall-cmd`, SELinux, Cockpit, KVM und Ansible. Die Lernkurve wandert dadurch stärker zu den wirklich SUSE-spezifischen Themen: `zypper`, SUSEConnect, SCC/RMT, Btrfs/Snapper, Agama sowie SUSE Lifecycle- und Repository-Modelle.

Lab-Aufbau

Das Lab ist klein genug für einen Laptop oder Build-Host und groß genug, um SLES 16 realistisch zu prüfen. Für Produktion gelten natürlich andere Vorgaben, besonders bei Storage, Netzwerk, Backup, Monitoring und Lifecycle-Prozessen.

vCPU:      2
RAM:       4 GiB
Disk:      40 GiB qcow2
Hostname:  sles16.example.test
Domain:    example.test
Network:   NAT for lab validation
Firmware:  UEFI recommended for production

SLES-16.0-Online-x86_64-QU0.install.iso

ISO prüfen

Vor der Installation wird das ISO nicht einfach gestartet, sondern zuerst nachvollziehbar geprüft. Die lokale Datei war `SLES-16.0-Online-x86_64-QU0.install.iso` mit 661 MB. Der ermittelte SHA-256-Wert wird im Lab-Report dokumentiert.

ls -lh SLES-16.0-Online-x86_64-QU0.install.iso
sha256sum SLES-16.0-Online-x86_64-QU0.install.iso
isoinfo -d -i SLES-16.0-Online-x86_64-QU0.install.iso | sed -n '1,35p'

Für produktive Builds sollte zusätzlich der offizielle Download- oder Mirror-Prozess dokumentiert werden. Wenn ein exakt benannter Build wie ein Quarter-Update-Medium verwendet wird, muss klar sein, welches Medium getestet wurde und ob ein späterer Build bewusst abweicht.

VM starten

Der einfachste Weg ist ein normaler ISO-Boot mit UEFI. Das folgende Beispiel zeigt eine reine QEMU-Variante. In produktionsnahen Umgebungen ist `virt-install` mit libvirt oft angenehmer, aber die technischen Parameter bleiben vergleichbar: 2 vCPU, 4 GiB RAM, 40 GiB Disk, virtio Storage und virtio Netzwerk.

qemu-img create -f qcow2 sles16.qcow2 40G

qemu-system-x86_64 \
  -machine q35,accel=kvm \
  -cpu host \
  -smp 2 \
  -m 4096 \
  -drive file=sles16.qcow2,if=virtio,format=qcow2 \
  -cdrom SLES-16.0-Online-x86_64-QU0.install.iso \
  -boot d \
  -nic user,model=virtio-net-pci,hostfwd=tcp:127.0.0.1:2222-:22

Wenn der Bootloader im Lab nicht sauber durchstartet, kann Agama auch über Kernel und Initrd direkt gebootet werden. Das ist ein Lab-Workaround, kein Muss für eine normale Installation. Für produktive Installationen ist ein sauberer UEFI-Bootpfad vorzuziehen.

Agama installieren

SLES 16 verwendet Agama als modernen Installer. Agama ist kein neues YaST mit anderer Oberfläche, sondern ein Installations- und Provisioning-Werkzeug. Im Browser werden Produkt, Registrierung, Sprache, Tastatur, Zeitzone, Netzwerk, Softwareauswahl, Storage und Benutzer konfiguriert. Der Hostname wird vor der Registrierung gesetzt, damit Systemidentität, Logs und Subscription-Status eindeutig bleiben.

Das Architekturmodell ist bewusst getrennt: Agama installiert und provisioniert, Cockpit unterstützt interaktive Day-2-Administration, die CLI bleibt für direkte Diagnose und Betrieb unverzichtbar, Ansible beschreibt reproduzierbare Konfiguration, und SUSE Multi-Linux Manager übernimmt Fleet- und Lifecycle-Aufgaben, wenn viele Systeme dauerhaft verwaltet werden. Agama ersetzt deshalb nicht jede frühere YaST-Funktion.

• Produkt: SUSE Linux Enterprise Server 16.0 auswählen.

• Hostname: `sles16.example.test` setzen.

• Zeitzone: passend zum Betrieb wählen, im Lab `Europe/Vienna`.

• Software: Cockpit und SELinux gezielt aktivieren.

• Storage: Btrfs für `/`, Swap und Snapper-Snapshots nutzen.

• Benutzer: ersten Admin-Benutzer anlegen; root per SSH-Passwort bleibt nicht der normale Betriebsweg.

Ein wichtiger Praxispunkt: Wenn die Softwareauswahl zu stark reduziert wird, können erwartete Sicherheitskomponenten fehlen. Im Lab war SELinux erst nach expliziter Auswahl des SELinux-Patterns vollständig aktiv. Wer SLES 16 bewusst härtet, prüft daher nicht nur die UI-Auswahl, sondern danach auch Kernel-Parameter, Mounts, Pakete und `getenforce`.

Registrierung richtig verstehen

Die Registrierung in Agama bindet das installierte System an eine bestehende SUSE-Entitlement. Eine Meldung, dass eine Subscription bereits aktiviert ist, bedeutet nicht automatisch, dass die konkrete VM registriert ist. Aktivierung der Subscription und Registrierung eines Systems sind zwei unterschiedliche Schritte.

Nach der Installation muss die Systemregistrierung geprüft werden. In der Dokumentation und in Screenshots werden Registrierungscodes niemals ausgeschrieben. Für Automatisierung und Runbooks gehören sie in Secret Stores oder kurzlebige Secret-Dateien mit restriktiven Rechten, nicht in Git, Screenshots, Logs oder CMS-Inhalte.

Erster Boot

Nach dem Reboot sollte die Konsole den gesetzten Hostnamen und die Web-Console-URLs zeigen. Danach prüfen Sie zuerst, ob das System sauber gestartet ist, bevor Pakete, Firewall oder Dienste verändert werden.

cat /etc/os-release
uname -r
hostnamectl
systemctl --failed
ip addr show
ip route
nmcli connection show --active
timedatectl

Im validierten Lab lief SLES 16.0 mit Kernel 6.12, der Hostname war `sles16.example.test`, NetworkManager war aktiv und `systemctl --failed` zeigte keine fehlgeschlagenen Units. Das ist die Mindestbasis, bevor man ein System als sauber installiert betrachtet. Für RHEL-, Rocky-, AlmaLinux- und Fedora-Admins fühlt sich dieser erste Diagnoseblock vertraut an: systemd, Journal, NetworkManager und firewalld sind keine exotischen SUSE-Sonderwege.

NetworkManager statt wicked

Networking ist eine der wichtigsten Umstellungen für bestehende SLES-Administratoren. SLES 15 konnte wicked und NetworkManager nutzen; SLES 16 konsolidiert auf NetworkManager. Skripte, Runbooks und Automatisierung, die wicked-Dateien oder wicked-Kommandos erwarten, müssen deshalb geprüft und angepasst werden.

Das praktische Denken ändert sich: Statt “wicked-Konfiguration prüfen” schaut man auf Devices, Connections und aktive Profile. Die Namen unterscheiden sich je nach System und Installer-Auswahl, deshalb sind die folgenden Kommandos bewusst mit einem synthetischen Connection-Namen gezeigt.

https://sles16.example.test:9090/network

Netzwerkverwaltung in Cockpit: SLES 16 verwendet NetworkManager statt wicked. Die Aufnahme zeigt nur das isolierte Lab-System mit synthetischem Hostnamen und Lab-Adresse.

nmcli device status
nmcli connection show
nmcli connection show --active

sudo nmcli connection modify "Wired Connection" \
  ipv4.method manual \
  ipv4.addresses 192.0.2.20/24 \
  ipv4.gateway 192.0.2.1 \
  ipv4.dns "192.0.2.53 192.0.2.54"
sudo nmcli connection up "Wired Connection"

Für Admins aus der RHEL-Familie ist genau das vertraut: NetworkManager und `nmcli` gehören dort längst zum Alltag. Trotzdem bleiben die Distributionen unterschiedlich. Vertraut sind die Werkzeuge; SUSE-spezifisch bleiben Paketierung, Registrierung, Lifecycle und Supportmodell.

Storage, Btrfs und Snapper prüfen

SLES setzt weiterhin stark auf Btrfs und Snapper. Das ist für Administratoren aus RHEL-Umgebungen ungewohnt, aber für SLES wichtig: Paketänderungen erzeugen Snapshots, Rollback-Szenarien werden sichtbarer, und Subvolumes trennen Bereiche wie `/home`, `/var`, `/opt` oder `/srv`.

findmnt /
findmnt /tmp
lsblk -f
df -h
sudo btrfs subvolume list /
sudo snapper list

Für Admins aus SLES 15 bleibt Btrfs vertraut, aber SLES 16 bringt an anderer Stelle deutliche Änderungen. YaST ist nicht mehr der zentrale Installations- und Admin-Weg; Agama, Cockpit, CLI und Automatisierung übernehmen die relevanten Aufgaben.

Von AppArmor zu SELinux

SELinux ist eine der größten SLES-16-Geschichten. Frühere SLES-Generationen waren stark mit AppArmor verbunden. SLES 16 entfernt AppArmor und setzt auf SELinux mit Policies für einen großen Teil des Systems. Auf einem korrekt eingerichteten SLES-16-System sollte SELinux aktiv sein und im Regelfall enforcing laufen.

Das verändert Security-Troubleshooting und Runbooks. Bestehende AppArmor-Annahmen können nicht einfach übernommen werden: Denials, Labels, Kontexte und Policies werden anders geprüft und bewertet. RHEL-Admins kennen das Grundmodell bereits, aber die konkrete Policy- und Paketwelt bleibt SUSE-spezifisch.

getenforce
sestatus
sudo systemctl status firewalld --no-pager
sudo firewall-cmd --list-all
sudo nft list ruleset | sed -n '1,120p'

Im Lab lief SELinux im Enforcing-Modus. firewalld war aktiv, und die Dienste `ssh` und `cockpit` waren freigegeben. nftables wird dabei durch firewalld verwaltet. Für Produktion werden Zonen, Quellen, Services und Management-Zugriffe deutlich restriktiver festgelegt.

getenforce
sestatus
sudo journalctl -t setroubleshoot --since "30 minutes ago"
sudo ausearch -m AVC,USER_AVC -ts recent

SELinux-Probleme löst man nicht dauerhaft durch Abschalten von SELinux. Der robuste Ablauf ist: Dienstproblem beobachten, Denial in Audit- oder Journal-Daten prüfen, Kontext oder Policy verstehen, Konfiguration oder Policy korrigieren und danach erneut verifizieren. Genau dieser Ablauf trennt produktionsfähiges Hardening von kurzfristigem Workaround.

SUSEConnect, Produkte und Repositories prüfen

Nach dem ersten Boot wird geprüft, ob das System wirklich registriert ist und die erwarteten Produkt- und Update-Repositories kennt. Diese Ausgabe kann sensible Repository-URLs und Registration-Metadaten enthalten. Sie gehört deshalb nicht unredigiert in Tickets, Screenshots oder Blogartikel.

SUSEConnect --status-text
zypper products -i
zypper repos --uri
zypper patterns --installed-only

Im validierten Lab war SLES 16.0 als installiertes Basisprodukt registriert. Update-Repositories waren nutzbar. Externe optionale Repositories wie NVIDIA oder CUDA waren sichtbar, aber deaktiviert. Das ist ein guter Zustand für ein schlankes Server-Lab.

Updates und Patches testen

Ein frisch installiertes System ist erst nach einem Patch-Test wirklich bewertbar. `zypper patch-check` zeigt, was anwendbar ist. `zypper patch` installiert nicht-interaktive Patches. Interaktive Patches müssen bewusst gelesen und mit passender Option oder Wartungsfenster behandelt werden.

sudo zypper refresh
sudo zypper patch-check
sudo zypper list-patches
sudo zypper patch
sudo zypper patch-check

Im Lab wurden nicht-interaktive Patches erfolgreich installiert. Ein interaktiver Security-Patch blieb erwartungsgemäß zur manuellen Entscheidung offen. Das ist kein Installationsfehler, sondern ein Hinweis darauf, dass Patch-Prozesse zwischen Standard-Patches und interaktiven Eingriffen unterscheiden müssen.

Cockpit als Admin-Oberfläche

Cockpit ist in SLES 16 der webbasierte Einstieg für viele Day-2-Aufgaben. Es nutzt vorhandene System-APIs und ist für Übersicht, Dienste, Logs, Storage, Netzwerk, SELinux und schnelle Betriebsprüfungen hilfreich. Für RHEL-Admins ist Cockpit ebenfalls vertraut, dadurch wirkt ein frisch installiertes SLES-16-System im Tagesbetrieb schneller zugänglich als ältere SUSE-Installationen.

https://sles16.example.test:9090/system

Systemübersicht des installierten SLES-16-Servers in Cockpit. Sichtbar sind nur synthetische Lab-Daten, der Hostname `sles16.example.test` und der SLES-16-Systemkontext.

Cockpit ersetzt weder CLI noch Automation. Es ist die interaktive Ebene für einzelne Systeme. Wiederholbare Konfiguration gehört in Ansible oder ein passendes Fleet-Werkzeug; Paket-, Repository- und Lifecycle-Entscheidungen bleiben über `zypper`, SUSEConnect, SCC/RMT und SUSE-Prozesse kontrolliert.

https://sles16.example.test:9090/system/services

systemd-Dienste lassen sich in Cockpit einsehen und verwalten; für Automatisierung bleibt die CLI beziehungsweise Configuration as Code maßgeblich.

sudo systemctl enable --now cockpit.socket
systemctl status cockpit.socket --no-pager
curl -k -I https://127.0.0.1:9090/

Automatisierbare Agama-Installation

Agama kann nicht nur interaktiv genutzt werden. Für wiederholbare Labs und spätere Standardisierung kann eine JSON- oder Jsonnet-basierte Konfiguration geladen und validiert werden. Das folgende Beispiel ist bewusst redigiert und enthält nur Platzhalter für Secrets.

{
  "product": {
    "id": "SLES",
    "registrationCode": "<REGISTRATION-CODE>",
    "registrationEmail": "<OPTIONAL-EMAIL>"
  },
  "localization": {
    "language": "en_US.UTF-8",
    "keyboard": "us",
    "timezone": "Europe/Vienna"
  },
  "network": {
    "hostname": "sles16.example.test"
  },
  "software": {
    "patterns": ["cockpit", "selinux"],
    "packages": ["vim", "curl", "policycoreutils", "selinux-tools"]
  },
  "users": {
    "root": {
      "sshPublicKey": "<ADMIN-SSH-PUBLIC-KEY>"
    },
    "users": [
      {
        "userName": "forgeone",
        "fullName": "ForgeOne Lab Admin",
        "hashedPassword": "<HASHED-LAB-PASSWORD>"
      }
    ]
  }
}

agama config validate /run/agama/profile.json
agama config load /run/agama/profile.json
agama install
agama monitor
agama finish

Im Lab wurde das Profil in der Live-Installer-Umgebung validiert, geladen und mit `agama install` installiert. Registration Code und temporäre Passwörter wurden nur kurzlebig verwendet, lokal redigiert und nach Abschluss entfernt. Für CI/CD-ähnliche Abläufe muss dieser Schritt an einen Secret Store angebunden werden.

Was sich für RHEL-Admins anders anfühlt

SLES 16 nutzt mehrere Kernkomponenten, die Administratoren aus modernen Enterprise-Linux-Umgebungen bereits kennen. Für RHEL-Admins sind SELinux und NetworkManager beim Wechsel auf ein aktuelles SLES-System kein Wechsel des grundsätzlichen Betriebsmodells mehr. Die Distributionen bleiben verschieden, aber die täglichen Bausteine überschneiden sich stärker.

Das heißt ausdrücklich nicht, dass SLES 16 und RHEL austauschbare Distributionen wären. Einfacher wird der mentale Übergang: Ein erfahrener Enterprise-Linux-Engineer muss SELinux-Grundlagen, `nmcli`, `systemctl`, `journalctl`, `firewall-cmd`, nftables-Konzepte, Cockpit, KVM und Ansible nicht neu lernen. Die eigentliche Lernkurve liegt bei `zypper`, SUSEConnect, SCC/RMT, Btrfs/Snapper, Agama und dem SUSE Lifecycle-, Repository- und Supportmodell.

Was sich für SLES-15-Admins ändert

SLES-15-Admins müssen SLES 16 nicht neu als Linux lernen, aber sie sollten die Plattformänderungen ernst nehmen. Agama ersetzt den klassischen Installer-Weg, YaST ist nicht mehr der zentrale Admin-Anker, NetworkManager ist gesetzt, SELinux ersetzt AppArmor als Standardpfad, und Cockpit wird wichtiger.

Für Migrationen und Betrieb heißt das: Runbooks, Screenshots, Schulungen und Automatisierung müssen überprüft werden. Alte Annahmen über wicked, YaST-Module, AppArmor-Profile oder Modul-Repositories sollten nicht ungeprüft übernommen werden. Ein typischer alter Reflex “wicked prüfen” wird zu `nmcli connection show`; “AppArmor-Profil prüfen” wird zu `getenforce`, `sestatus` und Audit-Analyse; “alles über YaST konfigurieren” wird zu Agama für Installation, Cockpit/CLI für interaktive Administration und Ansible für reproduzierbare Konfiguration.

Abschlusscheck

Eine SLES-16-Installation ist erst dann abgeschlossen, wenn das System bootet, registriert ist, Repositories nutzbar sind, keine Units fehlgeschlagen sind, Netzwerk und Zeit stimmen, SELinux im gewünschten Modus läuft, Firewall-Regeln passen, Snapper funktioniert, Cockpit erreichbar ist und der Patch-Prozess getestet wurde.

Die Disposable-VM kann nach Abschluss der Update- und Screenshot-Tests aus dem SUSE Customer Center deregistriert werden, wenn die Test-Entitlement nicht weiter gebunden bleiben soll. Vor Abschluss aller Nachweise sollte sie jedoch registriert bleiben, damit Repository- und Patch-Checks reproduzierbar sind.

Professionelle Unterstützung