tuxnix
Ich schreibe mal nach und nach noch ein paar Dinge, kann etwas dauern. D.h. der beitrag wächst ggf. noch:
tuxnix [x] Paket-Cache(-Pfad) des ProLoad-"Servers" würde ich nicht als Zwang antasten -
Das hat mich bewogen gar keinen seperaten Cache Ordner mehr anzulegen.
Der Paketcache des Servers ist jetzt der Paketcache für alle Rechner. Dann muss man auch beim jeweiligen Client nicht an der /ect/pacman.conf herumschrauben.
Oder halt den Hinweis an den User, daß der Paketcache(CacheDir) der Clients in der pacman.conf dann auf das Mount-Dir der Freigabe zu ändern ist. Mein Server exportiert z.B. /srv/nfs/pkg (was ein Bind-mount von /var/cache/pacman/pkg ist), die Clients finden den lokal dann unter /mnt/servername/pkg. Dafür habe ich die pacman.conf angepaßt. Wichtig ist m.E. das der User versteht: es soll einen gemeinsamen Pkg-Cache geben und alle müssen dann darauf zugreifen.
tuxnix [x] paccache hab ich aus der Anleitung gestrichen. Privat nutze ich es weiter in dem script.
Einen Hinweis im diesem Wiki-Beitrag drauf zu geben finde ich ok. Hat ja was mit dem Thema zu tun. So a la "Bevor die Festplatte explodiert gibt es auch noch dieses Tool, was sich anbietet" -> Link zu paccache-Wiki (ggf. auf .org)
tuxnix [x] -Qqe tut es. Optionale Abhängigkeiten sind für pacman explizit installierte Pakete.
Auch für optionale Abhängigkeiten, die der User brav als --depend" installiert hat?
tuxnix Um die Gefahr eines partielles Upgrades, das die Konsistenz des Systems bei einen unbedachten pacman -S foobar beschädigen könnte zu vermeiden, wird eine separate Paketdatenbank für das Preload genutzt.
Keine separate Paketdatenbank, sondern eine extra Sync-Datenbank. Sowas wie "Für eine Liste der aktuell verfügbaren Pakete (Sync-Datenbank/-Sy) wird hier eine eigene benutzt, um die Gefahr von parti. Updates blabla zu vermeiden"
tuxnix Dabei wird der Paketbestand einzeln gelistet, sodass jeder Rechner nur die Pakete erhält die auf ihm schon installiert sind.
Verstehe ich nicht was du damit sagen willst.
paccache hast du im nächsten Satz auch noch drin, ich würde den Hinweis auf paccache (s.o.) ans Ende des beitrags schieben.
tuxnix Die Installation der auf diese Weise vorab heruntergeladenen Pakete wird dabei wie bisher mit dem Befehl pacman -Syu auf jedem Rechner separat durchgeführt.
Das würde ich um den Sinn des ganzen nochmal ausführen, daß dann halt im Idealfall schon die meisten Pakete im gemeinamen Cache vorhanden sind (und wg. -Syu der Clients nur die letzten wichtig wirklich neuen ggf. nachgezogen werden müssen).
tuxnix Vorbereitung
Für die separate preload Paketdatenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.
Das ist die separate Sync-Datenbank, nicht Paketdatenbank s.o.
tuxnix chmod 777 /var/cache/pacman/pkg
Das halte ich in einem Wiki-Beitrag für falsch. Warum soll der User ein Sicherheitsloch auf seinem Server aufmachen (777 für zu installierende Pakete). Kann jeder Hinz und Kunz Pakete "unterschieben"...
Am Server und auf den Clients werden für die pacman-Operation jeweils Root-Rechte gebraucht, das Cache-Dir am Server und auf den Clients kann/sollte also root:root 755 haben. Mit einem ordentlichen NFS-Export geht das auch (stichwort no_root_squash, da du irgendwo oben mal schriebst daß dein root-User an den Clienst auf nobody gemappt wird). Alles besser als 777...
tuxnix # Write and sort package lists, delete AUR package names
pacman -Qqe > $ListDir/$HOSTNAME.list
sort -u $ListDir/*.list > $ListDir/org.list
comm -12 <(pacman -Slq --dbpath $PreLoad_DB | sort) <(sort $ListDir/org.list) > //$ListDir/all.list
"ignore packages not available in our sync DB (like AUR and local installed packages)"
Generell: In Scripts ist es generell besser auf (Pfad) und andere Variablen mittels "$(varname)" zuzugreifen (inkl. der Anführungszeichen). Ein Pfad kann auch mal Leerstellen enthalten.
tuxnix systemd service
Service unter /etc/systemd/system/ abspeichern und danach aktivieren
systemctl enable --now pkgpreload.timer
Da hast du glaube ich jeweils die Dateinamen von *.timer und .service verwechselt.
Beim Timer würde ich noch einen Hinweis auf das Intervall geben ("Im Beispiel machen wir einmal täglich einen PreDownload"). Kann der USer ja ändern wollen.
So, ich glaub das wars erstmal ;-)
"Kritisieren" macht ja so Spaß...<g> Nein, bitte nicht mißverstehen, ich habe eine große Achtung vor deinem Engagement gerade bzgl. Wiki-Beiträgen, okay?