© Robert McIntyre, 123RF.com

Ob auf dem Land, im hochsicheren Serverraum oder einfach in der Urlaubswohnung – manche Rechner sehen nie, selten oder nur sehr, sehr langsam die Weiten des Internets. Um solche Maschinen auf den aktuellen Stand zu bringen oder zu halten, braucht der Admin Update-Datenträger.

Einsame Rechner haben vielleicht aus Sicherheitsgründen wie eine Insel gar keine Internetverbindung oder nur schwachbrüstige ISDN- oder GSM-Links, über die das schnell Hunderte von MByte umfassende Update einer Distribution überhaupt keinen Spaß macht.

Als Ausweg bietet es sich an, eine CD, DVD oder einen USB-Stick zu erstellen und damit die Zivilisation der Insel zu bewahren. Das Update gelingt mit allen Distributionen, doch der Aufwand dafür ist unterschiedlich und reicht vom einfachen Copy- oder Wget-Befehl bei den freien Community-Distributionen bis zum Aufsetzen und fortwährenden Pflegen eines identischen Systems oder gar eines teuren Update-Servers für Red Hats Enterprise Linux.

Debian: Aptoncd bringt GUI

Als die einzigen Distributionen im Vergleich können Debian-basierte Systeme auf ein maßgeschneidertes Tool zurückgreifen: Aptoncd [1]. Es eignet sich nicht nur dazu, Update-Datenträger zu erstellen, sondern erlaubt es dem Admin sogar, Backups der installierten Pakete eines Systems zu erstellen. Die DVD enthält dann alle Deb-Dateien, die auf dem lokalen System installiert sind, was auch das Klonen oder Neuinstallieren stark vereinfacht. Der (idealerweise identische) Quellrechner braucht auf jeden Fall Internetanschluss. Er holt – wie auf Debian-Systemen üblich – via »aptitude update« und »upgrade« seine Pakete und hält sie unter »/var/cache/apt/archives« vor – zumindest so lange, wie sie der Admin dort nicht löscht, etwa mit »apt-get clean« .

Das Installieren zieht auf einem Ubuntu Quantal Quetzal knapp 20 MByte an Paketen nach sich, die der Admin des nicht mit dem Netz verbundenen Systems von Hand herunterladen, kopieren und mit Dpkg installieren muss:

aptitude install aptoncd[...]
aptdaemon-data{a} aptoncd gir1.2-atk-1.0{a}gir1.2-freedesktop{a} gir1.2-gdkpixbuf-2.0{a} gir1.2-gtk-3.0{a} gir1.2-pango-1.0{a} gir1.2-vte-2.90{a}gnome-user-guide{a} libcairo-perl{a} libgail-3-0{a} libglib-perl{a} libgtk2-perl{a} libjavascriptcoregtk-3.0-0{a} libpango-perl{a} librarian0{a} libvte-2.90-9{a} libvte-2.90-common{a} libwebkitgtk-3.0-0{a} libwebkitgtk-3.0-common{a} libyelp0{a} python-central{a} python3-aptdaemon.gtk3widgets{a} rarian-compat{a} software-properties-gtk{a} synaptic{a} yelp{a} yelp-xsl{a}

Nach dem Start von Aptoncd hat der Anwender die Wahl zwischen Erstellen und Wiederherstellen, Abbildung 1 zeigt das Auswahlmenü der Updates, die das Tool in »/var« gefunden hat. »Brennen« erstellt die CD, DVD oder das ISO-File (was der folgende Dialog genauer definiert).

Abbildung 1: Aptoncd baut eine CD aus den Updates des lokalen Systems.

Die fertige DVD legt der Admin dann auf dem Inselsystem ein, startet Aptoncd und wählt den Eintrag »Wiederherstellen« . Übers Menü lässt sich hier der Datenträger auch gleich als Repository eintragen, so sind auch nur einzelne Pakete über die gängigen Tools installierbar – allerdings entstehen dabei schnell unübersichtlich viele Einträge in »sources.list« , nämlich einer pro Update-DVD.

Prinzipiell ginge es natürlich auch ohne Aptoncd, also einfach alle Pakete aus dem »/var« -Unterverzeichnis des identischen Systems auf einen USB-Stick kopieren oder in eine DVD brennen, doch die Integration des Tools macht vieles einfacher, etwa die Auswahl der zu aktualisierenden oder zu installierenden Pakete.

Suse: Repository spiegeln

Auf einen zweiten, identischen Rechner kann der Suse-Anwender getrost verzichten, wenn er bereit ist eine größere Datenmenge zu transportieren: Wer seine Offline-Maschine im Outback mit aktuellen Paketen versorgen will, braucht nur das betreffende Verzeichnis auf einem FTP- oder HTTP-Server von Suse [2] zu spiegeln, am besten mit Tools wie Wget und dessen Rekursivoption »-r« . Für Suse 12.2 heißt das:

wget -r http://download.opensuse.org/update/12.2/Architektur

Den so erhaltenen, sehr umfangreichen Dateibaum kann er entrümpeln und einfach auf eine DVD brennen – eine CD dürfte hier nicht mehr reichen – oder auf einen größeren USB-Stick kopieren und dem Offline-System mit Zypper (»-ar Pfad_zur_DVD« ) oder Yast als Repository zur Verfügung stellen. Beim nächsten Update gelangen so alle Aktualisierungen auf das Inselsystem.

Alternativ ließen sich auch hier alle auf einem identischen System gecachten Updates aus »/var/lib/rpm« auf einen Datenträger kopieren und später mit Rpm oder Zypper installieren. Ähnliches gilt für Fedora oder Cent OS.

Red Hat

Bei Red Hat sorgt der Network Satellite Server für Aktualisierungen, doch auch ohne ihn gelingen Offline-Updates. Allerdings braucht der Admin Zugriff auf einen Satelliten, denn sonst gibt es keine Pakete – die Updates machen schließlich einen wesentlichen Bestandteil von Red Hats Geschäftsmodell aus – und eine RHEL-Installation mit der gleichen Versionsnummer.

Dann helfen Tools wie der Yumdownloader: »yum install yum-downloadonly createrepo« installiert das Werkzeug, ein anschließendes »yum clean all« räumt die lokale Paketlandschaft auf. Die Anleitung aus dem Knowledge-Center [3] erläutert alle Details, die wesentliche Arbeit erledigen drei Befehle:

yumdownloader --resolve `rpm -qa` --destdir/tmp/rpm_updates
yum update --downloadonly --downloaddir/tmp/rpm_updates
createrepo /tmp/rpm_updates

Sie erzeugen das lokale Repository mit den Updates, die sich dann unter »/tmp/rpm_updates« finden und von dort per Stick, DVD oder lokales Netz auf die Offline-Maschine übertragen lassen.

Jetzt noch die Dateien für die Repositories anpassen (Listing 1) – und schon steht einem »yum upgrade« auf dem Inselsystem nichts mehr im Wege.

01 [rhel-offline-updates]
02 name=Red Hat Enterprise Linux $releasever - $basearch - Offline Updates Repository
03 baseurl=file:///tmp/rpm_updates
04 enabled=1
05 EOF