Fryboyter

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

Fritz!WLAN Stick AC 860 funktioniert nach Standby-Modus nicht mehr

Vor ein paar Tagen hatte ich einen Artikel über den Fritz!WLAN Stick AC 860 veröffentlicht. Zwischenzeitlich habe ich leider feststellen müssen, dass die WLAN-Verbindung nicht wieder aufgebaut wird, wenn der Rechner aus dem Standby-Modus geholt wird.

Die Lösung oder besser gesagt der Workaround ist allerdings relativ simpel. Ich habe mir unter /etc/systemd/system einfach zwei neue Service-Dateien mit folgenden Inhalt erstellt und diese dann aktiviert.

[Unit]
Description=WLAN vor Standby deakivieren
Before=sleep.target

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl stop netctl@wlan.service ; /usr/bin/rmmod mt76x2u

[Install]
WantedBy=sleep.target
[Unit]
Description=WLAN nach Standby aktivieren
After=suspend.target

[Service]
Type=oneshot
ExecStart=/sbin/modprobe mt76x2u ; /usr/bin/systemctl start netctl@wlan.service

[Install]
WantedBy=suspend.target

Die erste Service-Datei deaktiviert die Netzwerkverbindung bevor der Rechner schlafen gelegt wird. Die zweit startet die Netzwerkverbindung wieder wenn der Rechner aus dem Standby-Modus geholt wurde.

Linux | OSBN

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