Jump to content

Fachinformatiker - Blog

  • Einträge
    41
  • Kommentare
    142
  • Aufrufe
    61.063

Mitwirkende

Arbeiten mit Arch - Updates und Distributed Pacman Cache

560 Aufrufe

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

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?

Diesen Kommentar teilen


Link zu diesem Kommentar

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

Diesen Kommentar teilen


Link zu diesem Kommentar
Gast
Kommentar schreiben...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

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

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

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

  • Blogkommentare

    • 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 bishe
    • 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?
    • Richtig Budgie basiert auf Gnome. Früher war ich zwar kein Gnome Fan aber das sieht schon ganz brauchbar aus. Die Skalierung funktioniert bei dem 4K Display allerdings eher so mittel-gut. Gnome typisch kann man nur 100, 200 und 300% auswählen. 200% ist dann schon wieder zu groß, das Problem lässt sich aber mit xrandr beheben. Das kommt dann im nächsten Teil. oh-my-zsh kenn ich schon, muss mich nur mal tiefer damit beschäftigen. Kommt wohl auch beim nächsten mal, zusammen mit tmux und ranger
    • "Budgie" kenne ich noch nicht - ist das ein Ableger von Gnome? Bei meinem Arch kann ich mich momentan nicht so wirklich zwischen XFCE aus Gewohnheit und i3-gaps wegen der Geschwindigkeit (wenn man fertig eingerichtet...) entscheiden. Wenn du bereits zsh-Fan bist, würde ich noch "oh-my-zsh" empfehlen. Ŭber kleine Module kommt da noch ne ganze Menge an Helferlein für die Shell hinzu.
    • oh super, danke dir. Ja mit den hochgestellten und tiefgestellten zahlen ist das so ne Sache. Da kommt der ein oder andere Fehler gern zustande. Leider kann man das nicht bearbeiten. Also hoffe ich das die Option irgendwann dazukommen wird oder jeder hier auch die Kommentare liest  
    • Das ist natürlich richtig, aber ich bin nicht der geduldigste Mensch und Arch kannte ich halt auch schon  Dazu kommt dann noch das der Core m5-Y71 nicht gerade ein Kraftpaket ist. Aber ich merkt mir mal Gentoo für ganz viel Langeweile oder potentere Hardware vor.
    • @_n4p_: Auch eine Gentoo Stage1 Installation ist gar nicht sooo kompliziert. Man braucht halt vor allem entsprechend viel Zeit, um alles selber zu kompilieren, anstatt es viel schneller nur zu installieren. Dafür läuft das System (wenn man alles richtig macht) aber auch schneller und stabiler als so ziemlich jedes andere System.
    • Das Arch Wiki ist echt großartig. Das kann man gar nicht oft genug sagen Für Gentoo und LFS war die Motivation einfach nicht groß genug. Arch bildet einen schönen Mittelweg aus den Extremen - Ubuntu, Mint auf der einen und LFS auf der anderen Seite. Irgendwo hab ich mal gelesen Arch sei auf die richtige Art kompliziert, zumindest zum Lernen. Will man einfach ein Linux um produktiv zu arbeiten, ist Arch vermutlich nicht der richtige Anfang. Das Abenteuer geht auch noch weiter
    • Schönes Abenteuer...verleitet mich ja fast dazu auch mal wieder was zu installieren und mit Linux rumzuspielen. Arch habe ich damals mit 16 oder 17 das erste Mal installiert. Da war die Wiki glaube ich noch nicht soooo gut wie heute und musste oft in Foren nachfragen oder Yt Vids gucken. Danach (einige Jahre später) wars dann eher Manjaro oder Antergos. Gentoo würde in meiner Liste noch fehlen (und LFS)
  • Blogstatistik

    • Blogs insgesamt
      1
    • Einträge insgesamt
      37

Fachinformatiker.de, 2020 SE Internet Services

fidelogo_small.png

if_icon-6-mail-envelope-closed_314900.pnSchicken Sie uns eine Nachricht!

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

Fachinformatiker.de App


Get it on Google Play

Kontakt

Hier werben?
Oder senden Sie eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...

Wichtige Information

Fachinformatiker.de verwendet Cookies. Mehr dazu in unserer Datenschutzerklärung