nikken

# Links #1

covid19, links, science

Weil es sonst nicht so viel zu tun gibt zur Zeit, fange ich auch damit an, gute Links der letzten Tage zusammenzustellen. Ich möchte keine Versprechen darüber machen, wie regelmäßig das jetzt kommen wird und ich denke, fünf Links mit jeweils ordentlichem Inhalt sind erstmal ein guter Anfang, aber wie man an der URL erkennen kann, bin ich auf jeden Fall erstmal auf alle Eventualitäten vorbereit. Niemand sollte mehr als 999 Linkdumps benötigen.

# Cyberrevolutionäres Chile

chile, radio, sozialismus

Vor vier Jahren habe ich eine Menge Bücher gekauft, von denen die meisten immernoch ungelesen in meinem Regal stehen oder auch wieder verkauft wurden. Eines davon war Eden Medinas Cybernetic Revolutionaries, das den Versuch der Allende-Regierung in Chile Anfang der 1970er Jahre beschreibt, mithilfe von Kybernetik und Computern eine sozialistische Volkswirtschaft zu verwirklichen.

Letzten Herbst habe ich mir das Buch endlich mal vorgenommen. Ein paar Tage später wurden in Santiago de Chile die Fahrpreise der Metro de Santiago um 30 Peso erhöht und die wohl größten Massenproteste der Landesgeschichte brachen aus. Über eine Millionen Menschen protestierten gegen die soziale Ungerechtigkeit, die die Chilenen als das Versuchslabor des Neoliberalismus seit der Pinochet-Diktatur erleiden müssen.

Gruselig, wie sich solche Gleichzeitigkeiten manchmal zufällig ergeben.

Vor ein paar Tagen haben Jakob Schmidt und Jannis Funk für das Deutschlandfunk-Format Das Feature eine Doppelfolge über genau jenes Projekt Cybersyn veröffentlicht, über das Eden Medina 2011 schrieb.

Medinas Buch ist eine umfassende wissenschaftliche Abhandlung über die Entstehungsgeschichte und technischen Details des Projekts, die das Radioprogramm so natürlich nicht leisten kann. Dafür ist das Feature gespickt mit Zeitzeugeninterviews und Tondokumenten aus der Zeit der Allende-Regierung.

Es ist unüberhörbar, wie aufrichtig begeistert und entschlossen die Beteiligten an Cybersyn einerseits, vorallem aber an Allendes Projekt des demokratischen, gewaltfreien Sozialismus gearbeitet haben.

Umso grausamer, wie die Konterrevolution, gesponsert unter anderem vom CIA, dessen Untergang bereitet hat. Salvador Allendes letzte Rede aus dem Präsidialpalast zerreißt mir jedes Mal aufs Neue das Herz.

🎵: Floh de Cologne - Mumien und Vietnam (1974)

# Brother DCP-7055 Scanner unter Void Linux

drucker, hardware, linux

Update: Seit kurzem benutze ich statt Xubuntu Void Linux und das hat weder dpkg noch rpm (von Haus aus, jedenfalls), die beiden Paketformate für die Brother die Linuxtreiber mitliefert. Im Folgenden habe ich deshalb den Prozess für Void Linux annotiert und tote Links durch die Version vom Internet Archive ersetzt.

Vor etlichen Jahren habe ich mir für zuhause einen Brother DCP-7055 Drucker/Scanner gekauft. So dringend brauchte ich ihn meistens garnicht, nach 7-8 Jahren bin ich erst bei der zweiten Kartusche. Zwischendurch musste ich dem Drucker erklären, dass seine erste Kartusche nicht leer war, aber ansonsten tut er, was er tun soll: drucken und scannen.

Ersteres ist mit den Linux-Treibern überhaupt kein Problem. Letzteres an und für sich auch nicht, aber das Installieren stellt sich seit einiger Weile als nicht sehr trivial heraus.

Zum Glück bin ich nicht der Einzige, dem es so geht. Daher nun hier (vorallem für mich, sollte ich den Drucker demnächst nochmal installieren müssen) ein “works for me”-Setup für die Nachwelt:

1. Linux-Treiber installieren

Nach dem Download der Treiber (Stand heute: 2.2.1-1) das Archiv entpacken und mit sudo bash linux-brprinter-installer-2.2.1-1 installieren. Drücke y bzw. Y bis alles installiert ist und der Drucker die Testseite ausspuckt.

Void: Hier half es tatsächlich, rpm zu installieren. Das Shell-Skript benutzt dann automatisch die richtigen Pakete um den Drucker zu installieren.

Stelle fest, dass Drucken klappt, der Scanner aber nicht erkannt wird.

2. Den Scanner konfigurieren

Ziehe die offizielle Dokumentation (Wayback Machine) zu Rate (den Ubuntu-Versionen nach zu urteilen muss die mindestens 6 Jahre nicht aktualisiert worden sein…) und lade die Datei brother-udev-rule-type1-1.0.0-1.all.deb herunter. Installiere sie mit sudo dpkg -i brother-udev-rule-type1-1.0.0-1.all.deb.

Void: Dieser Schritt funktioniert natürlich nicht. Void hat offizielle brscan4-Pakete für die Druckertreiber die ich auch installiert habe, das reichte aber nicht. Ich habe dann das udev-rule von Hand extrahiert und den Inhalt nach /opt/brother/scanner/udev-rules/type1/ kopiert.

Öffne die Datei /lib/udev/rules.d/60-libsane-rules (mit Superuser-Privilegien) im $EDITOR und füge folgende Zeilen hinzu (NB: in den oben verlinkten Foreneinträgen heißt die Datei 40-libsane.rules, in meiner Xubuntu 19.10 Installation scheint die Datei 60-libsane.rules aber genau den gleichen Zweck zu erfüllen (Void: 49-sane.rules):

# Brother scanners
ATTRS{idVendor}=="04f9", ENV{libsane_matched}="yes"

Achte darauf, dass dies vor der Zeile LABEL="libsane_rules_end" eingefügt wird.

Starte den Rechner neu und teste den Scanner.

Irgendwie bleiben Druckergeräte weiterhin ein Mysterium für mich, ich bin allerdings sehr froh, dass nach all den Jahren immernoch neue Treiber (immerhin: das letzte Update scheint von September 2018 zu sein) herauskommen und diese Merkwürdigkeiten sich dennoch zuverlässig beheben lassen (wenn man denn weiß, wo man suchen muss) (und fragt mich nicht, was diese Skripte da genau installieren).

Void: Hier noch einmal alle XBPS-Pakete aufgelistet, die ich hierfür installiert habe, wer weiß, welche davon wirklich nötig waren.

# Full-Disk-Encryption mit OpenBSD

hardware, openbsd

Ich habe OpenBSD schon öfter auf Laptops installiert und genutzt, auch schon mit Festplattenverschlüsselung. Als ich aber neulich mein “neues” ThinkPad T430 einrichten wollte, schien das alles nicht mehr so leicht von der Hand zu gehen wie bei den vorherigen Malen.

Nach etwas Recherche bin ich auf einen Verlauf in der Mailingliste gestoßen (der dann auch seinen Weg in die offizielle Dokumentation zur Festplattenverschlüsselung gefunden hat) der mir weiterhalf.

Der generelle Prozess läuft etwa so:

Nach dem Boot vom Installationsmedium (also etwa dem USB-Stick) geht man nicht direkt in den Installer sondern erst in die Shell, um die Festplatten vorzubereiten. Wenn man davon ausgeht, dass im Laptop bloß eine Festplatte (sd0) verbaut ist, ist außerdem noch das Installationsmedium (sd1) vorhanden. Bei OpenBSD ist es so, dass man sd0 im RAID-Modus aufsetzt, mit zufälligen Daten überschreibt und eine weitere Festplatte sd2 (das Mirror-Device zum ersten) erstellt. Dabei ist dann das erste Device vom Bootloader lesbar und auf dem neu erstellten Device befinden sich die eigentlichen Daten.

Nun war es bei mir so, dass es bei jedem erneuten Versuch unterschiedlich weit funktionierte, bis ich eine Meldung a la “device not found” erhielt. Wie, das Device wurde nicht gefunden? Die Festplatte ist doch vorhanden? Und ich habe die Anleitungen befolgt?

In der Mailinglisten-Diskussion wurde dann aufgeklärt, dass der Installer aus verschiedenen Gründen nicht alle möglichen Device-Nodes (sd0, sd1, sd2, usw.) erstellt, sondern nur die tatsächlich vorhandenen, also in diesem Fall sd0 und sd1. Die Lösung für mein Problem war es also, vor dem Einrichten der Festplatten erst die neuen Device-Nodes zu erstellen:

# cd /dev && sh MAKEDEV sd0 sd2

Ich weiß nicht, was diesmal anders war als bei den vorherigen Malen oder was sich in der Zwischenzeit (nun bestimmt schon ein paar Jahre) am Installationsprozess geändert hat, aber so konnte ich dann wie gewohnt fortfahren.

Quellen

Für die weitere Installation und spätere Einrichtung habe ich mich an den folgenden hilfreichen Posts orientiert:

# FreeBSD 12 & Nginx & Kirby CMS

freebsd, nginx, server, web

Damit ich nicht jedes Mal von Neuem suchen und zusammenpuzzlen muss (Quellen s.u.), wie man sein PHP CMS mit TLS usw. usf. aufsetzt, habe ich hier mal alle Schritte (Disclaimer: funktioniert so für mich, für die angegebenen Versionen) aufgelistet.

Nachdem ich meinen Server eingerichtet habe (in diesem Fall einen VPS mit FreeBSD 12) gehe ich erstmal sicher, dass mein System auf dem aktuellen Stand ist und installiere danach alle nötigen Pakete.

# freebsd-update fetch install
# pkg update && pkg upgrade -y
# pkg install -y sudo bash vim-console unzip wget \
    nginx py37-certbot py37-certbot-nginx php73 \
    php73-extensions php73-mbstring php73-curl \
    php73-ctype php73-gd php73-json php73-filter

Um zu vermeiden, dass ich auf dem Server alles als root machen muss, erstelle ich meinen eigenen Nutzer, füge ihn der wheel-Gruppe hinzu und editiere die sudo-config dahingehend, dass Nutzer der wheel-Gruppe alle Befehle ausführen dürfen. Alsdann wechsle ich zu meinem neuen User und stelle die Zeitzone ein.

# adduser
    ...
    group: wheel
    ...
# visudo
    # uncomment %wheel ALL=(ALL) ALL
# su - $USER
$ sudo tzsetup

Weil Kirby ein PHP Programm ist, muss ich jetzt die lokale PHP und PHP-FPM Installation konfigurieren. Insbesondere muss ich dem FPM-Service sagen, dass er auf einem UNIX-Socket zuhören soll und welchen Nutzer- und Zugriffsrechten er unterliegt.

$ sudo ln -s /usr/local/etc/php.ini-production /usr/local/etc/php.ini
$ sudo vim /usr/local/etc/php-fpm.d/www.conf
    ...
    listen = 127.0.0.1:9000 -> listen = /var/run/php73-fpm.sock
    ...

    # uncomment:
    listen.owner = www
    listen.group = www
    listen.mode = 0660

Ist das erledigt, aktiviere ich den php_fpm-Service mit sysrc, sodass er beim Server-Neustart automatisch angeschmissen wird.

$ sudo sysrc php_fpm_enable=yes
$ sudo service php-fpm start

Das gleiche mache ich dann schonmal mit Nginx, bevor es dann an die eigentlichen Einstellungen geht:

$ sudo sysrc nginx_enable=yes
$ sudo service nginx start

Hierfür erstelle ich ein permanentes Verzeichnis für die Website und gebe meinem Nutzer Zugriffsrechte darauf.

$ sudo mkdir -p /usr/local/www/$DOMAIN
$ sudo chown -R $USER:$GROUP /usr/local/www/$DOMAIN

Weil ich einige Anläufe und Hilfe aus dem Kirby-Forum dafür gebraucht habe, um die Config hinzubekommen, schreibe ich sie hier mal komplett hin, in der Hoffnung, dass es irgendjemand (im Zweifel ich) nützlich finden könnte.

Insbesondere leitet diese Config allen HTTP-Verkehr auf HTTPS um (weiter unten richte ich dafür noch Let’s Encrypt ein), setzt einige Rewrite-Regeln fest und konfiguriert das fastcgi.

$ sudo vim /usr/local/etc/nginx/$DOMAIN.conf

server {
    listen 80;
    listen [::]:80;
    return 301 https://$DOMAIN$request_uri;
}

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl;
    server_name $DOMAIN www.$DOMAIN;

    ssl on;

    ssl_certificate /usr/local/etc/letsencrypt/live/$DOMAIN/fullchain.pem;
    ssl_certificate_key /usr/local/etc/letsencrypt/live/$DOMAIN/privkey.pem;

    root /usr/local/www/$DOMAIN;

    index index.html index.php;

    # don't hint these as folders
    rewrite ^/(content|site|kirby)$ /error last;

    # block content
    rewrite ^/content/(.*).(txt|md|mdown)$ /error last;

    # block all files in the site and kirby folder from being accessed directly
    rewrite ^/(site|kirby)/(.*)$ /error last;

    # site links
    location / {
        try_files $uri $uri/ /index.php?$uri&$args;
    }

    # prevent clients from accessing to backup/config/source files
    location ~ (?:\.(?:bak|config|sql|fla|psd|ini|log|sh|inc|swp|dist)|~)$ {
        deny all;
    }

    location ~ \.php$ {
        try_files $uri = 404;
        fastcgi_pass unix:/var/run/php73-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Damit die Config auch gelesen wird, muss ich jetzt noch include $DOMAIN.conf; in den http-Block der Original-nginx.conf schreiben.

Let’s Encrypt hat es innerhalb von kurzer Zeit möglich gemacht, dass man einfach, kostenlos und automatisiert den Verkehr zu seinem Webserver mit TLS verschlüsseln kann. Es gehört mittlerweile zum guten Ton, das in jedem Fall zu tun, auch wenn http ausreichen würde. Da mein CMS aber eine Login-Funktion hat und also Benutzerdaten und Passwörter über die Leitungen geschickt werden, will ich meinen Traffic auf jeden Fall verschlüsseln.

certbot ist das offizielle Skript von Let’s Encrypt, das die Automatisierung der ganzen Zertifikats-Angelegenheiten möglich macht. Hier noch eine kleine FreeBSD-Besonderheit, auf die ich erstmal kommen musste: dort heißt nicht nur das Paket certbot-36 sondern auch die Binary. (Anm. 2019-09-14: Anscheinend ist dem nicht mehr so! Die folgenden Anweisungen habe ich unten entsprechend korrigiert. Anm. 2020-04-24: Der Port heißt jetzt py37-certbot und ist um einiges aktueller. Das Upgrade geschieht aber nicht von selbst, also py36-certbot* deinstallieren, py37-certbot{-nginx} installieren. Außerdem gibt es jetzt eine Konfiguration zum automatischen Aktualisieren in /etc/periodic.conf, nämlich weekly_certbot_enable="YES")

Die folgenden Zeilen erstellen dann Zertifikate für die beiden angegebenen Domains, testen im Trockenen ob das Erneuern auch funktioniert und erneuern sie.

$ sudo certbot certonly --webroot -w /usr/local/www/$DOMAIN -d $DOMAIN -d www.$DOMAIN
$ sudo certbot renew --dry-run
$ sudo certbot renew

Da die Let’s Encrypt-Zertifikate nur ein paar Monate am Stück gültig sind, richten wir noch einen crontab ein, der in zufälligen Abständen unsere Zertifikate erneuert.

$ crontab -e
0 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew

Wenn bis hierhin alles gut gegangen ist, wird sich Nginx beim Testen der Config nicht beschweren und durch’s Neustarten setzen wir alle Änderungen in Kraft.

$ sudo nginx -t
$ sudo service nginx reload

Jetzt sind wir endlich da angekommen, wo wir die ganze Zeit hinwollten: wir können Kirby installieren! Dafür laden wir uns die neueste Version auf den PC, bauen unsere Website und benutzen dann unser liebstes sftp/scp-Tool (nicht vergessen, die ssh/ftp-daemons einzurichten!) um die Dateien in das Verzeichnis zu laden, das wir oben erstellt haben.

Sollte jetzt alles funktionieren, geben wir dem Webserver (bzw. dem Nutzer, der den Webserver ausführt) noch die Verfügung über das Verzeichnis.

$ sudo chown -R www:www /usr/local/www/$DOMAIN

Quellen