Pakete für Offline-PC

[debianx]

Hallo,

zur Offline-installation von Paketen speichere ich auf einem Online-PC derzeit die Downloadliste und lade Sie runter um sie dann auf dem offline PC zu installieren.
Ein Nachteil hat das aber und zwar darf das Paket/Programm auf dem Online-PC wohl NICHT installiert sein.
Meine Frage ist: Wie kann ich die Pakete herunterladen, sodass sie auf den Paketstatus des offline-PC abgestimmt ist also unabhängig vom Online-PC?
Mein aktueller Vorgang ist bisher so:

- speichere downloadliste: apt-get -y install --print-uris package-name | cut -d\' -f2 | grep http:// > downloadliste
- lade dateien runter die in liste stehen: wget -i downloadliste
- kopiere die daten auf datenträger
- Gehe zum Offline-PC und installiere dort die Pakete: sudo dpkg -i *.deb

Ziel wäre zudem, mal abgesehen von Programminstallationen, so auch die Sicherheits-Updates machen zu können. Insofern müsste wohl die Erstellung der Downloadliste irgendwie auf den Paketstatus des Offline-PCs abgestimmt sein. Wie wäre es möglich Paketinstallationen sowie Updates abgestimmt auf den Offline-PC herunterzuladen?

Grüße

[eggy]

- speichere downloadliste: apt-get -y install --print-uris package-name | cut -d\' -f2 | grep http:// > downloadliste

Mach den Schritt anfangs auf dem Offline PC, kopier die Liste auf den OnlinePC und dann den Rest wie beschrieben.

[letzter3]

Und woher soll der offline PC wissen, welche Updates verfügbar sind?

[smutbert]

Wenn du zumindest einmal vorübergehend eine Verbindung zum Internet herstellen kannst, wäre eventuell apt-offline eine Lösung:
https://wiki.ubuntuusers.de/apt/apt-offline/

Ich habe, als ich einmal in der Situation war, die offline-Installation auf einen USB-Stick geklont und dann mit chroot auf einem System mit Internetverbindung die Pakete heruntergeladen/installiert (apt-get kennt den Schalter -d damit die Pakete nur heruntergeladen, aber nicht installiert werden).

[inne]

Such mal nach apt-mirror und Repository auf einer externen USB-Festplatte. Denke das ist eine Lösung.

[eggy]

Und woher soll der offline PC wissen, welche Updates verfügbar sind?

aehm ups

[debianx]

Danke ich werde mir apt-mirror mal ansehen.

[debianx]

Noch eine Frage, geht bei apt-mirror die Signaturprüfung verloren?, konnte dazu nichts finden.
Grüße

[inne]

Ich kanns nicht mit Gewissheit sagen, vermute aber da zur Installation weiterhin die Paketverwaltung/APT verwendend wird, sollte auch die Archivauthentifizierungsunterstützung für APT zum Zuge kommen. Aber apt-mirror selbst prüft glaube ich nicht.

[debianx]

Ich versuche jetzt doch nochmal die Downloads selektiv auf den Zielcomputer abzustimmen.
Meine Idee wäre alle Pakete herunter zu laden die auf dem Zielcomputer installiert sind um damit dann offline "apt update" und "apt full-upgrade" durchzuführen (Programme sowohl Sicherheitsupdates).

1. Alle auf dem Zielcomputer installierten Programme in Datei speichern.
Gefunden dazu habe ich: dpkg -l | grep ii > programme

2. Auf dem Onlinecomputer die Programme in dieser Liste herunterladen.
Gefunden dazu habe ich apt-get download
damit sollte denke ich auch das Thema Signaturprüfung ok sein.

3. Die Downloads dann wieder auf den Zeilcomputer ziehen und damit dort die Updates machen (Programme sowohl Sicherheitsupdates).

Soweit die Idee.
Probleme hab ich jetzt noch bei Punkt 2: wie kann ich "apt-get download" auf Basis der Downloadliste von Punkt 1 durchführen? (Denn die Liste beinhaltet zb auch mehr als nur die Paketnamen...)
Und bei Punkt 3: wie mache ich "apt update" und "apt full-upgrade" auf Basis der heruntergeladenen Dateien?

viele Grüße

[MSfree]

Und bei Punkt 3: wie mache ich "apt update" und "apt full-upgrade" auf Basis der heruntergeladenen Dateien?

Genau an dem Punkt wird es haken, wenn du apt-get nur ein Verzeichnis mit runtergeladenen deb-Dateien vorwirfst. Ohne es genau zu wissen, sagt mir mein Bauch, daß das, was du vorhast, zwar die Anzahl der runterzulandenden deb-Dateien minimiert, es wird aber nicht mit apt-get, apt oder aptitude zusammenspielen.

Ich habe selbst einen kompletten Debianmirror, den ich auch dazu benutze, den Server, der den Mirror hält, selbst zu aktualisieren. In meiner /etc/apt/sources.list steht:

Code: Alles auswählen

deb file:/pub/mirror/debian/ jessie main contrib non-free
deb file:/pub/mirror/debian/ jessie-backports main contrib non-free
deb file:/pub/mirror/debian-security/ jessie/updates main contrib non-free

Wobei das Verzeichnis /pub/mirror/debian eine Verzeichnis auf meiner Festplatte ist, unter dem der Mirror mit seiner kompletten Verzeichnisstruktur liegt, das Verzeichnis könnte aber genauso gut eine USB-Platte unter /media sein.

Du könntest also eine USB-Platte an einen Online-Rechner hängen, mittels apt-mirror aktualisieren, die USB-Platte an den Offline-Rechner stecken und dort mit apt-get update und apt-get upgrade und entsprechend angepaßter sources.list aktualisieren.

[inne]

Du könntest also eine USB-Platte an einen Online-Rechner hängen, mittels apt-mirror aktualisieren, die USB-Platte an den Offline-Rechner stecken und dort mit apt-get update und apt-get upgrade und entsprechend angepaßter sources.list aktualisieren.

So wäre das gedacht und dazu gab es auch mal ein Anleitung in den Weiten des Webs, aber da schaut es Heute wohl mau mit aus.

[MSfree]

So wäre das gedacht und dazu gab es auch mal ein Anleitung in den Weiten des Webs, aber da schaut es Heute wohl mau mit aus.

Naja, wie man (auf dem Onlinerechner) einen apt-mirror einrichtet, ist im Web doch leicht zu finden, die Stichworte apt-mirror example in eine Suchmaschine des geringsten Mißtrauens eingegeben, führt einen schon auf die richtigen Seiten.

Viel mehr, als base_path in der /etc/apt/mirror.list auf die USB-Platte zeigen zu lassen statt auf /var/spool/apt-mirror, ist da ja nicht zu machen. OK die Distribution und die Architektur muß noch ausgewählt werden und die deb-sources kann man sich auch sparen, um den Mirror nicht ausufernd groß werden zu lassen. Mein Mirror belegt 800GiB für oldstable, stable, testing und SID jeweils in amd64 und x86 inklusive deb-sources. Ein Mirror, der z.B. nur stretch/amd64 spiegelt, dürfte unter 200GiB liegen.

Wie man die sources.list auf dem Offlinerechner anpaßt, habe ich ja oben schon angedeutet. Man verwende einfach die file: Direktive und lasse die Pfade auf den Mountpunkt plus Unterverzeichnis der angesteckten USB-Platte zeigen, und schon funktioniert das.

Der einzige Nachteil, der durch apt-mirror entsteht, ist, daß man relativ viel Plattenplatz für nicht genutzte Pakete benötigt. Das macht das erste Download des Mirrors zeitaufwendig. Danach werden aber wie mit apt-mirror (ähnlich rsync) nur noch neuere Pakete beim Aufruf übertragen. Für stable und oldstable hält sich das Datenvolumen in Grenzen, diese Distributionen ändern sich ja nur in geringem Umfang.

Der Vorteil ist, daß man durch den kompletten Mirror auf dem Offlinerechner Software nachinstallieren kann, ohne daß einzelne Pakete separat runterladen und per USB-Stick rüberkopieren werden müßten, wegen Abhängigkeiten ggfls. sogar mehrfach.

[MSfree]

So wäre das gedacht und dazu gab es auch mal ein Anleitung in den Weiten des Webs, aber da schaut es Heute wohl mau mit aus.

Naja, wie man (auf dem Onlinerechner) einen apt-mirror einrichtet, ist im Web doch leicht zu finden, die Stichworte apt-mirror example in eine Suchmaschine des geringsten Mißtrauens eingegeben, führt einen schon auf die richtigen Seiten.

Viel mehr, als base_path in der /etc/apt/mirror.list auf die USB-Platte zeigen zu lassen statt auf /var/spool/apt-mirror, ist da ja nicht zu machen. OK die Distribution und die Architektur muß noch ausgewählt werden und die deb-sources kann man sich auch sparen, um den Mirror nicht ausufernd groß werden zu lassen. Mein Mirror belegt 800GiB für oldstable, stable, testing und SID jeweils in amd64 und x86 inklusive deb-sources. Ein Mirror, der z.B. nur stretch/amd64 spiegelt, dürfte unter 200GiB liegen.

Wie man die sources.list auf dem Offlinerechner anpaßt, habe ich ja oben schon angedeutet. Man verwende einfach die file: Direktive und lasse die Pfade auf den Mountpunkt plus Unterverzeichnis der angesteckten USB-Platte zeigen, und schon funktioniert das.

Der einzige Nachteil, der durch apt-mirror entsteht, ist, daß man relativ viel Plattenplatz für nicht genutzte Pakete benötigt. Das macht das erste Download des Mirrors zeitaufwendig. Danach werden aber wie mit apt-mirror (ähnlich rsync) nur noch neuere Pakete beim Aufruf übertragen. Für stable und oldstable hält sich das Datenvolumen in Grenzen, diese Distributionen ändern sich ja nur in geringem Umfang.

Der Vorteil ist, daß man durch den kompletten Mirror auf dem Offlinerechner Software nachinstallieren kann, ohne daß einzelne Pakete separat runtergeladen und per USB-Stick rüberkopiert werden müßten, wegen Abhängigkeiten ggfls. sogar mehrfach.

[debianx]

ok ein Versuch wars nochmal Wert aber dann ist apt-mirror scheinbar die saubere und beste Sache dafür. Anleitungen hab ich auch inzwischen einige gefunden das sollte passen.
Jetzt aber nochmal ganz paranoid gefragt, wenn apt-mirror alles per http runterzieht können die Daten auf dem Weg nicht manipuliert werden?
apt-get per http soll scheinbar über eine Signaturprüfung ok sein (wie auch immer das funktioniert) aber wie ist das mit apt-mirror?
Wäre es besser bei apt-mirror das http der Quellen dann durch ein https zu ersetzen?

[inne]

Die Prüfung passiert erst mit apt/apt-get beim installieren. Aber wenn apt-mirror mit https funktioniert, wäre das zu empfehlen.

[MSfree]

Wäre es besser bei apt-mirror das http der Quellen dann durch ein https zu ersetzen?

Ich weiß nicht, ob https überhaupt unterstützt wird. Wenn ja, dann kann es nicht schaden.

Der Mirror aber beinhaltet Dateien mit Prüfsummen und GPG-Schlüsseln. Beides wird von der apt-Familie genutzt, um die Integrität der Debianpakete zu verifizieren.

[debianx]

Danke, also bedeutet das apt/apt-get kann auch offline von einer beliebigen Quelle kompromittierte Pakete erkennen und die Installation solcher verhindern?

[MSfree]

Danke, also bedeutet das apt/apt-get kann auch offline von einer beliebigen Quelle kompromittierte Pakete erkennen und die Installation solcher verhindern?

Im Prinzip ja. Theoretisch könnte ein Angreifer natürlich während der Übertragung zum Onlinesystem Debianpakete manipulieren, neue Prüfsummen berechnen und in die Prüfsummendatei speichern und mit einem gefälschten GPG-Schlüssel signieren. Am Ende müßte noch der gefälschte Schlüssel auf dem Offlinerechner unter /etc/apt/trusted.gpg.d ersetzt werden, gegen die die Signaturen geprüft werden. Vor allem der letzte Schritt dürfte bei einem Offlinesystem fast unmöglich zu bewerkstelligen sein.

[inne]

Könnte man nicht dscverify über den Pool von deb-mirror laufen lassen? Es muss dann nur das Paket debian-kering vertrauenswürdig und in der entsprechenden Version installiert sein.