Strategie & Migration

Linux im Unternehmen einführen: dein Fahrplan vom Pilot zum Regelbetrieb

Nicht die Technik bringt solche Projekte zu Fall, sondern fehlende Bestandsaufnahme und ungeklärte Fachanwendungen. Fang mit einer Abteilung an, deren Arbeit im Browser stattfindet, und lerne dort, bevor du ausrollst.

5 Kapitel mit allen Befehlen
IT-Entscheider besprechen eine Infrastruktur-Roadmap im Besprechungsraum
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum Linux-Einführungen im Zwischenstand hängen bleiben

Die meisten Organisationen starten nicht bei null. Linux läuft längst auf Servern, im Container-Stack und in der CI, während Arbeitsplätze, Fachverfahren und Verzeichnisdienst weiter an Windows hängen. Dieser Mischbetrieb ist der Normalfall und kein Übergangszustand von ein paar Monaten, sondern eine Architektur, die du bewusst planen musst: Identitäten über Kerberos und LDAP beziehungsweise Active Directory, Dateidienste über Samba oder NFS, dazu Drucken, Zertifikate, Backup und Monitoring.

Der zweite typische Bruch liegt bei den Fachanwendungen. Eine ehrliche Inventarisierung trennt Anwendungen, die nativ oder im Browser laufen, von solchen, die eine Terminalserver-Sitzung, eine VM oder eine Ablösung brauchen. Wer diese Liste erst nach dem Pilotstart erstellt, verhandelt anschließend unter Zeitdruck mit Herstellern, die für Linux keine Supportzusage geben. Genauso häufig unterschätzt wird die Peripherie: Spezialhardware, Kartenleser und Treiber, die es nur für einen bestimmten Kernel-Zweig gibt.

Der dritte Punkt ist der Betrieb. Eine Distribution auszuwählen ist schnell erledigt, ein Lebenszyklus dagegen nicht. Du brauchst eine Antwort darauf, wer Pakete freigibt, wie Updates gestaffelt ausgerollt werden, wie CVE-Meldungen bewertet werden und was passiert, wenn ein Kernel-Update einen Treiber bricht. Ohne definierten Patch- und Rollback-Weg entstehen genau die handgepflegten Einzelsysteme, wegen derer Linux später als schwer beherrschbar gilt, obwohl das Problem der fehlende Prozess ist.

Miniatur-Szene: Spielbrett, auf dem eine Server-Figur von einer alten auf eine neue Plattform zieht, daneben eine Roadmap
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Die sechs Stufen der Linux-Einführung

  1. 01 Bestandsaufnahme und Anwendungsmatrix
  2. 02 Zielbild und Distributionsentscheidung
  3. 03 Pilotbereich im Echtbetrieb
  4. 04 Automatisiertes Rollout
  5. 05 Patch- und Sicherheitsprozess
  6. 06 Regelbetrieb und Supportmodell
Was du mitnimmst

So sieht ein belastbarer Einführungspfad aus

Der Fahrplan folgt einer festen Reihenfolge, weil jede Stufe die Entscheidungen der nächsten absichert. Wichtig ist, dass am Ende jeder Stufe etwas Schriftliches steht: eine Liste, ein Zielbild oder ein Betriebsdokument.

Bestandsaufnahme statt Bauchgefühl

Erfasse Anwendungen, Datenflüsse, Peripherie und Schnittstellen mit einer klaren Einstufung: nativ lauffähig, per Browser oder Remote-Sitzung nutzbar, virtualisierbar oder abzulösen. Dazu gehört die Hardware-Basis, also Firmware, Grafik, Netzwerkkarten und alles, was im Zweifel Treiber aus dem Hersteller-Repository braucht.

Zielbild und Distribution festlegen

Entscheide anhand von Supportzeitraum, Update-Kadenz, Zertifizierungen der Fachanwendungen und vorhandenem Know-how, ob du in Richtung RHEL, SUSE, Debian oder Ubuntu gehst. Die Entscheidung wirkt sich direkt auf Paketverwaltung, Managementwerkzeuge und Supportvertrag aus, deshalb gehört sie vor den Pilot und nicht danach.

Pilotbereich mit echten Arbeitsplätzen

Wähle eine Abteilung mit realem Tagesgeschäft und definiertem Anwendungsprofil, nicht die IT selbst. Der Pilot liefert belastbare Aussagen zu Druckern, Dateiablage, VPN, Zwei-Faktor-Anmeldung und zur Zusammenarbeit mit Kolleginnen und Kollegen, die noch auf Windows arbeiten.

Automatisierung von Anfang an

Installation, Grundkonfiguration und Rollen gehören in ein reproduzierbares Werkzeug. Mit Ansible, Kickstart oder AutoYaST und einem eigenen Paket-Spiegel baust du Systeme identisch neu auf, statt sie zu reparieren. Genau das macht später den Unterschied zwischen zwanzig und zweitausend Systemen.

Patch-, CVE- und Härtungsprozess

Lege fest, welche Quellen du auswertest, wie schnell kritische Lücken geschlossen werden und über welche Staging-Stufen ein Update läuft. Dazu kommen Basishärtung, Rechtemodell, Auditing und je nach Umfeld SELinux oder AppArmor sowie ein Firewall-Regelwerk mit nftables.

Supportmodell und Kompetenzaufbau

Kläre, was du selbst betreibst und wofür du Herstellersupport einkaufst, und wer im ersten und zweiten Level tatsächlich Logs liest, systemd-Units debuggt und Storage-Probleme einordnet. Ohne eigenes Wissen im Haus verlagerst du nur die Abhängigkeit, statt sie zu verringern.

Tutorial

Vom ersten Testgerät bis zum automatisierten Rollout

Die Reihenfolge hier ist die, in der Einführungen tatsächlich gelingen: erst Hardware und Peripherie auf echten Geräten prüfen, dann die Anmeldung an der bestehenden Domäne lösen, dann die Installation automatisieren und zuletzt Patchen und Härtung in den Regelbetrieb überführen. Jeder Schritt endet mit einem Ergebnis, das du vorzeigen kannst.

01

Hardware und Peripherie vor der Entscheidung prüfen

Ein Live-System auf den tatsächlich vorhandenen Geräten beantwortet in zwei Stunden, wofür Anforderungslisten Wochen brauchen. Nimm die Geräte mit, die im Alltag danebenstehen, nicht nur das Notebook.

Testlauf vom Live-Stick
# Welche Bauteile stecken drin, und lädt ein Treiber?
lspci -k | grep -A3 -E 'Network|VGA|Audio'
lsusb

# Firmware-Aktualisierungen über LVFS, bei Notebooks entscheidend
fwupdmgr refresh
fwupdmgr get-devices
fwupdmgr get-updates

# Drucken ohne Herstellertreiber?
driverless
lpinfo -m | grep -i everywhere

# Ruhezustand und Aufwachen, der häufigste Rückläufer
systemctl suspend
journalctl -b -g 'PM:' --no-pager | tail -20

fwupdmgr get-devices zeigt dir gleich mit, ob der Hersteller seine Firmware über LVFS bereitstellt. Tut er das nicht, brauchst du für BIOS-Aktualisierungen dauerhaft einen zweiten Weg, und das gehört in die Beschaffungskriterien der nächsten Gerätegeneration.

02

Anmeldung an der bestehenden Domäne

Solange die Linux-Arbeitsplätze eigene lokale Konten haben, bleibt die Einführung eine Insel. Der Anschluss an das vorhandene Verzeichnis ist deshalb der erste echte Meilenstein, nicht die Oberfläche.

Domänenbeitritt mit realmd und SSSD
# RHEL, Rocky, AlmaLinux
sudo dnf install -y realmd sssd adcli oddjob oddjob-mkhomedir \
  samba-common-tools

# Debian, Ubuntu
sudo apt install -y realmd sssd sssd-tools adcli oddjob oddjob-mkhomedir \
  samba-common-bin packagekit

realm discover ad.firma.de
sudo realm join --user=beitritt ad.firma.de

# Gegenprobe
realm list
id anna@ad.firma.de

realm discover verrät dir vor dem Beitritt, ob DNS und Zeit stimmen. Beides ist die häufigste Ursache für einen fehlgeschlagenen Beitritt, und beides siehst du in der Ausgabe, bevor du etwas veränderst.

/etc/sssd/sssd.conf
[sssd]
domains = ad.firma.de
services = nss, pam

[domain/ad.firma.de]
id_provider = ad
access_provider = ad
ad_gpo_access_control = enforcing
use_fully_qualified_names = False
fallback_homedir = /home/%u
default_shell = /bin/bash
cache_credentials = True
krb5_store_password_if_available = True

cache_credentials ist bei Notebooks Pflicht, sonst kommt niemand ohne Netzverbindung mehr an sein Gerät. ad_gpo_access_control wertet die Anmelderechte aus den Gruppenrichtlinien aus. Setz das im Pilot zuerst auf permissive und lies im Journal mit, wen die Regel aussperren würde.

03

Installation automatisieren, ab dem ersten Gerät

Wer die ersten zwanzig Rechner von Hand aufsetzt, baut zwanzig unterschiedliche Systeme und weiß ein halbes Jahr später nicht mehr, warum eines davon anders ist. Die unbeaufsichtigte Installation entsteht deshalb im Pilot, nicht danach.

Kickstart und autoinstall
# RHEL, Rocky, AlmaLinux: Kickstart vom Webserver, Bootparameter im Installer
#   inst.ks=https://provision.firma.de/ks/arbeitsplatz.cfg

# Vorlage aus einer bereits installierten Maschine ziehen
sudo cat /root/anaconda-ks.cfg

# Kickstart-Datei vor dem Ausrollen prüfen
sudo dnf install -y pykickstart
ksvalidator /srv/www/ks/arbeitsplatz.cfg

# Ubuntu: autoinstall über cloud-init, Bootparameter
#   autoinstall ds=nocloud-net;s=https://provision.firma.de/ubuntu/
cloud-init schema --config-file user-data

Beide Prüfbefehle kosten Sekunden und ersparen dir den Abbruch mitten in der Installation, bei dem der Rechner unbrauchbar zurückbleibt. Nimm sie in die Pipeline auf, die deine Provisionierungsdateien ausliefert.

Ansible: der Rechner ist ein Ergebnis, keine Handarbeit
- name: Arbeitsplatz herrichten
  hosts: linux_clients
  become: true
  tasks:
    - name: Basispakete
      ansible.builtin.package:
        name: [firefox, libreoffice, remmina]
        state: present

    - name: Unternehmenszertifikat verteilen
      ansible.builtin.copy:
        src: files/firma-ca.crt
        dest: "{{ '/etc/pki/ca-trust/source/anchors/firma-ca.crt'
                  if ansible_facts['os_family'] == 'RedHat'
                  else '/usr/local/share/ca-certificates/firma-ca.crt' }}"
        mode: '0644'
      notify: ca aktualisieren

  handlers:
    - name: ca aktualisieren
      ansible.builtin.command: >-
        {{ 'update-ca-trust' if ansible_facts['os_family'] == 'RedHat'
           else 'update-ca-certificates' }}

Das Zertifikat ist ein gutes erstes Beispiel, weil es in beiden Welten gebraucht wird und die Pfade sich unterscheiden. Wenn diese Rolle sitzt, hast du das Muster für alles Weitere: Pfad und Befehl abhängig von der Familie, der Rest identisch.

04

Patchen, Neustarts und Härtung in den Regelbetrieb bringen

Automatische Aktualisierung und Neustart-Erkennung
# RHEL, Rocky, AlmaLinux
sudo dnf install -y dnf-automatic
sudo sed -i 's/^apply_updates =.*/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer

# Debian, Ubuntu
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# Ist ein Neustart fällig?
needs-restarting -r                                        # EL-Familie
test -f /var/run/reboot-required && echo 'Neustart fällig' # Debian, Ubuntu

Automatisch einspielen und automatisch neu starten sind zwei getrennte Entscheidungen. Spiel auf Arbeitsplätzen automatisch ein und lass den Neustart die Person selbst auslösen, auf Servern umgekehrt: eingespielt wird geplant, neu gestartet wird im Wartungsfenster.

Dasselbe Ziel, zwei Werkzeugkästen

AufgabeRHEL, Rocky, AlmaLinuxDebian, Ubuntu
Automatische Aktualisierungdnf-automatic.timerunattended-upgrades
Nur Sicherheitsupdatesdnf update --securityOrigins-Muster auf -security begrenzen
Neustart fällig?needs-restarting -r/var/run/reboot-required
Paketfirewallfirewalld auf nftablesnftables oder ufw
Härtungsprofil messenoscap mit ssg-rhel-Inhaltenoscap mit ssg-ubuntu-Inhalten
Härtungsstand messen statt behaupten
sudo dnf install -y openscap-scanner scap-security-guide

# Welche Profile bringt die Distribution mit?
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Bewerten, Bericht schreiben
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results /var/log/oscap-$(date +%F).xml \
  --report  /var/log/oscap-$(date +%F).html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Lauf den Scan einmal vor dem Pilot und einmal danach. Die Differenz der beiden Berichte ist die Zahl, mit der du in die Lenkungsrunde gehst, und sie schlägt jede Formulierung über gestiegene Sicherheit.

05

Den Pilot messbar abschließen

Ein Pilot ohne vorher festgelegte Kriterien endet mit einer Diskussion über Geschmack. Leg die folgenden Punkte fest, bevor das erste Gerät ausgegeben wird.

Go-Kriterien für den Rollout

  • Jede Fachanwendung hat einen benannten WegNativ, im Browser, über RDP auf einen Terminalserver oder in einer Windows-VM. Ein offenes wird noch geprüft ist kein Weg, und genau dieser eine Punkt hält am Ende ganze Rollouts an.
  • Ein Gerät wurde ohne Handarbeit neu aufgesetztDer Beweis, dass Installation und Konfiguration reproduzierbar sind. Solange das nur einer Person gelingt, hast du kein Verfahren, sondern eine Person.
  • Der Helpdesk hat echte Tickets bearbeitetErst dann weißt du, welche Dokumentation fehlt. Zähl die Tickets pro Gerät und Woche und stell sie dem bestehenden Bestand gegenüber. Das ist die Zahl, nach der die Geschäftsführung fragt.
  • Sicherung und Wiederherstellung wurden einmal durchgespieltEine Sicherung einrichten kann jeder. Erst die Rückspielung auf ein frisches Gerät zeigt, ob Profil, Zertifikate, Schlüssel und Netzlaufwerke vollständig erfasst sind.
  • Zwei Personen im Team können das System ohne Hilfe betreibenEin einzelner Wissensträger ist ein Betriebsrisiko und der häufigste Grund, warum eine Einführung nach der Pilotphase stehen bleibt. Plane die zweite Person von Anfang an mit ein, nicht als Nachtrag.
Gut zu wissen

Häufige Fragen zu Linux-Einführung im Unternehmen

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie lange dauert die Einführung von Linux im Unternehmen realistisch?
Verlässlich planbar ist nur der Ablauf, nicht die Gesamtdauer, weil sie vor allem von der Zahl der Fachanwendungen und ihren Herstellerzusagen abhängt. Bestandsaufnahme und Zielbild lassen sich meist in einigen Wochen erledigen, ein aussagekräftiger Pilot braucht mindestens einen vollständigen Geschäftszyklus der beteiligten Abteilung, und der breite Rollout richtet sich danach, wie gut die Automatisierung steht.
Müssen wir alle Systeme migrieren oder reicht ein Teilbereich?
Ein dauerhafter Mischbetrieb ist völlig üblich und oft die wirtschaftlich sinnvollere Variante. Entscheidend ist, dass die Integration sauber definiert ist, also Anmeldung, Dateifreigaben, Druck, Zertifikate und Monitoring für beide Welten dokumentiert funktionieren, statt dass Linux-Systeme als Sonderfall neben der eigentlichen IT laufen.
Welche Distribution eignet sich für Unternehmen?
Sinnvoll ist die Auswahl entlang von Supportzeitraum, Update-Kadenz, Zertifizierung deiner Fachanwendungen und dem vorhandenen Know-how. RHEL und SLES bringen lange Lebenszyklen und kommerziellen Support mit, Debian und Ubuntu LTS sind ohne Subskription nutzbar und verlagern mehr Verantwortung ins eigene Team. Wichtiger als die Marke ist, dass du dich auf wenige Varianten festlegst und diese konsequent automatisiert betreibst.
Was kostet uns die Umstellung wirklich?
Die Lizenzersparnis ist der sichtbare Teil, entscheidend sind aber Aufwand für Anwendungsprüfung, Automatisierung, Qualifizierung des Teams und gegebenenfalls Subskriptionen für Support und Managementwerkzeuge. Rechne den Vergleich immer über den gesamten Lebenszyklus und beziehe den Betrieb ein, nicht nur die Anschaffung.
Welche Kompetenzen braucht das IT-Team dafür?
Im Kern sind das Systemadministration und Shell-Scripting, Netzwerk- und Infrastrukturdienste, Sicherheit und Härtung, Automatisierung mit Ansible sowie strukturiertes Troubleshooting. Genau diese Themen deckt cmt mit dem Linux Systemadministration und Shell-Scripting Kompaktkurs, dem Linux Security Intensivkurs, dem Ansible Kompaktkurs und dem Linux Troubleshooting Training ab.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Sehr intensiver Lehrgang, hat mich für meine Arbeit ein gutes Stück voran gebracht.
Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Sprich mit uns über deinen Linux-Fahrplan

Wenn du gerade zwischen Bestandsaufnahme und Pilot stehst, hilft ein kurzes Gespräch mehr als eine weitere Konzeptrunde. Wir ordnen mit dir ein, welche Schritte anstehen und welche Schulungen dein Team dafür braucht, von den Linux-Grundlagen über Ansible und Sicherheit bis zum Troubleshooting. Alle Kurse laufen wahlweise vor Ort, an unseren Standorten oder Live-Online, auf Wunsch als Firmenschulung mit deinen eigenen Systemen.