Arch Linux – jojumaxx

Du bist hier: Home ➥ Linux-Distributionen ➥ Arch Linux

Inhalt

Basics über Arch Linux
How To’s
Weiteres Wissen
1. nmcli und mmcli

Bitte beachtet den Disclaimer!

Basics

Bei Arch Linux handelt es sich um eine für Prozessoren mit der „x86-64“-Architektur (AMD) optimierte Linux-Distribution.
Da viele Intel-Prozessoren über die EM64T Technologie verfügen, die kompatibel zur „x86-64“-Architektur ist und teilweise darauf basiert, läuft Arch Linux auch auf Rechnern mit Intel-Prozessoren.

Arch Linux ist relativ UNIX-nah und ist eine Linux Distribution für Fortgeschrittene, weil man sich sein System nach eigenen Wünschen selbst konfiguriert und in Eigenverantwortung pflegt.
Außerdem handelt es sich um eine „Rolling-Release“-Distribution was bedeutet, dass es keine Versionen mit eigenen Versionsnummern oder -namen gibt, sondern das bestehende System immer weiter optimiert und aktualisiert wird. Es erscheinen also keine neue Releases, die eine komplette Neuinstallation des Systems erfordern.
Hierin liegt ein gewisser Teil an oben erwähnter Eigenverantwortung der darin besteht, sich über Systemaktualisierungen und die daraus resultierenden Veränderungen zu informieren und diese dementsprechend durchzuführen.

Achtung:
Wurde das System über Monate nicht aktualisiert, kann auch bei einem Rolling Release eine komplette Neuinstallation notwendig werden, da das System aufgrund des Alters nicht schrittweise, wie geplant, aktualisiert werden kann.

Arch Linux auf mobile Geräten zu bringen, hat sich das „Arch Linux ARM“ Projekt auf die Fahnen geschrieben. Ob hier die Absicht besteht, die ARM-Version in den Main-Kernel zu integrieren, kann ich bis dato nicht sagen.

Arch Linux ARM

Das seit 2002 existierende Projekt Arch Linux ARM portiert Arch Linux auf die ARM-Architektur mobiler Prozessoren nach dem Motto

„simplicity and full control to the end user“

welches in starkem Kontrast zu den existierenden kommerziellen mobilen Betriebssystemen steht.
Das Projekt basiert vollständig auf freiwilliger, spendenfinanzierter Arbeit.

Welche Distributionen basieren auf Arch Linux?

Manjaro

Paketmanager

Der Paketmanager von Arch Linux nennt sich Pacman (package manager).
Speziell für Manjaro existiert eine Paketverwaltung mit grafischer Oberfläche, die darauf aufsetzt und sich pamac nennt, die auch Pakete aus dem AUR (Arch User Repository) verwalten kann.
Mehr zu pamac findet sich unter Manjaro/Arch Basics.

pacman -Syyu	Vollständige Systemaktualisierung mit Datenbankprüfung
pacman -Syu	Vollständige Systemaktualisierung
pacman -S <paketname>	Paketinstallation inkl. Abhängigkeiten
pacman -Rs <paketname>	Deinstallation inkl. Abhängigkeiten
pacman -Ss <suchbegriff>	Suche in Paketnamen Paketbeschreibungen
pacman -Scc	Paket-Cache leeren (Speicher freigeben)

Die wichtigsten pacman – Befehle

Beim Installieren von Anwendungen via Terminal sollte man dies nach dem Muster:

$ sudo pacman -Syu <package>

tun. Dabei steht:

S für „sync“
y für „download fresh package database“ (das zweite y erzwingt den Download, auch wenn die Datenbank aktuell scheint (siehe auch hier)
u für system update

Dies sorgt dafür, dass die Datenbank aktuell gehalten wird und es nicht zu Fehlern kommt.

Hinweis:
Flatpaks werden von pacman nicht verwaltet!

Paketquellen (Repositories)

Installierte Repositories auflisten:
Meines Wissens verfügt Pacman über keinen Befehl, um die installierten Repositories direkt aufzulisten.
Jedoch kann man auf den Befehl zum Synchronisieren der offiziellen Repositories zurückgreifen, da während des Synchronisierens alle Repositories aufgelistet werden:

$ sudo pacman -Syy

Arch User Repository (AUR)

Neben den offiziellen Paketquellen (Arch Linux official repositories) gibt es das Arch User Repository (AUR). AUR-Skripte werden von Arch Linux Benutzern für Arch Linux erstellt. Solche PKGBUILD’s sind somit inoffiziell und ohne spezielle Prüfung. Daher nutzt man Pakete aus diesem Repository auf eigene Gefahr.

In der Regel unterscheidet jede Linux-Distribution Paketquellen (Repositories), die von den Entwicklern selbst bereitgestellt werden und jenen, die von der Community gepflegt werden.
Erstere sind bei Arch Linux „Core“ und „Extra“ und bspw. bei Ubuntu „main“.
Letztere sind bei Arch Linux „community“ und bspw. bei Ubuntu „universe“.
Standardmäßig stehen diese Repositories den Paketmanagern zur Verfügung, so dass man im laufenden Betrieb hier keinen Unterschied bemerkt.

Das Arch User Repository (AUR) stellt in diesem Umfeld eine Besonderheit für Arch Linux und die darauf aufbauenden Distributionen (Derivate) dar.
Wurde neue Software entwickelt, muss diese zunächst in einem Repository zur Verfügung gestellt werden, um sie über die Standardkanäle verfüg- und nutzbar zu machen.
Nicht so beim Arch User Repository. Aus dem AUR bezieht man sog. PKGBUILD-Dateien. Diese beinhalten nicht die Software selbst, sondern eine Art Anleitung, die beschreibt, woher die Software zu beziehen ist, wie sie optimalerweise in die Arch-Distribution eingebunden wird und welcher Abhängigkeiten sie bedarf.
So können Programme, die lediglich als Quellcode vorliegen, in einem speziellen Paketformat wie „.deb“ oder „.rpm“, oder als statisch gebaute Binärpakete, i.d.R. problemfrei installiert werden.
Nahezu jede Software wird auf diese Weise in einem Arch-System nutzbar, selbst proprietäre.

Die Hürde, Software bereitzustellen, ist auf diesem Weg niedriger, was zu Schadsoftware im AUR führen kann. Auch wenn sich eine Gruppe von „Trusted Users“ dem Entfernen selbiger verschrieben hat, ist es dennoch angeraten, die Augen offen zu halten.

Die PKGBUILD-Dateien aus dem AUR lassen sich mittels pacman installieren. Das sähe für die pinephone-dev-tools z.B. so aus:

$ sudo pacman -S --needed git
$ git clone https://aur.archlinux.org/pinephone-dev-tools.git
$ cd pinephone-dev-tools
$ makepkg -si

Eine Aktualisierung sähe mit pacman so aus (muss in jenem Verzeichnis ausgeführt werden, in das die Software geklont wurde:

$ git pull && makepkg -si

Die Deinstallation:

$ sudo pacman -R pinephone-dev-tools

Deinstallation inkl. der nicht mehr benötigten Abhängigkeiten:

sudo pacman -Rs pinephone-dev-tools

Deinstallation inkl. der nicht mehr benötigten Abhängigkeiten und Konfigurationen:

sudo pacman -Rns pinephone-dev-tools

Durch die Nutzung von pacman behält man die volle Kontrolle über die Abläufe. Diese Methode hat jedoch einen entscheidenden Nachteil: pacman verwaltet nicht die Abhängigkeiten, die AUR-Software haben kann. Ist also ein Paket von einem anderen Paket des AUR abhängig und dieses evtl. noch einmal von einem weiteren, müssen diese manuell verwaltet werden, was extrem kompliziert bis nahezu unmöglich werden kann.

Hier kommen nun die „AUR-Helper“ ins Spiel, derer es mehrere gibt. Dabei handelt es sich um eine Art „Installer“, ein Tool, das die PKGBUILD-Dateien interpretiert die Anweisungen ausführt und die Abhängigkeiten auflöst. Durch diese Automatisierung und dadurch, dass die AUR-Helper i.d.R. die Syntax von pacman übernehmen, ist die Installation von Software aus dem AUR vergleichbar mit der Installation von Software aus den Standardquellen.

Die AUR-Helper selbst sind Tools, die von der Community betreut werden. Es kommt immer wieder vor, dass ein AUR-Helper nicht weiter betreut wird und nach einer Weile nicht mehr funktioniert. Desweiteren kann praktisch kein AUR-Helper alles. Das soll heißen, dass man immer Alternativen zum verwendeten AUR-Helper im Blick haben sollte.

Da es sich auch bei den AUR-Helpern selbst um PKGBUILD-Dateien aus dem AUR handelt, erfolgt die Installation selbiger auf die oben, für die pinephone-dev-tools beschriebene Weise. Hier als Beispiel für paru:

$ sudo pacman -S --needed base-devel
$ git clone https://aur.archlinux.org/paru.git
$ cd paru
$ makepkg -si

Die pinephone-dev-tools würde man mittels paru also folgendermaßen installieren:

$ paru -S pinephone-dev-tools

Eine Aktualisierung der installierten Pakete sähe mit paru so aus:

$ paru -Syu

Dabei führt paru auch noch ein normales Update aus, indem es

$ pacman -Syu

ausführt.

Service-/Prozessmanager

Arch Linux verwaltet Prozesse mittels systemd (beinhaltet init system zur Verwaltung von Services die mit Systemstart geladen werden).
Zum Verwalten/Kontrollieren von systemd nutzt man systemctl Befehle.

Die aktuell installierte Version von systemctl lässt sich ermitteln via:

$ systemctl --version

How To’s

Während meiner Nutzung der Pinephones gab es immer wieder kleinere und größere Hürden zu überwinden, um bestimmte Funktionalitäten zu ermöglich. Wie ich dabei vorgegangen bin, möchte ich hier beschreiben.

Es handelt sich lediglich um bestimmte Szenarien, denen ich begegnet bin. Für diese beschreibe ich meine persönliche Lösung bzw. mein persönliches Vorgehen.

Dateien im Terminal editieren

Anfangs fand ich keinen funktionierenden grafischen Texteditor, mittels dem sich Dateien edsitieren ließen.
Die Lösung war der im Terminal funktionierende Texteditor „Vim“. Man öffnet die Datei mittels

$ vim <dateiname>

Vim funktioniert grundlegend mit folgenden Eingaben:

Um den Text bearbeiten zu können wechselt man in den Bearbeitungsmodus: ‚i‚ (insert)
Bearbeitungsmodus verlassen: ‚Esc‚
Text speichern: ‚:‚ gefolgt von ‚w‚ (write)
vim beenden: ‚:‚ gefolgt von ‚q‚ (quit)

Prüfen, ob erfolgreich geschrieben wurde (der „concatenate“-Befehl liest den Inhalt einer Datei und gibt ihn im Terminal aus):

$ cat <dateiname>

Software Updates

Den graphischen Apps zur Paketverwaltung wird nachgesagt, in Einzefällen nicht richtig zu funktionieren, weshalb man besser das Terminal zum (De-)Installieren, Updaten usw. nutzen sollte.
Denn wenn während einer Systemaktualisierung ein Fehler auftritt, kann dies das ganze System unbrauchbar machen. Hier funktioniert das Terminal zuverlässiger.

Nach Software Updates suchen:

$ sudo pacman -Syu

oder

$ sudo pacman -Syyu

(Sinngemäßer) Unterschied zwischen
sudo pacman -Syu und sudo pacman -Syyu:

sudo pacman -Syu

User: Hallo Server, hast du neue Pakete, Aktualisierungen oder andere Änderungen für mich?
Server: Nein
User: Ok, tschüss

sudo pacman -Syyu

User: Hallo Server, hast du neue Pakete, Aktualisierungen oder andere Änderungen für mich?
Server: Nein
User: Mir egal, schick mir trotzdem die gesamte Datenbank, ich schau selbst

Updatefehler

Fehler bei Updates können immer wieder auftreten. Bisher hatte ich lediglich folgende Fehler:

Ein lokales Paket ist neuer als die Version der aktuellen Datenbank

Beim Ausführen eines Systemupdates mittels

$ pacman -Syu

erscheinen Fehlermeldungen wie diese:

warning: initscripts: local (2011.09.2-1) is newer than core (2011.07.3-1)
warning: kbd: local (1.15.3-2) is newer than core (1.15.3-1)

Das kommt potentiell dann vor, wenn Pakete nicht aus den Standard-Paketquellen installiert werden (bspw. eine neuere Betaversion oder einfach eine aktuellere Version, die noch nicht in die Kerndatenbank aufgenommen wurde).

In der Regel hilft die Anweisung, Pakete, deren Version aktueller ist, als jene, in der aktuellen Kerndatenbank, downzugraden. Die neuere lokale Version wird also durch die aktuelle Version der Kerndatenbank ersetzt. Dies funktioniert durch ein zusätzliches ‚u‘ beim Update-Befehl („-uu: sys upgrade all packages, repeated ‚u‘ flag enables downgrades“):

$ pacman -Syuu

Anschließend sollte ein normales Systemupgrade problemlos durchlaufen:

$ pacman -Syu

SSH-Zugriff auf Arch

Arch Linux‘ Servicemanager ist systemd. Mit systemd interagiert man via „systemctl“-Befehlen.
Der SSH Service nennt sich „sshd.service“. Hier sind einige Befehle, um den Zugriff auf dem Pinephone zu ermöglichen (Voraussetzung:
Privater und öffentlicher Schlüssel (/home/user/.ssh/<public-key>) sind bereits hinterlegt).

SSH starten	sudo systemctl start sshd.service
SSH stoppen	sudo systemctl stop sshd.service
SSH neu starten	sudo systemctl restart sshd.service
SSH Server Status	sudo systemctl status sshd.service
SSH beim Booten starten	sudo systemctl enable sshd.service
Prüfen, ob SSH beim Booten startet	sudo systemctl is-enabled sshd.service

sshd – Befehle

Die aktuelle IP-Adresse lässt sich via

$ ip address

auf dem Pinephone abfragen. Auf dem Rechner funktioniert der Zugriff dann wie gewohnt:

$ ssh <pp-username>@<pp-ip-address>

Beenden lässt sich die SSH-Session via

$ exit

SSH-Schlüssel

Damit der Zugriff via SSH überhaupt funktioniert, muss es ein Schlüsselpaar geben, das sicherstellt, dass der zugreifende Rechner vertrauenswürdig ist. Dieses Schlüsselpaar muss für jeden Rechner, der SSH-Zugriff erhalten soll, einzeln generiert werden.
Dabei entstehen ein privater, sowie ein dazugehörender öffentlicher Schlüssel. Der öffentliche Schlüssel kann auf jedes Gerät kopiert werden, auf das per SSH zugegriffen werden soll.

Das Schlüsselpaar wird also auf dem Rechner, der mittels SSH auf das Pinephone zugreifen soll, generiert.
Auf einem Rechner, auf dem bspw. Ubuntu läuft, funktioniert dies folgendermaßen:

Schlüsselpaar generieren (auf Rechner):

$ ssh-keygen -b 4096

Der private Schlüssel (id_rsa) wird in folgendes Verzeichnis kopiert:

/home/<benutzer>/.ssh/<private_key>

Existiert dieses Verzeichnis bisher nicht, muss es angelegt werden.
Der Pfad lautet dann: /home/<benutzer>/.ssh/id_rsa

Da auf das PinePhone mehrere Rechner mit jeweils eigenem öffentlichen Schlüssel zugreifen können, werden diese zusammen in der Datei „authorized_keys“ gespeichert. Hierfür muss lediglich der neue Schlüssel (die Zeichenfolge), aus der oben generierten Datei „id_rsa.pub“, an das Ende der Datei „authorized_keys“ kopiert werden.

Gibt es bisher noch keine weiteren Schlüssel, kann der öffentliche Schlüssel (id_rsa.pub) auf das Pinephone in folgendes Verzeichnis kopiert werden:

/home/<benutzer>/.ssh/<public_key>

Existiert dieses Verzeichnis bisher nicht, muss es auch hier angelegt werden. Der Pfad lautet dann:
/home/<benutzer>/.ssh/id_rsa.pub

Jetzt wird diese Datei einfach in „authorized_keys“ umbenannt:

$ mv id_rsa.pub authorized_keys

Der vollständige Pfad lautet dann:
/home/<benutzer>/.ssh/authorized_keys

Wie kopiere ich den Key in das richtige Verzeichnis?

Nachdem ich das Schlüsselpaar auf dem Rechner generiert hatte, habe ich den öffentlichen Schlüssel (public key) auf einen Cloudspeicher kopiert.
Auf diesen konnte ich mit dem Browser des Pinephones zugreifen und die Datei herunterladen. Anschließend habe ich diese mittels Terminal nach /home/<benutzer>/.ssh/ verschoben

$ mv /home/<benutzer>/Downloads/id_rsa.pub /home/<benutzer>/.ssh/

und in „authorized_keys“ umbenannt

$ mv /home/<benutzer>/.ssh/id_rsa.pub /home/<benutzer>/.ssh/authorized_keys

ZIP-Dateien entpacken

Hin und wieder ließen sich ZIP-Archive nicht in der GUI entpacken. Im Terminal funktioniert dies i.d.R. dennoch. Hierfür das Paket unzip mittels

$ sudo pacman -Syu unzip

installieren. Anschließend mittels

$ unzip <dateiname>.zip

entpacken.

Achtung:
Das Entpacken großer Dateien mittels „unzip“ im Terminal kann fehlschlagen, wenn nicht genügend Arbeitsspeicher zur Verfügung steht. Das Entpacken von ca. 3GB großen Archiven schlug auf einem Pinephone mit 3GB RAM fehl, während kleinere Dateien problemlos funktionieren.

Weiteres Wissen

Hinweis:
Diese Informationen erheben keinen Anspruch auf Richtig- oder Vollständigkeit! Es werden hier lediglich Informationen wiedergegeben, die ich während dem Sammeln von Erfahrung mit den Pinephones gesammelt habe.

nmcli – mmcli

Dem Überblick geschuldet sei hier erwähnt, dass sich der Netzwerkmanager via nmcli (network manager command line interface) – Befehlen steuern lässt, während man den Modemmanager via mmcli (modem manager command line interface) – Befehlen steuert.

Diese Befehle gehören zu einem, über den DBus laufenden Linux-Daemon, der ein High-Level API (Interface mit hohem Abstraktionslevel) bereitstellt. Mit Hilfe dessen kann man mit verschiedenen mobilen Breitbandmodems über einheitliche Befehle kommunizieren.