Archiv der Kategorie: Linux

Alles rund um die Pinguine – auf dem Desktop und dem Server

Horde GnuPG auf Ubuntu 18.04

Horde ist hier auf einem Ubuntu 18.04 Server installiert – mit Hilfe von PEAR.  Leider funktionierte eine ganze Zeit lang die PGP / GnuPG Schlüsselerstellung damit nicht mehr. Ich vermute inzwischen, weil der Commit hier

https://github.com/horde/Crypt/pull/2/commits/5f0c7e7b7a3dc7b6a8a3e9ba1e085be7a94d3477

nie Eingang in das Horde fand, das hier mittels PEAR aktuell gehalten wird.

Was nämlich funktioniert, ist, der Austausch von

/usr/share/php/Horde/Crypt/Pgp/Backend/Binary.php

mit der Binary.php von oben! Also

wget https://raw.githubusercontent.com/horde/Crypt/5f0c7e7b7a3dc7b6a8a3e9ba1e085be7a94d3477/lib/Horde/Crypt/Pgp/Backend/Binary.php
mv /usr/share/php/Horde/Crypt/Pgp/Backend/Binary.php /usr/share/php/Horde/Crypt/Pgp/Backend/Binary.php.bak
mv Binary.php /usr/share/php/Horde/Crypt/Pgp/Backend/Binary.php

und die Schlüsselerstellung funktioniert wieder.

Danke auch an kruedewagen und die weiterführenden Links dort, der mich auf die richtigen Gleise setzte, auch wenn dessen Lösung hier nicht funktionierte.

Q4 auf Arch

Musste ich mal wieder anschauen, weil die Jungs die DVD im Keller fanden, auch wenn es das einst von mir am wenigsten gespielte Quake war.

Die Voraussetzungen dafür, dass das im Netz noch immer als Download zu findende quake4-linux-1.4.2.x86.run beim Start nicht Fehler dieser

error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory

oder dieser Art

MESA-LOADER: failed to open i965: libgcc_s.so.1: version `GCC_7.0.0' not found (required by /usr/lib32/dri/i965_dri.so) (search paths /usr/lib32/dri)

warf, war erstens die Installation von

sudo pacman -S lib32-sdl lib32-mesa

und zweitens ein

mv libgcc_s.so.1 libgcc_s.so.1.bak
mv libstdc++.so.6 libstdc++.so.6.bak

in /usr/local/games/quake4.

Alle weiteren Hinweise und Tipps sind hier zu finden:

https://www.gamingonlinux.com/articles/playing-quake-4-on-linux-in-2018.11017

Ubuntu Server Upgrade 18.04 auf 20.04

Das Update von 18.04 auf 20.04 auf einem Server mit RSpamd, Postfix, Dovecot, Apache, MySQL zeigte gestern, dass nur relativ wenig bricht:

Das Paket mail-stack-delivery ist ja seit 18.04 schon nicht mehr das, was es einst war. Leider. Jetzt scheint dessen Vorhandensein dafür zu sorgen, dass beim Upgrade die Pakete

dovecot-imapd dovecot-pop3d dovecot-sieve

entfernt werden. Dovecot wirft dann mit Fehlern, die nicht ganz in die richtige Richtung weisen – nämlich u.a.

Error: sieve: Failed to initialize script execution: Invalid postmaster_address: invalid
address `postmaster' specified for the postmaster_address setting

auch wenn mensch hier ebenfalls tätig werden und postmaster_address setzen darf.

Weiter fällt der Start des MySQL Servers auf die Nase, wenn vorher Anpassungen für Moodle und / oder Nextcloud vorgenommen wurden. Er moniert:

[ERROR] [MY-000067] [Server] unknown variable 'innodb_file_format=Barracuda'.

Behoben wird dies (zumindest bei diesem Server) durch Auskommentieren der Zeilen

innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_large_prefix

in /etc/mysql/mysql.conf.d/moodle.cnf bzw. nextcloud.cnf ebenda. Weder Moodle noch Nextcloud scheinen sich hieran bisher zu stören.

Check_MK kommt mit dem frischen Kernel ebenfalls nicht richtig klar und zeigt auf einer Maschine mit 32GB RAM bei 2GB RAM Auslastung nun:

Largest Free VMalloc Chunk: 0 B (warn/crit below 50 MB/30 MB) CRIT

Der Workaround ganz unten im Thread hier hilft weiter.

Der Rest (z.B. RSpamd, Tripwire, Postfix, ufw, Redis, PHP-Upgrade auf 7.4 und Anpassungen des Apachen hierzu, Certbot usw usw) lief hier ohne weitere Probleme durch.

Debian Installbox

Um viele Laptops möglichst zügig mit einem Betriebssystem versorgen zu können, habe ich eine „Debian Installbox“ erzeugt. Diese basiert auf

https://salsa.debian.org/installer-team/netboot-assistant

und der Dank geht somit an andi für das Konzept, die Skripte und seine Unterstützung.

Meine eigenen Konfigurationsdateien habe ich ins Git gelegt:

https://codeberg.org/dowel/installbox

Eine fertige VM für Virtualbox kann mensch hier herunterladen:

https://cloud.kvfg.de/index.php/s/aXtJQxKccPCm8kX

Ein paar Erläuterungen dazu:

Host

Den Hostrechner mit zwei Netzwerkkarten versorgen. Die „nach Außen“ / Richtung Internet zeigende Netzwerkkarte sollte die langsamere der beiden sein. Nach „innen“ und damit in Richtung der zu installierenden Maschinen das schnellste nehmen, was rumliegt.

Die VM unter Debian Buster braucht nicht viel – die voreingestellten 4GB und 2 CPUs sollten reichen. Vermutlich reicht auch die Hälfte – die VM hat ja fast nix zu tun, außer Steuerbefehle zu schicken und Dateien auszuteilen. Der Host sollte das doppelte der VM an Ressourcen aufweisen. Hier klappt das auf Rechnern der „Isny-Klasse“ (Core i3 mit 8 GB RAM und SSD) ganz flott – so als Orientierung.

Adapter 1 zeigt in Richtung Internet und ist im Auslieferungszustand vermutlich noch als Bridge konfiguriert, weil das in meinem lokalen Netz praktischer war. Das Interface darf ruhig NATen. Im Bild oben ist das nicht so, weil ich dann vom VM-Host via SSH einfacher auf die VM komme.

Adapter 2 zeigt in Richtung der zu installierenden Maschinen und muss deswegen eine Netzwerkbrücke direkt auf das Interface im Host sein. Hier in der VM die Einstellungen in /etc/network/interfaces nur befummeln, wenn man die Folgen abschätzen kann – also dazu bereit ist, die Konfiguration zu überarbeiten. Voreingestellt ist hier die IP 192.168.0.10. Da fährt dann auch der TFTP-Server hoch und lauscht der dnsmasq auf Anfragen.

Am Host selbst hatte ich für diese zweite Karte keine IP gesetzt, was unter Arch gut funktionierte. Unter Debian funktionierte das überhaupt nicht. Da musste ich auf dem Host dem Interface eine 192.168.0.1 statisch verpassen, erst dann konnte die VM dort bridgen.

Dann noch eine Anmerkung zum Grafik-Controller: VBox will da inzwischen VMSVGA haben. Das führt in der Debian-VM hier (unter Arch) jedoch dazu, dass diese alle paar Sekunden eine Denkpause in der GUI einlegt. Mit VBoxVGA flutscht es in der VM weitaus besser. Muss man ausprobieren – tun sollte beides.

VM

Usermanagement

Es sind zwei Benutzer eingerichtet – installbox als Arbeitskonto (Passwort: muster) und kvfg (Passwort: kvfg) für die Erzeugung eines hübschen Homeverzeichnisses für die SuS, das dann auf die Laptops mit ausgerollt wird und somit schon alle sinnigen Einstellungen mitbringt. Da müsst ihr Euch halt einen eigenen backen – das Schulkürzel bietet sich als Benutzername wie auch als Passwort an.

Also: Als kvfg anmelden und alle Einstellungen so vornehmen, wie sie später die SuS an den Laptops vorfinden sollen. Z.B. kann hier das hässliche XFCE-Debian-Theme überarbeitet werden. Ich habe dann noch in Firefox ublock und decentraleyes installiert, die Suchmaschinenliste überarbeitet, Bookmarks eingefügt, die Startseite angepasst und auch Libreoffice für den Einsatz in den Fächern Deutsch, Englisch, Französisch und Spanisch inklusive Beispieldateien vorbereitet. Weiter habe ich Nextcloud „halb installiert“, damit den SuS das auch auffällt, wie sie von zu Hause aus geschickt arbeiten könnten. Dazu kommt – seit der letzten Version – auch ein Skript, das die Verbindung mit dem Schulnetzwerk herstellt (WLAN, Servermounts), sofern die SuS mal in der Schule arbeiten. So Sachen eben, die den Alltag für die SuS erleichtern.

Sobald das alles nach Wunsch aussieht ausloggen und als installbox wieder anmelden. Von diesem Konto aus als root das Homeverzeichnis von kvfg komplett in ein TAR packen. Das Skript build-skel.sh im Rootverzeichnis hilft dabei.

Die Laptops holen sich im Zuge der Installation das TAR-Archiv und entpacken das auf dem Laptop nach /home/kvfg, womit die Einstellungen auf den Geräten wie gewünscht gesetzt sind.

Wer sich einen eigenen Benutzer für die Schule gebacken hat, sollte also die Pfade und Namen in der preseed.cfg daraufhin überprüfen.

Hints

Die VM ist mit einem Apt-Cacher NG versorgt, der die gesamte Installation Stand 13.08.2020 10:00 Uhr auch offline abwickeln kann. Ihr könnt in der VM unter http://localhost:3142 nachsehen, wie viel an Download aus dem Netz ihr schon gespart habt – und außerdem geht es so einfach total flott.

In Zeile 81 hinter

d-i pkgsel/include string

der preseed.cfg sind die Pakete aufgeführt, die nachinstalliert werden. Da lassen sich leicht weitere ergänzen. Ich hab hier z.B. Gimp, VLC, Okular und Gwenview sowie Kate mit eingetragen, weil ich diese selbst gerne nutze – und weil sie auf den Clients in der Schule auch da sind. Dazu kamen dann noch Cheese für einen Test der Webcam und Nextcloud-Desktop für die Verbindung mit der Schulcloud usw usw usw …

Releases

2020-08-13

Initial release

2020-08-14

Paketliste ergänzt (Druckmöglichkeit), Splash-Screen, Softwarecenter

2020-08-17

Paketliste ergänzt (simple-scan), ublock im Firefox-ESR für die BBB Domains auf lehrerfortbildung-bw.de und die schulischen Domains deaktiviert

2020-08-18

KISS: Die Druckerpakete machen vermutlich keinen Sinn. Wenn die SuS keine Geräte haben und deswegen einen Laptop von der Schule erhalten, dann haben diese aller Wahrscheinlichkeit nach auch keinen Drucker rumstehen – und wenn doch, dann lernen sie was bei der Nachinstallation. Synaptics-Touchpad-Treiber kamen noch dazu – und die Repos wurden freundlicher eingestellt (contrib, non-free hinzugefügt).

2020-08-20

Das XFCE-Batteriestatus Icon hat noch gefehlt. Weiter habe ich, um den Überblick zu behalten, etckeeper und git auf den Laptops installiert [1]. So kann bei Tests vor Ort besser abgeschätzt werden, welche Anpassungen noch fehlen (z.B. Netzwerkverbindungen).

Die Verbindung mit dem Schulnetz wird nun via WPA2-Enterprise hergestellt. Deswegen wird in der Downloadversion der VM eine weitere Datei mit ausgerollt:

/var/lib/tftpboot/d-i/buster/schueler.nmconnection

In dieser sind die Credentials für die Verbindung mit dem Schulnetz „schueler“ mit drin (in der Downloadversion der VM nicht wirklich – aber den Teil muss mensch eh selbst an die Gegebenheiten in der Schule vor Ort anpassen).

Damit diese Configdatei an Ort und Stelle auf den Laptops ankommt, wurde dann die preseed.cfg überarbeitet, was wiederum im Git auf Codeberg (Link siehe oben) zu finden ist.

Damit evtl. Änderungen schnell eingepflegt werden können, die schueler.nmconnection in der VM nach /root legen. Dort liegt auch das Skriptchen build-skel.sh, das dann das Homeverzeichnis zusammen mit dieser Datei packt.

2020-08-24

Die VM hat nun Skripte an Bord, die auf den Laptops die Einrichtung individueller Verbindungen mit dem Schulnetzwerk (WPA2-Enterprise) unterstützen – inklusive mount der Servershares. Der Würgaround vom 20.08 mit einem Xtra-User ist somit nicht mehr nötig.

2020-08-25

Gut, wenn man noch einmal drüber schläft. Ich hatte die cifs-utils in der preseed.cfg vergessen.

Grubgefummel

Weil wireguard mit dem heute gekommenen Kernel für Ubuntu 18.04 nicht durch den Compiler ging

Unpacking wireguard-dkms (1.0.20200520-0ppa1~18.04) over (1.0.20200520-0ppa1~18.04) ...
Setting up wireguard-dkms (1.0.20200520-0ppa1~18.04) ...
Loading new wireguard-1.0.20200520 DKMS files...
Building for 4.15.0-106-generic
Building initial module for 4.15.0-106-generic
Error! Bad return status for module build on kernel: 4.15.0-106-generic (x86_64)
Consult /var/lib/dkms/wireguard/1.0.20200520/build/make.log for more information.
Setting up wireguard (1.0.20200513-1~18.04) ...

und dann in /var/lib/dkms/wireguard/1.0.20200520/build/make.log Derartiges hinterließ

DKMS make.log for wireguard-1.0.20200520 for kernel 4.15.0-106-generic (x86_64)
Wed Jun 10 07:49:21 CEST 2020
make: Entering directory '/usr/src/linux-headers-4.15.0-106-generic'
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/main.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/device.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/peer.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/timers.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/queueing.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/send.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/receive.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/socket.o
In file included from <command-line>:0:0:
/var/lib/dkms/wireguard/1.0.20200520/build/socket.c: In function ‘send6’:
/var/lib/dkms/wireguard/1.0.20200520/build/compat/compat.h:102:42: error: ‘const struct ipv6_stub’ has no member named ‘ipv6_dst_lookup’; did you mean ‘ipv6_dst_lookup_flow’?
 #define ipv6_dst_lookup_flow(a, b, c, d) ipv6_dst_lookup(a, b, &dst, c) + (void *)0 ?: dst
                                          ^
/var/lib/dkms/wireguard/1.0.20200520/build/socket.c:139:20: note: in expansion of macro ‘ipv6_dst_lookup_flow’
   dst = ipv6_stub->ipv6_dst_lookup_flow(sock_net(sock), sock, &fl,
                    ^~~~~~~~~~~~~~~~~~~~
scripts/Makefile.build:330: recipe for target '/var/lib/dkms/wireguard/1.0.20200520/build/socket.o' failed
make[1]: *** [/var/lib/dkms/wireguard/1.0.20200520/build/socket.o] Error 1
Makefile:1577: recipe for target '_module_/var/lib/dkms/wireguard/1.0.20200520/build' failed
make: *** [_module_/var/lib/dkms/wireguard/1.0.20200520/build] Error 2
make: Leaving directory '/usr/src/linux-headers-4.15.0-106-generic'

wollte ich prüfen, ob ich um den Bug herumkomme, wenn ich den Server mit dem alten Kernel starte.

Ich dachte, das geht so:

Ein

grub-mkconfig | grep -E 'submenu |menuentry '

liefert den Menüeintrag für den älteren Kernel

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
        menuentry 'Ubuntu, with Linux 4.15.0-106-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-106-generic-advanced-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
        menuentry 'Ubuntu, with Linux 4.15.0-106-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-106-generic-recovery-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
Found linux image: /boot/vmlinuz-4.15.0-101-generic
Found initrd image: /boot/initrd.img-4.15.0-101-generic
        menuentry 'Ubuntu, with Linux 4.15.0-101-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-101-generic-advanced-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
        menuentry 'Ubuntu, with Linux 4.15.0-101-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-101-generic-recovery-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {

der dann beim Boot via /etc/default/grub (vorher wegsichern!) ausgewählt wird

GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 4.15.0-101-generic"

nachdem ein

update-grub

fehlerfrei durchläuft.

Doof gedacht: wireguard-dkms baut natürlich trotzdem für den neueren Kernel. Weil? Weil er da ist. So simpel.

Das Ergebnis ist also das gleiche wie oben: wireguard-dkms fällt beim Modulbau auf die Nase – obwohl der Server mit dem älteren Kernel läuft.

Eigentlich total klar – aber die Finger auf den Tasten sind manchmal schneller als das Hirn dazu.

Einfacher – und dazu noch fehlerfreier bei den Nacharbeiten mit DKMS zu handhaben – ist ein simpler apt-get purge auf den neueren Kernel.

apt-get purge linux-image-4.15.0-106-generic
apt-get clean ; apt-get autoremove

Dann evtl. noch die alten /etc/default/grub Inhalte wiederherstellen (falls mensch so blöd wie ich war), ein update-grub und nach einem Neustart ist wireguard wieder brav am Start.

Update

Was hier bezüglich Wireguard wunderbar funktioniert hat:

apt-get install --install-recommends linux-generic-hwe-18.04
apt-get install --reinstall wireguard-dkms wireguard-tools linux-headers-$(uname -r)

Ich hoffe, das hält nun eine Weile.

Videochat mit Conversations

Der neue Conversations Client kann nun auch Video- und Audioanrufe, wenn der XMPP-Server mitspielt.

Quick and Dirty Kurzanleitung für Prosody:

In /opt/prosody-moduls ein hg pull -u absetzen. Updates schaden ja nicht.

In der prosody.cfg.lua im Abschnitt modules_enabled

"turncredentials"; -- enable coturn module

eintragen und damit das Modul aktivieren.

Im Abschnitt darunter (noch über den VirtualHost Einträgen) die Angaben für den Coturn hinterlegen:

turncredentials_host = "mein.coturn.tld"
turncredentials_secret = "geheimessecret"
turncredentials_port = 443

Dann prosody neu starten und selbstverständlich auch den neuesten Client von Conversations installieren.

Literatur: [ 1 ] [ 2 ] [ 3 ]

Nextcloud … mal wieder

Ich warte ja immer gerne, bis die frischen NC Versionen einen gewissen Reifegrad erreichen, bevor ich diese einspiele. Beim Sprung von 17.x auf 18.x dachte ich, 18.0.3 müsste passen, erlebe hier aber eine kleine Hürde nach der anderen.

Ist Talk aktiviert, dann fliegt das Update via occ erst einmal komplett auf die Schnauze und meldet in schönem Rot:

Checking for update of app spreed in appstore
Checked for update of app "spreed" in appstore 
Repair error: Repair step 'OCA\Talk\Migration\FixNamespaceInDatabaseTables' is unknown
PHP Fatal error:  Cannot declare class OCA\Talk\Migration\Version8000Date20200331144101, because the name is already in use in /path/to/somedomain-tld/nextcloud/apps/spreed/lib/Migration/Version8000Date20200331144101.php on line 54

Das lässt sich beheben.

sudo -u www-data php occ app:disable "spreed"
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
No such app enabled: spreed

Die letzte Meldung – No such app enabled: spreed – ist irreführend. Ja – eine App „Spreed“ ist nicht eingeschaltet, aber Talk. Und app:disable „Talk“ führt zu nix. Außerdem wirft ja NC beim Update selbst mit Checked for update of app „spreed“ in appstore den Fehler. Anyway. Es hilft. Der Dank geht an freedox.

Alternative: Talk vor dem Upgrade abschalten und dann wieder anschalten, wenn das Update durchgelaufen ist. Erzeugt weniger Puls.

Danach dann

sudo -u www-data php occ upgrade

erneut ausführen, Wartungsmodus wieder abschalten und einloggen, um auf die nächsten Fehler unter nextcloud/index.php/settings/admin/overview blicken zu können. Diese lassen sich weitgehend beheben mit

sudo -u www-data php occ db:add-missing-indices

was allerdings immer noch ranzt ist die dumme Meldung zu

- core
	- INVALID_HASH
		- core/js/mimetypelist.js
	- EXTRA_FILE
		- core/img/filetypes/mindmap.svg

die bezüglich mimetypelist.js schlicht nicht stimmt und sich – je nach Installation – aus dem exakt gleichen Paket auch nicht reproduzieren lässt. Einmal wirft NC diesen Fehler, das andere mal nicht. Toll. Ich ignoriere das nun ebenso wie den Fehler zu mindmap.svg und hoffe auf die nächste Runde.

LiSCrypt

Irgendein Mensch auf dem Amt der in Weisheit klug Erschlauten kam auf die Idee, dass man doch weiterhin VeraCrypt ignorieren könnte – und beschloss, dass man nun in den Kommissionen LiSCrypt zu nutzen habe. Naja. Wenigstens ist es quelloffen zu haben, auch wenn die Idee, lauter Einzeldateien zu verschlüsseln, statt einen Container zu nutzen, davon zeugt, dass dieser Mensch mit der konkreten Arbeit in Kommissionen wenig zu tun hat.

Und was ein Audit ist, weiß er wohl auch nicht.

Aber es hilft ja alles nix. Also ran an das Ding.

Unter Kubuntu 18.04 kommt LiSCrypt wie folgt an Bord:

wget https://github.com/MaWe2019/LiSCrypt_public/archive/v0.9.7.zip
unzip v0.9.7.zip

Das oben geht natürlich auch händisch. Downloads hat es hier: https://github.com/MaWe2019/LiSCrypt_public/releases

Dann pip3 updaten

pip3 install --upgrade pip

Noch die Abhängigkeiten installieren

pip3 install psutil
pip3 install base91

Und dann geht es im entpackten Quelltextverzeichnis an die Arbeit mit

python3 -m Steuerung.LiSCrypt

Sieht dann so aus:

 

Wer kein KDE hat, muss evtl. noch die Qt Abhängigkeiten installieren. Aber wer die Ausgaben beim Start des Programms liest, findet die passenden Pakete, die man sich per pip an Bord holen kann. Vermutlich ist das dann sowas wie

pip3 install PyQt5

Hat man die defaults in der GUI gelassen, dann ist mit der Verschlüsselung des Originals dasselbe auch gleich weggelöscht. Hübsch, wenn man sich bei der Eingabe des Kennwortes zwei mal vertippt haben sollte. Dann sind die Dateien richtig sicher 😉

Ich tippe mal, das führt im Kommissionsalltag dann dazu, dass alle das Häkchen dort wegmachen und die unverschlüsselten Dateien im Dateisystem liegen lassen.

Prosody, systemd und prosodyctl

Wer gerade auch seinen Augen nicht trauen will, weil

prosodyctl status

ein

Prosody is not running

liefert, während

systemctl status prosody

ein

active (running)

meldet … das liegt hieran: https://hg.prosody.im/debian/rev/8cd0ff3ebf74

Bis die Updates an Bord kommen, kann man sich damit helfen, in

/lib/systemd/system/prosody.service

die PIDFile Zeile auszukommentieren. Die fliegt dann demnächst eh raus. Und systemd kümmert sich um den Rest.

TL-MR3020 v1

Ich hatte hier im Schrank noch einen älteren TL-MR3020 v1 herumliegen, auf dem sich ein olles Image von Freifunk Stuttgart befand. Von dort (FF) erhielt er keine Updates mehr, so dass er irgendwann ausgemustert wurde. Heute hab ich ihn reaktiviert mit einem LEDE für den Einsatz auf der Straße.

Zuerst musste das alte Freifunk Image runter.

Einen Rechner mit einer IP aus dem Netz 192.168.x.100 /16 ausstatten (ich nehme gerne so eine Netzmaske, weil ich so leichter zwischen der IP der TPL-Stockfirmware und der IP eines Freifunk-APs wechseln kann)

Den MR3020 in den Wiederherstellungsmodus versetzen. Dazu beim Einstöpseln der Stromversorgung den WPS-Knopf gedrückt halten, bis der Router wild blinkt (ca. 5 Sekunden).

Dann via Telnet drauf verbinden

telnet 192.168.1.1

und sich Zugang via SSH verschaffen:

mount_root
passwd
dropbear
cd /tmp/

Vom Rechner aus das passende Image per SCP zum MR3020 übertragen

scp lede-17.01.5-ar71xx-generic-tl-mr3020-v1-squashfs-factory.bin root@192.168.1.1

und dieses dort Flashen:

sysupgrade -n lede-17.01.5-ar71xx-generic-tl-mr3020-v1-squashfs-factory.bin

Sollte die FF-Firmware neuer sein, als das zu flashende Image, hilft ein -F bei sysupgrade.

Der MR3020 braucht nun eine Zeit mit sich allein, in der die Stromversorgung nicht verloren gehen darf. Er sollte dann von sich aus neu booten und wieder unter 192.168.1.1 zu erreichen sein – jetzt allerdings auch im Browser per LuCI. Und in LuCI kann dann die restliche Konfiguration bequem vorgenommen werden.

Ich hab ihn mir so eingerichtet, dass er sich am verkabelten Interface per DHCP eine IP aus dem dann je lokalen Netz holt. Besonders brauchbar für den Außeneinsatz wird er, weil die MAC für dieses Interface händisch leicht gesetzt werden kann. Man besorgt sich vor Ort die MAC eines Rechners, stöpselt diesen aus und den MR3020 mit dessen MAC an – voila ist Netz für eigene Geräte da. Das geht in LuCI zügig:

  1. Network
  2. Interfaces
  3. Edit
  4. Advanced Settings
  5. Override MAC address
  6. Save & Apply

Literatur: MR3020, FF Reset