Diskussion:Package-Preload (Beispiel)

Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):

- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)

- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.

-- Tuxnix (Diskussion) 13:24, 1. Okt. 2022 (CEST) Ja, auskommentiert und dann einfach nur (if needed) an die Überschrift hängen. Oder als Kommentarzeile hinter der Befehlszeile einfügen. #(if needed) --logfile blal, bla... .Das Loggen vom Sync zeigt aber nicht einmal auf, welche Pakete aktualisiert wurden. Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf verzichtet.

--GerBra (Diskussion) 10:45, 2. Okt. 2022 (CEST) Dann sollten wir auch auf dieses eigene Logfile verzichten, ich dachte es würde mehr "Müll" geben. Ich passe das preload-Skript dann wieder an.

Generell noch ein paar Dinge:

• Die Bezeichnung für die Wiki-Seite bzw. das Prozedere

Genaugenommen müßte statt (Package)Preload eher PreDownload verwendet werden, oder ein anderer treffender Begriff. preload ist ein anderer Vorgang, dazu gibt es hier auch eine eigene Wiki-Seite. Sowas wie "PackagePreDownload"? Das sollte dann aber auch in allen Scripts einheitlich verwendet werden.

• Im preload.sh (ggf. andere Stellen auch)

-- Tuxnix (Diskussion) 13:24, 1. Okt. 2022 (CEST) Ja! Und wenn dann einheitlich. Vielleicht auch als Akronym wenn es viel zu lange wird. ich schlage deshalb so was wie 'ppd' vor. (Gute Benennungen zu finden ist gar nicht immer so einfach)

--GerBra (Diskussion) 11:02, 2. Okt. 2022 (CEST) Ich würde dann (pacman ) PackagePreDownload als Titel/Setup-Intention vorschlagen, wenn eine Abkürzung notwendig ist dann ggf. PPD (obwohls das ein Suchbegriff im Zusammenhang mit Cups/Printer ist).

->tuxnix: Ich würde vorschlagen im Skript die sog. "Ungarische Notation" für Variablen-Bezeichner zu vermeiden. Also ListDir, PreLoad_DB. Gerade in Shell-Skripts. Irgendwann schleichen sich so Fehler wie list_dir oder Listdir ein, also bei der Schreibweise. Der bessere und sichere Stil wäre: Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb Konstanten mit Großbuchstaben am Anfang oder komplett. Das macht jedes Skript lesbarer und weniger fehleranfällig. -- Tuxnix (Diskussion) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!

Exportliste der Hosts / Filtern von AUR/Fremd-Paketen

Meine Gedanken zu Änderung wie diese behandelt werden.

Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante: pacman -Qqn > $HOST.list zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts. -n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten. Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"

Überlegung: --native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist. M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb: "2) Eigene bzw. Fremd-Repos" https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7

Wenn an einem Host z.B. das Testing-Repo aktiv ist und ggf. noch weitere (in)offizielle Repos, dann wandern beim Export mittels --native diese Pakete in die Host.list - da ja am Host in der SyncDB vorhanden.

Der Server kennt diese Pakete aber dann nicht (Repos nicht definiert) bzw. predownloaded ggf. andere als die gewünschten/erwarteten Pakete. Da diese ja nicht im (eigenen) Sync-DB des preload.sh Skripts sind. Es hagelt also ggf. etliche "package not found" Meldungen - obwohl eigentlich die Hosts und der "Server" alles "richtig" machen.

Es wäre wirklich zu beobachten, ob sowas zu einem "Problem" wird. Dann wäre es ggf. doch sinnvoller, die all(package).list die an pacman -Syuw verfüttert wird wieder **zentral** am "Server" zu bereinigen von nichtbekannten (in der eigenen Sync-DB des Servers) Paketen (mittel des:

comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list

Befehls. Die Hosts können ja weiterhin ihre Paketliste mittels: "pacman -Qqn" exportieren, ergibt ja eine "kleinere" Liste, aber wir schalten nochmal eine "zentrale" Instanz am Server dazu.

-- Tuxnix (Diskussion) 13:24, 1. Okt. 2022 (CEST) Ja, das macht Sinn und ist auch ein wichtiges Argument dafür deine wunderschöne Zeile wieder einzufügen. (Ich musste im Forum die Diskussion abkürzen, deshalb hab ich so flux und einsam die '-n' Entscheidung gefällt, sorry) Beim Host das '-n' wohl auch wieder zu entfernen. Wir wissen ja nicht ob der Host auch zusätzliche Repos nutzt. Tuxnix (Diskussion) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.

--GerBra (Diskussion) 11:02, 2. Okt. 2022 (CEST) Ich denke es schadet nichts die Host-Listen mittels -n/--native zu exportieren, am Server schlagen dann ja jeweils viel "kleinere" Listen auf. Trotzdem sollte der Server die all-Liste dann nochmal anhand seiner Sync-DB abgleichen vor dem PreDownload (also ich werde die comm -12 blabla wieder einbauen)

Da musste ich jetzt auch schnell sein. Ich schlage vor wir machen jetzt erst einmal alles fertig und ändern den Artikelnamen zu letzt. Um den Namen zu ändern muss man einen neuen Artikel anlegen und Dirk muss den alten Artikel dann wieder löschen. Ich vermeide es ihm mit sowas unnötig viel Arbeit zu machen und schreibe meistens erst auf der eigenen Seite vor, ehe ich veröffentliche. Aber ich war mir hier nicht sicher ob du da überhaupt Schreibrechte hast. _______

Herzlich willkommen in der Arch-Wiki

Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten. Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln. Damit der gemeinsame Wissensaustausch nicht plötzlich abbricht, kann man ja erst einmal nur den Wiki-Artikel hier in der Wiki positionieren und bei der Diskussion schauen wie sich das organisch entwickelt.

Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;) Meinerseits macht mir das auch viel Spaß. Alles was ich über Linux weiß, hab ich mir allein aus dem Internet zusammengesucht. Ich habe auch nur privat mit IT zu tun. Ich lerne durch die Zusammenarbeit mit dir viel dazu. Auch gibt es viele Aspekte die man allein übersehen würde.

Zum Inhalt

Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben. Wir müssten uns noch darüber verständigen ob die Anleitung alle Möglichkeiten beinhalten soll oder ob der Artikel lediglich pur und ohne viele Extras lediglich das Prinzip aufzeigen soll eine eigene Sync-Datenbank zu implementieren.

--GerBra (Diskussion) 11:02, 2. Okt. 2022 (CEST) Also ich finde es immer gut, wenn ein Wikiartikel initial erklärt um was es eigentlich geht, Überblick über den Ablauf gibt und erst dann die konkrete Implementation aufzeigt. Ohne das der Leser das Grobe eineigermaßen verstanden hat lassen sich auch von ihm keine Anpassungen an **seine** Umgebung vornehmen. Das Einrichten reduziert sich dann leider oft auf das blindlingse/verständnislose Abkopieren der einzelnen Befehle. Ich habe mir mal eine so eine "Textstruktur" für den Artikel überlegt. Ich packe das hier in die Diskussion mal in einen eigenen Abschnitt, ich wollte den momentanen Wiki-Text noch nicht ändern. Du kannst ja mal schauen, ob dir sowas zusagt bzw. auch verbessern.
PPS: Diese "Kommentare" in die Diskussions-Struktur wild reinzuschreiben ist IMHO irgendwie unübersichtlich. So ist nicht ganz klar wer was sagt (mein neuer text geht in deinen alten über, wie hier ). Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?

Ich tendiere dazu, weil das auch viel Spaß macht, alle Möglichkeiten aufzuführen. Im Script könnte das dann etwa in dieser Form geschehen, dann entscheidet der User darüber was er braucht und was nicht:

- # Logfile Synx-DB (if needed) - #${SyncDb.log} ...blah blah

Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?) Dann kommen wir uns nicht gegenseitig in die Quere.

--GerBra (Diskussion) 11:02, 2. Okt. 2022 (CEST) Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.

P.S.: Tipp - Viermal ~ erzeugt eine Signatur mit Datumsstempel unter deinem Diskussionsbeitrag. Das ist sehr praktisch wenn man später die Diskussion nachvollziehen möchte. Tuxnix (Diskussion) 13:18, 1. Okt. 2022 (CEST)

Artikel Struktur "Vorwort"

PackagePreDownload

1. Übersicht

Ein grosser Teil der Zeit bei einem Systemupdate mittels pacman -Syu vergeht beim Download der Pakete. In einer Forumsdiskussion¹ kam nun die Idee auf, diese Zeit zu verkürzen dadurch, dass die aktuellen Pakete schon vorher von den Spiegelservern heruntergeladen werden. Diese also dann beim eigentlichen Systemupdate im pacman-Paketcache schon vorhanden sind.

Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.

Der PreDownload von Paketen wird mittels der pacman-Option -w/--downloadonly realisiert, ein pacman -Syuw würde also die Repositorien-Sync-Datenbank(-y) aktualisieren, -u würde die zu aktualisierbaren Pakete erfassen. Durch -w/--downloadonly erfolgt im Zuge des Befehls nun aber kein Systemupdate, sondern es werden lediglich die aktualisierbaren Paketdateien heruntergeladen um im pacman-Paketcache (Default: /var/cache/pacman/pkg) abgelegt. Ein weiteres pacman -Syu (ohne -w) stösst nun das wirkliche Systemupgrade an, wobei im Idealfall eben der größte Teil der notwendigen Paketdateien schon vorhanden sind.

Bei einem angestrebten Setup mit mehreren Rechnern, die jeweils ganz unterschiedliche Softwarebestände haben können, gibt es nun ein paar Dinge, die erfüllt sein müssen:

• Alle Rechner müssen einen gemeinsamen Paketcache verwenden.
• Dieser gemeinsame Paketcache muss im Netzwerk für alle beteiligten Rechner lese- und schreibar sein. Eventuell habt ihr bei mehreren Rechnern schon so eine Lösung, ansonsten wird im Artikel die Freigabe mittels NFS vorgestellt.
• Einer der Rechner kümmert sich in bestimmten Intervallen um den Pre-Download der Pakete, wir bezeichnen diesen als "Server". Die Rechner, die vom Pre-Download profitieren sollen sind "Clients".

Das unten aufgeführte Setup funktioniert folgendermassen:

• Die "Clients" exportieren ihre unterschiedlichen (z.B ein KDE-Rechner, ein Gnome-Rechner) Liste der installierten Pakete in das gemeinsam genutzte Paketcache-Verzeichnis. Das geschieht automatisch über einen pacman-Hook.
• Der "Server" erzeugt nun eine gemeinsame Liste aller Pakete, die auf allen Rechnern jeweils installiert sind. Anhand dieser Liste erfolgt dann der Pre-Download dieser Pakete. Der "Server" verwendet, um die Gefahr eines partiellen Upgrades, das die Konsistenz des Systems bei einen unbedachten pacman -S foobar beschädigen könnte zu vermeiden, für den Pre-Download der aktuellen Pakete eine eigene Sync-Datenbank.
• Sobald nun einer der beteiligten Rechner "sein" Systemupdate anstösst mittels pacman -Syu sind eben ein Großteil der Pakete für diesen Rechner schon vorhanden. Das -y (Aktualisierung der Repositorien-Datenbank) ist trotzdem notwendig um aktualisierte Pakete zwischen diesem Upgrade und dem Pre-Download-Vorgang zu erfassen.

2. Implementierung (bisheriger Wiki-Artikel)

3. Fallstricke / Fehlergefahren AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.

4. weiterführende Links ¹ Forums-Thread
pacman / pacman Tips (ggf. auf .org) ?

NFS-Clients

Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkgnfs rw,nofail 0 0
gemountet. Das würde real dann aber nicht funktionieren, da daß neuen Cache-Verzeichniss dann auch als CacheDir in die jeweilige pacman.conf geschrieben/editiert weren muß.

Weiter unten beim Hook exportierst du die Pakeltliste aber nach:
/var/cache/pacman/pkg/$HOSTNAME.list
also **nicht** in das gemeinsame Cache-Verzeichnis...

Wir sollten uns im Artikel auf das gem. Cache-Verzeichnis einigen, und dem User den Hinweis geben das ggf. bei anderem Mount-Point seines Setups die pacman.conf anzupassen ist (wenn er/sie/es nicht schon längst getan hat)

Überhaupt: Nach Abschluß des Artikels (vor der "Freigabe") muß das ganze Procedere nochmal an einem "sauberen" Rechner /virt. Maschine etc. durchgespielt werden. Ansonsten fallen Fehler nicht auf...