Zum Inhalt springen

Fachinformatiker - Blog

  • Einträge
    45
  • Kommentare
    159
  • Aufrufe
    134272

Mitwirkende

Arbeiten mit Arch - Updates und Distributed Pacman Cache


Was und Warum?

In den letzten Monaten wurden die meisten unserer Linuxserver auf Arch-Linux umgestellt. Ein paar Ausnahmen wird es weiterhin geben. vCenter läuft beispielsweise auf der VMWare eigenen Linux-Distribution, andere Software bringt in Form einer virtuellen Appliance auch eigene Linux-Distributionen oder verlangt nach einer spezifischen Distribution mit speziellen Paketen.

Jedenfalls sind 11 Server auf Arch-Linux Basis im Einsatz. Eine Update-Runde dauert bei unserer Internetanbindung dann eine Weile. Das Ziel war nun die Angelegenheit zu Beschleunigen. Dafür gibt es prinzipiell mehrere Möglichkeiten.

  1. Einen eigenen Arch Mirror aufbauen
  2. ein zentraler Cache für Pakete
  3. ein verteilter Cache für Pakete

Beim eigenen Mirror hat man dann einen Server auf dem alle Arch-Pakete liegen. Für den zentralen Cache lädt ein Server zunächst das Paket um es dann zunächst über das Netzwerk im Cache abzulegen und von dort aus zu installieren. Dafür werden Pakete die alle Server benötigen im verteilten Cache auf jedem Server abgelegt.

Pacman Cache

Für den zentralen Cache müssten alle Server über NFS o.ä. auf den Server mit dem Cache zugreifen. Vom Aufwand abgesehen, bastelt man sich so natürlich einen Single-Point-of-Failure. Für den verteilten Cache benötigt man nur einen simplen Webserver und ein paar Zeilen Shell-Befehle.

Für diesen Zweck genügt darkhttpd vollkommen. Hat man den installiert "konfiguriert" man ihn einfach indem die Systemd Unit angepasst wird. Dann benötigt man noch ein paar Links im Paket-Cache und ist im Grunde fertig.

pacman -S darkhttpd
systemctl enable darkhttpd
nano /etc/systemd/system/multi-user.target.wants/darkhttpd.service
systemctl daemon-reload
ln -s /var/lib/pacman/sync/*.db /var/cache/pacman/pkg
systemctl restart darkhttpd

Die Unit sieht dann in etwa so aus.

[Unit]
Description=Darkhttpd Webserver
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/darkhttpd /var/cache/pacman/pkg --port 9090 --uid http --gid http --mimetypes /etc/conf.d/mimetypes
ProtectSystem=full
ProtectHome=on
PrivateDevices=on
NoNewPrivileges=on

[Install]
WantedBy=multi-user.target

Der Pacman-Cache in /var/cache/pacman/pkg wird hier zum WWW-Root. Als Port wurde 9090 gewählt, da auf keinem der Server etwas auf dem Port läuft. Welchen Port man letztlich wählt ist egal. Die Standardoptionen "chroot" und "no-listing" werden entfernt. Mit chroot funktionieren Symlinks nicht und Verzeichnislisting ist fürs Debuggen ganz sinnvoll.

Updates

Damit die Server nun ihre Pakete von dem vorbereiteten Server erhalten, muss der auf jedem weiteren Server in die Mirrorliste eingetragen werden. Da die Mirrorliste zeilenweise verarbeitet wird, müssen die neuen Einträge an den Anfang der Datei.

Server = http://enton.<domäne>.intern:9090

Der Port :9090 ist natürlich durch den vorher gewählten Port vorgegeben.

Danach funktionieren Updates wie gewohnt mit pacman -Syu

Mehr

Da die Server verschiedene Aufgaben haben, sind auch unterschiedliche Pakete installiert, einige haben docker, andere php oder mariadb oder eine bunte Mischung. Nachdem der Cache eines Servers nun für alle verfügbar ist, bekommen wir aber zumindest Standardpakete (Kernel, ..) für alle weiteren Server nun aber aus dem lokalen Netz. Der Vorgang lässt sich nun für weitere Server wiederholen. Die Mirrorliste wird einfach nur länger.

Wenn alle Server ihren Cache freigeben und in jeder Mirrorliste alle Server eingetragen sind, ist dann auch egal, welcher Server mit Updates beginnt. Die nächsten Server sollten mit ihren Updates allerdings auf vorherige Server warten, da sonst die Pakete noch nicht auf den lokalen Servern verfügbar sind und wieder aus dem Netz geladen werden.

Als Fallback für neue Pakete oder Pakete die kein anderer Server hat, sollten in der Mirrorliste nicht nur die eigenen Server eingetragen sein. Ein praktisches Tool um die Liste aktuell zu halten ist reflector. Ich habe auf einem der Webserver eine Liste aller lokalen Paketcaches. Aus der Liste und reflector kann man sich vor den Updates dann eine frische Mirrorliste basteln.

curl --silent http://kangama.<domäne>.local:9090/liste |grep -v `hostname` && reflector -f 5 -l 5 -c de > /etc/pacman.d/mirrorlist

 

2 Kommentare


Empfohlene Kommentare

RubberDog

Geschrieben

Arch als Server interessiert mich.
Ich nutze es seit 2011 privat als Desktop-OS und erlebe kaum einen Tag ohne mehrere Paket-Updates.
Wenn man die zu lange warten lässt, geht später gern mal was kaputt. 
Von gefühlt dauernden Kernel-Updates mal ganz zu schweigen.
Wie sind deine / eure Erfahrungen damit bisher?

_n4p_

Geschrieben

Also ernsthaft kaputt war noch nichts, ein mittleres Problem sind VMware Vorlagen. Die erste angelegte Vorlage ist nun etwas über ein Jahr alt. Das erste was "kaputt" geht ist der arch-keyring. Pakete von damals gibt es nicht mehr und neue bekommt man unter umständen nicht weil die Signaturen nicht mehr stimmen. Etwas nervig. Dann kann man sich erstmal aktuelle Schlüssel besorgen (pacman-key --refresh-keys) und dann den neuen keyring holen (pacman -S archlinux-keyring)

Updates hab ich bisher monatlich manuell gemacht. Daher dann auch das "Problem" das jeder Server je nach Paketaktivität mal ne halbe Stunde nur Updates herunterlädt. 

Ansonsten gab es mal Reibungsverluste mit einer Software die sich auf Fehlverhalten älterer mariadb-Versionen verlassen hat, aber das wäre wohl auch von Debian 9 auf 10 passiert. Bei den Servern mit docker möchte ich auch aktuelle Versionen und beim Rest stört es nicht wenn php plötzlich auf 7.4 updated. Bei kritischen Systemen kann man vor dem Update immer noch n Snapshot machen.

Insgesamt bin ich echt zufrieden damit

Gast
Kommentar schreiben...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...