Fryboyter

WLAN Stick und Predictable Network Interface Names

Predictable Network Interface Names sind im Grunde eine gute Sache, da der zugeteilte Name des Interfaces immer gleich bleibt. Bei einem USB-WLAN-Stick kann es aber auch nerven.

Wie heute schon geschrieben, habe ich mir den Fritz!WLAN Stick AC 860 zugelegt. Diesen habe ich bei ersten Tests in den USB-Port auf der rechten Seite des Notebooks gesteckt. Der Befehl “ip addr” hat dann zum Beispiel “wlp0s26u1u2” als Interface-Name ausgspuckt, welchen ich in die Konfigurationsdatei von netctl eingetragen habe. Nachdem alles funktioniert hat, habe ich noch etwas herumgespielt und hierbei den Stick auch in den USB-Port auf der linken Seite gesteckt. Und schon konnte ich die Netzwerkverbindung nicht aufbauen. Ein erneutes Ausführen von “ip addr” hat mir nun den Interface-Namen “wlp0s20u2” angezeigt.

Im Grunde genommen ist das auch logisch, da es sich um einen anderen Steckplatz handelt und daher auch ein anderer Name fest zugeteilt wird. Aber in der Praxis ist das ungünstig, da in der Konfiguration von netctl der Interface-Name fix eingetragen wird. Muss ich also zukünftig darauf achten, den Stick immer in den gleichen Port zu stecken? Entweder das oder man erstellt sich eine udev-Regel.

Hierzu schließt man erst einmal den Stick an und führt danach “lsusb” aus. Hiermit erhält man beispielsweise folgende Ausgabe.

Bus 001 Device 004: ID 057c:8503 AVM GmbH

Nun prüft man, wie udev den Stick sieht. Hierzu führt man folgenden Befehl aus.

udevadm info -a -p $(udevadm info -q path -n \_/dev/bus/usb/001/004) | grep ATTR{configuration} 

Hier muss man den Teil mit /dev/bus/usb entsprechend der Ausgabe von lsub anpassen. Im Falle des von mir verwendeten Sticks wird “ATTR{configuration}==“FRITZ!WLAN AC 860”” ausgegeben.

Nun hat man alles, was man für eine udev-Regel braucht. Unter /etc/udev/rules.d/ erstellt man daher die Datei 10-network-devices.rules mit folgendem Inhalt und speichert diese ab. Nutzt man einen anderen Stick, muss man logischerweise bei ATTRS{product} etwas anderes eintragen.

SUBSYSTEM=="net", ACTION=="add", ATTRS{product}=="FRITZ!WLAN AC 860", NAME="wlan"

Schließt man zukünftig einen Netzwerkadapter über USB an, wird geprüft ob dieser das Produkt-Attribut “FRITZ!WLAN AC 860” hat. Wenn ja, wird diesem der Interface-Name “wlan” zugeteilt. Und zwar egal an welchem USB-Anschluss der Stick angeschlossen wurde.

Vielleicht ist es dem einen oder anderen aufgefallen, dass bei dem Befehl mit udevadm ATTR{product} angezeigt wird, in der Regel aber ATTRS{product} steht. Das ist kein Fehler, sondern muss in diesem Fall so sein.

Linux | OSBN

Fritz!WLAN Stick AC 860 unter Linux

In meinem Notebook ist eine Centrino Advanced-N 6205 WLAN-Karte verbaut. Diese verbindet, egal was ich mache, mit maximal 54 MB/s (genutzt wird noch weniger). Laut Google bin ich wohl nicht der einzige mit dem Problem. Also muss etwas her das mehr Bandbreite bietet.

Normalerweise würde ich einfach die Karte wechseln. Was bei Geräten von Lenovo (zumindest bei älteren Modellen) nicht ganz so einfach ist. Denn im Bios / UEFI ist eine Whitelist vorhanden. Somit funktionieren nur bestimmte Karten. Eine offizielle Aufstellung funktionierender Karten gibt es natürlich nicht. Weihnachtsgeld sei dank habe ich mir spontan den WLAN-USB-Stick AC 860 von AVM gekauft.

Im Lieferumfang findet man neben dem USB-Stick auch einen USB-Standfuß sowie eine Anleitung.

Auf dem Notebook ist Arch (Kernel 4.19.9) installiert. Gleich nach dem anschließen des Sticks wird dieser erkannt und startet im sogenannten CD-ROM-Modus. Auf diesem “CD-ROM” sind die Treiber gespeichert. Natürlich für Windows. Das ist zum einen für Linux überflüssig und zum anderen bleibt der Stick in diesem Modus hängen. Super.

Die Lösung ist allerdings ziemlich einfach. Man muss einfach usb_modeswitch installieren. Bei Arch liegt das Paket in den community Paketquellen. Stöpselt man dann den Stick an, startet er im richtigen Modus durch.

Für die Netzwerkverbindungen auf meinem Notebook verwende ich netctl. Hier musste ich nur die Bezeichnung des alten Interface gegen die des neuen in der Konfigurationsdatei austauschen. Und schon steht die Verbindung. Theoretisch sind laut Router 866 / 866 Mbit/s möglich. In der Praxis ist der Stick mit 650 / 780 Mbit/s verbunden und läuft stabil. Mal schauen ob man hier noch etwas an der einen oder anderen Schraube drehen kann. Alles in allem bin ich zufrieden. Endlich kann ich die komplette Bandbreite meines Internetanschlusses auch mit dem Notebook ausreizen. Einen Datentransfer im LAN konnte ich noch nicht testen. Ich gehe aber davon aus, dass das auch keine Probleme macht.

Noch ein Hinweis zum Schluss. Der Stick wird erst ab Kernel 4.19 unterstützt.

Linux | OSBN

Dateisystem Btrfs wird demnächst Swap-Dateien unterstützen

Seit Jahren verwende ich auf meinen privaten Rechnern kein Swap. Für spezielle Fälle war es aber ganz nützlich mal eben eine Swap-Datei anzulegen. Seit ich Btrfs nutze, war dies leider keine Option mehr, da dieses Dateisytem keine Swap-Dateien unterstützt. Das wird sich demnächst voraussichtlich aber wieder ändern.

Warum wieder? Im Jahre 2009 wurde die Unterstützung von Swap-Dateien entfernt, da Swap-Dateien Probleme gemacht haben. Der Entwickler Omar Sandoval hat nun aber kürzlich einen Patcheingereicht, der die sichere Nutzung von Swap-Files unter Btrfs ermöglicht. Wenn es keine Probleme damit gibt, könnte diese Änderung bereits in der übernächsten Version des Kernels (voraussichtlich März 2019)_enthalten sein.

Linux | OSBN

Hinweis an alle Betreiber von DNS-Resolvern die DNSSEC verwenden

Der eine oder andere wird sicherlich einen DNS-Resolver im eigenen Netzwerk einsetzen um damit beispielsweise die Anfragen zu beschleunigen oder um die Privatsphäre zu vergrößern. Wer hierbei DNSSEC einsetzt, sollte sich den 11.10.2018 im Kalender anstreichen.

Denn an diesem Tag will ICANN den bisherigen Vertrauensanker (Trust Anchor) gegen einen neuen tauschen. Wer ab dann noch den alten Anker nutzt, wird hinsichtlich DNS ein Problem haben.

Wer zum Beispiel DNSSEC auf seinem Pi Hole nutzt, kann wie folgt nachsehen.

cat /etc/dnsmasq.d/01-pihole.conf

...

trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

Die erste Zeile entspricht hier dem bisherigen Anker und die zweite dem neuen Anker. Somit sollten Pi-Hole-Nutzer nichts von der Umstellung bemerken.

Wer Unbound nutzt, kann mittels unbound-anchor -l nachsehen. Bei den von mir getesteten Versionen 1.6.0-3 (Raspbian) sowie 1.8.0-1 (Arch) ist ebenfalls alles im grünen Bereich. Nutzer anderer DNS-Resolver müssen leider selbst schauen wie sie an die nötigen Informationen kommen.

Wer aber seinen DNS-Resolver händisch installiert hat bzw. diesen schon wirklich lange nicht mehr aktualisiert hat, sollte vorsichtshalber einmal nachsehen. ICANN geht selbst davon aus, dass nach der Umstellung nur eine überschaubare Anzahl an Nutzern betroffen sein werden.

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 eigenen Paketquelle für das LAN erstellen. Nur ist auf dem Raspberry Pi Debian installiert, so dass ich die Arch-Tools wie repo-add nicht direkt nutzen kann. Naja 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 Resourcen 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.124; 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 Betreuuung 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 willl 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