Software-Pakete: MSI, MSIX, DEB, RPM

Bevor Software auf vielen Computern installiert werden kann, muss sie in einem Paketformat verpackt werden. Jedes Betriebssystem hat seine eigenen Standards: MSI/MSIX für Windows, DEB für Debian/Ubuntu, RPM für Red Hat/Fedora. Diese Pakete enthalten nicht nur die Software, sondern auch Anweisungen für die Installation: Wohin kopieren? Welche Dependencies brauchen wir? Welche Registry-Einträge anlegen? Was beim Deinstallieren tun?

Diese Lektion zeigt die wichtigsten Paketformate und wie sie sich unterscheiden. Wer als FISI Software ausrollen muss, kommt um diese Formate nicht herum. Auch FIAE-Azubis sollten sie kennen – schließlich liefert man manchmal Software in diesen Formaten aus.

1) Warum überhaupt Pakete?

Wenn du eine kleine Anwendung manuell installierst – Datei in einen Ordner kopieren, Verknüpfung anlegen, fertig – reicht das für ein paar User. Aber bei hunderten oder tausenden Geräten ist das nicht praktikabel. Pakete lösen mehrere Probleme:

• Standardisierte Installation: gleicher Ablauf auf jedem System
• Abhängigkeiten: das Paket sagt „brauche libssl 1.1+, Python 3.9+" – System installiert automatisch mit
• Updates: alte Version sauber durch neue ersetzen
• Deinstallation: rückstandslos entfernen
• Signierung: Echtheit prüfbar (kommt von wem es soll?)
• Skriptbarkeit: silent install ohne Klicks
• Inventarisierung: was ist installiert? Welche Version?

Ohne Pakete wäre Massen-Ausrollung wie sie in Unternehmen passiert nicht möglich.

2) Die vier wichtigsten Formate im Überblick

Vier Formate decken den Großteil der Software-Distribution ab. Jedes hat eigene Stärken und eine eigene Ökosystem-Geschichte:

3) MSI: das klassische Windows-Format

MSI steht für Microsoft Installer (auch „Windows Installer" genannt). Seit Windows 2000 das Standard-Format. Eine MSI-Datei ist im Grunde eine kleine relationale Datenbank, die beschreibt was installiert werden soll:

Installation via Kommandozeile passiert mit dem Tool msiexec:

Diese Befehle nutzt du z.B. in PowerShell-Skripten für automatisiertes Ausrollen. WSUS und Intune verwenden intern auch msiexec.

4) MSIX: der moderne Nachfolger

MSIX ist Microsofts modernes Paketformat seit Windows 10 (2017 vorgestellt). Es soll die Schwächen von MSI ausgleichen und bringt einige Innovationen:

• App-Container: jede Anwendung läuft in einer isolierten Umgebung – kann nicht andere Programme stören (ähnlich Docker-Container)
• Saubere Deinstallation: Container wird komplett entfernt, keine Reste in Registry/Files
• Automatische Updates: integriert in den Microsoft Store oder über Update-Server
• Modernes Format: ZIP-basiert mit klarer XML-Struktur, einfacher zu erstellen als MSI
• Signaturpflicht: jedes MSIX-Paket muss signiert sein – Sicherheit
• Klein: Nutzt File-System-Sharing – mehrere Apps mit gleicher Datei teilen sie

MSIX ist die Zukunft für Windows-Software-Verteilung, aber MSI ist immer noch sehr verbreitet, weil viele bestehende Anwendungen darauf basieren.

5) DEB: Debian-Pakete

DEB ist das Paketformat für Debian und alle Debian-basierten Distros: Ubuntu, Mint, Pop!_OS, Kali Linux, Raspberry Pi OS. Eine DEB-Datei ist technisch ein ar-Archiv mit drei Komponenten: Steuer-Metadaten, Programm-Files, und Skripte.

Eine DEB-Datei lokal installieren mit dpkg:

Eine DEB-Datei hat folgende interne Struktur:

Die control-Datei ist das Herzstück – sie sagt was das Paket ist und was es braucht:

6) RPM: Red Hat Package Manager

RPM ist das Pendant für Red Hat Enterprise Linux, CentOS, Fedora, AlmaLinux, Rocky Linux, OpenSUSE und Derivate. Strukturell sehr ähnlich zu DEB, aber andere Tools und etwas andere Befehle:

7) Dependencies und ihre Auflösung

Ein zentrales Konzept aller Paketsysteme: Abhängigkeiten (Dependencies). Eine Anwendung braucht oft andere Pakete um zu funktionieren. Modernes apt oder dnf löst diese Abhängigkeiten automatisch aus den Repositories:

8) Repositories: woher kommen die Pakete?

Ein Repository ist eine zentrale Server-Sammlung von Paketen. Linux-Distros haben offizielle Repos mit tausenden Paketen, Microsoft hat den Store mit MSIX-Paketen. So funktioniert's:

• Konfiguration: System weiß welche Repos zur Verfügung stehen (z.B. /etc/apt/sources.list bei Ubuntu)
• Update: apt update holt aktuelle Paket-Listen von den Repos
• Installation: apt install nginx – System findet nginx im Repo und installiert
• Upgrade: apt upgrade – alle Pakete auf neueste Version bringen

Eigene Repositories einrichten ist üblich in Unternehmen: interne Pakete die nicht öffentlich sind, oder Mirror öffentlicher Repos für Internet-getrennte Umgebungen. Bei DEB: apt-mirror, bei RPM: createrepo.

9) Signierung und Vertrauen

Wie weißt du, dass ein Paket wirklich vom Anbieter kommt und nicht von einem Angreifer? Antwort: digitale Signaturen. Die meisten modernen Pakete sind signiert mit dem privaten Schlüssel des Herstellers. Das System prüft die Signatur mit dem öffentlichen Schlüssel:

• MSI/MSIX: Authenticode-Signaturen, von vertrauenswürdigen CAs ausgestellt (gleiche Technik wie HTTPS-Zertifikate)
• DEB: GPG-Signaturen, Schlüssel werden in /etc/apt/trusted.gpg.d/ abgelegt
• RPM: GPG-Signaturen, Schlüssel werden mit rpm --import registriert

Bei unsignierten Paketen fragt das System (oder weigert sich gleich). Das ist eine wichtige Sicherheitsmaßnahme gegen Supply-Chain-Angriffe – siehe auch K08 L6 Digitale Signaturen.

10) Format-Vergleich

Die wichtigsten Unterschiede der vier Formate auf einen Blick:

11) Universelle Linux-Formate

Es gibt drei moderne Alternativen die distro-übergreifend funktionieren – also auf Ubuntu UND Fedora UND Arch Linux:

• Snap (Canonical/Ubuntu): zentraler Snap Store, automatische Updates. Kontrovers wegen Performance.
• Flatpak (community/Red Hat): Standard auf Fedora, viele Desktop-Apps in Flathub. Sandbox-basiert.
• AppImage: einzelne ausführbare Datei – keine Installation nötig, einfach chmod +x und doppelklicken.

Diese Formate enthalten alle Dependencies im Paket selbst. Sie sind größer, aber funktionieren immer – egal welche Distro. Trade-off: mehr Festplatte gegen weniger Konflikt-Probleme.

12) Pakete in CI/CD-Pipelines

Wer Software entwickelt, muss sie oft selbst paketieren. Das passiert typischerweise in der CI/CD-Pipeline:

Tool wie fpm (Effing Package Management) macht das Bauen über mehrere Formate hinweg einfach – aus einem Quellverzeichnis erzeugst du DEB, RPM und sogar OSX-Pakete. Bei Windows-Software wird's mit WiX oder NSIS erstellt.

Zusammenfassung

Software-Pakete verpacken Software standardisiert für Massen-Installation – mit Dependencies, Skripten, Signaturen. MSI = klassisches Windows-Format (msiexec, Registry, komplex). MSIX = moderner Windows-Nachfolger (Container-isoliert, signiert, Auto-Update). DEB = Debian/Ubuntu (dpkg, apt, control-File). RPM = RHEL/Fedora (rpm, dnf, spec-File). Alle haben: Metadaten, Files, Pre/Post-Skripte, Dependencies. Dependency-Auflösung automatisch via apt/dnf aus Repositories. Signierung garantiert Authentizität – Authenticode bei Windows, GPG bei Linux. Universelle Formate: Snap, Flatpak, AppImage – funktionieren distro-übergreifend. Build in CI/CD mit Tools wie fpm, WiX, dpkg-buildpackage. Pflicht-Wissen für FISI und alle die Software ausrollen.