Diskussion:Package-Preload (Beispiel)

Erledigte Diskussions-Themen

(bitte alles hier rein kopieren was deiner Meinung nach erledigt ist. Ich habe mir schon mal erlaubt damit zu beginnen. Falls ein Punkt wieder zu Diskussion gestellt werden muss, dann kopiert man ihn halt wieder nach unten)

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.

Loginfile

- 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.

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Prima!

Artikel editieren

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)

Namen der Variablen

• 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! Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):

Namen des scripts

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Die Anpassung des scripts fehlt noch.

--GerBra (Diskussion) 07:06, 3. Okt. 2022 (CEST) Ok, ich ändere das jetzt mal auf pkgpredownload.sh

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)

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen: Im script für den server die comm... Zeile setzen, das verhindert auch, dass der User eine Anzeige von z.B. AUR-Paketen zu sehen bekommt wenn er das script auf der Konsole testet. Das würde ihn m.M.n. nur irritieren. Der Hook für den client darf aber so bleiben mit der -n Option!

NFS-Clients

--GerBra (Diskussion) 11:58, 2. Okt. 2022 (CEST)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) Ich würde als Einhängepunkt /var/cache/pacman/pkg vorschlagen, da daß die wenigsten Änderungen bedarf. Der NFS-Mount wird dann halt über das bestehende Cache-Dir eingehängt, daß schadet aber nicht. Und Wenn (Laptop) mal der Server nicht verfügbar wäre können die Clients trotzdem ohne Änderungen Updates fahren.

Ü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... Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Ups! wo kommt denn das nfs bei '<server>:/var/cache/pacman/pkg /var/cache/pacman/pkgnfs rw,nofail 0 0' her? Ich mache das nfs sofort weg! Kann man so nicht stehen lassen.

Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!

____

Noch zu erledigen

Namen der Seite

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.

--> GerBra 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.

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Ja, merken wir uns "PackagePreDownload" schon einmal als Seitentitel vor. Wenn wir einen neuen Artikel anlegen, (man muss den Namen nur in die Suche eingeben, dann muss man wenn man eiggelogged ist nur auf den Link klicken), dann wird aber etwas später auch hier die Diskussion gelöscht. Denke mal, das ist aber kein Problem ist, wenn alles hier o.K. ist.

Besserer Einleitugstext

--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.

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.
paccache gegen explodierende Festplatten

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

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Die Überschriften zu 1. und 2. braucht man nicht. Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.

3. Autsch s. unten.

4. Ja. Das mach ich sofort.

Zu 1. Der Text ist klasse, aber mein Stil ist das nicht. Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.

Ich persönlich bin im Laufe meiner Wiki-Artikel-Erstellerei dazu übergegangen es möglichst kurz zu halten. Viel Text macht es nicht immer einfacher und der User soll auch nicht davon Abgehalten werden sich selbst Gedanken zu machen. Denn die eigen Suchprozesse sind das, was hinterher im Gedächtnis bleibt. Ich versuche möglichst nur ein Thema abzuhandeln und setze für alle anderen Gebiete einen Link. Das sind meine 2€-cents, aber entscheide selbst. Du bist jetzt Wikiautor!

Die Diskussions-Struktur hier im Wiki

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?

Tuxnix (Diskussion) 17:42, 2. Okt. 2022 (CEST) Ich habe mal Überschriften zu den Einzelthemen gesetzt und mir erlaubt ein wenig zu sortieren. Dinge die du für erledigt betrachtest, kannst du dann ganz oben anfügen. Wenn ein Thema wieder gehoben werden muss, kann man es auch wieder unten anfügen. Wenn du beim Abrufen der Wiki auf der Seite 'Letzte Änderungen' nicht auf den Artikellink sondern direkt darunter auf z.B. '12 Änderungen' gehst, dann siehst du sofort was neu editiert wurde und du musst dann auch nicht mehr alten Kram durchlesen. Das klappt auch bei den Diskussionen.

--GerBra (Diskussion) 11:55, 2. Okt. 2022 (CEST)

Syntax Fehler bei pacman -Syuw

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

Tuxnix (Diskussion) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen. Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.

Die Listen haben bisher gar keine Funktion - stimmt das?

Ich werde mal testen, ob ein Paket, dass ausschließlich auf dem client installiert ist, nach seiner Deinstallation vom gemeinsamen paket-cache oder vom mirror geladen wird.