Steffens Blog

Wireguard ist ein VPN mit direkter Integration in den Linux Kernel. Wireguard ist mit ca. 4000 Zeilen Code vergleichsweise übersichtlich und deshalb wartbarer als z.B. OpenVPN. Wireguard ist außerdem schneller und um Längen leichter aufzusetzen. Alle benötigten Werkzeuge zur Schlüsselverwaltung sind dabei

In den meisten Distributionen ist Wireguard verfügbar. In CentOS 8 sollte man einfach Kernel 6.x nachinstallieren, denn das Wireguard Modul ist dort fest einkompiliert. Nach erfolgreicher Installation kann man das Kernelmodul testen.

modinfo wireguard

Server Grundkonfiguration

Wenn diese Ausgabe nicht leer ist, kann man loslegen. Wir generieren einen privaten Schlüssel und schreiben ihn direkt in eine neue Konfigurationsdatei.

sudo -i
cd /etc/wireguard/
wg genkey | tee wg0.conf
vim wg0.conf

Dann die Datei editieren und speichern.

[Interface]
PrivateKey = <privater Schlüssel>
Address = 192.168.10.1/24
ListenPort = 12345
PostUp = iptables -A FORWARD -i wg1 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens11 -j MASQUERADE;
PostDown = iptables -D FORWARD -i wg1 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o ens11 -j MASQUERADE;

Den Service aktivieren und starten

systemctl enable wg-quick@wg0.service --now

Firewall

Beispielkonfiguration für firewall-cmd

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Wireguard</short>
  <description>Ports for currently configured Wireguard instances</description>
  <port protocol="udp" port="12345"/>
  ...
</service>

Konfigurationsdatei nach /etc/firewalld/services/wireguard.xml speichern. Dann den Service aktivieren und die …

Neue Version von pyduin verfügbar.

Hauptsächlich Qualitätssicherung durch pytest, yamllint und pylint. Unter der Haube wurden Pinfiles zu Boardfiles. Das Wording emanzipiert sich zunehmend von der Arduino-Umgebung. Es macht mehr Sinn, von Devices zu sprechen.

Bei den Tests setze ich erstmalig auf pytest und das funktioniert nach einigen Startschwierigkeiten sehr gut und spart tatsächlich eine Menge Code. Die coverage liegt derzeit bei 78% und deckt die neuralgischen Punkte ab.

Es gibt jetzt eine Github-Pipeline. Alle Tests können nach wie vor lokal mit tests.sh lokal getestet werden.

Mit dem sparkfun_promicro16 wird ein neues Gerät unterstützt. Kleine Firmwarebugs wurden beseitigt. Das Abrufen der gesetzten Modi bei einem Pin funktioniert nun korrekt. Das Protokoll zwischen Code und Mikrocontroller ist nun etwas weniger komplex und intuitiver.

Im Boardfile können nun Zusatzfunktionen für Pins abgelegt werden.

pins:
    [...]
    - physical_id: 12
      extra:
        - led1
        - mosi
        - miso

Die erste Funktionalität, die damit arbeitet, erlaubt das Ansprechen der definierten LEDs über ihre Namen. Z.B.:

pyduin -B buddy led1 on

Der Gedanke, einen echten PC als zentralen Rechner mit vielen Octoprint-Instanzen zu nutzen, ist naheliegend und preiswert. Dabei will man jedoch nicht zwangsweise auf dem Host selbst installieren, sondern in eine virtuelle Maschine. Das hat zahlreiche Vorteile, wie z.B. Snapshots und vereinfachte Hostmigration, bringt aber auch Komplexität mit sich.

Die virtuelle Maschine kann die Drucker nun nicht mehr direkt sehen, weil /dev auf dem Host nicht gleich /dev in der virtuellen Maschine ist. Daher müssen die Drucker dynamisch und möglichst automatisch an die die virtuelle Maschine durch gereicht werden. Unter Linux kein Problem, dank udev.

Udev-Regel im VM Host erstellen

Die Regeln für udev sind leicht erstellt. Vorher braucht man aber den Identifikator des Gerätes. Ich nehme meist

watch -n .1 lsusb

und verbinde dann das Gerät. So sehe ich schnell, welches Gerät dazu kommt und welchen Identifikator es hat. Mein Drucker sieht dann so aus. Die ID ist die entscheidende Information.

Bus 003 Device 007: ID 1a86:7523 QinHeng Electronics CH340 serial converter

Nun die Konfigurationsdatei in /etc/udev/rules.d/20_3dprinter.rules erstellen. Meine sieht so aus.

ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ENV{DEVTYPE}=="usb_device", RUN+="/opt/scripts/attach_wanhaoi3plus.sh"

Damit wird beim Anstecken des Gerätes ein Skript ausgeführt. Udev kann leider keine Argumente an die ausgeführten Skripte weitergeben. Daher braucht …

Neue Version von pyduin verfügbar.

Die neue default_buddy-Option erlaubt das definieren eines Buddies aus der Buddylist. Damit werden Kommandozeileneingaben noch kürzer, wenn nur ein Gerät im Einsatz ist. Beispiel:

pyduin p 13 h

Es ist nun auch möglich Aliasnamen für Pins zu vergeben. Da viele Nutzer an Pinnamen wie A0 oder auch D1 gewöhnt sind, halte ich das für ein sinnvolles Feature. Last, but not least: Arbeiten an Unittests, Pinfiles refaktorieren, Pylint Action auf Github aktivieren, Badges ins Readme, Readme aktualisieren, Code aufräumen.

Die Implementation von analogRead ist auch durch. Damit machen auch die Pinaliasnamen dann voll Sinn, wenn man in Arduino-Terminologie denkt.

pyduin p A0 read

Um in Pelican das Syntax-Highlighting zu aktivieren, sind eigentlich nur wenige Schritte notwendig. Die Dokumentation von Pelican ist nicht sehr aussagekräftig und offensichtlich sind auch schon andere an dem Thema gescheitert.

So geht’s: Die pelicanconf.py muss folgenden Eintrag enthalten, damit das Markdown-Plugin codehilite aktiviert wird.

# pelicanconf.py
MARKDOWN = {
    'extension_configs': {
        'markdown.extensions.codehilite': {
            'css_class': 'codehilite',
        },
}

Es kann vorkommen, dass pygmentize installiert werden muss. Bei der Installation von Pelican mit pip, wird pygmentize als Abhängigkeit mit installiert. Andernfalls erfolgt die Installation mit pip.

pip install pygmentize

Mit folgendem Befehl kann man sich eine Liste der verfügbaren Stile anzeigen lassen. So lässt sich das Erscheinungsbild der Codeblöcke anpassen.

pygmentize -L style

Wenn man z.B. den zenburn-Stil aktivieren möchte, kann man mit nachfolgendem Befehl ein entsprechendes Stylesheet erzeugen. Wichtig ist, dass der der Wert von -a, (.codehilite) mit der in der pelicanconf.py angegebenen css_class übereinstimmt und von einem . angeführt wird.

pygmentize -S zenburn -f html -a .codehilite > themes/simple/static/css/styles.css

Das erzeuge Stylesheet anschließend in der base.html verlinken.

<link rel="stylesheet" href="{{ SITEURL }}/{{ THEME_STATIC_DIR }}/css/styles.css" />

Schon seit einigen Jahren fertige ich Bohrschablonen und andere Templates in Freecad. Für diesen Arbeitsfluss ist es essentiell, dass die Templates am Ende maßhaltig sind.

Ich hatte ein Problem mit dem Drucken von Zeichnungen (TechDraw) aus Freecad. Trotz ausgeschalteter Skalierung in Freecad und Treiber, stimmte die Skalierung nicht. Der Drucker wurde driverless bei der Installation gefunden und verwendete den generischen Gutenprint-Treiber.

Nach einigen Versuchen habe ich dann den Treiber vom Hersteller heruntergeladen und manuell installiert. Meine exportierten PDF-Dateien wurden anschließend maßhaltig ausgedruckt und auch der direkte Druck aus Freecad führt bei Verwendung des Herstellertreibers zu korrekt skalierten Drucken.

Nach mehrjähriger Pause habe ich pyduin nach Python3 portiert und einige wesentliche Verbesserungen vorgenommen.

Das Kommandozeileninterface ist nun aus meiner Sicht deutlich einfacher strukturiert und effizienter zu bedienen.

Zum flashen der Zielgeräte kommt nun platformio zum Einsatz. Eine enorme Komplexitätsreduktion. Gleichzeitig wird die Anzahl der potentiellen Zielgeräte massiv gesteigert.

Das Packagaing wird nun nicht mehr über setup.py, sondern über pyproject.toml abgewickelt, was die Entwicklung deutlich vereinfacht.

Im nächsten Release wird es wieder mehr um Features gehen. Es sind noch nicht alle Funktionalitäten für die Pins implementiert. PWM, OneWire und die DHT Sensoren sind die nächste Zielmarke.

Immerhin, könnte man sagen, hat sich Quellcodeversionierung durchgesetzt. So weit so gut. Schaut man auf das Konkrete, wird man Fefist. Es ist zum Haare ausreißen, was man so hört und sieht. Aktueller Fall dieser Tage: Bashskripte aus der Hölle. Starring: Visual Studio Code, Windows und Git.

Windows macht natürlich die Zeilenumbrüche per default kaputt. Wen die Zeilenumbrüche nicht korrekt sind, funktioniert git grep nicht mehr. Ein absolut essentielles Kommando. Klar kann man das nachträglich ändern. Dazu muss das Problem aber erst einmal Jemandem auffallen. Passiert halt nie, wenn man nicht mal statische Codeanalyse macht.

Und wenn Windows dann noch seine Byte-Order-Mark einfügt, startet jedes Skript direkt mit einer für den durchnittlichen Windowsadmin esoterischen command not found-Fehlermeldung. Die wird natürlich ignoriert, denn irgendwie scheint Linux kaputt zu sein. Ein Fehlschluss jagt den nächsten.

Natürlich ist nichts testbar und wenn nach Jahren der Pfuscherei mal eine statische Codeanalyse über den Code huscht und im Prinzip alles in die Tonne lintet, geht man lieber kollektiv den Nestbeschmutzer an, der shellcheck angeworfen hat. Management hat was zu verlieren. Das wird hier schon immer so gemacht.

Eigentlich wollte ich ja nur sagen: Macht statische Codeanalyse. Man lernt enorm viel dabei. Ja, ist manchmal nervig. Aber ist die Arbeit wert. Man wird nur ein guter Coder, wenn man sich aktiv permanent weiterentwickelt und sich dabei …