Archiv des Autors: d.weller

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.

Hohen Genkingen

Hals- und Lendenwirbelsäule sind in gutem Zustand – also los in den Wald, Löcher suchen. An die HSK trau ich mich noch nicht wieder ran, so war ich bei Hohen Genkingen nach einem Eintrag im Binder gucken.


Größere Karte anzeigen
Gefunden habe ich zwei Löcher und eine kleine Doline.

Hohen Genkinger Löchle

Hohen Genkinger Löchle

Das kleinere  von den beiden befindet sich in der Felsformation auf der rechten Seite vom Waldweg aus betrachtet und ist nicht arg tief. Vermutlich schafft es das Löchle nicht den Kataster.

Hohen Genkinger Höhle

Hohen Genkinger Höhle

Das andere ist eine Höhle nach allen Maßstäben.

Hohen Genkinger Höhle Eingangshalle

Hohen Genkinger Höhle Eingangshalle

Hinter dem Eingang liegt eine kleine Halle mit rund 2m Höhe, die sich an einer Querkluft entlang bildete. Auf der linken Seite geht es dann gleich eine 50cm Stufe abwärts in einen Gang, der nach einer weiteren kleinen Halle, in der man noch hocken kann, nach links in den Berg zieht. Hier wäre schlufen angesagt, worauf ich mich heute nicht einlassen wollte.

Hohen Genkinger Höhle Gang

Hohen Genkinger Höhle Gang

Die Gesamtlänge ist bei LGRB mit 10m angegeben. Nachgemessen wurde heute nicht.

Genkinger Höhle Eingang

Genkinger Höhle Eingang

Unten am Hang, zwischen dem, was ich mal Hohen Genkinger Löchle genannt habe und der Hohen Genkinger Höhle gelegen, befindet sich noch eine Doline mit einem geschätzten Durchmesser von 4m und einer Tiefe von rund 1,5m.

Doline Hohen Genkingen

Doline Hohen Genkingen

Die kleine Doline ist auf dem Bild oben schwer zu erkennen, aber wer von der Genkinger Höhle einen fast geraden Weg zurück zum Waldweg läuft, fällt da fast rein.

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

Nextcloud cannot modify header information

Das Problem mit zwei meiner Nextcloud-Installationen entstand nach dem Update von 16.0.5 auf 16.0.6: Nach dem Login im Browser wurden keine Dateien oder Ordner mehr angezeigt. Die Apache-Logs waren leer. Der Sync-Client funktionierte.

In den Nextcloud-Logs war das hier zu finden:

Cannot modify header information - headers already sent by (output started at /var/www/domain.tld/nextcloud/3rdparty/sabre/http/lib/Sapi.php:80) at /var/www/domain.tld/nextcloud/3rdparty/sabre/http/lib/Sapi.php#63

Diese Datei schien mir aber in Ordnung zu sein: ASCII als Codierung, keine whitespaces vor den ersten oder nach den letzten Einträgen.

Nach langem Hin und Her kam ich zu einer wenig eleganten Lösung: Zuerst wurde das Nextcloud Installationspaket erneut heruntergeladen und erneut an Ort und Stelle geschoben – inklusive sudo -u www-data php occ upgrade

Jetzt meckerte Nextcloud, dass die Datei mimetypelist.js den falschen Hash hätte – und weiterhin wurden weder Dateien noch Ordner angezeigt.

Also ersetzte ich die mimetypelist.js durch die Version aus dem git:

wget https://raw.githubusercontent.com/nextcloud/server/master/core/js/mimetypelist.js

und alles war wieder gut: kein Gemecker über falsche Hashes und alle Ordner und Dateien wurden brav angezeigt.

Bei beiden Nextcloud-Instanzen auf unterschiedlichen Servern die gleiche Lösung. Ich meine, dass ich serverspezifische Probleme somit ganz gut ausschließen kann. Whatever.

Nextcloud Talk mit Coturn auf CX11

Einen eigenen Coturn für Videochats über die eigene Nextcloud zu betreiben ist nicht schwer. Gute Anleitungen für den Einstieg sind im Netz zu haben. Lauscht der Coturn auf Port 443, ist man gleich noch die Routerprobleme bei den Nutzern los.

In der Annahme, dass man da nicht genug Ressourcen hinwerfen kann, stellte ich Coturn bei meinen ersten Gehversuchen eine VM unter KVM mit 4 CPUs und 8GB RAM zur Verfügung. Heute weiß ich, dass das overkill ist, wenn das System nur gelegentlich und dann meist nur von wenigen Menschen parallel benutzt wird.

Die Grafik oben ist ein Screenshot aus OMD und zeigt die CPU Auslastung während eines Videotelefonats zwischen zwei Personen auf einem CX11 bei Hetzner (2,96€ / Monat). Top zeigte eine CPU Auslastung von rund 7% – OMD ein wenig mehr. Aber festhalten lässt sich, dass für eine NC-Talk-Familieninstanz der CX11 ausreichend ist – und vermutlich sogar für eine Schule, weil es sehr selten dazu kommen dürfte, dass mehrere L gleichzeitig ihren S Nachhilfe via Talk geben.

Jetzt hängen vier Nextcloud Instanzen am CX11 – zwei private und zwei Kollegien. Mal sehen, was passiert.

Joplin dual

Mich trieb die Idee um, Joplin nicht nur selbst zu nutzen, sondern auch mit anderen zusammen.

Ein einzelnes Joplin mit anderen zusammen (also: gemeinsam) zu verwenden ist kein Problem: Voraussetzung hierfür ist, dass alle Beteiligten einen Zugang zu einer Nextcloud haben. Dann teilt man in der Nextcloud den Ordner, in dem Joplin seine Daten ablegt. Sofern man nicht gleichzeitig an der gleichen Notiz herum schreibt, klappt das – synchrone Kollaboration funktioniert also nicht, sondern füllt nur den Ordner „Konflikte“.

Will man weiterhin sein eigenes Joplin nutzen, dann legt man sich für das gemeinsame ein gesondertes Profil lokal an und startet Joplin mit diesem:

/home/.../.joplin/Joplin.AppImage --profile /home/.../.config/joplin-2/

Dieses zweite Joplinprofil konfiguriert man sich dann auf einen frischen Ordner in der Nextcloud, den man wiederum für die Kooperationspartner als Share freigibt.

Dann noch ein alias dazu, damit man dieses Joplin einfacher starten kann – und voila! Was leider nicht klappen wollte hier, war, beide Joplins parallel offen zu haben.

Notizen zum build von LOS für Flo / Mako

Damit ich es nicht vergesse, was hier Schritt für Schritt abzuarbeiten ist bei der Erstellung von neuen Images für Flo und Mako:

## Note for Mako and Flo LOS builds
## Flo
## See https://wiki.lineageos.org/devices/flo/build
## repo init -u https://github.com/LineageOS/android.git -b cm-14.1
## Mako 
## https://wiki.lineageos.org/devices/mako/build
## repo init -u https://github.com/LineageOS/android.git -b lineage-15.1
##
## Keep buildenv up to date
## in this case in two sub-dirs in ~/android:
## ~/android/flo and ~/android/mako
##

cd ~/android/flo ; repo sync
# or
cd ~/android/mako ; repo sync

# if we run into problems with repo sync this might help:
# repo sync --force-broken --force-sync

##
## Source and export what we need for build
##

source build/envsetup.sh  

export LC_ALL=C
export USE_CCACHE=1
export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"

##
## Start build process
##

breakfast flo
# or
breakfast mako

# change dir to pull in proprietary blobs from device
cd ~/android/flo/device/asus/flo
# or
cd ~/android/mako/device/lge/mako

# Connect device via USB
# Check your path: 
# ~/android/flo/device/asus/flo
# ~/android/mako/device/lge/mako
# Check that USB debugging is ON on device
# Can we see the device?

adb devices

# pull the proprietary blobs in
./extract-files.sh 

# prepare compile
ccache -M 50G
croot

# compile
brunch flo
# or
brunch mako

## 
## Install the image
##

cd $OUT
adb reboot sideload
adb sideload lineage [TAB]
# return to sideload mode
adb sideload addonsu [TAB]

Mit je einem Image ist hier der Ordner für Flo ca. 85G und der Ordner für Mako rund 122G groß.

Dichtungsring Cubis Pro

Mein Cubis Pro verliert immer wieder seine Dichtung im Deckelverschluss oder diese leiert aus.

Da es keine Ersatzteile für diesen etwas älteren Verdampfer mehr gibt, habe ich mir den Dichtungsring selbst gedruckt.

Zum Einsatz kam TPU mit 1.75 mm, das sich ziemlich bescheiden verarbeiten lässt. Es klebt wie die Hölle auf dem Druckbett, weswegen dieses unbedingt mit Klebenstift vorbehandelt werden sollte. Außerdem fließt TPU anders als PLA, was es nötig macht, die beiden Schrauben des Idlers sehr weit heraus zu drehen.

Meine OpenSCAD Datei ist die hier:

// Außen
// hring = Materialstärke o. Dicke des Dichtungsrings
// dring = Durchmesser des Rings

hring=1.1;
dring=15.5;
rring=(dring/2);

// Innen
// dloch = Durchmesser des Lochs im Ring

hloch=hring+2;
dloch=11.5;
rloch=(dloch/2);

// Render

difference() {
cylinder(hring, rring, rring, center = true);
cylinder(hloch, rloch, rloch, center = true);
}

Die Einstellungen für den MK3 im Slicer waren diese:

Eine Nachbearbeitung war bei dem Druck mit 1.1 mm Materialdichte leider nötig. Da hilft eine Nagelschere, um die vielen kleinen Fuzzel weg zu bekommen (siehe Bild oben) und den evtl. vom Slicer automatisch hinzugefügten Brim.

Weitere Infos hier: https://blog.prusaprinters.org/how-to-print-with-flexible-filament/

Webriot Update Notizzettel

Eine Notiz für mich bezüglich des Updates von Webriot:

Aktuelle Version https://github.com/vector-im/riot-web/releases herunter laden und auspacken:

wget https://github.com/vector-im/riot-web/releases/download/...
tar xzf riot-versionnumber.tar.gz

Benutzer und Rechte anpassen:

chown -R www-data.www-data riot-versionumber
chmod -R 750 riot-versionnumber

Die config Datei aus dem bisherigen Verzeichnis kopieren, evtl. auch vergleichen mit der frisch mitgelieferten und notwendige Anpassungen vornehmen:

cd riot-version/
cp -p /var/www/riotwebroot.tld/config.json .

In das Webverzeichnis von Riot wechseln:

cd /var/www/
mv /root/riot-versionnumber .

Den Symlink zum Webriotverzeichnis frisch setzen:

rm riotwebroot.tld
ln -s riot-versionnumber/ riotwebroot.tld

Die Weboberfläche aufrufen und prüfen, was schief ging (meistens nix).

Hintergrund ist /etc/nginx/conf.d/matrix.conf mit dem folgenden Inhalt:


server {
listen 443 ssl;
server_name sub.domain.tld1;
root /var/www/sub.domain.tld1;

ssl_certificate /etc/letsencrypt/live/sub.domain.tld1/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/sub.domain.tld1/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;

location /_matrix {
proxy_pass http://127.0.0.1:8008;
proxy_set_header X-Forwarded-For $remote_addr;
}
}

server {
listen 443 ssl;
server_name riotwebroot.tld;
root /var/www/riotwebroot.tld;

ssl_certificate /etc/letsencrypt/live/riotwebroot.tld/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/riotwebroot.tld/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;

}