SLES 16 und Enterprise Linux: Wie unterschiedlich ist der Admin-Alltag noch?

Einordnung

Ein Administrator, der täglich mit Red Hat Enterprise Linux, Rocky Linux oder AlmaLinux arbeitet, bekommt einen SLES-16-Server auf den Tisch. Die ersten Fragen sind naheliegend: Wo ist YaST? Wie wird das Netzwerk konfiguriert? AppArmor oder SELinux? Funktioniert mein systemd-Wissen? Und muss ich für SUSE wieder einen völlig eigenen Betriebsalltag lernen?

Die kurze Antwort lautet: SLES 16 ist nicht RHEL, und es sollte auch nicht so beschrieben werden. Aber viele grundlegende Werkzeuge und Konzepte fühlen sich für Enterprise-Linux-Admins deutlich vertrauter an als in älteren SUSE-Generationen. Die Unterschiede verschieben sich stärker in Richtung Paketverwaltung, Repository- und Registrierungsmodell, Lifecycle, Support und Flottenmanagement.

Diagramm: Die gemeinsame Ebene liegt bei systemd, NetworkManager, SELinux, RPM und Logs. Unterschiede bleiben bei Paketverwaltung, Registrierung, Installation, Lifecycle und Management.

Warum SUSE früher anders wirkte

SUSE hatte historisch starke eigene Berührungspunkte: YaST für Installation und Administration, wicked für Netzwerke, AppArmor als Standard-Sicherheitsframework, zypper und libzypp für Pakete sowie SCC, SMT/RMT und SUSE-spezifische Lifecycle-Konzepte. Das war nicht schlechter oder besser, aber beim Wechsel zwischen Distributionen war mehr distributionsspezifisches Wissen nötig.

SLES 16 verändert mehrere dieser Berührungspunkte. NetworkManager wird zum zentralen Netzwerk-Stack, SELinux ist das Standard-Sicherheitsframework, Cockpit übernimmt viele interaktive 1:1-Aufgaben, und Agama ersetzt den klassischen Installationspfad durch einen modernen Installer mit Web UI, CLI und API.

Vergleich im Admin-Alltag

Systemd, Dienste und Logs

Für den täglichen Betrieb ist systemd die gemeinsame Sprache. Dienste starten, stoppen, aktivieren und Logs auswerten funktioniert auf SLES 16 genauso konzeptionell wie auf RHEL-kompatiblen Systemen. Vorsicht ist nur bei konkreten Unit-Namen angebracht: sshd, apache2/httpd, mariadb/mysql oder distributionseigene Komponenten heißen nicht überall gleich.

systemctl status sshd
systemctl restart sshd
systemctl enable --now sshd
journalctl -u sshd -b
systemctl --failed

Netzwerk: NetworkManager statt wicked

SLES 16 konsolidiert den Netzwerk-Stack auf NetworkManager. Für Admins aus dem RHEL-Umfeld ist das einer der wichtigsten Annäherungspunkte: nmcli, Verbindungsprofile, DNS- und Routing-Prüfungen fühlen sich wesentlich vertrauter an als klassische wicked-Konfiguration.

nmcli general status
nmcli connection show
nmcli device status
ip address show
ip route show
resolvectl status

SELinux: vertrautes Modell, nicht identische Policy

Der Wechsel zu SELinux ist für RHEL-, Rocky- und AlmaLinux-Admins besonders relevant. Werkzeuge wie sestatus, getenforce, setsebool, semanage und restorecon sind konzeptionell bekannt. Trotzdem ist die Aussage nicht: SUSE verhält sich exakt wie RHEL. Policies, Paketpfade, Module und Herstellerdefaults müssen jeweils geprüft werden.

sestatus
getenforce
ls -Z /var/www
restorecon -Rv /srv/www
semanage fcontext -l | grep httpd

Pakete: RPM ist gemeinsam, zypper und dnf bleiben verschieden

SLES 16 und die RHEL-Familie verwenden RPM-Pakete, aber die operative Paketverwaltung bleibt distributionsspezifisch. Auf RHEL-kompatiblen Systemen ist dnf der zentrale Einstieg. Auf SLES bleibt zypper mit libzypp, Patterns, Produkten, Patches und SUSE-Repositories das Werkzeug der Wahl.

Registrierung, Repositories und Lifecycle

Die größten Unterschiede liegen selten beim einzelnen systemctl-Befehl, sondern beim Betriebsmodell. SUSE arbeitet mit SUSE Customer Center, SUSEConnect, RMT und SUSE Multi-Linux Manager. Red-Hat-Umgebungen arbeiten mit RHSM, subscription-manager und häufig Satellite oder kompatiblen Managementpfaden. Das betrifft Berechtigungen, Repositories, Patch-Freigaben, Wartungsfenster, Compliance und Supportfälle.

# SLES
SUSEConnect --status-text
zypper repos
zypper patches

# RHEL-compatible systems
subscription-manager status
dnf repolist
dnf updateinfo list

Cockpit und YaST richtig einordnen

SUSE positioniert Cockpit in SLES 16 für viele interaktive Administrationsaufgaben. Das ist für Enterprise-Linux-Admins angenehm, weil Cockpit auch im RHEL-Umfeld bekannt ist. Wichtig bleibt die Einschränkung: Cockpit ersetzt YaST nicht vollständig im Sinne aller früheren YaST-Funktionen. Für größere Umgebungen sind Automatisierung und zentrales Management der wichtigere Maßstab.

Agama statt klassischem Installationsdenken

Agama ist ein moderner Installationsansatz mit Web UI, CLI und HTTP API. Wer aus der RHEL-Welt kommt, sollte Agama nicht mit Anaconda gleichsetzen. Sinnvoller ist die operative Einordnung: Beide Welten unterstützen reproduzierbare Installationen, aber über unterschiedliche Werkzeuge, Profile und Automatisierungspfade.

Ansible und Automatisierung

Für Infrastrukturteams ist Ansible der gemeinsame Nenner. Rollen sollten Distributionen nicht über Dateipfade raten, sondern facts, Variablen und eine explizite Support-Matrix verwenden. Besonders paket- und repositorynahe Aufgaben bleiben unterschiedlich, während systemd-, Datei-, Template- und Service-Tasks oft sauber abstrahiert werden können.

- name: Install web server package
  ansible.builtin.package:
    name: "{{ webserver_package }}"
    state: present

- name: Ensure service is running
  ansible.builtin.service:
    name: "{{ webserver_service }}"
    state: started
    enabled: true

Was bleibt bewusst unterschiedlich?

• Paketverwaltung: zypper und dnf haben unterschiedliche Befehle, Resolver-Verhalten und Updatekonzepte.

• Registrierung: SUSEConnect/SCC/RMT ist nicht RHSM/subscription-manager.

• Installation: Agama ist nicht Anaconda und AutoYaST ist nicht Kickstart.

• Lifecycle: Supportkanäle, Patchkategorien, Module, Produkte und Maintenance Policies unterscheiden sich.

• Management: SUSE Multi-Linux Manager, Red Hat Satellite und reine Ansible-Setups lösen ähnliche Probleme, aber nicht identisch.

Mini-Workflow: Webdienst nicht erreichbar

Ein praktischer Fehlerpfad zeigt gut, wo Wissen übertragbar ist und wo Distributionswissen beginnt. Die ersten Schritte sind fast identisch: Dienst, Logs, Port, Firewall, SELinux-Kontext und DNS prüfen. Erst bei Paketquelle, Service-Namen, Repository, Registrierung und Herstellerdokumentation trennt sich der Weg.

systemctl status nginx
journalctl -u nginx -b
ss -lntp | grep ':80\|:443'
firewall-cmd --list-services
sestatus
restorecon -Rv /srv/www
curl -vk https://server.example.test/

Brücke zu SUSE Multi-Linux Manager

Genau an dieser Stelle wird SUSE Multi-Linux Manager interessant. Wenn SLES, RHEL, Rocky Linux, AlmaLinux, openSUSE oder andere Systeme gemeinsam betrieben werden, geht es nicht mehr nur um den einzelnen Administratorbefehl. Entscheidend werden Inventar, Patch- und Lifecycle-Steuerung, Compliance, Reporting, Automatisierung und reproduzierbare Betriebsstandards.

FAQ: kurze Antworten für Administratoren

Fazit

SLES 16 senkt die Einstiegshürde für Administratoren aus der Enterprise-Linux-Welt deutlich. Wer systemd, journalctl, NetworkManager, SELinux, RPM und Ansible sicher beherrscht, findet im täglichen Betrieb viele vertraute Muster. Die eigentliche Lernkurve liegt nicht mehr so stark im Linux-Handwerk, sondern im SUSE-spezifischen Plattformmodell: zypper, SCC, SUSEConnect, RMT, Agama, Lifecycle und Multi-Linux Manager.