https://wiki.archlinux.de/api.php?action=feedcontributions&user=Tuxnix&feedformat=atomwiki.archlinux.de - Benutzerbeiträge [de]2024-03-19T13:49:33ZBenutzerbeiträgeMediaWiki 1.41.0https://wiki.archlinux.de/index.php?title=Microcode&diff=24000Microcode2024-03-06T00:03:29Z<p>Tuxnix: Umstellung auf hook microcode</p>
<hr />
<div>Einige Prozessoren erlauben es, den Firmware-Code (oder auch Microcode genannt) beim Systemstart zu überschreiben, so dass ohne ein BIOS-Update eventuelle Firmware-Fehler zur Laufzeit beseitigt werden können.<br />
Das Überschreiben gilt aber nur bis zum Ausschalten des Computers (es ist reversibel), so dass danach wieder der ursprüngliche Code vorhanden ist.<br />
<br />
== Unterstützte Prozessoren ==<br />
Eine Liste mit unterstützten Modellen gibt es sowohl von [http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21925&keyword=%22microcode%22&lang=eng Intel] als auch von [http://www.amd64.org/microcode.html AMD].<br />
<br />
== Microcode Installieren ==<br />
Für AMD-Prozessoren wird das {{Paket|amd-ucode}}, für Intel-CPUs das Paket {{Paket|intel-ucode}} installiert.<br />
<br />
== Microcode Aktivieren ==<br />
In der Datei /etc/mkinitcpio.conf wird in der Zeile HOOKS=(base udev {{ic|microcode}}... eingefügt.<br />
Anschließend wird mit dem Befehl:<br />
mkinitcpio -p linux<br />
eine neue /boot/initramfs-linux.img und /boot/initramfs-linux-fallback.img Datei erzeugt. <br />
{{Hinweis|Seit der Umstellung auf den hook microcode am 5.3.2024 ist der Microcode in diesen Dateien integriert. Eine separate Anführung eines ucode.img im jeweiligen Bootloader entfällt damit.}}<br />
<br />
== Feststellen, ob Microcode-Updates vorgenommen wurden ==<br />
Möchte man überprüfen, ob beim Booten des Systems ein Microcode-Update stattgefunden hat, so kann einen ersten Test mittels <br />
journalctl -k --grep microcode<br />
durchführen. <br />
Im Falle von Intelprozessoren mit erfolgreichem Early Loading erhält man etwa folgendes (hier ein Lenovo Thinkpad T480s):<br />
Sep 04 15:31:40 darkstar kernel: microcode: microcode updated early to revision 0xb4, date = 2019-04-01<br />
Sep 04 15:31:40 darkstar kernel: microcode: sig=0x806ea, pf=0x80, revision=0xb4<br />
Sep 04 15:31:40 darkstar kernel: microcode: Microcode Update Driver: v2.2.<br />
Findet kein Microcode-Update statt, sieht die Ausgaben wir folgt aus (hier das selbe Lenovo Thinkpad T480s):<br />
Jul 30 10:21:06 darkstar kernel: SRBDS: Mitigation: Microcode<br />
Jul 30 10:21:06 darkstar kernel: microcode: sig=0x806ea, pf=0x80, revision=0xd6<br />
Jul 30 10:21:06 darkstar kernel: microcode: Microcode Update Driver: v2.2.<br />
Ein negatives Ergebnis muß nicht auf eine Fehlkonfiguration zurückzuführen sein. Es kann auch bedeuten, daß das BIOS bereits die neueste Firmware enthält. Im Falle des exemplarisch verwendeten T480s war dies nach einem BIOS-Update der Fall.<br />
Möchte man sichergehen, daß die neueste Firmwareversion geladen ist, geht man wie folgt vor:<br />
* Installation von iucode-tool:<br />
# pacman -S iucode-tool<br />
* Laden des cpuid Kernelmoduls:<br />
# modprobe cpuid<br />
* Bestimmung der neuesten Firmware-Revision für die vorhandene CPU:<br />
# bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS -<br />
* Prüfen, ob diese tatsächlich verwendet wird: <br />
grep microcode /proc/cpuinfo<br />
<br />
Bei AMD-Prozessoren findet das Microcode-Update erst etwas später im Bootprozess statt. Deshalb erhält man ein Ergebnis wie dieses:<br />
Jul 30 21:59:24 darkstar kernel: microcode: CPU0: patch_level=0x010000c8<br />
Jul 30 21:59:24 darkstar kernel: microcode: CPU1: patch_level=0x010000c8<br />
Jul 30 21:59:24 darkstar kernel: microcode: CPU2: patch_level=0x010000c8<br />
Jul 30 21:59:24 darkstar kernel: microcode: CPU3: patch_level=0x010000c8<br />
Jul 30 21:59:24 darkstar kernel: microcode: Microcode Update Driver: v2.2.<br />
[[Kategorie:Hardware]]<br />
[[en:Microcode]]</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Mkinitcpio&diff=23999Mkinitcpio2024-03-05T22:49:56Z<p>Tuxnix: Hook micrcode ergänzt</p>
<hr />
<div>{{SEITENTITEL:mkinitcpio}}{{righttoc}}<br />
<br />
'''mkinitcpio''' ist die nächste Generation der '''initramfs'''-Erstellung. Es hat viele Vorteile gegenüber den alten Skripten '''mkinitrd''' und '''mkinitramfs'''.<br />
<br />
* Es nutzt '''klibc''' und '''kinit''' der Linux-Entwickler, welches eine kleine und leichtgewichtige Basis bereitstellt, um Programme sehr früh im ''userspace'' laufen zu lassen. <br />
* Es kann mittels '''udev''' die Hardware zur Laufzeit erkennen, so dass nur die wirklich nötigen Module geladen werden.<br />
* Die hook-basierenden init-Scripte sind leicht erweiterbar und können auch durch externe Pakete genutzt werden.<br />
* Es unterstützt bereits '''lvm2''', '''dm-crypt''' (legacy und luks volumes), '''raid''', '''swsusp''' und '''suspend2''' Fortsetzen und Starten von '''usb''' Datenträgern.<br />
* Viele Funktionen können von der Kernel-Kommandozeile konfiguriert werden ohne das Image neu erstellen zu müssen.<br />
* Mit dem '''mkinitcpio'''-Skript ist es möglich, das Image in den Kernel zu integrieren.<br />
<br />
'''mkinitcpio''' wurde von '''phrakture''' und '''tpowa''' mit Hilfe aus der Community entwickelt.<br />
<br />
{{installation|paket=mkinitcpio|repo=core}}<br />
<br />
mkinitcpio ist Bestandteil jeder Arch Linux Installation.<br />
<br />
== Konfiguration ==<br />
<br />
Die Konfigurationsdatei lautet {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
=== MODULES ===<br />
<br />
Mit dem MODULES-Eintrag können Module explizit dem Image hinzugefügt werden.<br />
<br />
Beispiel: Bei Verwendung des nouveau Treiber wird bereits die Konsole beim Starten diesen verwenden.<br />
<br />
MODULES=(nouveau)<br />
<br />
=== BINARIES und FILES ===<br />
<br />
Mit diesen Optionen können Dateien dem Abbild hinzugefügt werden. Der einzige Unterschied zwischen BINARIES und FILES ist, dass BINARIES die Bibliotheken nach Abhängigkeiten durchsucht, während FILES nur Dateien hinzufügt.<br />
<br />
=== HOOKS ===<br />
<br />
Dies ist der wichtigste Teil der mkinitcpio Konfiguration. Diese Zeile enthält alle HOOKS, welche während der Imageerstellung oder zur Laufzeit ausgeführt werden. Hierbei muss die Reihenfolge beachtet werden:<br />
<br />
HOOKS=(foo1 foo2 bar1 bar2)<br />
<br />
Am besten man prüft anhand des eigenen Systems, welche HOOKS aktuell verfügbar sind. Zusätzlich wird angezeigt, welche als veraltet gelten, und welche zukünftig verwendet werden sollen.<br />
<br />
mkinitcpio -L<br />
<br />
Für jeden gelisteten HOOK gibt es eine Zusatzinfo.<br />
<br />
mkinitcpio -H base<br />
<br />
==== Verfügbare HOOKS ====<br />
{| border="2" cellspacing="0" cellpadding="4" rules="all" style="margin:1em 1em 1em 0; border-style:solid; border-width:1px; border-collapse:collapse; empty-cells:show"<br />
|-<br />
! Hook || Information <br />
|-<br />
| '''base''' || This hook provides crucial runtime necessities for booting. DO NOT remove this hook unless you know what you're doing. <br />
|-<br />
| '''udev''' || This hook will use udev to create your root device node and detect the needed modules for your root device. It is also required for firmware loading in initramfs. It is recommended to use this hook. <br />
|-<br />
|'''microcode''' || This hook adds early microcode update files for Intel and AMD processors. If /boot/amd-ucode.img or /boot/intel-ucode.img exist, they are included in the initcpio. If not, the individual microcode files in /lib/firmware/ are included if they exist. If the autodetect hook runs before this hook, it will only add early microcode update files for the processor of the system the image is built on.<br />
|-<br />
| '''systemd''' || This will install a basic systemd setup in your initramfs, and is meant to replace the 'base', 'usr', 'udev' and 'timestamp' hooks. Other hooks with runtime components will need to be ported, and will not work as intended. You also may wish to still include the 'base' hook (before this hook) to ensure that a rescue shell exists on your initramfs. <br />
|-<br />
| '''modconf''' || This hook installs modprobe configuration files from /etc/modprobe.d and /usr/lib/modprobe.d. <br />
|-<br />
| '''usr''' || This provides a support for mounting /usr via a late running hook. No configuration is needed, as the mount options will be pulled directly from the fstab on the real root device. <br />
|-<br />
| '''autodetect''' || This hook shrinks your initramfs to a smaller size by autodetecting the needed modules. Be sure to verify included modules are correct and none are missing. This hook must be run before other subsystem hooks in order to take advantage of auto-detection. Any hooks placed before 'autodetect' will be installed in full. <br />
|-<br />
| '''sata''' || This hook is deprecated in favor of 'block' <br />
|-<br />
| '''scsi''' || This hook is deprecated in favor of 'block' <br />
|-<br />
| '''usb''' || This hook is deprecated in favor of 'block' <br />
|-<br />
| '''fw''' || This hook is deprecated in favor of 'block' <br />
|-<br />
| '''block''' || This hook loads the necessary modules for most block devices using pata, sata, scsi, firewire, usb, or mmc. Detection will take place at runtime. To minimize the modules in the image, add the autodetect hook too. <br />
|-<br />
| '''usbinput''' || This hook is deprecated in favor of 'keyboard' <br />
|-<br />
| '''keyboard''' || This hook loads the necessary modules for keyboard devices. As a side-effect modules for some non-keyboard input devices might be added to, but this should not be relied on. Detection will take place at runtime. To minimize the modules in the image, add the autodetect hook too. <br />
|-<br />
| '''filesystems''' || This hook adds filesystems modules to the image. If you would like to minimize the modules installed in the image, add the autodetect hook too. <br />
|-<br />
| '''lvm2''' || This hook enables LVM2 volumes in initramfs. Do pacman -S lvm2 before. <br />
|-<br />
| '''sd-lvm2''' || This hook enables LVM2 volumes in systemd-based initramfs. Do pacman -S lvm2 before. <br />
|-<br />
| '''mdadm''' || This hook loads the necessary modules for any raid root device, and assembles the raid device when run. If arrays are defined in /etc/mdadm.conf, the file will be used instead of command line assembling. Do pacman -S mdadm before. Please see mkinitcpio -H mdadm <br />
|-<br />
| '''dmraid''' || This hook loads the necessary modules for a dmraid root device. Do pacman -S dmraid before. <br />
|-<br />
| '''encrypt''' || This hook allows for an encrypted root device. Users should specify the device to be unlocked using 'cryptdevice=device:dmname' on the kernel command line, where 'device' is the path to the raw device, and 'dmname' is the name given to the device after unlocking, and will be available as /dev/mapper/dmname. Do pacman -S cryptsetup before. Please see mkinitcpio -H encrypt <br />
|-<br />
| '''sd-encrypt''' || This hook allows for an encrypted root device. Users should specify the device to be unlocked using 'cryptdevice=device:dmname' on the kernel command line, where 'device' is the path to the raw device, and 'dmname' is the name given to the device after unlocking, and will be available as /dev/mapper/dmname. Do pacman -S cryptsetup before. Please see mkinitcpio -H sd-encrypt <br />
|-<br />
| '''resume''' || This hook initializes support for resuming from Disk. Supports swsusp and suspend2. <br />
|-<br />
| '''fschk''' || This hook provides fsck and filesystem specific helpers to perform an fsck operation on the root device prior to mounting. If the autodetect hook is used, only the fsck helper specific to your filesystem will be added to the image. It is highly recommended that if you include this hook that you also include any necessary modules to ensure your keyboard will work in early userspace. Please see mkinitcpio -H fsck <br />
|-<br />
| '''consolefont''' || This hook loads consolefont specified in vconsole.conf during early userspace. <br />
|-<br />
| '''sd-vconsole''' || This hook adds the keymap(s) and font specified in vconsole.conf to the image and loads them during early userspace. <br />
|}<br />
<br />
Beispiele:<br />
<br />
Diese Konfiguration sollte für die meisten Benutzer funktionieren:<br />
<br />
HOOKS=(base systemd autodetect modconf block filesystems sd-vconsole fsck)<br />
<br />
Du kannst verschlüsselte Dateisysteme innerhalb von lvm nutzen:<br />
<br />
HOOKS=(base autodetect modconf block lvm2 encrypt filesystems keyboard consolefont fsck)<br />
<br />
Du kannst verschlüsselte Dateisysteme innerhalb von lvm nutzen, wenn systemd im Einsatz ist:<br />
<br />
HOOKS=(base systemd autodetect modconf block sd-lvm2 sd-encrypt filesystems sd-vconsole fsck)<br />
<br />
=== COMPRESSION ===<br />
# Use this to compress the initramfs image. By default, gzip compression is used. Use 'cat' to create an uncompressed image.<br />
COMPRESSION=(xz)<br />
=== COMPRESSION_OPTIONS ===<br />
# Additional options for the compressor<br />
COMPRESSION_OPTIONS=(-9)<br />
<br />
== Erstellen des Images ==<br />
<br />
Erstelle das Image mit folgendem Befehl:<br />
<br />
# mkinitcpio -p linux<br />
<br />
== Extrahieren des Images ==<br />
<br />
Wenn du wissen möchtest, was sich innerhalb des initrd-Abbildes befindet, kann du es auspacken und in den enthaltenen Dateien herumstöbern.<br />
<br />
Das initrd-Abbild ist ein 'SVR4 CPIO'-Archiv, das durch die Befehle ''find'' und ''bsdcpio'' erstellt wurde und optional durch ein vom Kernel verstandenes Komprimierungsschema komprimiert wurde: genauer gesagt gzip, bzip2, lzma, lzo oder xz.<br />
<br />
mkinitcpio beinhaltet ein Werkzeug namens lsinitcpio, welches die Inhalte des initramfs-Abbildes anzeigt und extrahiert.<br />
<br />
Das Anzeigen der Dateien im Abbild geschieht durch:<br />
<br />
# lsinitcpio /boot/initramfs-linux.img<br />
<br />
Man kann sich auch eine Auflistung der wichtigen Teile des Abbildes anzeigen lassn:<br />
<br />
# lsinitcpio -a /boot/initramfs-linux.img<br />
<br />
Das Extrahieren aller Dateien in das aktuelle Verzeichnis:<br />
<br />
# lsinitcpio -x /boot/initramfs-linux.img<br />
<br />
== Kernelzeile anpassen ==<br />
<br />
Einige Optionen müssen in der Kernelzeile angegeben werden. Einige Mkinitcpio Hooks haben spezielle Optionen. Um diese soll es in diesem Abschnitt gehen.<br />
<br />
Wenn du nicht weißt was die Kernelzeile ist, schau in die Dokumentationen von [[GRUB]] oder [[Syslinux]].<br />
<br />
=== Failsafe Modus ===<br />
<br />
Wenn du<br />
<br />
break=y<br />
<br />
zur Kernelzeile hinzufügst, dann stoppt Init nach dem das Setup vollständig ist und du landest in einer ''dash'' shell. Diese kann genutzt werden um sich über den Erfolg des Vorgangs zu versichern. Wenn du dich ausloggst geht der normale Bootvorgang weiter.<br />
<br />
=== Hooks deaktivieren ===<br />
<br />
Du kannst hooks deaktivieren indem du ''disablehooks'' zur Kernelzeile hinzufügst:<br />
<br />
disablehooks=hook1,hook2,hook2<br />
<br />
zum Beispiel<br />
<br />
disablehooks=resume<br />
<br />
=== Module blacklisten ===<br />
<br />
Du kannst Module blacklisten indem du ''disablemodules'' zur Kernelzeile hinzufügst:<br />
<br />
disablemodules=mod1,mod2,mod3<br />
<br />
zum Beispiel<br />
<br />
disablemodules=ata_piix<br />
<br />
[[Kategorie:Konfiguration]]<br />
<br />
[[en:mkinitcpio]]</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Benutzer:Tuxnix&diff=23818Benutzer:Tuxnix2023-01-18T10:52:15Z<p>Tuxnix: inuse</p>
<hr />
<div>{{inuse|[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]])}}{{SEITENTITEL:sway}}{{righttoc}}[[Bild:Sway Wallpaper Blue 1920x1080.png|thumb|360px|Sway (Wallpaper)]]<br />
<br />
Sway ist ein Tiling Compositor für Wayland.<br />
{{Hinweis|Sway unterstützt keine proprietären Grafiktreiber. Für Nvidia-Karten ist der Treiber Nouveau zu nutzen.}}<br />
<br />
{{installation|paket=sway|repo=community}}<br />
<br />
Ergänzend stehen einige Tools zur Verfügung die in der Standartkonfiguration bereits mit eingebunden sind:<br />
<br />
* {{Paket|foot}} - Terminalemulator<br />
* {{Paket|dmenu}} - Anwendungslauncher<br />
* {{Paket|swaybg}} - Sway-Wallpaper<br />
<br />
Des Weiteren sind die folgenden Schriftarten empfohlen:<br />
<br />
* {{Paket|ttf-roboto}}<br />
* {{Paket|ttf-font-awesome}}<br />
<br />
Sollte man keine Alternativen Tools (s. unten) bevorzugen, dann lautet der komplette Installationsbefehl:<br />
pacman -S sway foot dmenu swaybg ttf-roboto ttf-font-awesome<br />
<br />
== Umstieg von i3 ==<br />
Sway ist bis auf wenige Features, die nur auf X11 Sinn machen, mit der Konfiguration von i3, i3 IPC, i3-gaps, und i3bar kompatibel. Es empfiehlt sich die bisherige i3-Konfigurationsdatei nach {{ic|~/.config/sway/config}} zu kopieren. Weitere Tipps sind vom [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] zu erfahren.<br />
<br />
== Sway Starten ==<br />
Eine Sway Sitzung kann auf verschiedene Arten gestartet werden:<br />
* Nach dem login auf TTY mit der Eingabe {{ic|sway}}<br />
* oder automatisch nach Einfügen der Zeile {{ic|[ "$(tty)" &#61; "/dev/tty1" ] && exec sway}} in die {{ic|~/.bash_profile}} Datei.<br />
* Mittels modernem [[Login-Manager]] wie [[GDM]] oder SDDM bzw. einem der [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway#login-managers hier] gelisteten.<br />
<br />
== Tastaturbefehle (default) ==<br />
{|<br />
|{{taste|mod}} + {{taste|1}}-{{taste|0}}<br />
| - Ein Fenster öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Return}}<br />
| - Ein Terminal öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Pfeil}}<br />
| - Den Fensterfokus wechseln<br />
|-<br />
|{{taste|mod}} + {{taste|d}}<br />
| - Den Anwendungsstarter aufrufen<br />
|-<br />
|{{taste|mod}} + {{taste|f}}<br />
| - Vollbildmodus ein-/ ausschalten<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|1}}-{{taste|0}}<br />
| - Die laufende Anwendung auf ein Fenster verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|c}}<br />
| - Die config Datei neu einlesen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|Pfeil}}<br />
| - Ein Fenster horizontal oder vertikal verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|q}}<br />
| - Eine Anwendung schließen <br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|e}}<br />
| - Sway beenden<br />
|}<br />
<br />
== Konfiguration ==<br />
Möchte man die vorgegebene Konfiguration anpassen, so wird empfohlen die Konfigurationsdatei ins eigene Benutzerverzeichnis zu kopieren und nur diese zu bearbeiten.<br />
mkdir ~/.config/sway<br />
cp /etc/sway/config ~/.config/sway/config<br />
<br />
Die folgende Auflistung führt einige zusätzlichen Tools und die jeweiligen dazugehörigen Einstellungen in der {{ic|~/.config/sway/config}} Datei auf. Eine komplette Liste von Sway-Ad-Ons ist [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway hier] abrufbar.<br />
{|<br />
|'''Paket/Einstellungen'''<br />
|'''Config-Eintrag (Bsp.)'''<br />
|-<br />
|{{taste|Win}} als mod-Taste<br />
|{{ic|set $mod Mod4}} (default)<br />
|-<br />
|{{taste|Alt}} als mod-Taste<br />
|{{ic|set $mod Mod1}}<br />
|-<br />
|Deutsches Tastaturlayout<br />
|{{ic|input * xkb_layout "de"}}<br />
|-<br />
|Auflösung<br />
|{{ic|output * resolution --custom 1920x1080}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Terminal-Emulatoren:''<br />
|<br />
|-<br />
|{{paket|foot}}<br />
|{{ic|set $term foot}} (default)<br />
|-<br />
|{{paket|alacritty}}<br />
|{{ic|set $term alacritty}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Wallpaper:''<br />
|<br />
|-<br />
|{{paket|swaybg}}<br />
|{{ic|output * bg <image-datei> fill}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Anwendungs-Lancher:''<br />
|<br />
|-<br />
|{{paket|dmenu}}<br />
|{{ic|set $menu dmenu_path &#124; dmenu &#124; xargs swaymsg exec --}} (default)<br />
|-<br />
|{{paket|wofi}}<br />
|{{ic|set $menu wofi --show run --exec-search}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Symbolleisten:''<br />
|<br />
|-<br />
|sway-bar (eingebaut)<br />
|siehe config Datei (default) <br />
|-<br />
|{{paket|waybar}}<br />
|{{ic|bar swaybar command waybar}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Idle Management Daemon und Screenlocker:''<br />
|<br />
|-<br />
|{{paket|swayidle}} und {{paket|swaylock}}<br />
|Das Beispiel in der config auskommentieren<br />
|}<br />
<br />
== siehe auch ==<br />
* [[i3]]<br />
<br />
== Weblinks ==<br />
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] {{sprache|en}}<br />
* [https://github.com/swaywm/sway/wiki Sway Wiki] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=hRIGYUWQfYU Sway Install Guide (Video)] {{sprache|en}}<br />
* [https://medium.com/hacker-toolbelt/linuxs-sway-window-manager-c39abe0b7bc9 A short install guide] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=oUpvtCEGrxQ Waybar Customization (Video)] {{sprache|en}}<br />
<br />
[[Kategorie:Fenstermanager]]<br />
[[en:sway]]</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Anleitung_f%C3%BCr_Einsteiger&diff=23808Diskussion:Anleitung für Einsteiger2023-01-04T12:34:19Z<p>Tuxnix: archlinux-keyring aktualisieren</p>
<hr />
<div>=Dinge die erledigt sind und in die Anleitung schon eingearbeitet wurden=<br />
<br />
==@ /etc/pacman.conf==<br />
'Um die Pacman Repository Datenbanken neu zu laden, anschließend folgenden Befehl eintippen<br />
pacman -Sy'<br />
<br />
Vorsicht Falle: Dieser Befehl alleine versetzt das System in einen Zustand des 'partiellen Updates', welcher von ArchLinux nicht unterstützt wird! Ohne unmittelbares Systemupdate mit pacman -Su kann es beim Installieren weiterer Software zu Problemen kommen, weil die Pacman Repository Datenbanken zwar aktuell sind und die aktuellste Version der zu installierenden Software abrufen, das System und die Versionen der vorhandenen Software aber noch auf dem 'alten' Stand sind.<br />
Generell ist der Befehl in Verbindung mit '-u' abzusetzen, also<br />
<br />
pacman -Syu<br />
<br />
== @ Verschlüsseltes W-LAN (WPA/WPA2) ==<br />
<br />
... und wlan0 muss durch den richtigen WLan - Gerätenanmen ersetzt werden<br />
(war jedenfalls grade bei mir so).. kann das jemand korrigieren? Lieben Gruß<br><br />
Ist erledigt. ip link --> Als Beispiel wlp0s1. Vielen Dank für den Hinweis!! Gruß [[Benutzer:Greg|Greg]] ([[Benutzer Diskussion:Greg|Diskussion]]) 11:49, 20. Okt. 2016 (CEST)<br />
<br />
:Ja, sollte eigentlich klar sein, aber ich habe es mal eingebaut. Diskussionsbeiträge im Wiki können mittels {{ic|<nowiki>--~~~~</nowiki>}} signiert werden :) --[[Benutzer:Dirk|Dirk]] ([[Benutzer Diskussion:Dirk|Diskussion]]) 19:45, 14. Feb. 2014 (CET)<br />
<br />
== @DHCP-Server der noch "alten" Mechanismus benutzt ==<br />
Wenn man sich in einem Netzwerk befindet, in dem ein etwas älterer DHCP-Server befindet (Div. DHCP-Server von Microsoft unter Windows Server 2003-2008), der seine IP-Adressen anhand der MAC-Adresse verteilt, sollte in der /etc/dhcpcd.conf der Mechanismus für das erstellen der Client ID geändert werden von duid auf clientid... Erst dann erhält der DHCP-Server die (in seinen Augen) richtige MAC-Adresse und kann eine IP-Adresse zuweisen.<br />
<br />
== @ Die Datei /etc/hosts muss normalerweise nicht verändert werden, da das Paket nss-myhostname die Auflösung des Hostnames übernimmt. ==<br />
<br />
Leider nicht, wenn man LibreOffice verwendet: Hier muss der Hostname zwingend ergänzt werden, da es sonst beim Start der Anwendung ohne Internetverbindung etwa 30s dauern kann.<br />
<br />
Erledigt. Ich habs mal rausgemacht. Gruß [[Benutzer:Greg|Greg]] ([[Benutzer Diskussion:Greg|Diskussion]]) 11:49, 20. Okt. 2016 (CEST)<br />
<br />
== Microcode / intel-ucode ==<br />
Hallo zusammen,<br />
<br />
da ich selbst mit meinem Intel Rechner nicht immer 100%ig mein Arch Linux sauber hochfahren konnte und im Nachgang im Arch Beginner's Guide auf den Hinweis bzgl. Microcode / intel-ucode gestoßen bin, würde ich es für gut befinden, wenn auch im deutschen Anfängerguide (diesen hatte ich mir damals zur Installation als Vorlage genommen) darauf hingewiesen wird, dass es sinnvoll ist, für Intel CPU's das Package intel-ucode zu installieren.<br />
<br />
Quellen: <br />
- https://wiki.archlinux.org/index.php/beginners'_guide (Install a boot loader)<br />
- https://wiki.archlinux.org/index.php/Microcode#Enabling_Intel_microcode_updates<br />
<br />
Viele Grüße<br />
Christian<br />
<br />
PS: "UEFI standardmäßig" find ich in der heutigen Zeit ebenfalls gut.<br><br />
Ich habs hinzugefügt Gruß [[Benutzer:Greg|Greg]] ([[Benutzer Diskussion:Greg|Diskussion]])<br />
<br />
== Zur Beachtung: Es darf nur genfstab -p... oder genfstab -Lp... ausgeführt werden. ==<br />
<br />
Wieso soll das nur einmal ausgeführt werden? genfstab gibt ja einfach das fstab aus, und mit > wird das in die Datei geschrieben - wenn mans mehrmals macht, wird die Datei überschrieben. Wieso also nur einmal?<br />
<br />
Irgend woher hatte ich die Info aufgeschnappt. Ich glaube aus dem englischen Wiki. Ist aber wirklich schon was her. Es könnte aber auch sein, dass mal genfstab -pL >> /mnt/etc/stab drin stand. So würde die fstab jedesmal immer größer weil immer hinten dran was drangehängt wird.<br />
Ich habe mal eine Testinstallation durchgeführt und mehrere male genfstab -pL >... ausgeführt. Natürlich wie erwartet ist die Datei immer neu überschrieben worden. Die Prüfung hat ergeben, dass es wirklich nichts ausmacht mehrere male genfstab auszuführen. Daher wird der Satz entfernt.<br />
<br />
Vielen Dank für den Hinweis<br />
Gruß aus DN [[Benutzer:Greg|Greg]] ([[Benutzer Diskussion:Greg|Diskussion]]) 11:49, 20. Okt. 2016 (CEST)<br />
<br />
== Xorg ==<br />
Da es xorg-utils sowie xorg-server-utils nicht mehr gibt habe ich diese aus der Anleitung herausgenommen.<br />
Muss da anstelle ein anderes Paket stehen oder geht es so?<br />
Außerdem ist weiter unten noch ein Menüpunkt X Server Installieren?<br />
--------------------------<br />
Es müssen stattdessen keine weiteren Pakete installiert werden.<br />
Menüpunkt X server installieren weiter unten habe ich geändert in Minimal Xorg und entsprechende Beschreibung falls kein Desktop oder Windowmanager installiert werden soll. <br />
Vielen Dank für den Hinweis !!<br />
Gruß aus DN [[Benutzer:Greg|Greg]] ([[Benutzer Diskussion:Greg|Diskussion]]) 18:43, 20. Mai. 2017 (CEST)<br />
<br />
== Verschlüsseltes Homverzeichnis standardmäßig ==<br />
Ich finde es schade, daß hier an der Stelle nicht darauf eingegangen wird, wie der User während des laufenden Installationsvorgangs [b]'''sein'''[/b] Home Verzeichnis (on the fly) verschlüsseln kann. <br />
Hier fehte der Zeitstempel! Habe die Zeit hier reinkopiert damit mein Text getrennt bleibt 23:47, 24. Jan. 2018 (CET)<br />
<br />
Wo wird das denn in der Wiki beschrieben? Gibt es schon einen Artikel auf den man verlinken könnte?--[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 23:48, 24. Jan. 2018 (CET)<br />
<br />
== Erwähnte Gruppen zum Eintragen von Nutzern veraltet? ==<br />
In der Anleitung werden einige Gruppen erwähnt, in denen man neue Nutzer eintragen kann. Darunter sind audio, video, games und power.<br />
Davon sind audio und video im englischen "Users and Groups"-Artikel (https://wiki.archlinux.org/index.php/Users_and_groups) unter dem Abschnitt "Pre-systemd groups" als obsolet oder gar schädigend (im Falle von audio mit fast-user-switching) denunziert. Sollten sie daher nicht auch hier heraus genommen werden? Und generell stellt sich die Frage wie eine solche Aufzählung up-to-date zu halten ist.<br />
<br />
Vielleicht macht ein Link "Sicherheitsaspekt" hier Sinn. Meine Idee dazu ist, dass es eine "Anleitung für Einsteiger" ist. Wenn der Einsteiger kein Mitglied in der Audio Gruppe ist, und die Speaker nach dem Installationsmaraton nichts ausgeben, hat der viel zu viel Arbeit und steigt auf die Ubuntu Wiki um und wird in der Folge auch Gruppenmitglied von Audio.--[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 23:48, 24. Jan. 2018 (CET) <br />
<br />
== LTS Kernel ==<br />
Sollten man eventuel noch auf den LTS Kernel eingehen, da es immer mal wieder Probleme mit dem neuesten Kernel geben kann? [[Benutzer:Truemmerer|Truemmerer]] ([[Benutzer Diskussion:Truemmerer|Diskussion]]) 23:23, 09. Sep. 2018 (CEST)<br />
<br />
== Betr. Abschnitt [[Anleitung_für_Einsteiger#Systemkonfiguration]] ==<br />
Es betrifft eigentlich nur ein kleines Detail in der Zeile LANGUAGE=de_DE:de in der Datei /etc/locale.conf.<br />
Ich habe den Artikel abgeändert. Der jetzige Eintrag im Wiki Artikel war aus folgenden Gründen nicht optimal:<br />
Der Eintrag de_DE:de bewirkt, dass ein Programm, dass auf diesen Wert zurückgreift zuerst Deutsch aus Deutschland verwendet und als fallback Deutsch nimmt bevor falls es diese Übersetzung nicht gibt Englisch ausgegeben wird. Dieser Eintrag nutzt die Möglichkeiten des Systems also nur mäßig.<br />
Der jetzt von mir geänderte Wert de_DE:pt_Br wäre z.B für Brasilianer in Deutschland sehr interessant, da falls kein Deutsch hinterlegt ist, Brasilianisch genutzt wird bevor auf die englische Version zurückgegriffen wird.<br />
Zudem könnten sich die Schweizer, die auch unsere Wiki lesen, dabei auf die Idee kommen, dass de_CH:de_DE oder evt. de_DE:fr_FR eine passende Einstellung darstellt.<br />
Hintergrund dazu: [https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/The-LANGUAGE-variable.html Locale Environment Variables].--[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 23:48, 24. Jan. 2018 (CET)<br />
<br />
----------<br />
»''Der jetzt von mir geänderte Wert de_DE:pt_Br wäre z.B für Brasilianer in Deutschland sehr interessant, da falls kein Deutsch hinterlegt ist, Brasilianisch genutzt wird bevor auf die englische Version zurückgegriffen wird.''«<br />
<br />
Das ist in höchstem Maße irritierend und verwirrend – insbesondere für Einsteiger. Eine Anleitung für Einsteiger sollte den Einstieg erleichtern und nicht unnötig verkomplizieren. Für die Grundkonfiguration der deutschsprachigen locale.conf reicht<br />
echo LANG=de_DE.UTF-8 > /etc/locale.conf<br />
<br />
Für die EinsteigerInnen aus der Schweiz und Österreich wäre ein Verweis auf [[Arch Linux auf Deutsch stellen]] hinreichend.<br />
<br />
Für fortgeschrittene Spezifikationen und spezielle Sprach-Offsets gibt es den Artikel [[Locale]], wo deine Erläuterungen zum Thema Fallback keine Verwirrung stiften würden, sondern ein wirklicher Zugewinn wären. <br />
<br />
Auch dein Beispiel, wie eine komplette locale.conf aussehen könnte, wirft in der Anleitung für EinsteigerInnen nur neue und völlig unnötige Unsicherheiten auf: »''Sollte ich das jetzt besser alles dort rein schreiben weil meine locale.conf sonst nicht komplett ist?''« Wer eine komplette locale.conf sehen möchte, findet sie mit hinreichenden Erklärungen in [[Arch Linux auf Deutsch stellen]].<br />
<br />
[[Benutzer:Werner|Werner]] ([[Benutzer Diskussion:Werner|Diskussion]]) 06:24, 25. Jan. 2018 (CET)<br />
---------------<br />
Also, wenn ich das jetzt richtig verstehe, dann schlägst du vor die Konfiguration hier auf die Zeile echo LANG=de_DE.UTF-8 > /etc/locale.conf<br />
zu reduzieren und für die Tricks auf die Seite [[Arch Linux auf Deutsch stellen]] zu verlinken. Gut, dann müsste ich diese Seite noch ein klein wenig nachbearbeiten um mein brasilianisches Portugisisch dort einzuarbeiten.<br />
Das würde auch Sinn machen, da man eigentlich nur die variable LANG belegt haben muss, wenn die anderen Werte auch nur die selben Einträge haben. Also ich gehe gleich mal ins Wochenende und schau in paar Tagen ob es dagegen Einsprüche gibt und dann mach ich das so. --[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 09:49, 25. Jan. 2018 (CET)<br />
------------------<br />
Danke. Und habe ein schönes Wochenende!<br />
<br />
[[Benutzer:Werner|Werner]] ([[Benutzer Diskussion:Werner|Diskussion]]) 13:26, 25. Jan. 2018 (CET)<br />
<br />
== Neuinstallation: Dit fiel mir uff ==<br />
Erst einmal vielen Dank für diese gute Anleitung, besonderns auch weil sie weitergeht als die auf dem Installationsmedium Juni 2019 beigelegte englischsprachige Anleitung. Bei der Durcharbeitung sind mir jedoch ein paar Punkte aufgefallen, die ich, bevor ich sie selber in euren Artikel einbaue, hier ansprechen möchte:<br />
<br />
* Es wäre gut, wenn in der Einleitung stände: <br />
* ISO-Abbild prüfen: Grundsätzlich nach dem Herunterladen mittels HTTPS überprüfen(man will ja auch nicht riskieren den Brennvorgang wiederholen zu müssen) und zur Sicherheit auch noch einmal nach Brennen des Mediums.<br />
* ISO-Abbild auf USB-Stick übertragen: Ich möchte hier <b>balenaEtcher</b> empfehlen(gibts für Linux und Windows) und überprüft anschliessend das Medium <br />
** Etcher war für mich nicht so dolle, weil die Versorgung mit lauffähigen Quellen unter Arch Linux nicht so der Hit war, habe das Teil daher nicht mehr genutzt<br />
* ISO-Abbild auf Windows erstellen: Was ist von CDBurnerXP zu halten, ist auch kostenlos<br />
** XDBurnerXP soll laut Heise nur als Portable-Version installiert werden (Download dort), weil die Installations-Version von der Webseite eine Menge Werbe-Müll und Adware installieren möchte<br />
* Die Hardware-Uhr überprüfen: Es sollte darauf hingewiesen werden, dass Windows die Hardware-Uhr als mit Lokalzeit laufend voraussetzt. Man soll dies Verhalten zwar durch einen Registry-Eintrag ändern könnn aber das wird nicht supported. In Dual-Boot-Umgebungen ist also mit Problemen zu rechnen wenn die RTC auf UTC eingestellt ist. --[[Benutzer:Tecumseh|Tecumseh]] ([[Benutzer Diskussion:Tecumseh|Diskussion]]) 07:01, 26. Jun. 2019 (CEST)<br />
:: UTC unter Windows ist seit 8.1 kein Problem mehr. Es ist besser, diesen Weg zu wählen, da sonst beide Systeme beim ersten Start nach einer Zeitumstellung die Uhr umstellen, was immer zu Fehlern führt. Die Umstellung unter Windows abzuschalten ist keine Lösung, da dies zu einer falschen Zeitzone führt. --[[Benutzer:Bachsau|Bachsau]] ([[Benutzer Diskussion:Bachsau|Diskussion]]) 16:26, 25. Okt. 2020 (CET)<br />
<br />
== Netzwerkverbindung herstellen: Dreizeiler klappt so nicht mehr ==<br />
Bei der Konfiguration für ein verschlüsseltes WLAN mit WPA/WPA2 klappt der "Dreizeiler" nicht so, wie dort angegeben.<br />
<br />
Er klappt aber, wenn wext durch nl80211 ersetzt wird. Also<br />
<br />
wpa_passphrase SSID Passwort > /etc/wpa_supplicant/wpa_supplicant.conf<br />
wpa_supplicant -i wlp0s1 -D nl80211 -c /etc/wpa_supplicant/wpa_supplicant.conf -B<br />
dhcpcd wlp0s1<br />
<br />
== Netzwerk automatisch starten ==<br />
In der Anleitung steht ja, dass man nach dem Neustart das Netzwerk erneut starten muss.<br />
Zusätzlich muss man nach dem Neustart wieder die deutsche Tastatur aktivieren durch<br />
loadkeys de<br />
loadkeys de-latin1-nodeadkeys<br />
Es fehlt ein Weg, wie man diese beiden Aufgaben am einfachsten so einrichtet, dass sie nach jedem Neustart automatisch erfolgen.<br />
Beim Netzwerk wird der meist genutzte Weg sein, NetworkManager nach der Installation der grafischen Oberfläche einzurichten und auch automatisch zu starten.<br />
Auch erst nach der Installation der grafischen Oberfläche kann die Tastatur auch für X fest eingestellt werden.<br />
localectl --no-convert set-keymap de-latin1-nodeadkeys<br />
localectl --no-convert set-x11-keymap de pc105 nodeadkeys<br />
Ein Link zu https://wiki.archlinux.de/title/Arch_Linux_auf_Deutsch_stellen wäre sinnvoll.<br />
<br />
== X11 manuell starten ==<br />
Man könnte das Thema "X11 manuell starten" auf eine Seite packen und es für die gesamte Wiki dort einmal ab handeln.<br />
Zur Zeit steht es auf der Einsteiger Seite X mal und auf jeder GUI - Seite noch einmal da.<br />
Es heißt zwar X11 aber es muss doch nicht sein, dass daraus Programm wird und es deshalb auch 11 X im Wiki stehen muss.<br />
<br />
== Änderungen in '''Installation weiterer Pakete''' ==<br />
[[Benutzer:bj00rn|bj00rn]] 20.01.2020<br />
<br />
Ich habe dhcpcd als empfehlenswertes Paket hinzugefügt und außerdem (in meinem Fall funktionierende) Lösungsvorschläge für Probleme, die ich bei der Erstinstallation hatte ergänzt: /etc/mtab als Symlink, ausführen von pacman in arch-chroot anstatt mit --sysroot /mnt. Der Hinweis auf LVM scheint mir auch zweckmäßig (weil ich es nutze).<br />
<br />
== /etc/vconsole.conf ==<br />
Die dort vorgenommenen Einstellungen griffen bei mir erst, nachdem ich mit ''nano'' die Datei ''/etc/mkinitcpio.conf'' angepasst habe. Und zwar habe ich im Abschnitt ''HOOKS'' hinter ''base'' noch ''systemd'' und hinter ''keyboard'' noch ''sd-vconsole'' eingefügt. (Danach ''mkinitcpio -p linux'' nicht vergessen.) Der Tipp stammt von: https://bbs.archlinux.org/viewtopic.php?pid=1789763#p1789763<br />
<br />
Kann der Eintrag ''udev'' eigentlich raus? Der Hook scheint zu busybox init zu gehören (siehe [https://wiki.archlinux.org/index.php/Mkinitcpio#Common_hooks Common hooks]), während standardmäßig ja nun ein systemd init durchgeführt wird.<br />
<br />
Wäre prima, wenn das jemand mit Arch-Erfahrung prüfen könnte, weil ich als Einsteiger die möglichen Nebenwirkungen nicht abschätzen kann. &ndash; Danke!<br />
<br />
[[Benutzer:Bttr|Bttr]] ([[Benutzer Diskussion:Bttr|Diskussion]]) 15:02, 31. Jan. 2020 (CET)<br />
<br />
== Änderungen in '''Installation weiterer Pakete''' ==<br />
[[Benutzer:bj00rn|bj00rn]] 20.01.2020<br />
<br />
Ich habe dhcpcd als empfehlenswertes Paket hinzugefügt und außerdem (in meinem Fall funktionierende) Lösungsvorschläge für Probleme, die ich bei der Erstinstallation hatte ergänzt: /etc/mtab als Symlink, ausführen von pacman in arch-chroot anstatt mit --sysroot /mnt. Der Hinweis auf LVM scheint mir auch zweckmäßig (weil ich es nutze).<br />
<br />
== /etc/vconsole.conf ==<br />
Die dort vorgenommenen Einstellungen griffen bei mir erst, nachdem ich mit ''nano'' die Datei ''/etc/mkinitcpio.conf'' angepasst habe. Und zwar habe ich im Abschnitt ''HOOKS'' hinter ''base'' noch ''systemd'' und hinter ''keyboard'' noch ''sd-vconsole'' eingefügt. (Danach ''mkinitcpio -p linux'' nicht vergessen.) Der Tipp stammt von: https://bbs.archlinux.org/viewtopic.php?pid=1789763#p1789763<br />
<br />
Kann der Eintrag ''udev'' eigentlich raus? Der Hook scheint zu busybox init zu gehören (siehe [https://wiki.archlinux.org/index.php/Mkinitcpio#Common_hooks Common hooks]), während standardmäßig ja nun ein systemd init durchgeführt wird.<br />
<br />
Wäre prima, wenn das jemand mit Arch-Erfahrung prüfen könnte, weil ich als Einsteiger die möglichen Nebenwirkungen nicht abschätzen kann. &ndash; Danke!<br />
<br />
[[Benutzer:Bttr|Bttr]] ([[Benutzer Diskussion:Bttr|Diskussion]]) 15:02, 31. Jan. 2020 (CET)<br />
<br />
==@ Linux Kernel erzeugen:==<br />
Der angegebene Befehl 'mkinitcpio -p linux' erzeugt keinen Linux-Kernel sondern ein 'anfängliches, frühes Ram-Filesystem' (initramfs) welches einen 'early userspace' beim Booten bereitstellt. Es dient dem Laden von verschiedenen Kernel-Modulen und dem Setzen diverser Einstellungen bevor der Bootprozess dem eigentlichen Init-Dienst (hier: systemd) übergeben wird.<br />
Dies ist bei der Installation nicht erforderlich, sofern keine Fesplattenverschlüsselung, -komprimierung oder RAID zum Booten bereit stehen müssen.<br><br />
Frage:<br />
Wie könnte man das in der Anleitung kurz formulieren ohne zuviel Fachchinesisch?--[[Benutzer:Greg|Greg]] ([[Benutzer Diskussion:Greg|Diskussion]]) 11:49, 20. Okt. 2016 (CEST)<br />
<br />
<br />
<br />
=Grundsätzliche Überarbeitung=<br />
=== UEFI standardmäßig ===<br />
Bin auch dafuer. habe es gerade hinter mir, und musste - nachdem die Anleitung nicht mehr funktionierte - die Information aus verschiedenen Page zusammensuchen. Definitiv nix fuer Einsteiger. Wie ist den hier das editieren geregelt? Ist es erwuenscht, das ich versuche den Aktikel zu verbessern? Alles nicht so einfach. Liebe Gruesse, Frank<br />
<br />
Wäre ich eigentlich auch dafür sowie Hinweise bezüglich SSD [[Benutzer:Truemmerer|Truemmerer]] 23:25, 09.09.2018<br />
<br />
Es ist ja schon was Zeit vergangen, die neuen Rechner haben alle UEFI-Boot. Sollten wir standardmäßig auf UEFI umschreiben und einen Link machen zum Booten per Bios?<br />
Gruß aus DN [[Benutzer:Greg|Greg]] ([[Benutzer Diskussion:Greg|Diskussion]]) 11:49, 16. Okt. 2017 (CEST)<br />
<br />
Frage an Euch, besteht ein Interesse das Ding standardmäßig auf UEFI mit systemd-boot umzuschreiben? Oder ein Abschnitt mit UEFI Installation und ein Abschnitt mit Legacy-Bios.<br />
Es gibt ja nur noch neue Rechner mit UEFI Bios. Hier im Forum sind schon so manche über die UEFI Anleitungen gestolpert und nicht zurechtgekommen.<br><br />
Weitere Möglichkeit, ein Beispiel zusammen mit Windoof10. Nur mit Berücksichtigung der vorhandenen Partitionen. (Nächste Weihnachten kommt bestimmt mit vorinstalliertem Winzeug. Würg).<br><br />
Könnte dann so aussehen:<br><br />
Hier im Beispiel wird davon ausgegangen, dass Windows 10 bereits installiert ist. Die angelegten Partitionen sind.... Es kommt für Arch-Linux eine Root und eine swap Partition hinzu....<br><br />
Hier steht noch mehr: https://bbs.archlinux.de/viewtopic.php?pid=342366#p342366<br />
<br />
Gruß aus DN [[Benutzer:Greg|Greg]] ([[Benutzer Diskussion:Greg|Diskussion]]) 11:49, 20. Okt. 2016 (CEST)<br />
<br />
[[Benutzer:bj00rn|bj00rn]], 18.01.2020: Ich halte eine Umstellung auf UEFI für wünschenswert.<br />
<br />
=== Gegen UEFI als Standard ===<br />
Es sollte etwas geschehen, damit der Einsteiger eine klare Richtschnur erhält. Das wird für UEFI zur Zeit schlecht realisiert.<br />
Ausschließlich UEFI als Standard zu setzen, hat aber auch wieder Nachteile. <br />
So gehören 32 Bit und ARM auch zu Arch Linux und deutschsprachige Nutzer ziehen genauso wie der UEFI-Mainstream diese Wiki hier zu Rate.<br />
<br />
Mein Vorschlag wäre in etwa die folgende Aufteilung:<br />
<br />
Überschrift:<br />
Installation des Bootsystems und Partitionierung<br />
<br />
Rechner mit:<br />
<br />
- Bios und 32 Bit<br />
<br />
- Bios und 64 Bit<br />
<br />
- UEFI (32) und 64 Bit Rechner<br />
<br />
- UEFI und 64 Bit Rechner<br />
<br />
- Coreboot<br />
<br />
- ARM<br />
<br />
Man hätte so die Möglichkeit, die einzelnen Abschnitte zu straffen.<br />
Der Leser hätte einen klar definierten Verzweigungspunkt und bräuchte sich dann nicht mehr mit Hinweisen auseinandersetzen die ihn gar nicht betreffen.<br />
Am Ende des Abschnittes wird jeweils ein Hinweis-Link für den Wiedereinstiegspunt in den Rest der Anleitung gesetzt. <br />
<br />
Ob dies mit einzelnen Artikel und entsprechender Verlinkung erfolgt oder ob dies integriert im Hauptartikel stattfindet ist dann eher nebensächlich.<br />
Gruß --[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 20:41, 28. Dez. 2018 (CET)<br />
<br />
== Überladene Anleitung ==<br />
Die '''Anleitung für Einsteiger''' sollte imho ein knapper Leitfaden sein, ein Lauffähiges Basissystem zu bekommen.<br />
Daher ist mMn alles ab [https://wiki.archlinux.de/title/Anleitung_f%C3%BCr_Einsteiger#Teil_2:_Installation_von_X_und_Konfiguration Punkt Nr. 3] überflüssig. Die Installation und Konfiguration der verschiedenen Bootloader und die EFI/MBR Optionen sollten in separaten Artikeln behandelt werden.<br />
<br />
Ebenso überflüssig finde ich die Abschnitte '''Weitere nützliche Dienste''' und die folgenden.<br />
Diese können besser in separaten Artikeln behandelt werden.<br />
[[Benutzer:Schard|Schard]] ([[Benutzer Diskussion:Schard|Diskussion]]) 15:07, 16. Jul. 2020 (CEST)<br />
----------<br />
:Alle ein, zwei Jahre kommt das Thema nun schon hoch, seit ich dabei bin. Nach dem dritten oder vierten Mal habe ich mich inzwischen komplett ausgeklinkt. Folgende wartbare allgemeine Anleitungen zum Installieren haben wir.<br />
:<br />
:* https://wiki.archlinux.de/title/Arch_Install_Scripts<br />
:* https://wiki.archlinux.de/title/Installations-Kurzanleitung<br />
:* https://wiki.archlinux.org/index.php/Installation_guide<br />
:<br />
:Wir sollten dieses Monstrum hier ersatzlos durch eine der genannten Anleitungen ersetzen. Es kann nur besser werden.<br />
:<br />
:Abgesehen davon ist alles, was nicht zur Grundinstallation (von mir aus mit Installation von X und einem WM oder DE) gehört nichts, das in einer Installationsanleitung irgendwas verloren hätte.<br />
:<br />
:Nach all den Jahren darf das aber gern jemand machen, der Bock darauf hat.<br />
:<br />
:--[[Benutzer:Dirk|Dirk]] ([[Benutzer Diskussion:Dirk|Diskussion]]) 15:43, 16. Jul. 2020 (CEST)<br />
<br />
-----------<br />
Du schreibst das du dich komplett ausgeklingt hast, die Frage ist warum?<br />
Wurdest du behindert, oder hat dich niemand unterstützt?<br />
Und wer entscheidet am Schluss?<br />
<br />
Wenn hier eine detaillierte Zusammenfassung aller Artikel die auszugliedern sind stehen würde und jeder der mitmachen möchte seinen Namen hinter den Abschnitt schreibt, müsste das doch zu machen sein. Oder nicht?<br />
<br />
Henrikx 16:19, 16. Jul. 2020 (CEST)<br />
--------------<br />
:Ich schliesse mich da komplett Dirk an. Wie er einst so schön und unvergesslich sagte, ist diese Anleitung ein unwartbarer Moloch.<br />
:Offensichtlich stiftet diese Anleitung mehr Verwirrung, als das sie jemandem nützt. Ich bin auch dafür, die Installations-Kurzanleitung als Einsteigeranleitung zu verwenden. Die Arch_Install_Scripts finde ich persönlich super, aber für Einsteiger zu abschreckend.<br />
[[Benutzer:Bogomips|Bogomips]] ([[Benutzer Diskussion:Bogomips|Diskussion]]) 22:26, 16. Jul. 2020 (CEST)bogomips<br />
<br />
-----------<br />
Wenn dem so ist, oder wäre, warum nicht das englische Werk übersetzen?<br />
<br />
Henrikx 10:43, 17. Jul. 2020 (CEST)<br />
<br />
------------<br />
Es kann nur besser werden :-) Und, es muss auch besser werden!<br />
Für jemanden der weiß was er tut, es schon öfter getan hat und eine Vorstellung besitzt genügt eine schnöde Liste die er/sie abarbeiten kann, für Einsteiger ist es aber wichtig, eine ausführliche Anleitung zu haben. Ich bin deshalb dagegen alles zu löschen.<br />
Da sich niemand anderes berufen fühlt, den "unwartbarer Moloch" aufzuarbeiten, werfe ich mich mal in den Ring und werde etliches aus der Anleitung löschen und versuchen an den neuralgischen Punkten wieder etwas Struktur herbeizuführen. Sicherlich wird das ein paar Wochen in Anspruch nehmen. Ich werde das auch nur nach und nach machen können. Am Praktischsten wird es sein, von unten her Aufzuräumen.<br />
<br />
Ich lösche jetzt schon einmal Teil 3 ff. - Ich denke hier besteht allgemeiner Konsens.<br />
Danach ist mMn. das Kapitel "Desktopumgebung und Fenstermanager installieren" daran entschlackt zu werden. Das Prinzip sollte dargestellt werden, die Installation einer bestimmten GUI/DE aber in den betreffenden Beitrag ausgelagert werden. (So weit ich weiß, seht in den einzelnen Beiträgen auch schon alles dazu drin.)<br />
"Die Installation und Konfiguration der verschiedenen Bootloader und die EFI/MBR Optionen" werde ich danach anpacken. Hier werde ich sehr wahrscheinlich Hilfe benötigen.<br />
Jedenfalls bilden die verschiedenen Bootloader, EFI/MBR, fdisk/gdisk, LVM uva. momentan in dem Kapitel Partitionieren ein logisches Knäul.<br />
Der erfahrene Arch Linuxer weiß welchen Bootloader er/sie benutzen will und hat dank eigener Prioritäten viel weniger Fragen. <br />
Der Einsteiger hört diese Begriffe aber vielleicht das erste mal und im Kapitel Partitionieren soll er dann 20 komplizierte Sachverhalte durchschauen und eine Entscheidung treffen. Das Ganze sollte also in eine möglichst klare Abfolge gefasst werden.<br />
Ich bin mir da noch nicht ganz sicher, ob es hier die Lösung ist alles in Einzelbeiträge auszulagern oder in der Anleitung eine UEFI Installation als Standard zu setzen.<br />
Mal sehen wie das am besten klappt.<br />
Jedenfalls halte ich es für wichtig, genau an dieser Stelle Anleitung zu geben. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 01:53, 22. Jul. 2020 (CEST)<br />
<br />
== Hinweis auf Lynx ==<br />
Erst einmal vielen Dank für diese gute Anleitung, besonderns auch weil sie weitergeht als die auf dem Installationsmedium Juni 2019 beigelegte englischsprachige Anleitung. Bei der Durcharbeitung sind mir jedoch ein paar Punkte aufgefallen, die ich, bevor ich sie selber in euren Artikel einbaue, hier ansprechen möchte:<br />
* Es wäre gut, wenn in der Einleitung stände: Auf dem Installationsmedium ist als Browser [[Elinks]] vorinstalliert, so dass ihr unserer Anleitung einfach durch Eingabe vpn [https://archlinux.de Anleitung für Einsteiger] folgen könnt. Ein einfaches Umschalten zwischen den Konsolen ist mittels Alt+(Pfeil-Links) bzw. Alt+(Pfeil-Rechts) möglich.<br />
<br />
Ist mittlerweile in die Anleitung integriert, siehe: Spickzettel. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:33, 4. Jan. 2023 (CET) <br />
<br />
=Gründliche Überarbeitung der Anleitung=<br />
Da ansonsten nur die Löschung in Frage gekommen wäre, habe ich mich getraut, den gesamten Beitrag von Grund auf neu zu überarbeiten.<br />
Der Byte-Umfang hat sich halbiert. Vom Inhalt her hat es keine Abstriche gegeben. Themen wie Bios, UEFI, Verschlüsselung, Btrf und Bootloader, sind klar voneinander abgegrenzt und machen es dem Einsteiger einfach seine Wahl zu treffen. Zudem nehmen diese Themen kaum noch Platz ein. Ich hoffe, dass mit dieser Lösung auch alle zufrieden sind die lieber ganz auf UEFI umschwenken wollten.<br />
Habe die obigen Diskussionsbeiträge geordnet und sie ggf. berücksichtigt. Falls allgemeiner Konsens besteht schlage ich vor sie dann allesamt zu löschen, weil der Artikel nicht mehr dem alten entspricht und dann auch eventuelle Änderungsvorschräge auf der neuen Grundlage stattfinden sollten. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 23:14, 13. Dez. 2020 (CET)<br />
<br />
<br />
==Reihenfolge der Installation==<br />
<br />
Ich würde gerne die Reihenfolge an einem Punkt ändern, weiß aber nicht, ob ich hier etwas Wichtiges übersehe.<br />
<br />
Ich hätte gerne, dass die Herstellung einer Internetverbindung erst nach dem Reboot erklärt wird.<br />
So wie es jetzt da steht, bildet das Kapitel Internet einen riesigen Block zwischen dem Mounten und der Basis-Installation. Das ist für das Verständnis recht ungünstig. Außerdem entsteht so eine Art Loop in der Anleitung, da man nach dem Reboot die Internetverbindung erneut herstellen muss.<br />
<br />
Ich sehe den einzigen Nachteil einer Umstellung darin, dass kein Alternativer Editor geladen werden kann. Der Einsteiger benötigt aber keine alternativen Editoren und der Erfahrene benötigt die ganze Anleitung für Einsteiger nicht bzw. hindert ihn die Umstellung wenig daran es trotzdem zu tun.<br />
<br />
Übersehe ich da etwas? Ist alles Benötigte auf der ISO? Was haltet ihr davon das Kapitel Internet erst nach dem Reboot zu besprechen?<br />
<br />
:„Übersehe ich da etwas?“, ja :) Für die Installation ist eine Internetverbindung nötig. Es muss daher also vor der Basis-Installation eine Verbindung hergestellt werden. Ob dies vor oder nach dem Mounten geschieht, ist aber irrelevant. --[[Benutzer:Dirk|Dirk]] ([[Benutzer Diskussion:Dirk|Diskussion]]) 10:16, 18. Jan. 2021 (CET)<br />
<br />
Danke ! Dann verschiebe ich nur das Mounten nach unten, damit der Zusammenhang mit der Installation der Basispakete und den nachfolgenden Chrooten deutlicher wird. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 20:37, 18. Jan. 2021 (CET)<br />
<br />
==Partitions LABEL==<br />
<br />
Ich würde gerne für die LABELs konventionsgemäß Großbuchstaben verwenden.<br />
Dann würde aus:<br />
<br />
* p_arch - ARCH<br />
* p_swap - SWAP<br />
* p_home - HOME<br />
<br />
Bei dem Namen EFIBOOT bekomme ich Pickel. <br />
Den Namen AESP (für ARCH-ESP) fände ich hier viel treffender auch was die Abgrenzung bei einem möglichen Dualboot mit Windows angeht.<br />
Was haltet ihr davon? [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 23:03, 4. Jun. 2021 (CEST)<br />
: p_arch ist für /, oder? Warum nicht ROOT? Und für die Boot-Partition einfach BOOT? Dann wäre alles einfach und generisch: HOME, klar; BOOT für die Bootpartition - egal, was da nun genutzt wird; und ROOT für eben das Rootverzeichnis. --[[Benutzer:Dirk|Dirk]] ([[Benutzer Diskussion:Dirk|Diskussion]]) 11:20, 7. Jun. 2021 (CEST)<br />
<br />
::Für "ARCH" als Label der Root Partition würde sprechen, dass andere Distros hier auch ihren Namen verwenden. Wenn jemand mehrere Systeme installiert weiß er so besser was da was ist.<br />
::Bei "AESP" war mein Gedanke, dass ESP der beste technische Ausdruck dafür ist und auch in der englischen Wiki häufig Verwendung findet.<br />
::Dabei geht es mir ein wenig um Sprachregelung. Wenn sich jemand im Forum meldet dann ist mit AESP alles gesagt. Wenn er Boot sagt, muss er erst einmal erklären, ob er jetzt die Partition oder den Vorgang damit meint.<br />
::Dein Vorschlag gefällt mir aber auch recht gut. Ich warte noch mal ein wenig ab, vielleicht hat ja jemand noch eine gute Idee bzw. gute Argumente.[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 12:01, 7. Jun. 2021 (CEST)<br />
<br />
<br />
=Offene Themen=<br />
<br />
<br />
== @Das Basissystem installieren/Installation der Basispakete ==<br />
<br />
vor dem pacstrap Befehl ist es gut die GPG Schlüssel mit "pacman -Sy archlinux-keyring" zu aktualisieren, ich habe stundenlange Fehlermeldungen bekommen bevor ich diesen Hinweis in einem Forum gefunden habe!<br />
<br />
:Ist denn das arch-installationsmedium aktuell gewesen? [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:33, 4. Jan. 2023 (CET)</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Sway&diff=23805Sway2022-12-26T17:15:49Z<p>Tuxnix: /* Konfiguration */</p>
<hr />
<div>{{SEITENTITEL:sway}}{{righttoc}}[[Bild:Sway Wallpaper Blue 1920x1080.png|thumb|360px|Sway (Wallpaper)]]<br />
<br />
Sway ist ein Tiling Compositor für Wayland.<br />
{{Hinweis|Sway unterstützt keine proprietären Grafiktreiber. Für Nvidia-Karten ist der Treiber Nouveau zu nutzen.}}<br />
<br />
{{installation|paket=sway|repo=community}}<br />
<br />
Ergänzend stehen einige Tools zur Verfügung die in der Standartkonfiguration bereits mit eingebunden sind:<br />
<br />
* {{Paket|foot}} - Terminalemulator<br />
* {{Paket|dmenu}} - Anwendungslauncher<br />
* {{Paket|swaybg}} - Sway-Wallpaper<br />
<br />
Des Weiteren sind die folgenden Schriftarten empfohlen:<br />
<br />
* {{Paket|ttf-roboto}}<br />
* {{Paket|ttf-font-awesome}}<br />
<br />
Sollte man keine Alternativen Tools (s. unten) bevorzugen, dann lautet der komplette Installationsbefehl:<br />
pacman -S sway foot dmenu swaybg ttf-roboto ttf-font-awesome<br />
<br />
== Umstieg von i3 ==<br />
Sway ist bis auf wenige Features, die nur auf X11 Sinn machen, mit der Konfiguration von i3, i3 IPC, i3-gaps, und i3bar kompatibel. Es empfiehlt sich die bisherige i3-Konfigurationsdatei nach {{ic|~/.config/sway/config}} zu kopieren. Weitere Tipps sind vom [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] zu erfahren.<br />
<br />
== Sway Starten ==<br />
Eine Sway Sitzung kann auf verschiedene Arten gestartet werden:<br />
* Nach dem login auf TTY mit der Eingabe {{ic|sway}}<br />
* oder automatisch nach Einfügen der Zeile {{ic|[ "$(tty)" &#61; "/dev/tty1" ] && exec sway}} in die {{ic|~/.bash_profile}} Datei.<br />
* Mittels modernem [[Login-Manager]] wie [[GDM]] oder SDDM bzw. einem der [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway#login-managers hier] gelisteten.<br />
<br />
== Tastaturbefehle (default) ==<br />
{|<br />
|{{taste|mod}} + {{taste|1}}-{{taste|0}}<br />
| - Ein Fenster öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Return}}<br />
| - Ein Terminal öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Pfeil}}<br />
| - Den Fensterfokus wechseln<br />
|-<br />
|{{taste|mod}} + {{taste|d}}<br />
| - Den Anwendungsstarter aufrufen<br />
|-<br />
|{{taste|mod}} + {{taste|f}}<br />
| - Vollbildmodus ein-/ ausschalten<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|1}}-{{taste|0}}<br />
| - Die laufende Anwendung auf ein Fenster verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|c}}<br />
| - Die config Datei neu einlesen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|Pfeil}}<br />
| - Ein Fenster horizontal oder vertikal verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|q}}<br />
| - Eine Anwendung schließen <br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|e}}<br />
| - Sway beenden<br />
|}<br />
<br />
== Konfiguration ==<br />
Möchte man die vorgegebene Konfiguration anpassen, so wird empfohlen die Konfigurationsdatei ins eigene Benutzerverzeichnis zu kopieren und nur diese zu bearbeiten.<br />
mkdir ~/.config/sway<br />
cp /etc/sway/config ~/.config/sway/config<br />
<br />
Die folgende Auflistung führt einige zusätzlichen Tools und die jeweiligen dazugehörigen Einstellungen in der {{ic|~/.config/sway/config}} Datei auf. Eine komplette Liste von Sway-Ad-Ons ist [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway hier] abrufbar.<br />
{|<br />
|'''Paket/Einstellungen'''<br />
|'''Config-Eintrag (Bsp.)'''<br />
|-<br />
|{{taste|Win}} als mod-Taste<br />
|{{ic|set $mod Mod4}} (default)<br />
|-<br />
|{{taste|Alt}} als mod-Taste<br />
|{{ic|set $mod Mod1}}<br />
|-<br />
|Deutsches Tastaturlayout<br />
|{{ic|input * xkb_layout "de"}}<br />
|-<br />
|Auflösung<br />
|{{ic|output * resolution --custom 1920x1080}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Terminal-Emulatoren:''<br />
|<br />
|-<br />
|{{paket|foot}}<br />
|{{ic|set $term foot}} (default)<br />
|-<br />
|{{paket|alacritty}}<br />
|{{ic|set $term alacritty}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Wallpaper:''<br />
|<br />
|-<br />
|{{paket|swaybg}}<br />
|{{ic|output * bg <image-datei> fill}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Anwendungs-Lancher:''<br />
|<br />
|-<br />
|{{paket|dmenu}}<br />
|{{ic|set $menu dmenu_path &#124; dmenu &#124; xargs swaymsg exec --}} (default)<br />
|-<br />
|{{paket|wofi}}<br />
|{{ic|set $menu wofi --show run --exec-search}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Symbolleisten:''<br />
|<br />
|-<br />
|sway-bar (eingebaut)<br />
|siehe config Datei (default) <br />
|-<br />
|{{paket|waybar}}<br />
|{{ic|bar swaybar command waybar}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Idle Management Daemon und Screenlocker:''<br />
|<br />
|-<br />
|{{paket|swayidle}} und {{paket|swaylock}}<br />
|Das Beispiel in der config auskommentieren<br />
|}<br />
<br />
== siehe auch ==<br />
* [[i3]]<br />
<br />
== Weblinks ==<br />
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] {{sprache|en}}<br />
* [https://github.com/swaywm/sway/wiki Sway Wiki] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=hRIGYUWQfYU Sway Install Guide (Video)] {{sprache|en}}<br />
* [https://medium.com/hacker-toolbelt/linuxs-sway-window-manager-c39abe0b7bc9 A short install guide] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=oUpvtCEGrxQ Waybar Customization (Video)] {{sprache|en}}<br />
<br />
[[Kategorie:Fenstermanager]]<br />
[[en:sway]]</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Sway&diff=23804Sway2022-12-26T17:11:14Z<p>Tuxnix: Vollbildmodus</p>
<hr />
<div>{{SEITENTITEL:sway}}{{righttoc}}[[Bild:Sway Wallpaper Blue 1920x1080.png|thumb|360px|Sway (Wallpaper)]]<br />
<br />
Sway ist ein Tiling Compositor für Wayland.<br />
{{Hinweis|Sway unterstützt keine proprietären Grafiktreiber. Für Nvidia-Karten ist der Treiber Nouveau zu nutzen.}}<br />
<br />
{{installation|paket=sway|repo=community}}<br />
<br />
Ergänzend stehen einige Tools zur Verfügung die in der Standartkonfiguration bereits mit eingebunden sind:<br />
<br />
* {{Paket|foot}} - Terminalemulator<br />
* {{Paket|dmenu}} - Anwendungslauncher<br />
* {{Paket|swaybg}} - Sway-Wallpaper<br />
<br />
Des Weiteren sind die folgenden Schriftarten empfohlen:<br />
<br />
* {{Paket|ttf-roboto}}<br />
* {{Paket|ttf-font-awesome}}<br />
<br />
Sollte man keine Alternativen Tools (s. unten) bevorzugen, dann lautet der komplette Installationsbefehl:<br />
pacman -S sway foot dmenu swaybg ttf-roboto ttf-font-awesome<br />
<br />
== Umstieg von i3 ==<br />
Sway ist bis auf wenige Features, die nur auf X11 Sinn machen, mit der Konfiguration von i3, i3 IPC, i3-gaps, und i3bar kompatibel. Es empfiehlt sich die bisherige i3-Konfigurationsdatei nach {{ic|~/.config/sway/config}} zu kopieren. Weitere Tipps sind vom [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] zu erfahren.<br />
<br />
== Sway Starten ==<br />
Eine Sway Sitzung kann auf verschiedene Arten gestartet werden:<br />
* Nach dem login auf TTY mit der Eingabe {{ic|sway}}<br />
* oder automatisch nach Einfügen der Zeile {{ic|[ "$(tty)" &#61; "/dev/tty1" ] && exec sway}} in die {{ic|~/.bash_profile}} Datei.<br />
* Mittels modernem [[Login-Manager]] wie [[GDM]] oder SDDM bzw. einem der [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway#login-managers hier] gelisteten.<br />
<br />
== Tastaturbefehle (default) ==<br />
{|<br />
|{{taste|mod}} + {{taste|1}}-{{taste|0}}<br />
| - Ein Fenster öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Return}}<br />
| - Ein Terminal öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Pfeil}}<br />
| - Den Fensterfokus wechseln<br />
|-<br />
|{{taste|mod}} + {{taste|d}}<br />
| - Den Anwendungsstarter aufrufen<br />
|-<br />
|{{taste|mod}} + {{taste|f}}<br />
| - Vollbildmodus ein-/ ausschalten<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|1}}-{{taste|0}}<br />
| - Die laufende Anwendung auf ein Fenster verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|c}}<br />
| - Die config Datei neu einlesen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|Pfeil}}<br />
| - Ein Fenster horizontal oder vertikal verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|q}}<br />
| - Eine Anwendung schließen <br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|e}}<br />
| - Sway beenden<br />
|}<br />
<br />
== Konfiguration ==<br />
Möchte man die vorgegebene Konfiguration anpassen, so wird empfohlen die Konfigurationsdatei ins eigene Benutzerverzeichnis zu kopieren und nur diese zu bearbeiten.<br />
mkdir ~/.config/sway<br />
cp /etc/sway/config ~/.config/sway/config<br />
<br />
Die folgende Auflistung führt einige zusätzlichen Tools und die jeweiligen dazugehörigen Einstellungen in der {{ic|~/.config/sway/config}} Datei auf. Eine komplette Liste von Sway-Ad-Ons ist [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway hier] abrufbar.<br />
{|<br />
|'''Paket/Einstellungen'''<br />
|'''Config-Eintrag (Bsp.)'''<br />
|-<br />
|{{taste|Win}} als mod-Taste<br />
|{{ic|set $mod Mod4}} (default)<br />
|-<br />
|{{taste|Alt}} als mod-Taste<br />
|{{ic|set $mod Mod1}}<br />
|-<br />
|Deutsches Tastaturlayout<br />
|{{ic|input * xkb_layout "de"}}<br />
|-<br />
|Auflösung<br />
|{{ic|output * resolution --custom 1920x1080}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Terminal-Emulatoren:''<br />
|<br />
|-<br />
|{{paket|foot}}<br />
|{{ic|set $term foot}} (default)<br />
|-<br />
|{{paket|alacritty}}<br />
|{{ic|set $term alacritty}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Wallpaper:''<br />
|<br />
|-<br />
|{{paket|swaybg}}<br />
|{{ic|output * bg <datei>.png fill}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Anwendungs-Lancher:''<br />
|<br />
|-<br />
|{{paket|dmenu}}<br />
|{{ic|set $menu dmenu_path &#124; dmenu &#124; xargs swaymsg exec --}} (default)<br />
|-<br />
|{{paket|wofi}}<br />
|{{ic|set $menu wofi --show run --exec-search}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Symbolleisten:''<br />
|<br />
|-<br />
|sway-bar (eingebaut)<br />
|siehe config Datei (default) <br />
|-<br />
|{{paket|waybar}}<br />
|{{ic|bar swaybar command waybar}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Idle Management Daemon und Screenlocker:''<br />
|<br />
|-<br />
|{{paket|swayidle}} und {{paket|swaylock}}<br />
|Das Beispiel in der config auskommentieren<br />
|}<br />
<br />
<br />
== siehe auch ==<br />
* [[i3]]<br />
<br />
== Weblinks ==<br />
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] {{sprache|en}}<br />
* [https://github.com/swaywm/sway/wiki Sway Wiki] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=hRIGYUWQfYU Sway Install Guide (Video)] {{sprache|en}}<br />
* [https://medium.com/hacker-toolbelt/linuxs-sway-window-manager-c39abe0b7bc9 A short install guide] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=oUpvtCEGrxQ Waybar Customization (Video)] {{sprache|en}}<br />
<br />
[[Kategorie:Fenstermanager]]<br />
[[en:sway]]</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Sway&diff=23776Sway2022-12-13T21:12:53Z<p>Tuxnix: sway-wallpaper</p>
<hr />
<div>{{SEITENTITEL:sway}}{{righttoc}}<br />
<br />
Sway ist ein Tiling Compositor für Wayland der als kompatibler Ersatz für [[i3]] konzipiert wurde.<br />
{{Hinweis|Sway unterstützt keine proprietären Grafiktreiber. Für Nvidia-Karten ist der Treiber Nouveau zu nutzen.}}<br />
<br />
{{installation|paket=sway|repo=community}}<br />
<br />
Ergänzend stehen einige Tools zur Verfügung die in der Standartkonfiguration bereits mit eingebunden sind:<br />
[[Bild:Sway Wallpaper Blue 1920x1080.png|thumb|300px|Sway (Wallpaper)]]<br />
* {{Paket|foot}} - Terminalemulator<br />
* {{Paket|dmenu}} - Anwendungslauncher<br />
* {{Paket|swaybg}} - Sway-Wallpaper<br />
<br />
Des Weiteren sind die folgenden Schriftarten empfohlen:<br />
<br />
* {{Paket|ttf-roboto}}<br />
* {{Paket|ttf-font-awesome}}<br />
<br />
Sollte man keine Alternativen bevorzugen (s. unten), dann lautet der komplette Installationsbefehl:<br />
pacman -S sway foot dmenu swaybg ttf-roboto ttf-font-awesome<br />
<br />
== Umstieg von i3 ==<br />
Sway ist bis auf wenige Features, die nur auf X11 Sinn machen, mit der Konfiguration von i3, i3 IPC, i3-gaps, und i3bar kompatibel. Es empfiehlt sich die bisherige i3-Konfigurationsdatei nach {{ic|~/.config/sway/config}} zu kopieren. Weitere Tipps sind vom [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] zu erfahren.<br />
<br />
== Sway Starten ==<br />
Eine Sway Sitzung kann auf verschiedene Arten gestartet werden:<br />
* Nach dem login auf TTY mit der Eingabe {{ic|sway}}<br />
* oder automatisch nach Einfügen der Zeile {{ic|[ "$(tty)" &#61; "/dev/tty1" ] && exec sway}} in die {{ic|~/.bash_profile}} Datei.<br />
* Mittels modernem [[Login-Manager]] wie [[GDM]] oder SDDM bzw. einem der [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway#login-managers hier] gelisteten.<br />
* Oder auch wenn man sich bereits in einer Wayland-Sitzung befindet mit der Eingabe von {{ic|sway}} als Konselenbefehl.<br />
<br />
== Tastaturbefehle (default) ==<br />
{|<br />
|{{taste|mod}} + {{taste|1}}-{{taste|0}}<br />
| - Fenster öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Return}}<br />
| - Terminal öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Pfeil}}<br />
| - Fensterfokus wechseln<br />
|-<br />
|{{taste|mod}} + {{taste|d}}<br />
| - Anwendungsstarter aufrufen<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|1}}-{{taste|0}}<br />
| - Laufende Anwendung auf Fenster verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|c}}<br />
| - config Datei neu einlesen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|Pfeil}}<br />
| - Fenster horizontal oder vertikal verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|q}}<br />
| - Fenster schließen <br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|e}}<br />
| - Sway beenden<br />
|}<br />
<br />
== Konfiguration ==<br />
Möchte man die vorgegebene Konfiguration anpassen, so wird empfohlen die Konfigurationsdatei ins eigene Benutzerverzeichnis zu kopieren und nur diese zu bearbeiten.<br />
mkdir ~/.config/sway<br />
cp /etc/sway/config ~/.config/sway/config<br />
<br />
Die folgende Auflistung führt einige zusätzlichen Tools und die jeweiligen dazugehörigen Einstellungen in der {{ic|~/.config/sway/config}} Datei auf. Eine komplette Liste von Sway-Ad-Ons ist [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway hier] abrufbar.<br />
{|<br />
|'''Paket/Einstellungen'''<br />
|'''Config-Eintrag (Bsp.)'''<br />
|-<br />
|{{taste|Win}} als mod-Taste<br />
|{{ic|set $mod Mod4}} (default)<br />
|-<br />
|{{taste|Alt}} als mod-Taste<br />
|{{ic|set $mod Mod1}}<br />
|-<br />
|Deutsches Tastaturlayout<br />
|{{ic|input * xkb_layout "de"}}<br />
|-<br />
|Auflösung<br />
|{{ic|output * resolution --custom 1920x1080}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Terminal-Emulatoren:''<br />
|<br />
|-<br />
|{{paket|foot}}<br />
|{{ic|set $term foot}} (default)<br />
|-<br />
|{{paket|alacritty}}<br />
|{{ic|set $term alacritty}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Wallpaper:''<br />
|<br />
|-<br />
|{{paket|swaybg}}<br />
|{{ic|output * bg <datei>.png fill}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Anwendungs-Lancher:''<br />
|<br />
|-<br />
|{{paket|dmenu}}<br />
|{{ic|set $menu dmenu_path &#124; dmenu &#124; xargs swaymsg exec --}} (default)<br />
|-<br />
|{{paket|wofi}}<br />
|{{ic|set $menu wofi --show run --exec-search}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Symbolleisten:''<br />
|<br />
|-<br />
|sway-bar (eingebaut)<br />
|siehe config Datei (default) <br />
|-<br />
|{{paket|waybar}}<br />
|{{ic|bar swaybar command waybar}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Idle Management Daemon und Screenlocker:''<br />
|<br />
|-<br />
|{{paket|swayidle}} und {{paket|swaylock}}<br />
|Das Beispiel in der config auskommentieren<br />
|}<br />
<br />
<br />
== siehe auch ==<br />
* [[i3]]<br />
<br />
== Weblinks ==<br />
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] {{sprache|en}}<br />
* [https://github.com/swaywm/sway/wiki Sway Wiki] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=hRIGYUWQfYU Sway Install Guide (Video)] {{sprache|en}}<br />
* [https://medium.com/hacker-toolbelt/linuxs-sway-window-manager-c39abe0b7bc9 A short install guide] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=oUpvtCEGrxQ Waybar Customization (Video)] {{sprache|en}}<br />
<br />
[[Kategorie:Fenstermanager]]<br />
[[en:sway]]</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Datei:Sway_Wallpaper_Blue_1920x1080.png&diff=23775Datei:Sway Wallpaper Blue 1920x1080.png2022-12-13T21:04:08Z<p>Tuxnix: Sway Wallpaper</p>
<hr />
<div>== Beschreibung ==<br />
Sway Wallpaper</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Sway&diff=23774Sway2022-12-11T23:56:33Z<p>Tuxnix: Neuer Artikel</p>
<hr />
<div>{{SEITENTITEL:sway}}{{righttoc}}<br />
<br />
Sway ist ein Tiling Compositor für Wayland der als kompatibler Ersatz für [[i3]] konzipiert wurde.<br />
{{Hinweis|Sway unterstützt keine proprietären Grafiktreiber. Für Nvidia-Karten ist der Treiber Nouveau zu nutzen.}}<br />
{{installation|paket=sway|repo=community}}<br />
<br />
Ergänzend stehen einige Tools zur Verfügung die in der Standartkonfiguration bereits mit eingebunden sind:<br />
<br />
* {{Paket|foot}} - Terminalemulator<br />
* {{Paket|dmenu}} - Anwendungslauncher<br />
* {{Paket|swaybg}} - Sway-Wallpaper<br />
<br />
Des Weiteren sind die folgenden Schriftarten empfohlen:<br />
<br />
* {{Paket|ttf-roboto}}<br />
* {{Paket|ttf-font-awesome}}<br />
<br />
Sollte man keine Alternativen bevorzugen (s. unten), dann lautet der komplette Installationsbefehl:<br />
pacman -S sway foot dmenu swaybg ttf-roboto ttf-font-awesome<br />
<br />
== Umstieg von i3 ==<br />
Sway ist bis auf wenige Features, die nur auf X11 Sinn machen, mit der Konfiguration von i3, i3 IPC, i3-gaps, und i3bar kompatibel. Es empfiehlt sich die bisherige i3-Konfigurationsdatei nach {{ic|~/.config/sway/config}} zu kopieren. Weitere Tipps sind vom [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] zu erfahren.<br />
<br />
== Sway Starten ==<br />
Eine Sway Sitzung kann auf verschiedene Arten gestartet werden:<br />
* Nach dem login auf TTY mit der Eingabe {{ic|sway}}<br />
* oder automatisch nach Einfügen der Zeile {{ic|[ "$(tty)" &#61; "/dev/tty1" ] && exec sway}} in die {{ic|~/.bash_profile}} Datei.<br />
* Mittels modernem [[Login-Manager]] wie [[GDM]] oder SDDM bzw. einem der [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway#login-managers hier] gelisteten.<br />
* Oder auch wenn man sich bereits in einer Wayland-Sitzung befindet mit der Eingabe von {{ic|sway}} als Konselenbefehl.<br />
<br />
== Tastaturbefehle (default) ==<br />
{|<br />
|{{taste|mod}} + {{taste|1}}-{{taste|0}}<br />
| - Fenster öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Return}}<br />
| - Terminal öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Pfeil}}<br />
| - Fensterfokus wechseln<br />
|-<br />
|{{taste|mod}} + {{taste|d}}<br />
| - Anwendungsstarter aufrufen<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|1}}-{{taste|0}}<br />
| - Auf betr. Fenster verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|c}}<br />
| - config Datei neu einlesen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|Pfeil}}<br />
| - Fenster teilen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|q}}<br />
| - Fenster schließen <br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|e}}<br />
| - Sway beenden<br />
|}<br />
<br />
== Konfiguration ==<br />
Möchte man die vorgegebene Konfiguration anpassen, so wird empfohlen die Konfigurationsdatei ins eigene Benutzerverzeichnis zu kopieren und nur diese zu bearbeiten.<br />
mkdir ~/.config/sway<br />
cp /etc/sway/config ~/.config/sway/config<br />
<br />
Die folgende Auflistung führt einige zusätzlichen Tools und die jeweiligen dazugehörigen Einstellungen in der {{ic|~/.config/sway/config}} Datei auf. Eine komplette Liste von Sway-Ad-Ons ist [https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway hier] abrufbar.<br />
{|<br />
|'''Paket/Einstellungen'''<br />
|'''Config-Eintrag (Bsp.)'''<br />
|-<br />
|{{taste|Win}} als mod-Taste<br />
|{{ic|set $mod Mod4}} (default)<br />
|-<br />
|{{taste|Alt}} als mod-Taste<br />
|{{ic|set $mod Mod1}}<br />
|-<br />
|Deutsches Tastaturlayout<br />
|{{ic|input * xkb_layout "de"}}<br />
|-<br />
|Auflösung<br />
|{{ic|output * resolution --custom 1920x1080}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Terminal-Emulatoren:''<br />
|<br />
|-<br />
|{{paket|foot}}<br />
|{{ic|set $term foot}} (default)<br />
|-<br />
|{{paket|alacritty}}<br />
|{{ic|set $term alacritty}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Wallpaper:''<br />
|<br />
|-<br />
|{{paket|swaybg}}<br />
|{{ic|output * bg <datei>.png fill}} (default)<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Anwendungs-Lancher:''<br />
|<br />
|-<br />
|{{paket|dmenu}}<br />
|{{ic|set $menu dmenu_path | dmenu | xargs swaymsg exec --}} (default)<br />
|-<br />
|{{paket|wofi}}<br />
|{{ic|set $menu wofi --show run --exec-search}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Symbolleisten:''<br />
|<br />
|-<br />
|sway-bar (eingebaut)<br />
|siehe config Datei (default) <br />
|-<br />
|{{paket|waybar}}<br />
|{{ic|bar swaybar command waybar}}<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Idle Management Daemon und Screenlocker:''<br />
|<br />
|-<br />
|{{paket|swayidle}} und {{paket|swaylock}}<br />
|Das Beispiel in der config auskommentieren<br />
|}<br />
<br />
<br />
== siehe auch ==<br />
* [[i3]]<br />
<br />
== Weblinks ==<br />
* [https://github.com/swaywm/sway/wiki/i3-Migration-Guide i3 Migration Guide] {{sprache|en}}<br />
* [https://github.com/swaywm/sway/wiki Sway Wiki] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=hRIGYUWQfYU Sway Install Guide (Video)] {{sprache|en}}<br />
* [https://medium.com/hacker-toolbelt/linuxs-sway-window-manager-c39abe0b7bc9 A short install guide] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=oUpvtCEGrxQ Waybar Customization (Video] {{sprache|en}}<br />
<br />
[[Kategorie:Fenstermanager]]<br />
[[en:sway]]</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Benutzer:Tuxnix&diff=23773Benutzer:Tuxnix2022-12-09T18:51:50Z<p>Tuxnix: /* Tastaturbefehle */</p>
<hr />
<div>{{inuse|[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]])}}{{SEITENTITEL:sway}}{{righttoc}}<br />
<br />
= Entwurf Artikel sway =<br />
Sway ist ein Tiling Compositor für Wayland der als kompatibler Ersatz für [[i3]] konzipiert wurde.<br />
{{Hinweis|Sway unterstützt keine proprietären Grafiktreiber. Für Nvidia-Karten ist der Treiber Nouveau zu nutzen.}}<br />
{{installation|paket=sway|repo=community}}<br />
<br />
Sollte man keine Alternativen bevorzugen (s. unten), so kann man die vorkonfigurierten Anwendungen gleich mit installieren.<br />
* {{Paket|foot}} - Terminalemulator<br />
* {{Paket|dmenu}} - Anwendungslauncher<br />
* {{Paket|swaybg}} - Sway-Wallpaper<br />
<br />
Des weiteren sind die folgende Schriftarten empfohlen:<br />
* {{Paket|ttf-roboto}}<br />
* {{Paket|ttf-font-awesome}}<br />
<br />
== Umstieg von i3 ==<br />
Sway ist bis auf wenige Features, die nur auf X11 Sinn machen, mit der Konfiguration von i3, i3 IPC, i3-gaps, und i3bar kompatibel. Es empfiehlt sich die bisherige i3-Konfigurationsdatei nach {{ic|~/.config/sway/config}} zu kopieren.<br />
<br />
== Sway Starten ==<br />
Sway kann von TTY nach dem login mit der Eingabe {{ic|sway}} oder mittels [[Login-Manager]] gestartet werden.<br />
Befindet man sich bereits in einer Wayland-Sitzung kann man sway auch in einer Konsole starten.<br />
<br />
== Tastaturbefehle (default) ==<br />
{|<br />
|{{taste|mod}} + {{taste|1}}-{{taste|0}}<br />
| - Fenster öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Return}}<br />
| - Terminal öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Pfeil}}<br />
| - Fensterfokus wechseln<br />
|-<br />
|{{taste|mod}} + {{taste|d}}<br />
| - Anwendungsstarter aufrufen<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|1}}-{{taste|0}}<br />
| - Auf betr. Fenster verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|c}}<br />
| - config Datei neu einlesen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|Pfeil}}<br />
| - Fenster teilen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|q}}<br />
| - Fenster schließen <br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|e}}<br />
| - Sway beenden<br />
|}<br />
<br />
== Konfiguration ==<br />
Möchte man die vorgegebene Konfiguration anpassen, so wird empfohlen die Konfigurationsdatei ins eigene Benutzerverzeichnis zu kopieren und nur diese zu bearbeiten.<br />
mkdir ~/.config/sway<br />
cp /etc/sway/config ~/.config/sway/config<br />
<br />
Die folgende Auflistung führt die zusätzlichen Tools und die jeweiligen dazugehörigen Einstellungen in der {{ic|~/.config/sway/config}} Datei an.<br />
<br />
{|<br />
|'''Paket/Einstellungen'''<br />
|'''Config-Eintrag (Bsp.)'''<br />
|-<br />
|{{taste|Win}} als mod-Taste<br />
|set $mod Mod4<br />
|-<br />
|{{taste|Shift}} als mod-Taste<br />
|set $mod Mod1<br />
|-<br />
|Deutsches Tastaturlayout<br />
|input * xkb_layout "de"<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Terminal-Emulatoren:''<br />
|<br />
|-<br />
|{{paket|foot}}<br />
|set $term foot<br />
|-<br />
|{{paket|alacritty}}<br />
|set $term alacritty<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Wallpaper:''<br />
|<br />
|-<br />
|{{paket|swaybg}}<br />
|output * bg <datei>.png fill<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Anwendungs-Lancher:''<br />
|<br />
|-<br />
|{{paket|dmenu}}<br />
|set $menu dmenu_path | dmenu | xargs swaymsg exec --<br />
|-<br />
|{{paket|wofi}}<br />
|set $menu wofi --show run --exec-search<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Symbolleisten:''<br />
|<br />
|-<br />
|sway-bar (eingebaut)<br />
|siehe config Datei<br />
|-<br />
|{{paket|waybar}}<br />
|set $bar waybar<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Screenlocker:''<br />
|<br />
|-<br />
|{{paket|swaylock}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Bildbetrachter:''<br />
|<br />
|-<br />
|{{paket|swayimg}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Idle Management Daemon:''<br />
|<br />
|-<br />
|{{paket|swayidle}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Screen Recorder:''<br />
|<br />
|-<br />
|{{paket|wf-recorder}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Bildbetrachter:''<br />
|<br />
|-<br />
|{{paket|swayimg}}<br />
|<br />
|}<br />
<br />
<br />
== siehe auch ==<br />
[[i3]]<br />
<br />
== Weblinks ==<br />
* [https://i3wm.org/docs/refcard.html Tastaturbefehle] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=hRIGYUWQfYU Install Guide Video] {{sprache|en}}<br />
* [https://medium.com/hacker-toolbelt/linuxs-sway-window-manager-c39abe0b7bc9 A short install guide] {{sprache|en}}<br />
<br />
[[Kategorie:Fenstermanager]]<br />
[[en:sway]]<br />
<br />
<br />
Notizen:<br />
mkdir ~/.config/waybar</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Benutzer:Tuxnix&diff=23772Benutzer:Tuxnix2022-12-09T18:36:48Z<p>Tuxnix: Tastaturbefehle</p>
<hr />
<div>{{inuse|[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]])}}{{SEITENTITEL:sway}}{{righttoc}}<br />
<br />
= Entwurf Artikel sway =<br />
Sway ist ein Tiling Compositor für Wayland der als kompatibler Ersatz für [[i3]] konzipiert wurde.<br />
{{Hinweis|Sway unterstützt keine proprietären Grafiktreiber. Für Nvidia-Karten ist der Treiber Nouveau zu nutzen.}}<br />
{{installation|paket=sway|repo=community}}<br />
<br />
Sollte man keine Alternativen bevorzugen (s. unten), so kann man die vorkonfigurierten Anwendungen gleich mit installieren.<br />
* {{Paket|foot}} - Terminalemulator<br />
* {{Paket|dmenu}} - Anwendungslauncher<br />
* {{Paket|swaybg}} - Sway-Wallpaper<br />
<br />
Des weiteren sind die folgende Schriftarten empfohlen:<br />
* {{Paket|ttf-roboto}}<br />
* {{Paket|ttf-font-awesome}}<br />
<br />
== Umstieg von i3 ==<br />
Sway ist bis auf wenige Features, die nur auf X11 Sinn machen, mit der Konfiguration von i3, i3 IPC, i3-gaps, und i3bar kompatibel. Es empfiehlt sich die bisherige i3-Konfigurationsdatei nach {{ic|~/.config/sway/config}} zu kopieren.<br />
<br />
== Sway Starten ==<br />
Sway kann von TTY nach dem login mit der Eingabe {{ic|sway}} oder mittels [[Login-Manager]] gestartet werden.<br />
Befindet man sich bereits in einer Wayland-Sitzung kann man sway auch in einer Konsole starten.<br />
<br />
== Tastaturbefehle ==<br />
{|<br />
|{{taste|mod}} + {{taste|1}}-{{taste|0}}<br />
| - Fenster öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Return}}<br />
| - Terminal öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|v}}<br />
| - Fenster vertikal teilen<br />
|-<br />
|{{taste|mod}} + {{taste|b}}<br />
| - Fenster horizontal teilen<br />
|-<br />
|{{taste|mod}} + {{taste|d}}<br />
| - Anwendungsstarter aufrufen<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|1}}-{{taste|0}}<br />
| - Auf betr. Fenster verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|c}}<br />
| - config Datei neu einlesen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|q}}<br />
| - Fenster schließen <br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|e}}<br />
| - Sway beenden<br />
|}<br />
<br />
== Konfiguration ==<br />
Möchte man die vorgegebene Konfiguration anpassen, so wird empfohlen die Konfigurationsdatei ins eigene Benutzerverzeichnis zu kopieren und nur diese zu bearbeiten.<br />
mkdir ~/.config/sway<br />
cp /etc/sway/config ~/.config/sway/config<br />
<br />
Die folgende Auflistung führt die zusätzlichen Tools und die jeweiligen dazugehörigen Einstellungen in der {{ic|~/.config/sway/config}} Datei an.<br />
<br />
{|<br />
|'''Paket/Einstellungen'''<br />
|'''Config-Eintrag (Bsp.)'''<br />
|-<br />
|{{taste|Win}} als mod-Taste<br />
|set $mod Mod4<br />
|-<br />
|{{taste|Shift}} als mod-Taste<br />
|set $mod Mod1<br />
|-<br />
|Deutsches Tastaturlayout<br />
|input * xkb_layout "de"<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Terminal-Emulatoren:''<br />
|<br />
|-<br />
|{{paket|foot}}<br />
|set $term foot<br />
|-<br />
|{{paket|alacritty}}<br />
|set $term alacritty<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Wallpaper:''<br />
|<br />
|-<br />
|{{paket|swaybg}}<br />
|output * bg <datei>.png fill<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Anwendungs-Lancher:''<br />
|<br />
|-<br />
|{{paket|dmenu}}<br />
|set $menu dmenu_path | dmenu | xargs swaymsg exec --<br />
|-<br />
|{{paket|wofi}}<br />
|set $menu wofi --show run --exec-search<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Symbolleisten:''<br />
|<br />
|-<br />
|sway-bar (eingebaut)<br />
|siehe config Datei<br />
|-<br />
|{{paket|waybar}}<br />
|set $bar waybar<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Screenlocker:''<br />
|<br />
|-<br />
|{{paket|swaylock}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Bildbetrachter:''<br />
|<br />
|-<br />
|{{paket|swayimg}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Idle Management Daemon:''<br />
|<br />
|-<br />
|{{paket|swayidle}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Screen Recorder:''<br />
|<br />
|-<br />
|{{paket|wf-recorder}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Bildbetrachter:''<br />
|<br />
|-<br />
|{{paket|swayimg}}<br />
|<br />
|}<br />
<br />
<br />
== siehe auch ==<br />
[[i3]]<br />
<br />
== Weblinks ==<br />
* [https://i3wm.org/docs/refcard.html Tastaturbefehle] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=hRIGYUWQfYU Install Guide Video] {{sprache|en}}<br />
* [https://medium.com/hacker-toolbelt/linuxs-sway-window-manager-c39abe0b7bc9 A short install guide] {{sprache|en}}<br />
<br />
[[Kategorie:Fenstermanager]]<br />
[[en:sway]]<br />
<br />
<br />
Notizen:<br />
mkdir ~/.config/waybar</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Benutzer:Tuxnix&diff=23771Benutzer:Tuxnix2022-12-09T18:32:45Z<p>Tuxnix: Tastaturbefehle, Tools</p>
<hr />
<div>{{inuse|[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]])}}{{SEITENTITEL:sway}}{{righttoc}}<br />
<br />
= Entwurf Artikel sway =<br />
Sway ist ein Tiling Compositor für Wayland der als kompatibler Ersatz für [[i3]] konzipiert wurde.<br />
{{Hinweis|Sway unterstützt keine proprietären Grafiktreiber. Für Nvidia-Karten ist der Treiber Nouveau zu nutzen.}}<br />
{{installation|paket=sway|repo=community}}<br />
<br />
Sollte man keine Alternativen bevorzugen (s. unten), so kann man die vorkonfigurierten Anwendungen gleich mit installieren.<br />
* {{Paket|foot}} - Terminalemulator<br />
* {{Paket|dmenu}} - Anwendungslauncher<br />
* {{Paket|swaybg}} - Sway-Wallpaper<br />
<br />
Des weiteren sind die folgende Schriftarten empfohlen:<br />
* {{Paket|ttf-roboto}}<br />
* {{Paket|ttf-font-awesome}}<br />
<br />
== Umstieg von i3 ==<br />
Sway ist bis auf wenige Features, die nur auf X11 Sinn machen, mit der Konfiguration von i3, i3 IPC, i3-gaps, und i3bar kompatibel. Es empfiehlt sich die bisherige i3-Konfigurationsdatei nach {{ic|~/.config/sway/config}} zu kopieren.<br />
<br />
== Sway Starten ==<br />
Sway kann von TTY nach dem login mit der Eingabe {{ic|sway}} oder mittels [[Login-Manager]] gestartet werden.<br />
Befindet man sich bereits in einer Wayland-Sitzung kann man sway auch in einer Konsole starten.<br />
<br />
== Tastenkombinationen ==<br />
{|<br />
|{{taste|mod}} + {{taste|1}}-{{taste|0}}<br />
| - Fenster öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|Return}}<br />
| - Terminal öffnen<br />
|-<br />
|{{taste|mod}} + {{taste|v}}<br />
| - Fenster vertikal teilen<br />
|-<br />
|{{taste|mod}} + {{taste|b}}<br />
| - Fenster horizontal teilen<br />
|-<br />
|{{taste|mod}} + {{taste|d}}<br />
| - Anwendungsstarter aufrufen<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|1}}-{{taste|0}}<br />
| - Auf betr. Fenster verschieben<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|c}}<br />
| - config Datei neu einlesen<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|q}}<br />
| - Fenster schließen <br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|r}}<br />
| - sway neustarten<br />
|-<br />
|{{taste|mod}} + {{taste|Shift}} + {{taste|e}}<br />
| - Sway beenden<br />
|}<br />
<br />
== Konfiguration ==<br />
Möchte man die vorgegebene Konfiguration anpassen, so wird empfohlen die Konfigurationsdatei ins eigene Benutzerverzeichnis zu kopieren und nur diese zu bearbeiten.<br />
mkdir ~/.config/sway<br />
cp /etc/sway/config ~/.config/sway/config<br />
<br />
Die folgende Auflistung führt die zusätzlichen Tools und die jeweiligen dazugehörigen Einstellungen in der {{ic|~/.config/sway/config}} Datei an.<br />
<br />
{|<br />
|'''Paket/Einstellungen'''<br />
|'''Config-Eintrag (Bsp.)'''<br />
|-<br />
|{{taste|Win}} als mod-Taste<br />
|set $mod Mod4<br />
|-<br />
|{{taste|Shift}} als mod-Taste<br />
|set $mod Mod1<br />
|-<br />
|Deutsches Tastaturlayout<br />
|input * xkb_layout "de"<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Terminal-Emulatoren:''<br />
|<br />
|-<br />
|{{paket|foot}}<br />
|set $term foot<br />
|-<br />
|{{paket|alacritty}}<br />
|set $term alacritty<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Wallpaper:''<br />
|<br />
|-<br />
|{{paket|swaybg}}<br />
|output * bg <datei>.png fill<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Anwendungs-Lancher:''<br />
|<br />
|-<br />
|{{paket|dmenu}}<br />
|set $menu dmenu_path | dmenu | xargs swaymsg exec --<br />
|-<br />
|{{paket|wofi}}<br />
|set $menu wofi --show run --exec-search<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Symbolleisten:''<br />
|<br />
|-<br />
|sway-bar (eingebaut)<br />
|siehe config Datei<br />
|-<br />
|{{paket|waybar}}<br />
|set $bar waybar<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Screenlocker:''<br />
|<br />
|-<br />
|{{paket|swaylock}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Bildbetrachter:''<br />
|<br />
|-<br />
|{{paket|swayimg}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Idle Management Daemon:''<br />
|<br />
|-<br />
|{{paket|swayidle}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Screen Recorder:''<br />
|<br />
|-<br />
|{{paket|wf-recorder}}<br />
|<br />
|-<br />
|style="color:white"|-<br />
|<br />
|-<br />
|''Bildbetrachter:''<br />
|<br />
|-<br />
|{{paket|swayimg}}<br />
|<br />
|}<br />
<br />
<br />
== siehe auch ==<br />
[[i3]]<br />
<br />
== Weblinks ==<br />
* [https://i3wm.org/docs/refcard.html Tastaturbefehle] {{sprache|en}}<br />
* [https://www.youtube.com/watch?v=hRIGYUWQfYU Install Guide Video] {{sprache|en}}<br />
* [https://medium.com/hacker-toolbelt/linuxs-sway-window-manager-c39abe0b7bc9 A short install guide] {{sprache|en}}<br />
<br />
[[Kategorie:Fenstermanager]]<br />
[[en:sway]]<br />
<br />
<br />
Notizen:<br />
mkdir ~/.config/waybar</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Benutzer:Tuxnix&diff=23770Benutzer:Tuxnix2022-12-09T12:19:39Z<p>Tuxnix: Entwurf sway</p>
<hr />
<div>{{inuse|[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]])}}{{SEITENTITEL:sway}}{{righttoc}}<br />
<br />
= Entwurf Artikel sway =<br />
sway ist ein tiling-compositor für wayland der als kompatibler Ersatz für i3 konzipiert wurde.<br />
{{installation|paket=sway|repo=community}}<br />
<br />
<br />
== Tastenkombinationen (default) ==<br />
* Fenster öffnen - {{taste|mod}}+{{taste|1}} bis {{taste|0}}<br />
* Terminal öffnen - {{taste|mod}}+{{taste|Return}}<br />
* Anwendungsstarter aufrufen - {{taste|mod}}+{{taste|d}}<br />
* Auf betr. Fenster verschieben - {{taste|mod}}+{{taste|Shift}}+{{taste|1}} bis {{taste|0}}<br />
* Fenster schließen - {{taste|mod}}+{{taste|Shift}}+{{taste|q}}<br />
<br />
(Soweit die betreffenden Tools installiert und konfiguriert sind)<br />
<br />
<br />
== Konfiguration ==<br />
Es wird empfohlen die Konfigurationsdatei ins eigene Benutzerverzeichnis zu kopieren und nur diese zu editieren.<br />
cp /etc/sway/config ~/.config/sway/config<br />
<br />
Alle weiteren Schritte werden in den jeweiligen Kapiteln besprochen. Soweit nicht anders angegeben beziehen sich alle Einträge auf die {{ic|~/.config/sway/config}} Datei. Lese {{ic|man 5 sway}} als Referenz. <br />
<br />
=== Die {{taste|mod}} - Taste ===<br />
Als {{taste|mod}} ist die {{taste|Win}} -Taste voreingestellt: {{ic|set $mod Mod4}}<br />
<br />
Mit folgender Einstellung wäre stattdessen die {{taste|Alt}} - Taste aktiviert:{{ic|set $mod Mod1}}<br />
<br />
=== Hintergrundsbild ===<br />
Wird ein Wallpaper gewünscht, kann das Paket {{paket|swaybg}} installiert werden.<br />
<br />
In der Zeile {{ic|output * bg /usr/share/backgrounds/sway/Sway_Wallpaper_Blue_1920x1080.png fill}}<br />
kann dann die Darstellung entsprechend angepasst werden.<br />
<br />
=== Terminal ===<br />
Als Anwendung für den terminalemulator kann das Paket {{paket|foot}} installiert werden. Eintrag: {{ic|set $term foot}}<br />
<br />
Alternativ dazu kann als Terminal {{paket|alacritty}} installiert werden. Eintrag: {{ic|set $term alacritty}}<br />
<br />
=== Anwendungsstarter ===<br />
Als Anwendungsstarter wird {{paket|wofi}} empfohlen<br />
Die Zeile {{ic|set $menu dmenu_path ...}} ist hierbei durch {{ic|set $menu wofi --show run}} zu ersetzen.<br />
<br />
=== Symbolleiste ===<br />
Soll eine Symbolleiste verwendet werden, so bietet sich {{paket|waybar}} an.<br />
<br />
=== swaylock ===<br />
{{paket|swaylock}}<br />
Screen locker for Wayland<br />
<br />
=== swayimg ===<br />
{{paket|swayimg}}<br />
Lightweight image viewer<br />
<br />
=== swayidle ===<br />
{{paket|swayidle}}<br />
Idle management daemon for Wayland<br />
<br />
=== wf-recorder ===<br />
{{paket|wf-recorder}}<br />
Screen recorder<br />
<br />
=== python-pywal ===<br />
{{paket|python-pywal}}<br />
Generate and change colorschemes on the fly</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23739Package-Preload (Beispiel)2022-10-16T16:32:00Z<p>Tuxnix: Leerzeichen</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt. Er sammelt für alle anderen Rechner die jeweiligen Paket Upgrades.<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== Sync-Datenbank ====<br />
Ein Verzeichnis mit dem Rechnernamen wird angelegt und der lokale Teil der Paketdatenbank darauf symbolisch verlinkt.<br />
<br />
mkdir /var/cache/pacman/preload-${HOSTNAME}<br />
ln -s /var/lib/pacman/local/ /var/cache/pacman/preload-${HOSTNAME}<br />
<br />
==== pkgpreload.sh ====<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
for i in /var/cache/pacman/preload-*; do /usr/bin/pacman -Syuw --noconfirm --dbpath ${i}; done<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen:<br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Tipp: Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] mit ins script aufzunehmen um den Vorrat an alten Paketen im cache zu limitieren.<br />
<br />
==== systemd.service ====<br />
Ein entsprechender Service ist anzulegen.<br />
<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
Einen Timer erstellen, der den Service in den gewünschten Intervallen auslöst.<br />
Für mögliche Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren:<br />
systemctl enable --now pkgpreload.timer<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman /var/cache/pacman rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Falls noch nicht geschehen das Paket rsync installieren:<br />
pacman -S rsync<br />
Ein Verzeichnis hooks anlegen:<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Upgrade<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = Updating packagelist...<br />
When = PostTransaction<br />
Exec = /bin/sh -c '/usr/bin/rsync --mkpath --delete -r --ignore-existing /var/lib/pacman/local/ /var/cache/pacman/preload-${HOSTNAME}/local'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23738Package-Preload (Beispiel)2022-10-15T17:24:40Z<p>Tuxnix: /* systemd.timer */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt. Er sammelt für alle anderen Rechner die jeweiligen Paket Upgrades.<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== Sync-Datenbank ====<br />
Ein Verzeichnis mit dem Rechnernamen wird angelegt und der lokale Teil der Paketdatenbank darauf symbolisch verlinkt.<br />
<br />
mkdir /var/cache/pacman/preload-${HOSTNAME}<br />
ln -s /var/lib/pacman/local/ /var/cache/pacman/preload-${HOSTNAME}<br />
<br />
==== pkgpreload.sh ====<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
for i in /var/cache/pacman/preload-*; do /usr/bin/pacman -Syuw --noconfirm --dbpath ${i}; done<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen:<br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Tipp: Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] mit ins script aufzunehmen um den Vorrat an alten Paketen im cache zu limitieren.<br />
<br />
==== systemd.service ====<br />
Ein entsprechender Service ist anzulegen.<br />
<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
Einen Timer erstellen, der den Service in den gewünschten Intervallen auslöst.<br />
Für mögliche Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren:<br />
systemctl enable --now pkgpreload.timer<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman /var/cache/pacman rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Falls noch nicht geschehen das Paket rsync installieren:<br />
pacman -S rsync<br />
Ein Verzeichnis hooks anlegen:<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Upgrade<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = Updating packagelist...<br />
When = PostTransaction<br />
Exec = /bin/sh -c '/usr/bin/rsync --mkpath --delete -r --ignore-existing /var/lib/pacman/local/ /var/cache/pacman/preload-${HOSTNAME}/local'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23737Package-Preload (Beispiel)2022-10-15T17:22:26Z<p>Tuxnix: /* Sync-Datenbank */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt. Er sammelt für alle anderen Rechner die jeweiligen Paket Upgrades.<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== Sync-Datenbank ====<br />
Ein Verzeichnis mit dem Rechnernamen wird angelegt und der lokale Teil der Paketdatenbank darauf symbolisch verlinkt.<br />
<br />
mkdir /var/cache/pacman/preload-${HOSTNAME}<br />
ln -s /var/lib/pacman/local/ /var/cache/pacman/preload-${HOSTNAME}<br />
<br />
==== pkgpreload.sh ====<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
for i in /var/cache/pacman/preload-*; do /usr/bin/pacman -Syuw --noconfirm --dbpath ${i}; done<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen:<br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Tipp: Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] mit ins script aufzunehmen um den Vorrat an alten Paketen im cache zu limitieren.<br />
<br />
==== systemd.service ====<br />
Ein entsprechender Service ist anzulegen.<br />
<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
Einen Timer erstellen, der Service in den gewünschten Intervallen auslöst.<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren:<br />
systemctl enable --now pkgpreload.timer<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman /var/cache/pacman rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Falls noch nicht geschehen das Paket rsync installieren:<br />
pacman -S rsync<br />
Ein Verzeichnis hooks anlegen:<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Upgrade<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = Updating packagelist...<br />
When = PostTransaction<br />
Exec = /bin/sh -c '/usr/bin/rsync --mkpath --delete -r --ignore-existing /var/lib/pacman/local/ /var/cache/pacman/preload-${HOSTNAME}/local'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23736Package-Preload (Beispiel)2022-10-15T17:21:25Z<p>Tuxnix: /* Sync-Datenbank */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt. Er sammelt für alle anderen Rechner die jeweiligen Paket Upgrades.<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== Sync-Datenbank ====<br />
Ein Verzeichnis mit dem Rechnernamen wird angelegt und der lokale Teil der Paketdatenbank darauf symbolisch verlinkt.<br />
<br />
mkdir /var/cache/pacman/${HOSTNAME}<br />
ln -s /var/lib/pacman/local/ /var/cache/pacman/preload-${HOSTNAME}<br />
<br />
==== pkgpreload.sh ====<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
for i in /var/cache/pacman/preload-*; do /usr/bin/pacman -Syuw --noconfirm --dbpath ${i}; done<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen:<br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Tipp: Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] mit ins script aufzunehmen um den Vorrat an alten Paketen im cache zu limitieren.<br />
<br />
==== systemd.service ====<br />
Ein entsprechender Service ist anzulegen.<br />
<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
Einen Timer erstellen, der Service in den gewünschten Intervallen auslöst.<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren:<br />
systemctl enable --now pkgpreload.timer<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman /var/cache/pacman rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Falls noch nicht geschehen das Paket rsync installieren:<br />
pacman -S rsync<br />
Ein Verzeichnis hooks anlegen:<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Upgrade<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = Updating packagelist...<br />
When = PostTransaction<br />
Exec = /bin/sh -c '/usr/bin/rsync --mkpath --delete -r --ignore-existing /var/lib/pacman/local/ /var/cache/pacman/preload-${HOSTNAME}/local'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23735Package-Preload (Beispiel)2022-10-15T16:47:22Z<p>Tuxnix: Umstellung von Listen auf einzelne Paket-DBs</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt. Er sammelt für alle anderen Rechner die jeweiligen Paket Upgrades.<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== Sync-Datenbank ====<br />
Ein Verzeichnis mit dem Rechnernamen wird angelegt und der lokale Teil der Paketdatenbank darauf symbolisch verlinkt.<br />
<br />
mkdir /var/cache/pacman/${HOSTNAME}<br />
ln -s /var/lib/pacman/local/ /var/cache/pacman/${HOSTNAME}<br />
<br />
<br />
==== pkgpreload.sh ====<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
for i in /var/cache/pacman/preload-*; do /usr/bin/pacman -Syuw --noconfirm --dbpath ${i}; done<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen:<br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Tipp: Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] mit ins script aufzunehmen um den Vorrat an alten Paketen im cache zu limitieren.<br />
<br />
==== systemd.service ====<br />
Ein entsprechender Service ist anzulegen.<br />
<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
Einen Timer erstellen, der Service in den gewünschten Intervallen auslöst.<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren:<br />
systemctl enable --now pkgpreload.timer<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman /var/cache/pacman rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Falls noch nicht geschehen das Paket rsync installieren:<br />
pacman -S rsync<br />
Ein Verzeichnis hooks anlegen:<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Upgrade<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = Updating packagelist...<br />
When = PostTransaction<br />
Exec = /bin/sh -c '/usr/bin/rsync --mkpath --delete -r --ignore-existing /var/lib/pacman/local/ /var/cache/pacman/preload-${HOSTNAME}/local'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23734Package-Preload (Beispiel)2022-10-15T15:32:27Z<p>Tuxnix: Das "-" Zeichen wird hier gebraucht</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
# Paths<br />
ListDir="/var/cache/pacman/pkg"<br />
PreloadDB="/var/lib/preload"<br />
<br />
# Write, a pakage list for this host<br />
pacman -Qq > ${ListDir}/${HOSTNAME}.list<br />
<br />
# Create a unique list for all hosts<br />
sort -u ${ListDir}/*.list > ${ListDir}/unique.lt<br />
<br />
# Clean unique.lt from extra packages like AUR<br />
comm -12 <(pacman -Slq --dbpath ${PreloadDB} | sort) <(sort ${ListDir}/unique.lt) > /${ListDir}/cleaned.lt<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreloadDB} -<${ListDir}/cleaned.lt<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23733Diskussion:Package-Preload (Beispiel)2022-10-15T15:29:58Z<p>Tuxnix: /* Umstellung */</p>
<hr />
<div>= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
<br />
<br />
== Artikel editieren ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
[[Benutzer:GerBra|GerBra]] 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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:06, 3. Okt. 2022 (CEST)<br />
Ok, ich ändere das jetzt mal auf pkgpredownload.sh<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
== NFS-Clients ==<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
== Syntax Fehler bei pacman -Syuw ==<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen.<br />
Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.<br />
<br />
Die Listen haben bisher gar keine Funktion - stimmt das?<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:20, 3. Okt. 2022 (CEST)<br />
Ja, anfangs war das in dem Forumthread noch richtig, irgendwann fehlten dann die Verfütterung der all.list an den PreDownloader. Der pacman-Prozeß am Server hat in dem Moment halt nur die "Server"-Pakete predownloaded. Ist aber korrigiert.<br />
<br />
<br />
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.<br />
<br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST) Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem ist, wenn alles hier o.K. ist.<br />
<br />
== Besserer Einleitugstext ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br />
<br />
=== Artikel Struktur "Vorwort" ===<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ja, ich neige oft zu einem sehr erklärenden Schreibstil, teils "oberlehrerhaft". <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
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!<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ah, nein! Den Schuh laß ich mir nicht anziehen ;-)<br />
Nein, im Ernst. Ich finde diese Seite sollte jemand schreiben/betreuen, der das Setup auch verwendet. Ich habe z.B. ein anderes (gemeinsamer PKG-Cache, aber ohne PreDownload).<br />
Mach die Seite in Struktur und Stil so wie du wikimäßig arbeitest. Wenn dir aus meinem Text oben irgendwas "gefällt" kannst du es problemlos nehmen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Bitte zieh dir dann selbst den Schuh an! Dass man alles installiert haben muss, weil man einen Wiki-Artikel darüber geschrieben hat, kann so nicht gelten. Gerne aber, teste ich die Endversion.<br />
<br />
Es gibt aber gerade ein kleines Problem. Und obwohl wir uns ansonsten, prima verstehen und die Zusammenarbeit sehr fruchtbar ist, haben wir ganz unterschiedliche Schreib-Stile.<br />
Ich würde jetzt fast alles wieder rückgängig machen, was du gerade editiert hast, falls ich hier die Regie übernehmen würde.<br />
Ich habe andererseits, aber gar kein Problem damit, wenn du die Regie inne hast und wenn du alles nach deinem eignen Gusto gestaltest.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 18:05, 4. Okt. 2022 (CEST)<br />
Hmm, was soll ich denn deiner Meinung nach "gerade editiert" haben was du "alles wieder rückgängig" machen würdest? Ich bin mir keiner "Schuld" bewußt... Meine letzte Änderung an der Seite betreffen den Namen des predownlaod-Skripts.<br />
Aber ohne "böse" zu sein - bitte, bitte "übernimm die Regie". Ich habe an Wikis keinerlei Interesse. Es war deine Idee mit dem Artikel, ich wäre wohl nichtmal auf die Idee gekommen für sowas nen Artikel zu machen. Du/Ich - wir wollen ja beide auch wohl mal zu einem Abschluss kommen. "Technische Fragen" o.ä. sofern noch was unklar helfe ich jederzeit gerne, aber nach 8 Stunden Arbeit kostet mich das mittlerweile zu viel meiner Freizeit. Ich bin mittlerweile auch in einem Alter das ich so eine Entscheidung auch problemlos treffen kann ;-) Kein Stress zwischen uns, ok?------<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:53, 5. Okt. 2022 (CEST) Gut, morgen, wenn ich wieder Zeit habe, schreib ich es dann wieder um. Sorry es wird wieder ungarisch werden.<br />
Schuld? Nein ganz und gar nicht. Ganz im Gegenteil. Das ist alles richtig prima was du machst. Es ist eher mein Versagen bzw. meine Schwäche an dem Punkt.<br />
Ich bin Legastheniker und habe wenig photographische Fähigkeiten bei der Schriftsprache zur Verfügung. Ich kann, wenn die Zeilen so dicht wie jetzt im Script sind, kaum noch etwas auseinanderhalten. Zudem arbeitet mein Kopf etwas über-assoziativ.<br />
Die Variablen wirken auf mich jetzt, wie kleine Geschichten 'pkgpredownload'. Die Kommentare erzählen auch eine Geschichte. Und der Programmcode erzählt mir das Gleiche auch noch einmal. Wegen der Teilredundanz und der Phasenverschobenheit der Informationen lande ich in einer Art Assoziationsstrudel.<br />
Das alles ist nichts Schlimmes, ich muss damit zurechtkommen, aber ich sollte dann nicht selbst an so gestalteten Texten mitarbeiten, weil ich dann auch nicht mehr erkennen kann, wo sich Fehler eingeschlichen haben.<br />
Deshalb bleibt bei der Textgestaltung der Anleitung nur der Weg, dass dies nur einer von uns beiden macht.<br />
<br />
Kein Stress zwischen uns! Ja das ist mir auch das aller Wichtigste. Und es sollte uns beiden auch weiterhin miteinander Spaß machen. Ich bin schon etwas älter und die Aktivitäten hier, sollten ein schönes Nebenbei bleiben.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 15:02, 6. Okt. 2022 (CEST) Habe einige deiner Formulierungen sehr schön mit einbauen können. Und noch eine Schleife bei den Listen behoben. Damit deinstallierte Pakete nicht immer wieder in die Listen kopiert werden.<br />
<br />
==Testen==<br />
[[Benutzer:GerBra|GerBra]] Überhaupt: Nach Abschluss des Artikels (vor der "Freigabe") muss das ganze Procedere nochmal an einem "sauberen" Rechner /virt. Maschine etc. durchgespielt werden. Ansonsten fallen Fehler nicht auf... <br />
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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Ich teste gerade in Detail das Zusammenspiel von pacman mit /local, /sync, dem pkg-cache und mirror. Habe habe da so einen Verdacht. Es wird aber noch ein wenig dauern bis ich hier Ergebnisse habe. Ich habe gerade etwas wenig Zeit.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 15:02, 6. Okt. 2022 (CEST) Habe das script derzeit deaktiviert und teste gerade im Detail ob und vor allem wie es zu partiellen Upgrades kommen könnte, real mal durch. Je nach Erkenntnis kann man dann das script darauf testen.<br />
<br />
==Umstellung==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:28, 15. Okt. 2022 (CEST) Es gibt zwei Dinge, die mit der Implementation durch Listen so nicht so gut laufen. 1.Bei jedem Durchlauf werden alle installierten Pakete erneut auf Integrität geprüft. Das sind bei mir über 1600 Pakete die jedes mal erneut geprüft werden müssen.<br />
Das erzeugt eine Menge Overhead.<br />
<br />
2. Deinstallierte Pakete werden nicht automatisch wieder von den Listen genommen, das heißt, sie erfahren weiterhin package upgrades obwohl sie gar nicht mehr genutzt werden.<br />
<br />
Ich bin deshalb ganz von den Listen weg. Es gibt jetzt für jeden Rechner eine eigene Paketdatenbank für das zentral durchgeführte Paketupgrade.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23732Diskussion:Package-Preload (Beispiel)2022-10-15T15:28:48Z<p>Tuxnix: Umstellung von Listen auf separate PaketDB's</p>
<hr />
<div>= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
<br />
<br />
== Artikel editieren ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
[[Benutzer:GerBra|GerBra]] 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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:06, 3. Okt. 2022 (CEST)<br />
Ok, ich ändere das jetzt mal auf pkgpredownload.sh<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
== NFS-Clients ==<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
== Syntax Fehler bei pacman -Syuw ==<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen.<br />
Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.<br />
<br />
Die Listen haben bisher gar keine Funktion - stimmt das?<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:20, 3. Okt. 2022 (CEST)<br />
Ja, anfangs war das in dem Forumthread noch richtig, irgendwann fehlten dann die Verfütterung der all.list an den PreDownloader. Der pacman-Prozeß am Server hat in dem Moment halt nur die "Server"-Pakete predownloaded. Ist aber korrigiert.<br />
<br />
<br />
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.<br />
<br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST) Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem ist, wenn alles hier o.K. ist.<br />
<br />
== Besserer Einleitugstext ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br />
<br />
=== Artikel Struktur "Vorwort" ===<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ja, ich neige oft zu einem sehr erklärenden Schreibstil, teils "oberlehrerhaft". <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
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!<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ah, nein! Den Schuh laß ich mir nicht anziehen ;-)<br />
Nein, im Ernst. Ich finde diese Seite sollte jemand schreiben/betreuen, der das Setup auch verwendet. Ich habe z.B. ein anderes (gemeinsamer PKG-Cache, aber ohne PreDownload).<br />
Mach die Seite in Struktur und Stil so wie du wikimäßig arbeitest. Wenn dir aus meinem Text oben irgendwas "gefällt" kannst du es problemlos nehmen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Bitte zieh dir dann selbst den Schuh an! Dass man alles installiert haben muss, weil man einen Wiki-Artikel darüber geschrieben hat, kann so nicht gelten. Gerne aber, teste ich die Endversion.<br />
<br />
Es gibt aber gerade ein kleines Problem. Und obwohl wir uns ansonsten, prima verstehen und die Zusammenarbeit sehr fruchtbar ist, haben wir ganz unterschiedliche Schreib-Stile.<br />
Ich würde jetzt fast alles wieder rückgängig machen, was du gerade editiert hast, falls ich hier die Regie übernehmen würde.<br />
Ich habe andererseits, aber gar kein Problem damit, wenn du die Regie inne hast und wenn du alles nach deinem eignen Gusto gestaltest.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 18:05, 4. Okt. 2022 (CEST)<br />
Hmm, was soll ich denn deiner Meinung nach "gerade editiert" haben was du "alles wieder rückgängig" machen würdest? Ich bin mir keiner "Schuld" bewußt... Meine letzte Änderung an der Seite betreffen den Namen des predownlaod-Skripts.<br />
Aber ohne "böse" zu sein - bitte, bitte "übernimm die Regie". Ich habe an Wikis keinerlei Interesse. Es war deine Idee mit dem Artikel, ich wäre wohl nichtmal auf die Idee gekommen für sowas nen Artikel zu machen. Du/Ich - wir wollen ja beide auch wohl mal zu einem Abschluss kommen. "Technische Fragen" o.ä. sofern noch was unklar helfe ich jederzeit gerne, aber nach 8 Stunden Arbeit kostet mich das mittlerweile zu viel meiner Freizeit. Ich bin mittlerweile auch in einem Alter das ich so eine Entscheidung auch problemlos treffen kann ;-) Kein Stress zwischen uns, ok?------<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:53, 5. Okt. 2022 (CEST) Gut, morgen, wenn ich wieder Zeit habe, schreib ich es dann wieder um. Sorry es wird wieder ungarisch werden.<br />
Schuld? Nein ganz und gar nicht. Ganz im Gegenteil. Das ist alles richtig prima was du machst. Es ist eher mein Versagen bzw. meine Schwäche an dem Punkt.<br />
Ich bin Legastheniker und habe wenig photographische Fähigkeiten bei der Schriftsprache zur Verfügung. Ich kann, wenn die Zeilen so dicht wie jetzt im Script sind, kaum noch etwas auseinanderhalten. Zudem arbeitet mein Kopf etwas über-assoziativ.<br />
Die Variablen wirken auf mich jetzt, wie kleine Geschichten 'pkgpredownload'. Die Kommentare erzählen auch eine Geschichte. Und der Programmcode erzählt mir das Gleiche auch noch einmal. Wegen der Teilredundanz und der Phasenverschobenheit der Informationen lande ich in einer Art Assoziationsstrudel.<br />
Das alles ist nichts Schlimmes, ich muss damit zurechtkommen, aber ich sollte dann nicht selbst an so gestalteten Texten mitarbeiten, weil ich dann auch nicht mehr erkennen kann, wo sich Fehler eingeschlichen haben.<br />
Deshalb bleibt bei der Textgestaltung der Anleitung nur der Weg, dass dies nur einer von uns beiden macht.<br />
<br />
Kein Stress zwischen uns! Ja das ist mir auch das aller Wichtigste. Und es sollte uns beiden auch weiterhin miteinander Spaß machen. Ich bin schon etwas älter und die Aktivitäten hier, sollten ein schönes Nebenbei bleiben.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 15:02, 6. Okt. 2022 (CEST) Habe einige deiner Formulierungen sehr schön mit einbauen können. Und noch eine Schleife bei den Listen behoben. Damit deinstallierte Pakete nicht immer wieder in die Listen kopiert werden.<br />
<br />
==Testen==<br />
[[Benutzer:GerBra|GerBra]] Überhaupt: Nach Abschluss des Artikels (vor der "Freigabe") muss das ganze Procedere nochmal an einem "sauberen" Rechner /virt. Maschine etc. durchgespielt werden. Ansonsten fallen Fehler nicht auf... <br />
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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Ich teste gerade in Detail das Zusammenspiel von pacman mit /local, /sync, dem pkg-cache und mirror. Habe habe da so einen Verdacht. Es wird aber noch ein wenig dauern bis ich hier Ergebnisse habe. Ich habe gerade etwas wenig Zeit.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 15:02, 6. Okt. 2022 (CEST) Habe das script derzeit deaktiviert und teste gerade im Detail ob und vor allem wie es zu partiellen Upgrades kommen könnte, real mal durch. Je nach Erkenntnis kann man dann das script darauf testen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:28, 15. Okt. 2022 (CEST) Es gibt zwei Dinge, die mit der Implementation durch Listen so nicht so gut laufen. 1.Bei jedem Durchlauf werden alle installierten Pakete erneut auf Integrität geprüft. Das sind bei mir über 1600 Pakete die jedes mal erneut geprüft werden müssen.<br />
Das erzeugt eine Menge Overhead.<br />
<br />
2. Deinstallierte Pakete werden nicht automatisch wieder von den Listen genommen, das heißt, sie erfahren weiterhin package upgrades obwohl sie gar nicht mehr genutzt werden.<br />
<br />
Ich bin deshalb ganz von den Listen weg. Es gibt jetzt für jeden Rechner eine eigene Paketdatenbank für das zentral durchgeführte Paketupgrade.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23731Package-Preload (Beispiel)2022-10-08T21:54:57Z<p>Tuxnix: /* pkgpreload.sh */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
# Paths<br />
ListDir="/var/cache/pacman/pkg"<br />
PreloadDB="/var/lib/preload"<br />
<br />
# Write, a pakage list for this host<br />
pacman -Qq > ${ListDir}/${HOSTNAME}.list<br />
<br />
# Create a unique list for all hosts<br />
sort -u ${ListDir}/*.list > ${ListDir}/unique.lt<br />
<br />
# Clean unique.lt from extra packages like AUR<br />
comm -12 <(pacman -Slq --dbpath ${PreloadDB} | sort) <(sort ${ListDir}/unique.lt) > /${ListDir}/cleaned.lt<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreloadDB} <${ListDir}/cleaned.lt<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23730Package-Preload (Beispiel)2022-10-08T21:03:58Z<p>Tuxnix: /* pkgpreload.sh */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
# Paths<br />
ListDir="/var/cache/pacman/pkg"<br />
PreloadDB="/var/lib/preload"<br />
<br />
# Write, a pakage list for this host<br />
pacman -Qq > ${ListDir}/${HOSTNAME}.list<br />
<br />
# Create a unique list for all hosts<br />
sort -u ${ListDir}/*.list > ${ListDir}/unique.lt<br />
<br />
# Clean unique.lt from extra packages like AUR<br />
comm -12 <(pacman -Slq --dbpath ${PreloadDB} | sort) <(sort ${ListDir}/unique.lt) > /${ListDir}/cleaned.lt<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreloadDB} - <${ListDir}/cleaned.lt<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23729Diskussion:Package-Preload (Beispiel)2022-10-06T13:02:41Z<p>Tuxnix: Script+Testen</p>
<hr />
<div>= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
<br />
<br />
== Artikel editieren ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
[[Benutzer:GerBra|GerBra]] 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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:06, 3. Okt. 2022 (CEST)<br />
Ok, ich ändere das jetzt mal auf pkgpredownload.sh<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
== NFS-Clients ==<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
== Syntax Fehler bei pacman -Syuw ==<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen.<br />
Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.<br />
<br />
Die Listen haben bisher gar keine Funktion - stimmt das?<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:20, 3. Okt. 2022 (CEST)<br />
Ja, anfangs war das in dem Forumthread noch richtig, irgendwann fehlten dann die Verfütterung der all.list an den PreDownloader. Der pacman-Prozeß am Server hat in dem Moment halt nur die "Server"-Pakete predownloaded. Ist aber korrigiert.<br />
<br />
<br />
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.<br />
<br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST) Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem ist, wenn alles hier o.K. ist.<br />
<br />
== Besserer Einleitugstext ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br />
<br />
=== Artikel Struktur "Vorwort" ===<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ja, ich neige oft zu einem sehr erklärenden Schreibstil, teils "oberlehrerhaft". <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
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!<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ah, nein! Den Schuh laß ich mir nicht anziehen ;-)<br />
Nein, im Ernst. Ich finde diese Seite sollte jemand schreiben/betreuen, der das Setup auch verwendet. Ich habe z.B. ein anderes (gemeinsamer PKG-Cache, aber ohne PreDownload).<br />
Mach die Seite in Struktur und Stil so wie du wikimäßig arbeitest. Wenn dir aus meinem Text oben irgendwas "gefällt" kannst du es problemlos nehmen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Bitte zieh dir dann selbst den Schuh an! Dass man alles installiert haben muss, weil man einen Wiki-Artikel darüber geschrieben hat, kann so nicht gelten. Gerne aber, teste ich die Endversion.<br />
<br />
Es gibt aber gerade ein kleines Problem. Und obwohl wir uns ansonsten, prima verstehen und die Zusammenarbeit sehr fruchtbar ist, haben wir ganz unterschiedliche Schreib-Stile.<br />
Ich würde jetzt fast alles wieder rückgängig machen, was du gerade editiert hast, falls ich hier die Regie übernehmen würde.<br />
Ich habe andererseits, aber gar kein Problem damit, wenn du die Regie inne hast und wenn du alles nach deinem eignen Gusto gestaltest.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 18:05, 4. Okt. 2022 (CEST)<br />
Hmm, was soll ich denn deiner Meinung nach "gerade editiert" haben was du "alles wieder rückgängig" machen würdest? Ich bin mir keiner "Schuld" bewußt... Meine letzte Änderung an der Seite betreffen den Namen des predownlaod-Skripts.<br />
Aber ohne "böse" zu sein - bitte, bitte "übernimm die Regie". Ich habe an Wikis keinerlei Interesse. Es war deine Idee mit dem Artikel, ich wäre wohl nichtmal auf die Idee gekommen für sowas nen Artikel zu machen. Du/Ich - wir wollen ja beide auch wohl mal zu einem Abschluss kommen. "Technische Fragen" o.ä. sofern noch was unklar helfe ich jederzeit gerne, aber nach 8 Stunden Arbeit kostet mich das mittlerweile zu viel meiner Freizeit. Ich bin mittlerweile auch in einem Alter das ich so eine Entscheidung auch problemlos treffen kann ;-) Kein Stress zwischen uns, ok?------<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:53, 5. Okt. 2022 (CEST) Gut, morgen, wenn ich wieder Zeit habe, schreib ich es dann wieder um. Sorry es wird wieder ungarisch werden.<br />
Schuld? Nein ganz und gar nicht. Ganz im Gegenteil. Das ist alles richtig prima was du machst. Es ist eher mein Versagen bzw. meine Schwäche an dem Punkt.<br />
Ich bin Legastheniker und habe wenig photographische Fähigkeiten bei der Schriftsprache zur Verfügung. Ich kann, wenn die Zeilen so dicht wie jetzt im Script sind, kaum noch etwas auseinanderhalten. Zudem arbeitet mein Kopf etwas über-assoziativ.<br />
Die Variablen wirken auf mich jetzt, wie kleine Geschichten 'pkgpredownload'. Die Kommentare erzählen auch eine Geschichte. Und der Programmcode erzählt mir das Gleiche auch noch einmal. Wegen der Teilredundanz und der Phasenverschobenheit der Informationen lande ich in einer Art Assoziationsstrudel.<br />
Das alles ist nichts Schlimmes, ich muss damit zurechtkommen, aber ich sollte dann nicht selbst an so gestalteten Texten mitarbeiten, weil ich dann auch nicht mehr erkennen kann, wo sich Fehler eingeschlichen haben.<br />
Deshalb bleibt bei der Textgestaltung der Anleitung nur der Weg, dass dies nur einer von uns beiden macht.<br />
<br />
Kein Stress zwischen uns! Ja das ist mir auch das aller Wichtigste. Und es sollte uns beiden auch weiterhin miteinander Spaß machen. Ich bin schon etwas älter und die Aktivitäten hier, sollten ein schönes Nebenbei bleiben.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 15:02, 6. Okt. 2022 (CEST) Habe einige deiner Formulierungen sehr schön mit einbauen können. Und noch eine Schleife bei den Listen behoben. Damit deinstallierte Pakete nicht immer wieder in die Listen kopiert werden.<br />
<br />
==Testen==<br />
[[Benutzer:GerBra|GerBra]] Überhaupt: Nach Abschluss des Artikels (vor der "Freigabe") muss das ganze Procedere nochmal an einem "sauberen" Rechner /virt. Maschine etc. durchgespielt werden. Ansonsten fallen Fehler nicht auf... <br />
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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Ich teste gerade in Detail das Zusammenspiel von pacman mit /local, /sync, dem pkg-cache und mirror. Habe habe da so einen Verdacht. Es wird aber noch ein wenig dauern bis ich hier Ergebnisse habe. Ich habe gerade etwas wenig Zeit.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 15:02, 6. Okt. 2022 (CEST) Habe das script derzeit deaktiviert und teste gerade im Detail ob und vor allem wie es zu partiellen Upgrades kommen könnte, real mal durch. Je nach Erkenntnis kann man dann das script darauf testen.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23728Package-Preload (Beispiel)2022-10-06T12:40:09Z<p>Tuxnix: /* pkgpreload.sh */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
# Paths<br />
ListDir="/var/cache/pacman/pkg"<br />
PreloadDB="/var/lib/preload"<br />
<br />
# Write, a pakage list for this host<br />
pacman -Qq > ${ListDir}/${HOSTNAME}.list<br />
<br />
# Create a unique list for all hosts<br />
sort -u ${ListDir}/*.list > ${ListDir}/unique.lt<br />
<br />
# Clean unique.lt from extra packages like AUR<br />
comm -12 <(pacman -Slq --dbpath ${PreloadDB} | sort) <(sort ${ListDir}/unique.lt ) > \${ListDir}/cleaned.lt<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreloadDB} - <${ListDir}/cleaned.lt<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23727Package-Preload (Beispiel)2022-10-06T12:38:49Z<p>Tuxnix: /* pkgpreload.sh */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
# Paths<br />
ListDir="/var/cache/pacman/pkg"<br />
PreloadDB="/var/lib/preload"<br />
<br />
# Write, a pakage list for this host<br />
pacman -Qq > ${ListDir}/${HOSTNAME}.list<br />
<br />
# Create a unique list for all hosts<br />
sort -u ${ListDir}/*.list > ${ListDir}/unique.lt<br />
<br />
# Clean unique.list from extra packages like AUR<br />
comm -12 <(pacman -Slq --dbpath ${PreloadDB} | sort) <(sort ${ListDir}/unique.lt ) > \${ListDir}/cleaned.lt<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreloadDB} - <${ListDir}/cleaned.lt<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23726Package-Preload (Beispiel)2022-10-06T12:37:25Z<p>Tuxnix: /* pkgpreload.sh */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
# Paths<br />
ListDir="/var/cache/pacman/pkg"<br />
PreloadDB="/var/lib/preload"<br />
<br />
# Write, a pakage list for this host<br />
pacman -Qq > ${ListDir}/${HOSTNAME}.list<br />
<br />
# Create a unique.list for all hosts<br />
sort -u ${ListDir}/*.list > ${ListDir}/unique.lt<br />
<br />
# Clean unique.list from extra packages like AUR<br />
comm -12 <(pacman -Slq --dbpath ${PreloadDB} | sort) <(sort ${ListDir}/unique.lt ) > \${ListDir}/cleaned.lt<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreloadDB} - <${ListDir}/cleaned.lt<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23725Package-Preload (Beispiel)2022-10-06T12:36:47Z<p>Tuxnix: /* pkgpreload.sh */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
# Paths<br />
ListDir="/var/cache/pacman/pkg"<br />
PreloadDB="/var/lib/preload"<br />
<br />
# Write, a pakage list for this host<br />
pacman -Qq > ${ListDir}/${HOSTNAME}.list<br />
<br />
# Create a unique.list for all hosts<br />
sort -u ${ListDir}/*.list > ${ListDir}/unique.lst<br />
<br />
# Clean unique.list from extra packages like AUR<br />
comm -12 <(pacman -Slq --dbpath ${PreloadDB} | sort) <(sort ${ListDir}/unique.lt ) > \${ListDir}/cleaned.lt<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreloadDB} - <${ListDir}/cleaned.lt<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23724Package-Preload (Beispiel)2022-10-06T12:28:48Z<p>Tuxnix: /* pkgpredownload.sh */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
# Paths<br />
ListDir="/var/cache/pacman/pkg"<br />
PreloadDB="/var/lib/preload"<br />
<br />
# Write, a pakage list for this host<br />
pacman -Qq > ${ListDir}/${HOSTNAME}.list<br />
<br />
# Create a unique.list for all hosts<br />
sort -u ${ListDir}/*.list > ${ListDir}/unique.list<br />
<br />
# Clean unique.list from extra packages like AUR<br />
comm -12 <(pacman -Slq --dbpath ${PreloadDB} | sort) <(sort ${ListDir}/unique.list ) > \${ListDir}/cleaned.list<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreloadDB} - <${ListDir}/cleaned.list<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23722Diskussion:Package-Preload (Beispiel)2022-10-05T11:53:40Z<p>Tuxnix: Textgestaltung</p>
<hr />
<div>= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
<br />
<br />
== Artikel editieren ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
[[Benutzer:GerBra|GerBra]] 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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:06, 3. Okt. 2022 (CEST)<br />
Ok, ich ändere das jetzt mal auf pkgpredownload.sh<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
== NFS-Clients ==<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
== Syntax Fehler bei pacman -Syuw ==<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen.<br />
Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.<br />
<br />
Die Listen haben bisher gar keine Funktion - stimmt das?<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:20, 3. Okt. 2022 (CEST)<br />
Ja, anfangs war das in dem Forumthread noch richtig, irgendwann fehlten dann die Verfütterung der all.list an den PreDownloader. Der pacman-Prozeß am Server hat in dem Moment halt nur die "Server"-Pakete predownloaded. Ist aber korrigiert.<br />
<br />
<br />
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.<br />
<br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST) Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem ist, wenn alles hier o.K. ist.<br />
<br />
== Besserer Einleitugstext ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br />
<br />
=== Artikel Struktur "Vorwort" ===<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ja, ich neige oft zu einem sehr erklärenden Schreibstil, teils "oberlehrerhaft". <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
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!<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ah, nein! Den Schuh laß ich mir nicht anziehen ;-)<br />
Nein, im Ernst. Ich finde diese Seite sollte jemand schreiben/betreuen, der das Setup auch verwendet. Ich habe z.B. ein anderes (gemeinsamer PKG-Cache, aber ohne PreDownload).<br />
Mach die Seite in Struktur und Stil so wie du wikimäßig arbeitest. Wenn dir aus meinem Text oben irgendwas "gefällt" kannst du es problemlos nehmen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Bitte zieh dir dann selbst den Schuh an! Dass man alles installiert haben muss, weil man einen Wiki-Artikel darüber geschrieben hat, kann so nicht gelten. Gerne aber, teste ich die Endversion.<br />
<br />
Es gibt aber gerade ein kleines Problem. Und obwohl wir uns ansonsten, prima verstehen und die Zusammenarbeit sehr fruchtbar ist, haben wir ganz unterschiedliche Schreib-Stile.<br />
Ich würde jetzt fast alles wieder rückgängig machen, was du gerade editiert hast, falls ich hier die Regie übernehmen würde.<br />
Ich habe andererseits, aber gar kein Problem damit, wenn du die Regie inne hast und wenn du alles nach deinem eignen Gusto gestaltest.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 18:05, 4. Okt. 2022 (CEST)<br />
Hmm, was soll ich denn deiner Meinung nach "gerade editiert" haben was du "alles wieder rückgängig" machen würdest? Ich bin mir keiner "Schuld" bewußt... Meine letzte Änderung an der Seite betreffen den Namen des predownlaod-Skripts.<br />
Aber ohne "böse" zu sein - bitte, bitte "übernimm die Regie". Ich habe an Wikis keinerlei Interesse. Es war deine Idee mit dem Artikel, ich wäre wohl nichtmal auf die Idee gekommen für sowas nen Artikel zu machen. Du/Ich - wir wollen ja beide auch wohl mal zu einem Abschluss kommen. "Technische Fragen" o.ä. sofern noch was unklar helfe ich jederzeit gerne, aber nach 8 Stunden Arbeit kostet mich das mittlerweile zu viel meiner Freizeit. Ich bin mittlerweile auch in einem Alter das ich so eine Entscheidung auch problemlos treffen kann ;-) Kein Stress zwischen uns, ok?------<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:53, 5. Okt. 2022 (CEST) Gut, morgen, wenn ich wieder Zeit habe, schreib ich es dann wieder um. Sorry es wird wieder ungarisch werden.<br />
Schuld? Nein ganz und gar nicht. Ganz im Gegenteil. Das ist alles richtig prima was du machst. Es ist eher mein Versagen bzw. meine Schwäche an dem Punkt.<br />
Ich bin Legastheniker und habe wenig photographische Fähigkeiten bei der Schriftsprache zur Verfügung. Ich kann, wenn die Zeilen so dicht wie jetzt im Script sind, kaum noch etwas auseinanderhalten. Zudem arbeitet mein Kopf etwas über-assoziativ.<br />
Die Variablen wirken auf mich jetzt, wie kleine Geschichten 'pkgpredownload'. Die Kommentare erzählen auch eine Geschichte. Und der Programmcode erzählt mir das Gleiche auch noch einmal. Wegen der Teilredundanz und der Phasenverschobenheit der Informationen lande ich in einer Art Assoziationsstrudel.<br />
Das alles ist nichts Schlimmes, ich muss damit zurechtkommen, aber ich sollte dann nicht selbst an so gestalteten Texten mitarbeiten, weil ich dann auch nicht mehr erkennen kann, wo sich Fehler eingeschlichen haben.<br />
Deshalb bleibt bei der Textgestaltung der Anleitung nur der Weg, dass dies nur einer von uns beiden macht.<br />
<br />
Kein Stress zwischen uns! Ja das ist mir auch das aller Wichtigste. Und es sollte uns beiden auch weiterhin miteinander Spaß machen. Ich bin schon etwas älter und die Aktivitäten hier, sollten ein schönes Nebenbei bleiben.<br />
<br />
==Testen==<br />
[[Benutzer:GerBra|GerBra]] Überhaupt: Nach Abschluss des Artikels (vor der "Freigabe") muss das ganze Procedere nochmal an einem "sauberen" Rechner /virt. Maschine etc. durchgespielt werden. Ansonsten fallen Fehler nicht auf... <br />
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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Ich teste gerade in Detail das Zusammenspiel von pacman mit /local, /sync, dem pkg-cache und mirror. Habe habe da so einen Verdacht. Es wird aber noch ein wenig dauern bis ich hier Ergebnisse habe. Ich habe gerade etwas wenig Zeit.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23720Diskussion:Package-Preload (Beispiel)2022-10-04T12:44:45Z<p>Tuxnix: Unterschiedliche Stile, Testen</p>
<hr />
<div>= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
<br />
<br />
== Artikel editieren ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
[[Benutzer:GerBra|GerBra]] 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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:06, 3. Okt. 2022 (CEST)<br />
Ok, ich ändere das jetzt mal auf pkgpredownload.sh<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
== NFS-Clients ==<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
== Syntax Fehler bei pacman -Syuw ==<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen.<br />
Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.<br />
<br />
Die Listen haben bisher gar keine Funktion - stimmt das?<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:20, 3. Okt. 2022 (CEST)<br />
Ja, anfangs war das in dem Forumthread noch richtig, irgendwann fehlten dann die Verfütterung der all.list an den PreDownloader. Der pacman-Prozeß am Server hat in dem Moment halt nur die "Server"-Pakete predownloaded. Ist aber korrigiert.<br />
<br />
<br />
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.<br />
<br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST) Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem ist, wenn alles hier o.K. ist.<br />
<br />
== Besserer Einleitugstext ==<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br />
<br />
=== Artikel Struktur "Vorwort" ===<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ja, ich neige oft zu einem sehr erklärenden Schreibstil, teils "oberlehrerhaft". <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] 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.<br />
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!<br />
<br />
[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 07:31, 3. Okt. 2022 (CEST)<br />
Ah, nein! Den Schuh laß ich mir nicht anziehen ;-)<br />
Nein, im Ernst. Ich finde diese Seite sollte jemand schreiben/betreuen, der das Setup auch verwendet. Ich habe z.B. ein anderes (gemeinsamer PKG-Cache, aber ohne PreDownload).<br />
Mach die Seite in Struktur und Stil so wie du wikimäßig arbeitest. Wenn dir aus meinem Text oben irgendwas "gefällt" kannst du es problemlos nehmen.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Bitte zieh dir dann selbst den Schuh an! Dass man alles installiert haben muss, weil man einen Wiki-Artikel darüber geschrieben hat, kann so nicht gelten. Gerne aber, teste ich die Endversion.<br />
<br />
Es gibt aber gerade ein kleines Problem. Und obwohl wir uns ansonsten, prima verstehen und die Zusammenarbeit sehr fruchtbar ist, haben wir ganz unterschiedliche Schreib-Stile.<br />
Ich würde jetzt fast alles wieder rückgängig machen, was du gerade editiert hast, falls ich hier die Regie übernehmen würde.<br />
Ich habe andererseits, aber gar kein Problem damit, wenn du die Regie inne hast und wenn du alles nach deinem eignen Gusto gestaltest. <br />
<br />
<br />
==Testen==<br />
[[Benutzer:GerBra|GerBra]] Überhaupt: Nach Abschluss des Artikels (vor der "Freigabe") muss das ganze Procedere nochmal an einem "sauberen" Rechner /virt. Maschine etc. durchgespielt werden. Ansonsten fallen Fehler nicht auf... <br />
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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:44, 4. Okt. 2022 (CEST) Ich teste gerade in Detail das Zusammenspiel von pacman mit /local, /sync, dem pkg-cache und mirror. Habe habe da so einen Verdacht. Es wird aber noch ein wenig dauern bis ich hier Ergebnisse habe. Ich habe gerade etwas wenig Zeit.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23703Diskussion:Package-Preload (Beispiel)2022-10-02T16:54:01Z<p>Tuxnix: /* Syntax Fehler bei pacman -Syuw */</p>
<hr />
<div>= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
<br />
== Artikel editieren ==<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
--> 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem ist, wenn alles hier o.K. ist.<br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
<br />
== Besserer Einleitugstext ==<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br />
<br />
=== Artikel Struktur "Vorwort" ===<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
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.<br />
Ich versuche möglichst nur ein Thema abzuhandeln und setze für alle anderen Gebiete einen Link.<br />
Das sind meine 2€-cents, aber entscheide selbst. Du bist jetzt Wikiautor!<br />
<br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
<br />
<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST)<br />
<br />
== NFS-Clients ==<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
<br />
== Syntax Fehler bei pacman -Syuw ==<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen.<br />
Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.<br />
<br />
Die Listen haben bisher gar keine Funktion - stimmt das?<br />
<br />
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.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23702Package-Preload (Beispiel)2022-10-02T16:40:37Z<p>Tuxnix: edit</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
## Variables<br />
# where we find the exported package lists of each host<br />
pre_listdir="/var/cache/pacman/pkg"<br />
# our own pacman sync DB to keep the system sync DB clean<br />
pre_syncdb="/var/lib/preload"<br />
<br />
## write, sort and clean package lists<br />
# package list of this server<br />
pacman -Qqn > ${pre_listdir}/${HOSTNAME}.list<br />
# create a unique package list from all hosts lists<br />
sort -u ${pre_listdir}/*.list > ${pre_listdir}/all.list<br />
# clean the all.list from packages which could not pre-downloaded on this server<br />
comm -12 <(pacman -Slq --dbpath ${pre_syncdb} | sort) <(sort ${pre_listdir}/all.list ) > ${pre_listdir}/cleaned_all.list <br />
# preload the packages from the list<br />
pacman -Syuw --noconfirm --dbpath ${pre_syncdb} - <${pre_listdir}/cleaned_all.list<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
=== Siehe auch ===<br />
=== Weblinks ===</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23701Package-Preload (Beispiel)2022-10-02T16:38:41Z<p>Tuxnix: interne und externe Links</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
## Variables<br />
# where we find the exported package lists of each host<br />
pre_listdir="/var/cache/pacman/pkg"<br />
# our own pacman sync DB to keep the system sync DB clean<br />
pre_syncdb="/var/lib/preload"<br />
<br />
## write, sort and clean package lists<br />
# package list of this server<br />
pacman -Qqn > ${pre_listdir}/${HOSTNAME}.list<br />
# create a unique package list from all hosts lists<br />
sort -u ${pre_listdir}/*.list > ${pre_listdir}/all.list<br />
# clean the all.list from packages which could not pre-downloaded on this server<br />
comm -12 <(pacman -Slq --dbpath ${pre_syncdb} | sort) <(sort ${pre_listdir}/all.list ) > ${pre_listdir}/cleaned_all.list <br />
# preload the packages from the list<br />
pacman -Syuw --noconfirm --dbpath ${pre_syncdb} - <${pre_listdir}/cleaned_all.list<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'<br />
<br />
== Siehe auch ==<br />
== Weblinks ==</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23700Package-Preload (Beispiel)2022-10-02T16:29:49Z<p>Tuxnix: /* Den nfs Client einrichten */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
## Variables<br />
# where we find the exported package lists of each host<br />
pre_listdir="/var/cache/pacman/pkg"<br />
# our own pacman sync DB to keep the system sync DB clean<br />
pre_syncdb="/var/lib/preload"<br />
<br />
## write, sort and clean package lists<br />
# package list of this server<br />
pacman -Qqn > ${pre_listdir}/${HOSTNAME}.list<br />
# create a unique package list from all hosts lists<br />
sort -u ${pre_listdir}/*.list > ${pre_listdir}/all.list<br />
# clean the all.list from packages which could not pre-downloaded on this server<br />
comm -12 <(pacman -Slq --dbpath ${pre_syncdb} | sort) <(sort ${pre_listdir}/all.list ) > ${pre_listdir}/cleaned_all.list <br />
# preload the packages from the list<br />
pacman -Syuw --noconfirm --dbpath ${pre_syncdb} - <${pre_listdir}/cleaned_all.list<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkg rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23699Diskussion:Package-Preload (Beispiel)2022-10-02T16:23:20Z<p>Tuxnix: nur noch besser sortiert</p>
<hr />
<div>= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
<br />
== Artikel editieren ==<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
--> 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem ist, wenn alles hier o.K. ist.<br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
<br />
== Besserer Einleitugstext ==<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br />
<br />
=== Artikel Struktur "Vorwort" ===<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
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.<br />
Ich versuche möglichst nur ein Thema abzuhandeln und setze für alle anderen Gebiete einen Link.<br />
Das sind meine 2€-cents, aber entscheide selbst. Du bist jetzt Wikiautor!<br />
<br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
<br />
<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST)<br />
<br />
== NFS-Clients ==<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
<br />
== Syntax Fehler bei pacman -Syuw ==<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen.<br />
Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.<br />
<br />
Die Listen haben bisher gar keine Funktion - stimmt das?<br />
Die Frage wäre, ob sie überhaupt wichtig sind?<br />
Es klappt ja alles auch so.<br />
<br />
Sowohl der server als auch die einzelnen clints arbeiten ohnehin mit ihrer eigenen DB. Die zusätzliche Sync-DB listet jedes aktuelle Paket, dass im gemeinsamen Paket-Cache gespeichert wurde in local. Die Listen sind sehr schöne Listen und auch sehr brauchbar wenn man mal einen neuen Rechner aufsetzen muss.<br />
<br />
Habe ich das richtig erfasst?<br />
<br />
Ich finde die Listen aber sehr schön und würde sie auf jeden Fall gerne behalten.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23698Diskussion:Package-Preload (Beispiel)2022-10-02T16:14:45Z<p>Tuxnix: Syntaxfehler</p>
<hr />
<div>= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
<br />
== Artikel editieren ==<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
--> 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem wenn alles hier o.K. ist.<br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
<br />
== Besserer Einleitugstext ==<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br><br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
<br />
<br />
== Artikel Struktur "Vorwort" ==<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
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.<br />
Ich versuche möglichst nur ein Thema abzuhandeln und setze für alle anderen Gebiete einen Link.<br />
Das sind meine 2€-cents, aber entscheide selbst. Du bist jetzt Wikiautor!<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST)<br />
<br />
== NFS-Clients ==<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
<br />
Ich hab das bisher immer auch getestet und werde das auch, wenn alles dann fertig ist, noch einmal tun!<br />
<br />
<br />
== Syntax Fehler bei pacman -Syuw ==<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 18:14, 2. Okt. 2022 (CEST) Das ist mir auch schon aufgefallen.<br />
Da wolle ich auch schon mal nachfragen, aber ich hab es lieber vermieden, weil wir auch so immer noch genug zu tun hatten.<br />
<br />
Die Listen haben bisher gar keine Funktion - stimmt das?<br />
Die Frage wäre, ob sie überhaupt wichtig sind?<br />
Es klappt ja alles auch so.<br />
<br />
Sowohl der server als auch die einzelnen clints arbeiten ohnehin mit ihrer eigenen DB. Die zusätzliche Sync-DB listet jedes aktuelle Paket, dass im gemeinsamen Paket-Cache gespeichert wurde in local. Die Listen sind sehr schöne Listen und auch sehr brauchbar wenn man mal einen neuen Rechner aufsetzen muss.<br />
<br />
Habe ich das richtig erfasst?<br />
<br />
Ich finde die Listen aber sehr schön und würde sie auf jeden Fall gerne behalten.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23697Diskussion:Package-Preload (Beispiel)2022-10-02T15:53:27Z<p>Tuxnix: Namen der Variablen</p>
<hr />
<div>Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br><br />
<br />
= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
<br />
== Artikel editieren ==<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
--> 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem wenn alles hier o.K. ist.<br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
<br />
== Besserer Einleitugstext ==<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br><br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
<br />
<br />
== Artikel Struktur "Vorwort" ==<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
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.<br />
Ich versuche möglichst nur ein Thema abzuhandeln und setze für alle anderen Gebiete einen Link.<br />
Das sind meine 2€-cents, aber entscheide selbst. Du bist jetzt Wikiautor!<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST)<br />
<br />
== NFS-Clients ==<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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<br> her? Ich mache das sofort weg! Das geht ja gar nicht.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23696Diskussion:Package-Preload (Beispiel)2022-10-02T15:52:08Z<p>Tuxnix: /* Namen des scripts */</p>
<hr />
<div>Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br><br />
<br />
= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
<br />
== Artikel editieren ==<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
--> 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem wenn alles hier o.K. ist.<br />
<br />
== Namen des scripts ==<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Anpassung des scripts fehlt noch.<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
<br />
== Besserer Einleitugstext ==<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br><br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
<br />
<br />
== Artikel Struktur "Vorwort" ==<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
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.<br />
Ich versuche möglichst nur ein Thema abzuhandeln und setze für alle anderen Gebiete einen Link.<br />
Das sind meine 2€-cents, aber entscheide selbst. Du bist jetzt Wikiautor!<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST)<br />
<br />
== NFS-Clients ==<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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<br> her? Ich mache das sofort weg! Das geht ja gar nicht.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23695Diskussion:Package-Preload (Beispiel)2022-10-02T15:51:27Z<p>Tuxnix: /* Namen des scripts und der Variablen */</p>
<hr />
<div>Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br><br />
<br />
= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
<br />
== Artikel editieren ==<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
--> 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem wenn alles hier o.K. ist.<br />
<br />
== Namen des scripts ==<br />
<br />
== Namen der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
<br />
== Besserer Einleitugstext ==<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br><br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
<br />
<br />
== Artikel Struktur "Vorwort" ==<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
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.<br />
Ich versuche möglichst nur ein Thema abzuhandeln und setze für alle anderen Gebiete einen Link.<br />
Das sind meine 2€-cents, aber entscheide selbst. Du bist jetzt Wikiautor!<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST)<br />
<br />
== NFS-Clients ==<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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<br> her? Ich mache das sofort weg! Das geht ja gar nicht.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23694Diskussion:Package-Preload (Beispiel)2022-10-02T15:43:33Z<p>Tuxnix: Diskussionsstruktur, pfgnfs, Silfragen ect.</p>
<hr />
<div>Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br><br />
<br />
= Erledigte Diskussions-Themen =<br />
(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)<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
== Loginfile ==<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 10:45, 2. Okt. 2022 (CEST)<br />
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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Prima!<br />
<br />
== Artikel editieren ==<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
Ok, ich werde das preload-Skript nochmal bzgl Variablennamen anpassen.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)<br />
____<br />
<br />
= Noch zu erledigen = <br />
<br />
== Namen der Seite ==<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
<br />
--> 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.<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Denke mal, das ist aber kein Problem wenn alles hier o.K. ist.<br />
<br />
== Namen des scripts und der Variablen ==<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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).<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt!<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) All das gerne! Du hast freie Fahrt. Was ist mit Ungarn? Doch lieber nur Kleinschreibung bei den Variablen?<br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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)<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST) Ja, das ist dann wohl das Beste. Ich fasse es nochmal zusammen:<br />
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.<br />
Der Hook für den client darf aber so bleiben mit der -n Option!<br />
<br />
<br />
== Besserer Einleitugstext ==<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:02, 2. Okt. 2022 (CEST)<br />
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.<br />
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.<br><br />
<br />
== Die Diskussions-Struktur hier im Wiki ==<br />
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 ).<br />
<br />
Evtl. sollten wir die aktuelle Diskussions-Seite mal um erledigte Punkte bereinigen und für jedes Thema/Problem einen eigenen Abschnitt eröffnen?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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. <br />
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.<br />
<br />
<br />
<br />
== Artikel Struktur "Vorwort" ==<br />
<br />
PackagePreDownload<br />
<br />
1. Übersicht<br />
<br />
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.<br />
<br />
Zuerst beschränkte sich die Idee nur auf einen Rechner, im Weiteren dann aber auch auf ein Setup mit mehreren Rechnern.<br />
<br />
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.<br />
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.<br />
<br />
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:<br />
* Alle Rechner müssen einen gemeinsamen Paketcache verwenden.<br />
* 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.<br />
* 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".<br />
<br />
Das unten aufgeführte Setup funktioniert folgendermassen:<br />
* 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.<br />
* 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.<br />
* 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.<br />
<br />
<br />
2. Implementierung<br />
(bisheriger Wiki-Artikel)<br />
<br />
3. Fallstricke / Fehlergefahren<br />
AUR / Fremd_Repos / pacman.conf->CacheDir muß auf den gemeinsamen Paketcache weisen.<br><br />
paccache gegen explodierende Festplatten<br />
<br />
4. weiterführende Links<br><br />
¹ Forums-Thread<br><br />
pacman / pacman Tips (ggf. auf .org) ?<br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 17:42, 2. Okt. 2022 (CEST)<br />
Die Überschriften zu 1. und 2. braucht man nicht.<br />
Ein Wikiartikel hat immer ein (kurzes) Vorwort gefolgt von einer Anleitung.<br />
<br />
3. Autsch s. unten.<br />
<br />
4. Ja. Das mach ich sofort.<br />
<br />
Zu 1. Der Text ist klasse, aber mein Stil ist das nicht.<br />
Du solltest aber selbst entscheiden und deinen eigen Stil entwickeln. Vielleicht sollte man auch Dirk dazu einmal befragen, wie er darüber denkt.<br />
<br />
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.<br />
Ich versuche möglichst nur ein Thema abzuhandeln und setze für alle anderen Gebiete einen Link.<br />
Das sind meine 2€-cents, aber entscheide selbst. Du bist jetzt Wikiautor!<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:55, 2. Okt. 2022 (CEST)<br />
<br />
== NFS-Clients ==<br />
<br />
--[[Benutzer:GerBra|GerBra]] ([[Benutzer Diskussion:GerBra|Diskussion]]) 11:58, 2. Okt. 2022 (CEST)Im Artikel wird der gemeinsame Paketcache der Clients momentan nach:<br><br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/'''pkgnfs''' rw,nofail 0 0<br><br />
gemountet.<br />
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ß.<br />
<br />
Weiter unten beim Hook exportierst du die Pakeltliste aber nach:<br><br />
/var/cache/pacman/'''pkg'''/$HOSTNAME.list<br><br />
also **nicht** in das gemeinsame Cache-Verzeichnis...<br />
<br />
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.<br />
<br />
Ü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...<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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<br> her? Ich mache das sofort weg! Das geht ja gar nicht.</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23683Diskussion:Package-Preload (Beispiel)2022-10-01T12:02:40Z<p>Tuxnix: Artikelnamen</p>
<hr />
<div>Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br><br />
<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt! <br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 14:02, 1. Okt. 2022 (CEST) Und ja, der Name, des Artikels.<br />
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.<br />
_______<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
Ich tendiere dazu, weil das auch viel Spaß macht, alle Möglichkeiten aufzuführen.<br />
Im Script könnte das dann etwa in dieser Form geschehen, dann entscheidet der User darüber was er braucht und was nicht:<br />
<br />
- # Logfile Synx-DB (if needed) <br />
- #${SyncDb.log} ...blah blah<br />
<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23682Diskussion:Package-Preload (Beispiel)2022-10-01T11:27:08Z<p>Tuxnix: </p>
<hr />
<div>Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br><br />
<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
Das zeigt nur den Zeitpunkt der einzelnen Syncs auf. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt! <br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
_______<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
Ich tendiere dazu, weil das auch viel Spaß macht, alle Möglichkeiten aufzuführen.<br />
Im Script könnte das dann etwa in dieser Form geschehen, dann entscheidet der User darüber was er braucht und was nicht:<br />
<br />
- # Logfile Synx-DB (if needed) <br />
- #${SyncDb.log} ...blah blah<br />
<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23681Diskussion:Package-Preload (Beispiel)2022-10-01T11:24:48Z<p>Tuxnix: </p>
<hr />
<div>Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br><br />
<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, auskommentiert und einfach 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.<br />
Das hat nur den Zeitpunkt der einzelnen Syncs aufgelistet. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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)<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:24, 1. Okt. 2022 (CEST) Ja, umbedingt! <br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion: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.<br />
_______<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
Ich tendiere dazu, weil das auch viel Spaß macht, alle Möglichkeiten aufzuführen.<br />
Im Script könnte das dann etwa in dieser Form geschehen, dann entscheidet der User darüber was er braucht und was nicht:<br />
<br />
- # Logfile Synx-DB (if needed) <br />
- #${SyncDb.log} ...blah blah<br />
<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23680Diskussion:Package-Preload (Beispiel)2022-10-01T11:18:50Z<p>Tuxnix: /* Zum Inhalt */</p>
<hr />
<div>Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br><br />
<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- Kommentar Tuxnix: Ja, auskommentiert und einfach 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.<br />
Das hat nur den Zeitpunkt der einzelnen Syncs aufgelistet. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- Kommentar Tuxnix: 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)<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- Kommentar Tuxnix: Ja, umbedingt! <br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- Kommentar Tuxnix: 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 die '-n' Entscheidung einsam getroffen)<br />
Ich schlage auch vor im Hook für den Host das '-n' wieder zu entfernen. Wir wissen ja nicht ob der Host auch zusätzliche Repos nutzt.<br />
_______<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
Ich tendiere dazu, weil das auch viel Spaß macht, alle Möglichkeiten aufzuführen.<br />
Im Script könnte das dann etwa in dieser Form geschehen, dann entscheidet der User darüber was er braucht und was nicht:<br />
<br />
- # Logfile Synx-DB (if needed) <br />
- #${SyncDb.log} ...blah blah<br />
<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
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. [[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]]) 13:18, 1. Okt. 2022 (CEST)</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Diskussion:Package-Preload_(Beispiel)&diff=23679Diskussion:Package-Preload (Beispiel)2022-10-01T11:16:15Z<p>Tuxnix: Willkommen</p>
<hr />
<div>Ich habe das preload.sh bearbeitet. Neben marginalen Dingen (Kommentaren):<br><br />
<br />
- Syntax Fehler bei pacman -Syuw (die Liste der Pakete zu stdin wurde vergessen)<br><br />
<br />
- eigenes Logfile als Var und als (nicht aktiven) pacman-Befehl hinzugefügt<br />
Da sollten wir überlegen ob wir ein eigenes Logfile fix vorgeben oder ggf. als Option einbauen.<br />
<br />
-- Kommentar Tuxnix: Ja, auskommentiert und einfach 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.<br />
Das hat nur den Zeitpunkt der einzelnen Syncs aufgelistet. Deshalb habe ich dann darauf<br />
verzichtet.<br />
<br />
Generell noch ein paar Dinge:<br />
* Die Bezeichnung für die Wiki-Seite bzw. das Prozedere<br />
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.<br />
* Im preload.sh (ggf. andere Stellen auch)<br />
<br />
-- Kommentar Tuxnix: 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)<br />
<br />
->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:<br />
Variablen durchgehend in kleiner Schreibweise, also z.B. listdir oder preload_db/preloaddb<br />
Konstanten mit Großbuchstaben am Anfang oder komplett.<br />
Das macht jedes Skript lesbarer und weniger fehleranfällig.<br />
-- Kommentar Tuxnix: Ja, umbedingt! <br />
<br />
== Exportliste der Hosts / Filtern von AUR/Fremd-Paketen ==<br />
<br />
Meine Gedanken zu Änderung wie diese behandelt werden.<br />
<br />
Aktuell: Dank der Hinweises von Martin-MS sind wir ja umgestiegen auf die Variante:<br />
pacman -Qqn > $HOST.list<br />
zum Erstellen der Paketlisten für den PreDownload der einzelnen Hosts.<br />
-n/--native als Option um AUR/lokal installierte Pakete aus der Export-Liste rauszuhalten.<br />
Dafür verzichten wir am "Server" auf das explizite Filtern mittels "comm -12 blabla"<br />
<br />
Überlegung:<br />
--native packt richtigerweise kein Paket in die jeweilige Host.list was nicht nativ in der **lokalen** SyncDB des Hosts ist.<br />
M.E. sind wir da aber im "Grenzbereich" dessen, was ich im Forum ganz am Anfang schrieb:<br />
"2) Eigene bzw. Fremd-Repos"<br />
https://forum.archlinux.de/d/34605-pacman-syuw-und-die-gefahr-eines-partiellen-paket-updates/7<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
comm -12 <(pacman -Slq --dbpath /var/local/pacman-DL/ | sort) <(sort /pfad_zum/complete.list.org ) > /pfad_zum/complete.list<br />
<br />
Befehls.<br />
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.<br />
<br />
-- Kommentar Tuxnix: 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 die '-n' Entscheidung einsam getroffen)<br />
Ich schlage auch vor im Hook für den Host das '-n' wieder zu entfernen. Wir wissen ja nicht ob der Host auch zusätzliche Repos nutzt.<br />
_______<br />
<br />
== Herzlich willkommen in der Arch-Wiki ==<br />
<br />
Hier ist es tatsächlich viel praktischer zusammen an einem Artikel zu arbeiten.<br />
Wenn sich das nächste mal so etwas im Forum entwickelt, werde ich früher hier her wechseln.<br />
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.<br />
<br />
Ich hoffe dir macht es hier genau so viel Spaß mich zu verbessern. ;)<br />
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.<br />
<br />
=== Zum Inhalt ===<br />
Ich setze mal meine Kommentare in deinen Text. Das dürfte bei den einzelnen Punkten die beste Übersicht ergeben.<br />
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.<br />
<br />
Ich tendiere dazu, weil das auch viel Spaß macht, alle Möglichkeiten aufzuführen.<br />
Im Script könnte das dann etwa in dieser Form geschehen, dann entscheidet der User darüber was er braucht und was nicht:<br />
<br />
- # Logfile Synx-DB (if needed) <br />
- #${SyncDb.log} ...blah blah<br />
<br />
Ich überlasse erst einmal dir komplett das Editieren des Artikels. (Wenn es dir recht ist?)<br />
Dann kommen wir uns nicht gegenseitig in die Quere.<br />
<br />
P.S.: Tipp - Dreimal ~ erzeugt einen Datumsstempel unter deinem Diskussionsbeitrag.<br />
Das ist sehr praktisch wenn man später etwas nachvollziehen möchte. <br />
<br />
[[Benutzer:Tuxnix|Tuxnix]] ([[Benutzer Diskussion:Tuxnix|Diskussion]])</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Network_File_System&diff=23674Network File System2022-09-30T16:13:43Z<p>Tuxnix: /* Einrichtung des Client (Bsp.) */</p>
<hr />
<div>{{SEITENTITEL:nfs}}{{righttoc}}<br />
Der '''Network File Service''' ist ein Protokol, das Client-Rechnern den Netzwerkzugriff auf einen Dateiordner des Servers erlaubt, so als befände sich dieser Ordner auf der lokalen Festplatte.<br />
<br />
{{installation|repo=core|paket=nfs-utils}}<br />
Die Installation ist sowohl auf dem Server wie auch auf dem Client zu tätigen.<br />
<br />
==Einrichtung des Servers (Bsp.)==<br />
<br />
Erstellen eines Ordners:<br />
sudo mkdir /NAS<br />
In der Datei {{ic|/etc/exports}} wird folgende Zeile angehängt:<br />
/NAS <client>(rw,sync,no_subtree_check)<br />
(Für 'client' ist hier der jeweilige Host-Name oder die IP-Adresse des client einzutragen.)<br><br />
Weitere Optionen können hier nachgeschaut werden: {{ic|man exports}}<br><br><br />
<br />
Danach muss die Änderung der {{ic|/etc/exports}} Datei dem System bekannt gemacht werden:<br />
exportfs -arv<br />
<br />
<br />
Mit dem folgenden Befehl wird der Nfs-Server gestartet.<br />
systemctl enable --now nfs-server.service<br />
<br />
<br />
==Einrichtung des Client (Bsp.)==<br />
Erstellen eines Ordners:<br />
sudo mkdir /NAS<br />
<br />
<br />
Mounten des Ordners:<br />
mount -t nfs <server>:/NAS /NAS<br />
(Für 'server' ist hier der jeweilige Host-Name oder die IP-Adresse des Servers einzutragen.)<br />
<br />
<br />
Will man das Mounten des NFS-Ordnes dauerhaft einrichten, fügt man die folgende Zeile der {{ic|/etc/[[fstab]]}} Datei hinzu:<br />
<server>:/NAS /NAS nfs rw,nofail 0 0<br />
(Weitere Optionen können hier nachgeschlagen werden: {{ic|man nfs}} bzw. {{ic|man fstab}})<br />
<br />
==Siehe auch==<br />
*[[fstab]]<br />
*[[samba]]<br />
<br />
==Weblinks==<br />
*{{wikipedia|Network_File_System|NFS}}<br />
*[https://www.howtoforge.com/tutorial/setting-up-an-nfs-server-and-client-on-centos-7/#-links Tutorial für CentOs] {{sprache|en}}<br />
<br />
[[Kategorie:Netzwerk]]<br />
[[Kategorie:Dateisysteme]]<br />
[[en:NFS]]</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23673Package-Preload (Beispiel)2022-09-30T15:56:17Z<p>Tuxnix: /* pkgpreload.sh */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
ListDir="/var/cache/pacman/pkg"<br />
PreLoad_DB="/var/lib/preload"<br />
<br />
# Write and sort package lists<br />
pacman -Qqn > ${ListDir}/${HOSTNAME}.list<br />
sort -u ${ListDir}/*.list > ${ListDir}/all.list<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreLoad_DB}<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkgnfs rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23672Package-Preload (Beispiel)2022-09-30T15:40:20Z<p>Tuxnix: /* pacman Hook */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
ListDir="/var/cache/pacman/pkg"<br />
PreLoad_DB="/var/lib/preload"<br />
<br />
# Write and sort package lists<br />
pacman -Qqn > ${ListDir}/${HOSTNAME}.list<br />
sort -u ${ListDir}/*.list > ${ListDir}/org.list<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreLoad_DB}<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkgnfs rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqn > /var/cache/pacman/pkg/$HOSTNAME.list; exit'</div>Tuxnixhttps://wiki.archlinux.de/index.php?title=Package-Preload_(Beispiel)&diff=23671Package-Preload (Beispiel)2022-09-30T15:39:05Z<p>Tuxnix: /* systemd.service */</p>
<hr />
<div>{{righttoc}}<br />
<br />
Das folgende Beispiel zeigt die Möglichkeit auf den Download von neuen Paketen auf einem zentalen Rechner automatisch durchzuführen und die Pakete von dort aus auf alle anderen Rechner zu verteilen.<br />
Um die Gefahr eines [[Pacman#Keine_partiellen_Upgrades|partiellen Upgrades]], das die Konsistenz des Systems bei einen unbedachten {{ic|pacman -S foobar}} beschädigen könnte zu vermeiden, wird eine separate Sync-DB genutzt. Somit bleibt die originäre Paketdatenbank unangetastet und kann weiterhin den realen Stand des Systems wiedergeben. Das Upgrade des Systems wird wie bisher mit dem Befehl {{ic|pacman -Syu}} auf jedem Rechner einzeln durchgeführt. Die Installation der neuen Pakete läuft entsprechend schneller ab, da die meisten Pakete schon vorab in den gemeinsam genutzten Paket-Cache geladen wurden.<br />
<br />
=== Der Server für das Package-Preload: ===<br />
Ein Rechner wird als Server für das automatische Herunterladen der aktuellen Pakete bestimmt und folgende Installation durchgeführt.<br />
<br />
==== Sync-Datenbank ====<br />
Für die separate Sync-Datenbank wird ein Verzeichnis angelegt und der Ordner local symbolisch darauf verlinkt.<br />
<br />
mkdir /var/lib/preload<br />
ln -s /var/lib/pacman/local/ /var/lib/preload<br />
<br />
==== Einrichtung des nfs Servers ====<br />
Im Unterschied zu dem Beispiel im Wiki-Artikel [[Network_File_System|nfs Server]] wird in der Datei /etc/exports folgende Zeile hinzugefügt.<br />
/var/cache/pacman/pkg <client>(rw,sync,no_root_squash)<br />
Für <client> ist hier der entsprechende hostname des zugreifenden Rechners zu setzen. Für den Zugriff von weiteren Rechnern kann jeweils eine neue Zeile angelegt werden.<br />
<br />
==== pkgpreload.sh ====<br />
<br />
#!/usr/bin/env bash<br />
# file-> /usr/local/bin/pkgpreload.sh<br />
<br />
# Proof if root<br />
if (( `id -u` != 0 )); then<br />
echo "Sorry, you must be root."<br />
exit<br />
fi<br />
<br />
ListDir="/var/cache/pacman/pkg"<br />
PreLoad_DB="/var/lib/preload"<br />
<br />
# Write and sort package lists<br />
pacman -Qqn > ${ListDir}/${HOSTNAME}.list<br />
sort -u ${ListDir}/*.list > ${ListDir}/org.list<br />
<br />
# Preload packages<br />
pacman -Syuw --noconfirm --dbpath ${PreLoad_DB}<br />
<br />
Die Datei pkgpreload.sh nach /usr/local/bin/pkgpreload.sh abspeichern und mit dem folgen Befehl ausführbar machen. <br />
chmod +x /usr/local/bin/pkgpreload.sh <br />
Zusätzlich wäre zu überlegen, den Befehl [[Pacman#Paccache|paccache]] ins script zu integrieren um den Vorrat an alten Paketen zu limitieren.<br />
<br />
==== systemd.service ====<br />
# file-> /etc/systemd/system/pkgpreload.service<br />
<br />
[Unit]<br />
Description=preloads packages<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/pkgpreload.sh<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Den Service unter /etc/systemd/system/pkgpreload.service abspeichern.<br />
<br />
==== systemd.timer ====<br />
# file-> /etc/systemd/system/pkgpreload.timer<br />
<br />
[Unit]<br />
Description=preloads packages<br />
<br />
[Timer]<br />
OnCalendar=daily<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=basic.target<br />
Timer unter /etc/systemd/system/pkgpreload.timer abspeichern und danach aktivieren<br />
systemctl enable --now pkgpreload.timer<br />
Für andere Zeitintervalle siehe: [[Systemd/Timers|Systemd/Timers]]<br />
<br />
<br />
=== Für alle anderen Rechner: ===<br />
<br />
==== Den nfs Client einrichten ====<br />
Wie beim server ist auch hier das Paket nfs-utils zu installieren.<br />
pacman -S nfs-utils<br />
Danach ist der /etc/fstab Datei die folgende Zeile anzufügen.<br />
<server>:/var/cache/pacman/pkg /var/cache/pacman/pkgnfs rw,nofail 0 0<br />
Der Ausdruck <server> ist hier durch den hostname des Servers zu ersetzen.<br />
Nach einem {{ic|reboot}} sollte die Verbindung stehen.<br />
<br />
==== pacman Hook ====<br />
Ein Verzeichnis hooks anlegen<br />
mkdir /etc/pacman.d/hooks<br />
Und die folgende pkglist.hook Datei dort abspeichern<br />
# file->/etc/pacman.d/hooks/pkglist.hook<br />
<br />
[Trigger]<br />
Type = Package<br />
Operation = Install<br />
Operation = Remove<br />
Target = *<br />
<br />
[Action]<br />
Description = updating packagelist<br />
When = PostTransaction<br />
Exec = /bin/sh -c 'pacman -Qqe > /var/cache/pacman/pkg/$HOSTNAME.list; exit'</div>Tuxnix