Offline Installationen mit Linux

« | 21 Apr 2023 | »

Bei Produktinstallationen für Kunden melden diese oft:

Wir haben ein XYZ Linux Version 9.8.7 ohne Internetanbindung. Senden Sie uns alle notwendigen Installationspakete zu.

Und dann fängt das große Weinen an, wenn man bei Python3 angefangen eine halbe Linux-Distribution “nachliefern” soll.

---

Windows stammt aus der Offline-Zeit weshalb alles als einzelne Installationsdatei (.msi, .msu, .cab und andere) ausgeliefert werden kann. Heute ist das ein unguter Fluch, weil man die Fülle an Dateifragmenten nicht mehr verwaltet bekommt und erst seit kurzem wird versucht mit winget verspätet ins 21. Jahrhundert zu wechseln.

Linux Distributionen hatten früh erkannt, wie wichtig ein einheitliches Paket-Management ist und nutzten es. Allerdings spalteten sich schnell verfeindete Sekten ab und gründeten ihre eigene Paket-Religion.

Im Embedded-Bereich schmerzt das sehr, wenn man neben dem eigenen Produkt auch noch auf viele Geschmacksrichtungen von Linux-Varianten eingehen muss, denn dort ist ein System “offline” und stets veraltet für 10 Jahre in Betrieb.

Wenn wir Entwickler also ein tolles Feature implementieren, das auf der lib_superduper aufbaut, müssen wir dann auch einen Weg finden, wie diese fehlende lib_superduper beim Kunden integriert wird.

Aber wie findet man jetzt heraus, welche Pakete sonst noch fehlen, und wo kann man die dann herunterladen?

Debian (Kali, Ubuntu, Raspbian)

Wir brauchen also eine Liste der fehlenden .deb Dateien, die apt für uns herunterladen und dann installieren würde.

Folgender Trick hat da bei mir funktioniert:

• Eine VM (oder ein Docker Container) wird so aufgesetzt wie das Zielsystem.
• Man löscht die Inhalte von Verzeichnis /var/cache/apt/archives.
• Anschließend startet man sudo apt install --download-only PACKNAME.
• Und schon liegen alle notwendigen .deb Dateien in /var/cache/apt/archives

Von dort kopiert man sie dann zum Zielsystem und führt folgendes Kommando aus:
sudo dpkg -i *.deb, welches die .deb Dateien installiert. Nachdem die Reihenfolge der Installation nicht definiert ist, kann es aber auch zu Problemen oder Scriptfehler kommen, die man dann mit
sudo apt-get install --fix-broken wieder hinbekommen kann.

RedHat, Alma, CentOS

Distributionen, die mit dem dnf Tool ihre .rpm Pakete verwalten, benötigen das Kommando:
dnf download PACKNAME --resolve
und schon liegen alle korrekt aufgelösten Abhängigkeiten als .rpm Dateien im aktuellen Verzeichnis.

Installieren kann man die Softwarepakete aus dem Verzeichnis dann mit
sudo rpm -ihv *.rpm

Fazit

Ich als Entwickler brauche immer wieder mal einen gdb auf einer Zielmaschine. Und wenn ich weiß, dass mein Kunde eine Debian 9 oder Alma 8 Variante im Einsatz hat, dann kann ich bei mir lokal genau die Bibliotheken vorbereiten und dann per SSH installieren, die zur Distribution passen.

Schwerer haben es da meine Dev-Ops Kollegen, die Datenbanken, Monitoring-Tools und Deployment-Werkzeuge auf unterschiedliche Kundenhardware verteilen müssen.

Zumindest gibt es für die gängigen Linux Varianten Hilfsmittel um solche Offline-Updates vorzubereiten.

Mein gutes (Update-) Werk ist für heute getan und somit kann ich beruhigt auf der Konsole exit eintippen.