Fryboyter

Bestimmte Version von Composer bei Uberspace installieren

Als ich eben eine Wallabag-Installation bei Uberspace.de aktualisieren wollte, habe ich folgende Fehlermeldung erhalten.

Your lock file does not contain a compatible set of packages. Please run composer update.

  Problem 1
    - Root composer.json requires composer < 2.3, found composer[2.3.10] but it does not match the constraint.

Die Empfehlung composer update auszuführen, hilft in diesem Fall nicht. Denn das Problem ist, dass bei Uberspace Version 2.3.10 von Composer installiert ist. Wallabag setzt aktuell aber Composer in einer Version < 2.3 voraus. Bisher hatte ich bei Uberspace eigentlich nur Fälle bei denen bestimmte Pakete zu stable (man könne auch sagen zu alt) waren. Öfter mal was Neues.

Also ist, zumindest vorübergehend, ein Workaround nötig. Auf dem betreffenden Uberspace hab ich folgende Befehle ausgeführt.

wget -qO composer-setup.php https://getcomposer.org/installer
php composer-setup.php --install-dir=/home/$USER/bin --filename=composer --version=2.2.17

Der erste Befehl lädt den Installer von Composer herunter. Mit dem zweiten wird die Version 2.2.17 von Composer heruntergeladen und im Verzeichnis ~/bin mit dem Dateinamen composer gespeichert.

Anschließend konnte ich Wallabag ohne Probleme aktualisieren. Da ~/bin Teil von $PATH ist und Composer nicht für die Nutzung von Wallabag nötig ist, habe ich die Datei abschließend in composer.old umbenannt um eventuelle Probleme mit anderer, installierter Software vorzubeugen die eine neuere Version benötigt.

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 entmystifizieren 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.

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.

I/O Scheduler automatisch einstellen

Mit einem I/O Scheduler wird die zeitliche Abfolge von Lese- und Schreibvorgänge bei Speichermedien koordiniert. Je nachdem ob es sich um eine normale HDD, eine SSD oder eine NVMe handelt, können unterschiedliche Scheduler sinnvoll sein. Oft nutzen Distributionen allerdings den gleichen Scheduler für alle Speichermedien.

Bei einem normalen Rechner eines durchschnittlichen Benutzers fällt dies meist nicht ins Gewicht. Optimal ist es trotzdem nicht. Also sollte man sein System entsprechend konfigurieren.

Nun ist es so, dass ich in meinem Hauptrechner sowohl HDD, SSD als auch NVMe verbaut habe und regelmäßig zusätzliche Speichermedien temporär anschließe. Somit möchte ich den Scheduler automatisch zuweisen lassen. Dies lässt sich mit einer udev Regel umsetzen. Hierfür erstellt man die Datei /etc/udev/rules.d/60-ioschedulers.rules und füllt diese mit folgendem Inhalt.

# Scheduler für HDD
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
# Scheduler für SSD
ACTION=="add|change", KERNEL=="sd[a-z]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# Scheduler für NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"

Hiermit wird normalen HDD der Scheduler bfq zugeordnet. Bei SSD kommt der Scheduler mq-deadline zum Einsatz. Und im Falle von NVMe wird meist none eingestellt, da bei diesen Speichermedien ein anderer Scheduler oft keinen Vorteil bringt. Wer will, kann natürlich etwas anderes einstellen.

Anschließend liest man mit Root-Rechten mittels udevadm trigger die angeschlossene Hardware neu ein damit die Regeln genutzt werden. Alternativ kann man auch einfach den Rechner neu starten.

Danach sollte je nach Speichermedium der entsprechende Scheduler aktiv sind. Überprüfen lässt sich dies mit dem Befehl grep "" /sys/block/*/queue/scheduler. Der jeweils verwendete Scheduler wird in eckigen Klammern angezeigt.

Pi-hole - Interface eth0 does not currently exist

Seit einiger Zeit erhält man als Nutzer von Pi-hole unter Umständen die Fehlermeldung interface eth0 does not currently exist in der grafischen Oberfläche.

Der Grund hierfür ist in der Regel, dass Pi-hole schneller startet als die Netzwerkverbindung aufgebaut wird. Auf die Funktion hat dies keinen Einfluss, auch noch später getestet wird, ob eine Netzwerkverbindung vorhanden ist. Irgendwie nervt es aber trotzdem, da diese Meldung anhand eines hüpfenden Symbols angezeigt wird. Löscht man die Meldung, verschwindet es zwar, aber nach einem Neustart des Raspberry Pi geht es wieder von vorne los.

Die Lösung diese (kosmetischen) Problems ist ziemlich einfach. Man trägt einfach am Anfang der Datei /etc/pihole/pihole-FTL.conf DELAY_STARTUP=5 ein. Damit wird der Start um 5 Sekunden verzögert, sodass zwischenzeitlich die Netzwerkverbindung aufgebaut werden kann.

Je nach Konfiguration und verwendeten Raspberry Pi kann man eventuell einen niedrigeren Wert eintragen. Mit 5 Sekunden sollte man aber immer auf der sicheren Seite sein und es dürfte zu verschmerzen sein, wenn Pi-Hole etwas später zur Verfügung steht. Zumal man in der Regel ja nicht täglich mehrere Neustarts durchführt.