Fryboyter

Es ist auch möglich Arch Linux zu nutzen wenn man ein Leben hat

Gestern wurde auf gnulinux.ch ein Artikel bezüglich OS Entscheidungsbäume veröffentlicht. Dieser ist, hoffentlich, nicht ganz ernst gemeint. Trotzdem möchte ich bezüglich Arch Linux meinen Senft (ja in Franken ist es Senft nicht Senf) abgeben.

Um Arch Linux ranken sich viel Mythen. Und somit auch viel Bullshit. Wie zum Beispiel, dass man nur etwas lernt, wenn man beispielsweise Arch Linux nutzt. Ja das ist Bullshit. Ein Großteil meiner Kenntnisse zum Thema Linux habe ich mir beispielsweise unter Mandrake / Mandriva angeeignet. Was damals sozusagen das Ubuntu dieser Zeit war. Seit ich Arch nutze, ist natürlich einiges hinzugekommen. Aber nicht, weil ich Arch nutze, sondern weil ich eben bestimmte Probleme lösen oder bestimmte Aufgaben erfüllen musste. Aber egal, darum geht es nicht.

Es geht darum, dass viele behaupten, dass Arch Linux von Leuten genutzt wird die kein echtes Leben haben. Zum Beispiel, weil man nach fast jedem Update etwas reparieren muss. Bullshit!

Ich nutze Arch Linux seit ca. 2010 auf mehreren Rechnern mit unterschiedlicher Konfiguration. Sowohl was die Hard- als auch die Software betrifft. Und ich kann beim besten Willen nicht sagen, wann es das letzte Mal wegen eines Updates Probleme gab. Ich nutze Arch Linux sogar für Server im privaten Bereich.

Ich installiere nicht mehrmals täglich irgendwelche Updates. Bei manchen Rechnern installiere ich Updates sogar nur einmal die Woche, da ich diese nur am Wochenende nutze.

Vor einem Update prüfe ich, ob etwas unter https://archlinux.org/news/ veröffentlicht wurde, was meine Installationen betrifft. Um dies zu automatisieren, nutze ich Informant. Wenn es der Fall sein sollte, berücksichtige ich dies. Ohne Wenn und Aber.

Und von Zeit zu Zeit gleiche ich meine Konfigurationsdateien mit den Pacnew-Dateien ab (https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave). Zudem leere ich den Cache von pacman regelmäßig automatisch mittels eines Hooks (https://wiki.archlinux.org/title/pacman#Cleaning_the_package_cache).

Ansonsten nutze ich Arch Linux einfach. Ja, ernsthaft. Arch Linux ist im Grunde genommen eine ganz normale Distribution. Wie beispielsweise OpenSuse. Es ist kein Betriebssystem für die Elite. Oder für Leute ohne echtes Leben. Es ist nur eine Distribution bei der manche Dinge anders funktionieren als bei anderen Distributionen. Wie beispielsweise die Installation.

Dieser Artikel soll nun kein Aufruf sein, dass möglichst viele Nutzer Arch Linux installieren. Nein. Jeder soll die Distribution nutzen die er / sie / es für richtig hält. Dieser Artikel soll nur dazu dienen, Arch Linux zu demystifizieren und somit potenzielle Nutzer zu informieren. Mir persönlich ist es total egal welche Distributionen andere Nutzer einsetzen. Und ich habe mit dem Artikel von gnulinux.ch daher auch kein Problem.

OSBN | Linux

Pkgbuild-Datei automatisch aktualisieren und installieren

Unter Arch habe ich ein paar Pakete installiert, deren Updates teilweise zeitverzögert angeboten werden. Zum Beispiel, weil der jeweilige Paketbetreuer nicht die nötige Zeit hat oder weil er das erste Minor-Release abwarten will. Hugo ist oft solch ein Paket.

Daher installiere ich mir die aktuelle Version oft selbst. Hierfür habe ich das Verzeichnis ~/pkgbuilds/hugo/ erstellt und in diesem die PKGBUILD-Datei gespeichert anhand der darin enthaltenen Anweisungen das Paket installiert wird. Im Falle von Hugo sieht diese aktuell folgendermaßen aus.

pkgname=hugo
pkgver=0.101.0
pkgrel=1
pkgdesc="Fast and Flexible Static Site Generator in Go"
arch=('x86_64')
url="https://gohugo.io/"
license=('Apache')
depends=('glibc')
makedepends=('go' 'git')
optdepends=('python-pygments: syntax-highlight code snippets'
            'python-docutils: reStructuredText support')
source=(${pkgname}-${pkgver}.tar.gz::https://github.com/gohugoio/${pkgname}/archive/v${pkgver}.tar.gz)
sha512sums=('541d0e04e868845119f2b488fd53b92929ea4dc08685d438a2914b41586e204588b193522013e8eed908dc0c3fbc2714aefb1afad0beae875d57d71aadc59c70')

build() {
  cd "${srcdir}"/${pkgname}-${pkgver}
  export CGO_CPPFLAGS="${CPPFLAGS}"
  export CGO_CFLAGS="${CFLAGS}"
  export CGO_CXXFLAGS="${CXXFLAGS}"
  export CGO_LDFLAGS="${LDFLAGS}"
  export GOFLAGS="-buildmode=pie -trimpath -mod=readonly -modcacherw"
  go build -tags extended

  ./hugo gen man
  ./hugo completion bash > ${pkgname}.bash-completion
  ./hugo completion fish > ${pkgname}.fish
  ./hugo completion zsh > ${pkgname}.zsh
}

package() {
  cd "${srcdir}"/${pkgname}-${pkgver}
  install -Dm755 "${pkgname}" "${pkgdir}"/usr/bin/${pkgname}
  install -Dm644 LICENSE "${pkgdir}"/usr/share/licenses/${pkgname}/LICENSE

  install -Dm644 "${srcdir}"/${pkgname}-${pkgver}/man/*.1  -t "${pkgdir}"/usr/share/man/man1/
  
  install -Dm644 ${pkgname}.bash-completion "${pkgdir}"/usr/share/bash-completion/completions/${pkgname}
  install -Dm644 ${pkgname}.fish "${pkgdir}"/usr/share/fish/vendor_completions.d/${pkgname}.fish
  install -Dm644 ${pkgname}.zsh "${pkgdir}"/usr/share/zsh/site-functions/_${pkgname}
}

Wurde nun eine neue Version veröffentlicht, trage ich in der PKGBUILD-Datei in der Zeile pkgver= die neue Version ein. Anschließend führe ich im Verzeichnis in dem die Datei liegt, die Befehle updpkgsums PKGBUILD, makepkg -cirs PKGBUILD –noconfirm und rm – .tar. aus.

Der erste Befehl läd die Archivdatei mit dem Sourcecode herunter, erstellt die Prüfsumme der Datei und trägt diese in der PKGBUILD-Datei ein. Der zweite Befehl erstellt anhand der Anweisungen in der PKGBUILD-Datei das Paket und installiert es. Der letzte Befehl löscht sowohl die Archivdatei mit dem Sourcecode sowie das erstellte Paket.

Da ich darin schon ziemlich geübt bin, dauert dies keine Minute. Ich möchte den Vorgang aber trotzdem automatisieren. Daher habe ich mir eine Funktion erstellt.

updpkgbuild () {
	new_ver="$1"
	sed -E "s#(pkgver=).*#\1$new_ver#" -i PKGBUILD
	updpkgsums PKGBUILD
	makepkg -cirs PKGBUILD --noconfirm
	rm -- *.tar.*
}

Mit dieser brauche ich im Verzeichnis der PKGBUILD-Datei nur beispielsweise updpkgbuild 0.102.0 ausführen und Version 0.102.0 des Pakets wird automatisch installiert. Das ganze klappt natürlich nur, wenn nur die Version sowie die Prüfsumme geändert werden muss. Was aber in den meisten Fällen zutrifft.

Die Funktion habe ich für die zsh erstellt. Ob diese auch in anderen Shells wie der bash oder fish funktioniert, kann ich nicht sagen.

OSBN | Linux

AUR-Pakete wegen Python-Update neu erstellen

Als ich eben die über AUR installierte Software aktualisieren wollte, habe ich folgende Fehlermeldung erhalten.

Der Vorgang konnte nicht durchgeführt werden (In Konflikt stehende Dateien)
tortoisehg: /usr/lib/python3.9/site-packages/hgext3rd/__init__.py existiert im Dateisystem (gehört zu mercurial)
tortoisehg: /usr/lib/python3.9/site-packages/hgext3rd/__pycache__/__init__.cpython-39.pyc existiert im Dateisystem (gehört zu mercurial)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Die Ursache ist, dass in den offiziellen Paketquellen von Arch Linux Python auf Version 3.10 aktualisiert wurde. Was es leider nötig macht die Pakete, die Python nutzen und über AUR installiert wurden, neu zu erstellen.

Als Erstes sollte man mittels pacman -Syu die Pakete aus den offiziellen Paketquellen aktualisieren.

Um sich nun die betroffenen Pakete im AUR anzusehen, kann man folgenden Befehl ausführen.

pacman -Qqo /usr/lib/python3.9 | pacman -Qm -

In meinem Fall werden drei Pakete angezeigt, die ich neu erstellen muss. Wer als AUR-Helper paru verwendet, kann diese mit folgendem Befehl automatisch neu erstellen. Mit anderen AUR-Helpern die eine Rebuild-Funktion anbieten sollte es vergleichbar funktionieren.

pacman -Qoq /usr/lib/python3.9 | pacman -Qmq - | paru -S --rebuild -

Führt man den Befehl nun spaßeshalber noch einmal aus, sollte man die Meldung “Fehler: Kein Paket besitzt /usr/lib/python3.9” erhalten.

Und ja, das ist einer der Nachteile an AUR. Dafür lassen sich die dortigen Rezepte leichter prüfen als beispielsweise fertige Pakete aus einem PPA. Und leichter erstellen lassen sie sich in der Regel auch.

Linux | OSBN

Eigenen Mirror der Arch-Paketquellen erstellen

Wie bereits angekündigt, will ich mittels Ansible die Installation und Konfiguration von Arch automatisieren. Um unabhängig von den offiziellen Mirrors zu sein, habe ich mir daher einfach einen eigenen erstellt. Somit kann ich so lange herumspielen wie ich will.

Da das ganze nur intern für Tests gedacht ist, habe ich es relativ einfach gehalten.

Als Erstes habe ich mir auf einem Raspberry ein Verzeichnis erstellt, in dem die ganzen Pakete landen sollen. Nennen wir es “archpakete”.

Als Webserver nehme ich Caddy mit folgender Konfigurationsdatei.

$IP_DES_RASPBERRY:$PORT_VON_CADDY
root /pfad/zum/Mirrorverzeichnis
gzip
browse

Gzip, also die komprimierte Datenübertragung und browse (das Anzeigen von Verzeichnisinhalten) kann man sich im Grunde auch sparen. Es schadet allerdings auch nicht.

Startet man nun Caddy sollte man nicht viel sehen, da das Verzeichnis “archpakete” noch leer ist. Zeit es zu befüllen. Hierfür habe ich mal wieder im Wiki von Arch gestöbert und folgendes Script gefunden, was ich allerdings etwas angepasst habe (Anzeige des Fortschritts (–progress und | tee)) hinzugefügt und den Download auf die Paketquellen “core” “extra” “community” beschränkt.

#!/bin/bash
#
# The script to sync a local mirror of the Arch Linux repositories and ISOs
#
# Copyright (C) 2007 Woody Gilk <woody@archlinux.org>
# Modifications by Dale Blount <dale@archlinux.org>
# and Roman Kyrylych <roman@archlinux.org>
# Comments translated to German by Dirk Sohler <dirk@0x7be.de>
# Licensed under the GNU GPL (version 2)

# Speicherorte für den Synchronisationsvorgang
SYNC_HOME="/home/pi"
SYNC_LOGS="$SYNC_HOME/archpakete/logs/"
SYNC_FILES="$SYNC_HOME/archpakete"
SYNC_LOCK="$SYNC_HOME/archpakete/mirrorsync.lck"

# Auswahl der zu synchronisierenden Repositorys
# Gültige Optionen sind: core, extra, testing, community, iso
# Leer lassen, um den gesammten Mirror zu synchronisieren
# SYNC_REPO=(core extra testing community iso)
SYNC_REPO=(core extra community)

# Server, von dem synchronisiert werden soll
# Nur offizielle, öffentliche Mirrors dürfen rsync.archlinux.org verwenden
# SYNC_SERVER=rsync.archlinux.org::ftp
SYNC_SERVER=rsync.selfnet.de::archlinux
# An dieser Stelle weicht die Lokalisierte Version des Scripts von der
# Originalversion ab, da der Mirror in der Originalversion seit einigen
# Tagen nicht mehr synchronisiert wurde, und daher nur alte Pakete
# bereit stellte. Selfnet hat eine Quota von 50 GB fullspeed am Tag, und
# wird danach auf 16 KByte/s runtergestuft.

# Format des Logfile-Namens
# Das beispiel gibt etwas wie „sync_20091019-3.log“ aus
LOG_FILE="pkgsync_$(date +%Y%m%d-%H).log"

# Logfile anlegen und Timestamp einfügen
touch "$SYNC_LOGS/$LOG_FILE"
echo "=============================================" >> "$SYNC_LOGS/$LOG_FILE"
echo ">> Starting sync on $(date --rfc-3339=seconds)" >> "$SYNC_LOGS/$LOG_FILE"
echo ">> ---" >> "$SYNC_LOGS/$LOG_FILE"

if [ -z $SYNC_REPO ]; then
  # Sync a complete mirror
  rsync -rptlv \
        --delete-after \
        --safe-links \
        --max-delete=1000 \
        --copy-links \
        --progress \
        --delay-updates $SYNC_SERVER "$SYNC_FILES" \
        | tee "$SYNC_LOGS/$LOG_FILE"
else
  # Alle Repositorys synchronisieren, die in $SYNC_REPO angegeben wurden
  for repo in ${SYNC_REPO[@]}; do
    repo=$(echo $repo | tr [:upper:] [:lower:])
    echo ">> Syncing $repo to $SYNC_FILES/$repo" >> "$SYNC_LOGS/$LOG_FILE"

    # Wenn man nur i686-Pakete synchronisieren will, kann man in dem
    # rsync-Aufruf dies nach „--delete-after“ inzufügen:
    # „ --exclude=os/x86_64“
    # 
    # Will man stattdessen nur die x86_64-Pakete synchronisieren, verwendet
    # man stattdessen „--exclude=os/i686“
    #
    # Will man beide Architekturen auf dem eigenen Mirror anbieten, lässt
    # den rsync-Aufruf einfach, wie er ist
    #
    rsync -rptlv \
          --delete-after \
          --safe-links \
          --max-delete=1000 \
          --copy-links \
          --progress \
          --delay-updates $SYNC_SERVER/$repo "$SYNC_FILES" \
          | tee "$SYNC_LOGS/$LOG_FILE"

    # Erstellt eine Datei „$repo.lastsync“, die den Timestamp der synchronisation
    # beinhaltet (z. B. „2009-10-19 03:14:28+02:00“). Dies kann nützlich sein,
    # um einen Hinweis darauf zu haben, wann der eigene Mirror zuletzt mit
    # dem angegebenen Mirror abgeglichen wurde. Zum Verwenden einkommentieren.
    # date --rfc-3339=seconds > "$SYNC_FILES/$repo.lastsync"

    # Nach jedem Repository fünf Sekunden warten, um zu viele gleichzeitige 
    # Verbindungen zum rsync-Server zu verhindern, fall die Verbindung nach
    # dem synchronisieren des vorherigen Repositorys vom Server nicht
    # zeitig geschlossen wurde
    sleep 5 
  done
fi

# Weiteren Timestamp ins Logfile schreiben, und es schließen
echo ">> ---" >> "$SYNC_LOGS/$LOG_FILE"
echo ">> Finished sync on $(date --rfc-3339=seconds)" >> "$SYNC_LOGS/$LOG_FILE"
echo "=============================================" >> "$SYNC_LOGS/$LOG_FILE"
echo "" >> "$SYNC_LOGS/$LOG_FILE"

# Die lock-Datei zum Sperren des Script-Durchlaufs löschen und das
# Script beenden
rm -f "$SYNC_LOCK"
exit 0

Nun habe ich unter “archpakete” noch schnell ein Verzeichnis “logs” erstellt und obiges Script ausgeführt.

Sobald das Script seine Arbeit getan hat, kann man nun auf seinem Ansible-Test-System in /etc/pacman.d/mirrorlist folgenden Eintrag am Anfang der Datei eintragen.

Server = http://$IP_DES_RASPBERRY:$PORT_VON_CADDY/$repo/os/$arch

Nun laufen alle Downloads der Pakete über den lokalen Mirror und nicht mehr über die offiziellen Spiegelserver.

Linux | OSBN

Eigene Paketquelle für Arch Linux im LAN

Seit einigen Wochen nutze ich für die Zwischenablage das Tools CopyQ. Als ich heute die über AUR installierten Pakete aktualisiert habe, wurde mir angezeigt. Dass CopyQ nun “orphaned” ist. Somit kümmert sich aktuell niemand um die Aktualisierung von CopyQ im AUR.

Wie es der Zufall so will, wurde zwischenzeitlich auch Version 3.6.1 von CopyQ veröffentlicht. Also muss eine Lösung her. Am einfachsten wäre es wohl, die vorhandene PKGBUILD-Datei zu aktualisieren und mir damit Version 3.6.1 lokal zu installieren. Mit folgenden Schritten dauert das keine zwei Minuten.

  • Mit “curl -o PKGBUILD https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=copyq" die PKGBUILD-Datei von Version 3.6.0 herunterladen.
  • In der Datei dann die Version anpassen.
  • Mit updpkgsums PKGBUILD die Prüfsumme automatisch anpassen.
  • Mit makepkg -si PKGBUILD -noconfirm kann man dann das Paket erstellen und installieren.

An dieser Stelle ist es mir aber aufgefallen, dass ich CopyQ ja auf mehreren Rechnern / VM nutze. Gut, ich könnte mittels makepkg PKGBUILD einfach das Paket erstellen und dies auf den betreffenden Rechnern / VM installieren. Ich möchte aber möglichst die Rolle des Turnschuadmins vermeiden. Also wie löse ich das Problem?

Der Raspberry Pi auf dem Pi Hole läuft, langweilt sich im Grunde genommen. Auf diesem könnte ich eigentlich eine eigene Paketquelle für das LAN erstellen. Nur ist auf dem Raspberry Pi Debian installiert, sodass ich die Arch-Tools wie repo-add nicht direkt nutzen kann. Na ja wieso einfach, wenn es auch kompliziert geht?

Als Erstes habe ich auf dem Raspberry Pi ein Verzeichnis erstellt, dass als Paketquelle dienen soll. Dieses habe ich dann unter Arch mittels sshfs gemountet und mittels “repo-add /gemountetes_Verzeichnis/raspberry.db.tar” eine leere Paketquellendatenbank erzeugt. Mit der PKGBUILD-Datei von Version 3.6.0 und makepkg PKGBUILD habe ich dann unter Arch das Paket erstellt und dies in das gemountete Verzeichnis kopiert. Mittels “repo-add /gemountetes_Verzeichnis/raspberry.db.tar copyq-3.6.0-1-x86.pkg.tar” habe ich dann die Datenbank aktualisiert. Da man angeblich mit sshfs gemountete Verzeichnisse direkt als Paketquellen nutzen kann, habe ich dann einfach folgenden Eintrag in der /etc/pacman.conf unter Arch erstellt.

[raspberry]
SigLevel = Optional
Server = file:///gemountetes_Verzeichnis

Der Versuch mittels “pacman -Syy” die Paketquellen zu aktualisieren ist aber immer bei der Paketquelle raspberry gescheitert, da die Datenbank nicht gefunden werden kann. Und das, obwohl der Pfad stimmt und die Dateien vorhanden sind. Selbst mit etwas Google-Fu konnte ich das Problem nicht lösen.

Da auf dem Raspberry Pi ja bereits lighthttpd für die grafische Oberfläche für Pi Hole läuft, ist mir die Idee gekommen, dass ich die Pakete über lighthttpd anbiete. Aber scheinbar sieht Pi Hole es nicht vor, dass man über lighthttpd noch weitere Dienste anbietet. Oder ich bin zu blöd dafür.

Da sich der Raspberry Pi wirklich langweilt, kann man ja einfach Apache installieren. Nein besser nginx, da dieser weniger Ressourcen verbraucht. Gesagt getan. In der Konfigurationsdatei /etc/nginx/sites-available/default habe ich dann bei den beiden Zeilen, die mit listen beginnen, den Port geändert, da ja bereits lighthttpd auf Port 80 läuft. Die Zeile die mit root beginnt, habe ich dann so geändert, dass hier auf das Verzeichnis verwiesen wird, das als Paketquelle dienen soll. Noch etwas weiter unten habe ich den Block location / um die zwei Zeilen allow 192.168.1.1/24; und deny all; erweitert. Somit kann nur noch jemand aus meinem LAN auf nginx zugreifen. Sicher ist sicher. Mit einem Neustart von nginx sorge ich dafür, dass die Änderungen berücksichtigt werden.

Zurück auf dem Rechner mit Arch, auf dem ich die Paketquelle raspberry eingetragen habe, habe ich hier die dritte Zeile auf Server = IP_DES_RASPBERRY:PORT_VON_NGINX geändert. Mit “pacman -Syy” habe ich dann versucht die Paketquellen zu aktualisieren. Was scheinbar auch funktioniert hat, da ich keine Fehlermeldung erhalten habe. Da CopyQ über AUR installiert wurde, habe ich nun CopyQ deinstalliert und mittels pacman und der Paketquelle raspberry wieder installiert. Auch das hat funktioniert.

Da ich ja Version 3.6.1 installieren möchte, habe ich dann wie oben beschrieben die PKBUILD-Datei angepasst und das aktuelle Paket erzeugt. Dies habe ich dann wieder in das gemountete Verzeichnis gepackt und mit “repo-add /gemountetes_Verzeichnis/raspberry.db.tar copyq-3.6.1-1-x86.pkg.tar” die Datenbank aktualisiert. Als ich dann mittels “pacman -Syu” auf Updates geprüft haben, wurde mir Version 3.6.1 von CopyQ angeboten, welche ich gleich installiert habe.

Abschließend habe ich dann noch bei allen betreffenden Rechnern CopyQ deinstalliert, die neue Paketquelle hinterlegt und aktualisiert und CopyQ über diese neu installiert.

Vermutlich wäre es einfacher gewesen, einfach die Betreuung von CopyQ im AUR zu übernehmen. Aber das hätte weniger Spaß gemacht. Und wie schon weiter oben angegeben. Warum einfach, wenn es auch kompliziert geht? Zudem kann ich in meiner Paketquelle so viel Mist bauen wie ich will, ohne dafür einen verbalen Einlauf von Dritten zu erhalten. Und ich werde die Paketquelle wohl auch in mein Ansible-Projekt einbauen. Und da ich einige AUR-Pakete installiert habe, deren Betreuer sich oft ziemlich viel Zeit mit dem Aktualisieren lassen, wird es auch nicht bei einem Paket bleiben.

Linux | OSBN