Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe 
allgemeine Kategorie => Welches Linux-Programm verwende ich anstelle von xyz (Windows)? => Thema von: Sebastian am 06. Oktober 2023, 17:11:22
Titel: Pacoloco - caching proxy server für pacman
Beitrag von: Sebastian am 06. Oktober 2023, 17:11:22
Pacoloco ist ein Webserver, der als Arch Linux Pacman-Repository fungiert. Jedes Mal, wenn der Pacoloco-Server eine Paketanfrage vom Client erhält, lädt er dieses Paket vom echten Arch Linux-Mirror herunter und leitet diese zum Client weiter. Darüber hinaus speichert Pacoloco das Paket im lokalen Dateisystem-Cache und stellt dieses zukünftigen Clients zur Verfügung. Pacoloco ermöglicht auch, Updates der zuletzt verwendeten Pakete vorab selbst, ohne Benutzeranfrage regemässig abzurufen.

Wofür brauch man sowas?

Stellt euch eine Situation vor, in der mehrere Pacman-Benutzer über ein schnelles lokales Netzwerk verbunden sind. Jeder dieser Benutzer muss denselben Dateisatz herunterladen. Pacoloco ermöglicht es, die Internet-Traffic zu minimieren, indem die Pakete zwischengespeichert werden und über ein schnelles lokales Netzwerk bereitgestellt wird.

Pacoloco spiegelt nicht das gesamte Arch-Repository wider. Es lädt nur Dateien herunter, die von lokalen Benutzern benötigt werden. Ihr könnt euch Pacoloco als einen Lazy-Arch-Mirror vorstellen.

Weitere Informationen:

Paket: extra/pacoloco (https://archlinux.org/packages/extra/x86_64/pacoloco/)
Homepage: https://github.com/anatol/pacoloco
Arch Wiki: https://wiki.archlinux.org/title/Pacman/Tips_and_tricks#Pacoloco_proxy_cache_server



@Andreas

Bei dem Proxy musste ich sofort an dein Schulprojekt denken. Vielleicht hilft das bei der Paketverteilung im Schulnetzwerk.
Titel: Re:Pacoloco - caching proxy server für pacman
Beitrag von: Andreas am 07. Oktober 2023, 06:48:21
Danke für dein "entdecken" Sebastian. Das Projekt erfüllt die Aufgabe die ich dort habe nicht so wie ich es will - ich habe mir dazu ein eigenes Bash-Script zusammengehämmert das auf repo-add beruht. Ich muss mit dem lokalen Repo auf unserem Schulserver zwei Aufgaben erfüllen:
  • ein lokales Repo alles Pakete aus den "normalen Repos" vorhalten
  • alle fertig gebauten Pakete aus den AURs als fertiges Paket vorhalten
    • Das letzte ging damit nicht - also wie schon mal an anderer Stelle gesagt: "die grauen Zellen vorglühen und schöpferisch werden".

    LG
    Andreas
Titel: Re:Pacoloco - caching proxy server für pacman
Beitrag von: Sebastian am 07. Oktober 2023, 09:28:23
Der zweite Punkt würde in Kombination mit deiner Variante gehen (falls man Traffic und Speicherplatz sparen möchte). Indem dein selbst gebautes Repo (mit repo-add) auf selbst gebaute AUR Pakete beschränkst. Dann könnte pacoloco die Arch Pakete von Arch-Mirrors holen, und deine AUR Pakete holt sich pacoloco dann von deinem lokalen Repo.

Dann sind offizielle Arch Pakete von AUR Paketen auf Repository Ebene voneinander getrennt. Und man hätte den vorher genannten Vorteil, dass man Traffic und Speicherplatz spart. Für die Mirror Liste der normalen Repositorys kann pacoloco auch weiterhin auf eine Mirrorliste, die von reflector erstellt wurde zurückgreifen. Somit lässt sich dann auch die "normalen Repos" Mirrors automatisiert managen.

Man müsste nur daran denken die Option purge_files_after für die lokalen Repositorys auf einen sehr kurzen wert einzustellen. Damit pacoloco die Pakete nicht unnötig lang cached und somit der Speicherplatz gewinn wieder verloren geht. Lokale Repos bzw. Repos, die sich schon im LAN befinden, müssten ja nicht noch mal gecacht werden.

Man könnte auch die lokalen Repositorys die sich im LAN befinden natürlich auch ganz von pacoloco außen vor lassen. Und den Clients mitteilen, wo sich das Repo befindet. Dies hätte dann aber den Nachteil, dass, wenn sich die URI zum Repository ändert, dass diese Änderung an allen Clients vorgenommen werden müsste.

Falls doch mal eine Anpassung an einem Paket aus den "normalen Repos" nötig sein sollte. So könnte man dafür ein weiteres Repo erstellen (z.B. [arch-adjustments]) und das einfach vor den "normalen Repos" in der pacman.conf einbinden.

Dann wären die Pakete thematisch in Repositorys aufgeteilt, und man könnte einfacher auch für einzelne Clients die Paketprioritäten aus den einzelnen Repositorys beeinflussen.

Ist aber auch nur so eine Idee von mir, wie ich das aufteilen würde, falls ich sowas mal bräuchte.

LG
Sebastian
Titel: Re:Pacoloco - caching proxy server für pacman
Beitrag von: Andreas am 07. Oktober 2023, 17:13:48
Ich möchte auf den Clients einfach mit "pacman -Syu" alles updaten - auch die Pakete die eigentlich aus den AURs kommen. Dazu liegt auf meinem Server ein lokales Repo das alle installierten Pakete aus den Standard-Repos und alle selbst gebauten Pakete aus den AURs enthält (natürlch in der jeweils aktuellsten Version). Damit brauche ich nur auf dem Server(der auch alle installierten Pakete der Clients hat) ein yay -Syu zu machen- danach werden alle neuen Pakete (egal ob gebaut oder heruntergeladen) in das lokale Repo geschoben, die älteren Versionen dazu gelöscht und die Repo-Datenbank neu gebaut. Auf den Clients reicht dann ein pacman -Syu und das geht ratze-fatze. Der Server hat zwei CPUs mit jeweils acht Kernen und 32GB RAM - da geht das Bauen fix, auch bei umfangreichen Paketen. Die Clients haben nur vier Kern Prozessoren und 2GB RAM - Bauen macht da keinen Spaß.

LG
Andreas
Titel: Re:Pacoloco - caching proxy server für pacman
Beitrag von: Sebastian am 07. Oktober 2023, 20:54:45
Wie bereits gesagt, ist dies möglich, dabei kann sich dein lokales Repo, auf die AUR Pakete beschränken. Bauen musst du diese ja sowieso vorher, um diese im Repo abzulegen. Auf dem Client reicht weiterhin ein normales "pacman -Syu" wenn die Repos dort in der pacman.conf eingetragen sind, als Mirror wird dann für jedes Repo dann pacoloco angegeben, damit dieser als Proxy fungieren kann.

In meinem Beispiel hatte ich noch ein weiteres selbst erstelltes lokales Repo mit angeben, falls man die richtigen Arch Pakete anpassen möchte. Dann können diese Pakete mithilfe der Repo Position in der pacman.conf eingespielt werden, indem diese eine höre Priorität bekommen. (Dies ist optional)

Um das besser zu veranschaulichen, habe ich ein Sequence Diagramm (https://mermaid.ink/svg/pako:eNqVVMtu2zAQ_JWFbkUk5y4UAQSnBQr0ISTIyTKCFbWSWVOkykcTJ8jf9Bt6ys0_1qUtxWnjBohOArkzOzNL8j4RpqEkTxz9CKQFnUvsLPaVrvSA1kshB9Qe5oAO5kqS9pWuzS1ckv1J9tSB7OFz8bXSwN9zRBkRJQqjjDAvt4uri1iwwGCXR3aL_aYVqwyb78H5njs7riTd_K2s2PFcDc5bwh4Wwlhapgu69RaXKSz6oLxUsl6-r-0ZkBczYBsd6aj8k_ZkNfloVxtPYNgUlGlR5E_aU2gmoRB0c0QVXNBg0si_3v7WLBGcFCvA0EJDPThSNa_tE4P67mYWE4OaWqkb0rMIPDfWw4TGwOhG0i6kEtfEwtrtoz0I2XmJXaGjGoOHG7KR6rmLeQ7nzBGrjkWZTlHBf7Lae42uHesEqdmM5SmJHvVMGN0CSd0RQ7vRBHxwsEatWY3kXFcRgnb7WDMu2imtNFb67S8PyMgBnXtSHvGFcvBFWmvsuLp3jUpNNqKCaS5MZ243EceNuJ2izs_iIOfZ2dlJmY9SIbvchJfT_TjluUvx1ek6oxSD2S2sg72j2HKOYkWMD0x4MPht8NJoGILt6LqVitw1tixtDC8CT_kEng6jhdkGewUH-Ycxltm7E55-Po1_zCPG1vKFtXxieTvL3mXlvzV3oYedPM2HQyEvjXTFq2zF28hel_YWZVw5P1q5e21iZh05sZJi7ZM06cn2KBt-se7js1ElfkU9VUnOv3zY1lVS6Qeu40thLjdaJLm3gdIkDA366XVL8haVo4c_JVLIwA) erstellt. Vielleicht wird das dadurch klarer.

Wenn ich das richtig verstanden habe, ist der Unterschied zwischen meinen und deinem vorgehen der, dass du ein großes Repository hast, wo drin sich alle Arch Pakete (hoher Traffic/speicherplatz verbrauch, weil auch nicht gebrauchte Pakete gespigelt werden) und eine Auswahl an AUR Pakten drin befinden. Damit hast du auf dem Client, nur dein Repo in der pacman.conf worüber alle Pakete gezogen werden.

Bei meinem Vorschlag bleibt die Trennung zwischen den Upstream Arch Repos den selbst gebauten AUR Paketen und dem angepassten Arch Paketen erhalten. Was eine Priorisierung der Pakete auf einzelnen Clients ermöglichen könnte (wenn man es brauch). Zudem werden durch pacolocos Eigenschaften als lazy Mirror nur die benötigten Pakete aus dem Upstream Arch Repos gezogen und nicht alle, das Traffic und Speicherplatz spart.

Beides hat vor und Nachteile, mein Vorschlag wäre bei der Einrichtung etwas komplexer, da pacoloco vorher eingerichtet werden muss. Dafür ist man im Nachhinein bei den einzelnen Clients flexibler, wenn ein anderes Paket unter demselben Namen installiert werden soll + der anderen erwähnten vorteile.
Titel: Re:Pacoloco - caching proxy server für pacman
Beitrag von: Andreas am 08. Oktober 2023, 07:04:16
Auch bei mir werden nur die benötigten Pakete gespiegelt. Der Server und die Clients unterscheiden sich nur in einer Handvoll Pakete (die zusammen maximal 1GB Plattenplatz benötigen). Alle anderen Pakete gibt es sowohl auf dem Server als auch auf den Clients - es werden nur unterschiedliche Dienste auf beiden gestartet. Die Installation eines neuen Clients geschieht so auch "komplett offline" vom Server - dort sind alle Dinge für einen Client vorhanden. Damit beschränkt sich der Traffic komplett auf das interne Netz - da wäre er so oder so. Die Prio ist natürlich so gesetzt, dass das lokale Repo die höchste hat. Und es wird immer nur die letzte Version gecacht - möchte man eine ältere dann muss man downgraden, und das kann auch von Außen geschehen. Das Repo ist jetzt 14GB groß, was bei 8TB Speicherplatz irrelevent ist. Es ist sogar kleiner als die jeder/m SchülerIn zugeteilten Plattenplatz auf dem Server (17GB).

Und meine Lösung läuft schon seit 3 Jahren und ist inzwischen integraler Bestandteil des Schulsystems.

LG
Andreas
Titel: Re:Pacoloco - caching proxy server für pacman
Beitrag von: Sebastian am 09. Oktober 2023, 19:32:05
Zitat:
Auch bei mir werden nur die benötigten Pakete gespiegelt.

Zitat:

  • ein lokales Repo alles Pakete aus den "normalen Repos" vorhalten
  • alle fertig gebauten Pakete aus den AURs als fertiges Paket vorhalten



Dann habe ich dich da falsch verstanden, dann bringt dir pacoloco auch keinen Vorteil, wenn du auch nur benötigte Pakete in deinem Repo spiegelst. :)
Zitat:
Und meine Lösung läuft schon seit 3 Jahren und ist inzwischen integraler Bestandteil des Schulsystems.


Never change a running system. Zumindest nicht aus dem Grund, nur um etwas anders zu machen, um etwas anders zu machen. Man sollte schon einen Vorteil daraus ziehen können. Der hier nicht gegeben ist, also alles richtig. :)


Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.