Mehrere Ordner für die Ablage installierter DEB-Dateien

[Richard]

Hallo,

wenn ich über apt etwas installieren werden die Pakete in einem bestimmten Ordner, der mir gerade nicht einfällt, gespeichert und nach einer gewissen Zeit gelöscht. Ist es auch möglich zwei solcher Ordner in denen nach verfügbaren Paketen gesucht wird einzutragen? Wenn ja, wäre es dann möglich den zweiten auf einem zentralen Speicher im Netzwerk abzulegen? Dann könnten alle debian- und ubuntu-systeme die Pakete installieren wollen die noch nicht lokal - auf dem Rechner selbst - vorhanden sind vom netzwerkspeicher ziehen. Ist der netzwerkspeicher nicht verfügbar, wird nur der lokale geprüft und ggf. neu heruntergeladen.

Mir ist bewusst, dass es auch Programme für lokale paketquellen gibt, wie apt-cacher-ng. Andere spiegeln gleich die ganzen repos. Ganze repos kopieren ist Unsinn, bei apt-cacher-ng muss man dann IMMER über den Server auf dem es läuft installieren oder vorher manuell des proxy löschen. Ich hab es auf einem pi versucht, der ist zu schwach auf der Brust damit es produktiv läuft. Oder ich müsste vorher viele parallel laufende Dienste auf dem pi deaktivieren. Ich hab noch eine alte 160GB-platte, die ich an meine Fritzbox klemmen will.

Man könnte auch auf allen Systemen beim Boot ein syncacript einrichten um evtl. nur lokal vorhandene Pakete mit dem Netzwerk synchron zu halten.

Richard

[MSfree]

Vielleicht wäre approx etwas für dich:
https://en.wikipedia.org/wiki/Approx

[Richard]

So wie ich das sehe macht der das gleiche wie apt-cacher-ng mit all den Nachteilen. Ich brauche einen Server, was die Fritzbox als reinen datenserver ausschließt. Ich kann dann immer nur über den Server updates ziehen und wenn ich in einem anderen WLAN bin oder der Server nicht läuft muss ich die sources beim clienten manuell aendern.

Oder verstehe ich da etwas falsch?

[Lord_Carlos]

Es gibt transparente Proxies. Da muss nichts in der sources list angepasst werden. Die cachen dann alle .deb Daten die ein Klient im Netzwerk runterlaedt.
Es wird auch nur das gecached, nicht das ganze repo. Ist man auserhalb des Netzwerkes wird ganz normal vom Internet geladen.

[wanne]

was die Fritzbox als reinen datenserver ausschließt.

Du kannst dir sowas mit overlay-Dateisystemen basteln. Aber meine Fette Empfehlung: Lass die Finger davon. Gerade mit dem super unzuverlässigen Shares deiner Fritz!Box.
Lass die Finger von der Fritzbox für systemrelevante Komponenten. Was du dir mit solchen Setups mit kaputten Shares an Problemen rein holst sparst du nie durch weniger Downloadzeit ein.
Du kannst einen Doppelproxy aufbauen. Einen Proxy der lokal bei dir auf dem PC läuft und nicht cached und einen auf einem PI der lokale Proxy wird in APT konfiguriert und schaltet dann auf einen Internet-Mirror um sobald der auf dem PI nicht erreichbar ist. Für approx war ein Umschald Feature zumindest mal vorgesehen. Sonst kannst du sowas mit klassischen proxys erreichen. Ich würde lokal haproxy und zum Cachen apt-cacher-ng oder squid nehmen. Die können das auf jeden Fall.
Frage ist auch da in wie fern sich der Aufwand zum Einrichten lohnt.

[JTH]

Trifft anscheinend nicht genau deine Vorstellungen, aber vielleicht als Anregung:

Ich hab zuhause 3 Rechner stehen, auf einem davon ist apt-cacher-ng plus avahi-daemon installiert, auf allen dreien squid-deb-proxy-client. Letzteres installiert eigentlich nur einen Konfigurationsschnippsel für Apt, das bei jedem Aufruf von Apt nach einem lokalen Apt-Proxy/-Cache schaut und wenn vorhanden benutzt. Damit lässt sich bei großen Updates mal eben der Apt-Cacher dazwischenschalten (indem ich den einen Rechner hochfahre), ohne das die sources.list geändert werden muss. Da steht ganz normal deb.debian.org o.a. drin.

Das Ganze braucht wie erwähnt Avahi. Ich musste nichts besonderes konfigurieren, die Pakete installieren war schon alles.

[jph]

bei apt-cacher-ng muss man dann IMMER über den Server auf dem es läuft installieren oder vorher manuell des proxy löschen.

Einen Automatismus, der die Nutzung von apt-cacher-ng als Proxy auf den Clients in Abhängigkeit von der Netzwerkverbindung ein- oder ausschaltet, kannst du dir bspw. mit NetworkManager-Dispatcherskripten bauen. (Dir ist klar, dass apt-cacher-ng nur auf dem zentralen Cache, nicht aber auf den Clients installiert werden muss?)

[Richard]

Ich hab mal testweise apt-cacher-ng auf meinem desktop installiert und werde demnächst mal updates über den laptop versuchen. Ich hab auf dem desktop versucht die lokal gespeicherten Pakete zu apt-cacher-ng zu importieren, weiß aber nicht ob das klappte. Die DEB-dateien müssten dann doch im cache-verzeichnis liegen? Hab da nur unterordnet die irgendwann nur eine Textdatei enthalten.

Den proxy hab ich über apt eingerichtet, nicht in der sources.list. müsste aber auf das gleiche hinaus laufen, dass ich immer über apt-cacher-ng updaten müsste. Da wäre die oben beschriebene Variante über avahi besser, wenn ich das korrekt verstanden habe.

[jph]

Den proxy hab ich über apt eingerichtet, nicht in der sources.list. müsste aber auf das gleiche hinaus laufen, dass ich immer über apt-cacher-ng updaten müsste. Da wäre die oben beschriebene Variante über avahi besser, wenn ich das korrekt verstanden habe.

Korrekt, die sources.list lässt du unverändert. Der Proxy wird in der Datei /etc/apt/apt.conf.d/02proxy eingetragen:

Code: Alles auswählen

Acquire::http::proxy "http://proliant.fritz.box:3142";
Acquire::http::proxy::updates.signal.org "DIRECT"; 

Die erste Zeile sorgt dafür, dass grundsätzlich der Proxy verwendet wird. Die zweite Zeile weist apt an, den Proxy für updates.signal.org zu umgehen, da dort https verwendet wird.

Die Datei kannst du von einem Dispatcher-Skript schreiben lassen, das bspw. Zeilen per führendem # auskommentiert oder wieder aktiviert, je nachdem, in welchem Netz du dich aufhältst. Du kannst das Skript aus Netzlaufwerke einbinden als Grundlage nehmen.

[Richard]

Das heißt es wird nicht nur mit diesem proxy gehen auch bei bedarf ohne den Server upzudaten, ich brauche noch zusätzlich etwas, dass den proxy bei bedarf deaktiviert?

Wie ist das bei der weiter oben genannten Lösung über avahi? Ist das da auch nötig?

[Lord_Carlos]

Noch ne Loesung: apt-cacher-ng + eigener DNS funktioniert auch, ohne das was auf den Klienten eingestellt werden muss. Waere fuer mich das einfachste, da ich schon ein DNS server am laufen habe. (Pi hole)
Die avahi Loesung hoert sich auch gut an.

Viele Wege fuehren nach Rom.

[JTH]

Wie ist das bei der weiter oben genannten Lösung über avahi? Ist das da auch nötig?

Nein. Auf den Konsumenten des apt-cachers reicht es squid-deb-proxy-client zu installieren. Mehr Konfiguration oder Umkonfiguration bei Wechsel des LANs ist nicht nötig.

[Richard]

Hab nochmal nachgesehen. apt-cacher-ng speichert die Pakete unter /var/cache/apt-cacher-ng. Ich habe versucht die Pakete die schon abgelegt sind in apt-cacher-ng zu importieren. Der cache-ordner zeigt aber dennoch nur knapp ueber 200MB, es sollten aber deutlich mehr sein wenn jetzt wirkliche alle Pakete importiert wurden.

[Richard]

apt-cacher-ng scheint soweit zu gehen.

Squid ist ja eigentlich dazu da um Dateien lokal im Netzwerk zwischenzuspeichern, die irgendwann einmal beim surfen heruntergeladen wurden. Nicht speziell nur bei apt. Hier brauche ich normal einen Squid-Server und clienten.

Was ich bei der ganzen Avahi-Squid-Geschichte nicht verstehe: für mich klingt es so als sei es mit der i stallation beider Programme auf Server bzw. Client getan. Hier https://wiki.debian.org/AptCacherNg sieht es auch danach aus. Woher weiß der client mit squid, dass gerade dieser avahi-server es ist auf den er zugreifen soll?

Ich will auch eine Lösung haben, wenn eben der cache-server mal nicht läuft. Da schlägt ja sonst alles i.V. mit apt fehl, auch eine simple Installation eines Paketes.

[JTH]

squid-deb-proxy-client hat nicht viel mit Squid zu tun, hängt davon nicht ab. Es war der Beschreibung nach als Ergänzung zu Squid gedacht, funktioniert aber auch mit anderen Apt-Proxies.

Avahi erlaubts dir u.a. ohne Vorkonfiguration bestimmte Dienste/Server im lokalen Netz zu erkennen (und diesen Diensten, sich bekannt zu machen). Das nutzt apt-cacher-ng, um sich als Apt-Proxy bekannt zu machen.

squid-deb-proxy-client bringt ein Skript mit (/usr/share/squid-deb-proxy-client/apt-avahi-discover), das über Avahi nach einem Apt-Proxy im lokalen Netz sucht. Das wird für Apt zu Proxy-Auto-Erkennung festgelegt (/etc/apt/apt.conf.d/30autoproxy). Wenn ein Proxy läuft, wird er damit von Apt benutzt. Wenn keiner läuft, wird kein Proxy benutzt. Das Skript kannst du zum Verständnis manuell aufrufen, es gibt, wenn Apt-Proxy vorhanden, einfach eine Zeile mit Acquire::http::Proxy (siehe man apt.conf) aus.

Ich will auch eine Lösung haben, wenn eben der cache-server mal nicht läuft.

Genau das tut das Ganze. Wenn dein Cache-Server nicht läuft, lädt jeder Rechner die Deb-Pakete ganz normal selbst runter.

[Richard]

OK, scheint auch ohne Konfiguration zu gehen. Das Script gibt mit aber die IPv6-Adresse des Servers aus, das ist etwas strange.

[Richard]

In der config gibt es den Punkt "ExTreshold". Im UU-Wiki steht dazu

Tage, bevor ein Paket, welches aus keiner Paketquelle verfügbar ist, gelöscht wird.

Heißt das, dass wenn ich Paket im cache in einer paketquellen im Internet nicht mehr verfügbar ist, es gelöscht wird? Das würde bedeuten, dass bei jedem update auf dem Server oder einem clienten geprüft wird ob die Pakete noch vorhanden sind?

Hätte es denn Sinn auch einen raspberry pi ala client ei zu binden oder bringt das wenig? Immerhin sind das alles Pakete für arm und meine anderen Rechner alle normal intel-cpus.

[MSfree]

Code: Alles auswählen

Tage, bevor ein Paket, welches aus keiner Paketquelle verfügbar ist, gelöscht wird.

Heißt das, dass wenn ich Paket im cache in einer paketquellen im Internet nicht mehr verfügbar ist, es gelöscht wird?

Es heißt, daß ein Paket, daß seit soundsoviel Tagen nicht mehr in einer Paketquelle verfügbar ist, gelöscht wird. Steht dort 10 Tage, wird es 10 Tage, nach dem es aus den Repositories verschwunden ist, auch im Cache gelöscht.

Gelegendlich "verschwinden" Pakte auch mal für ein kurze Zeit aus den Repositories. Das sind in der Regel nur Timingprobleme, z.B. wenn der Build eine Paketes noch nicht fertig war, als die Mirrors synchronisiert wurden. Am nächsten Tag sind sie in der Regel schon wieder verfügbar. In solchen Fällen greift dann die "Tage"-Regel oben.

Das würde bedeuten, dass bei jedem update auf dem Server oder einem clienten geprüft wird ob die Pakete noch vorhanden sind?

Es wird die Paketliste runtergeladen und aus der Paketliste geprüft.

Hätte es denn Sinn auch einen raspberry pi ala client ei zu binden oder bringt das wenig?

Wie immer: es kommt drauf an:

• auf die Anzahl der Rechner, die du aktuell zu halten hast
• auf die Anzahl der Architekturen
• auf die Geschwindigkeit deines Internetzugans

Je mehr Rechner du zu aktualisieren hast, desto mehr bringt der Cache. Je schneller dein Internetzugang ist, desto weniger bringt der Cache. Wer 100 Rechner aktuell zu halten hat und das mit einer grottigen 2MBit/s DSL-Leitung machen muß, braucht unbedingt den Cache, weil er es sonst überhaupt nicht schaffen würde, die Rechner aktuell zu halten. Wer nur 2 Rechner an einer 400MBit/s Leitung aktuell halten will, kann sich den Cache sparen, der bringt hier praktisch gar nichts. Für alle anderen Situationen muß man es halt ausprobieren.

Immerhin sind das alles Pakete für arm und meine anderen Rechner alle normal intel-cpus.

Der Cache cached die Pakete, die einmalig beim Upgrade eines Rechners runtergeladen wurden. Wenn ich das mit einem Mac mit PowerPC Architekture mache, sind Pakete für den PowerPC im Cache. Wenn ich anschließend meine Sun mit Sparc Architektur aktualisiere, lädt er die Sparc-Pakete zusätzlich in den Cache. Anschließend aktualisiere ich noch meine SGI mit MIPS Architektur und habe dann die dritte Architektur im Cache. Danach kommen noch mein Raspberry Pi, mein Core-i3/64 und mein EeePC mit Intel/32 in den Cache. Insgesamt liegen dann also 6 Architekturen im Cache. Dumm nur, daß dabei nicht ein einziges Paket zweimal benutzt wurde, der Cache ist in dieser Konstellation also komplett sinnlos.

Ob der Rechner, der den Cache hält nun Intel, ARM, MIPS, PowerPC oder DEC Alpha ist, spielt überhaupt keine Rolle.

[Richard]

Ich musste jetzt mein Linux auf meinem Notebook neu installieren wegen eines HDD-Crashs. Hab da jetzt wieder Squid installiert und bin unsicher ob er die Verbindung zum Server herstellt. Kann ich das irgendwie testen? An den Downloadzeiten der Pakete bei apt kann ich das nicht sagen, da ich nicht sicher bin ob der apt-cacher-ng-Server die nicht zwischenzeitlich gelöscht hat, ich installiere ja alles komplett neu und mache nicht nur Updates.

[JTH]

Du kannst das dahintersteckende Skript selbst ausführen:

Code: Alles auswählen

$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 
http://192.168.178.xyz:3142/

Wenn dabei eine Ausgabe kommt, wird apt beim Benutzen den Cache benutzen. Wenn keine Ausgabe kommt – dann wurde kein Cache im lokalen Netz gefunden.

[Richard]

Da kommt

Code: Alles auswählen

./test: Zeile 1: $: Befehl nicht gefunden
./test: Zeile 2: http://192.168.10.21:3142/: Datei oder Verzeichnis nicht gefunden

Was läuft da falsch? Ich bin genauso vorgegangen wie beim letzten Versuch.

[JTH]

Ähäm, hast du meinen Beitrag eins-zu-eins kopiert? Das ist natürlich verkehrt. Ich hatte den Aufruf plus mögliche Ausgabe gepostet

Das $ soll dir sagen, dass du das Kommando dahinter nicht als root ausführen musst. Steht eine # am Anfang, brauchst du Rootrechte für ein Kommando.

Nochmal das Ganze vollständiger, falls besser verständlich:

Code: Alles auswählen

user@hostname:~$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 
http://192.168.178.28:3142/
user@hostname:~$

[Richard]

Ja, jetzt geht es. Cache wird benutzt.