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;

}

Q2A mit LDAP gegen LD Server

Question 2 Answer ist eine nette PHP-MySQL-Alternative to askbot und bringt hier auch ein LDAP Auth-Plugin mit. Will man dieses nutzen, um gegen einen LD-Server zu authentifizieren, dann kann man die folgenden Einstellungen wählen, damit „es tut“:

q2a LDAP Einstellungen Teil 1

Selbstverständlich wäre hier für den Produktivbetrieb in unsicherer Umgebung LDAPs und Port 636 zu wählen.

q2a LDAP Einstellungen Teil 2

Ich bin zuerst nicht auf die Idee gekommen, hier AD auszuwählen und versucht zuerst mit OpenLDAP zum Ziel zu gelangen. Das wollte nicht klappen, so dass ich in einem Anfall von „mal gucken“ plötzlich wie oben gezeigt Erfolg hatte.

Matrix / Synapse password reset

Hat ein Benutzer auf dem eigenen Serverchen sein Passwort verbummelt und man sucht nach einer CLI Lösung für den Reset wird leider eine veraltete Anleitung für die Bearbeitung der Datenbank (sqlite) ziemlich weit oben angezeigt. Richtig ist der hier

https://github.com/matrix-org/synapse/blob/master/README.rst#password-reset

beschriebene Weg.

Zum heutigen Stand funktioniert demnach:

root@homeserver: hash_password
root@homeserver: sudo -u matrix-synapse sqlite3 /var/lib/matrix-synapse/homeserver.db

sqlite> UPDATE users SET password_hash='$32b$32$hiErstEhteInPasswordHashdrinderLangist/vf' WHERE name='@user:ident.server.domain';
sqlite> .quit

getmyfreetraffic redirect

Wer, wie ich, ein wenig zu lang (in meinem Fall: 2 Tage) wartete, um das Update für Easy WP SMTP einzuspielen, deswegen gehackt wurde und nun vor lauter Redirects sein Blog nicht mehr sieht: hier mein Weg zu einer wieder funktionierenden Multiblog-Installation inklusive der Schilderung meiner Stolpersteine:

  1. Das Firefox Addon noscript verhinderte zuverlässig, dass ich bei der Begutachtung des eigenen Blogs dauernd von der eigenen Site weggeschubst wurde und im Orkus landete.
  2. Die eigentliche Reparatur erfolgte nach dieser Anleitung auf Stackoverflow. Ich wählte für meine Reparatur Option 2 – also den Weg über die functions.php im Theme-Ordner.
  3. Jedoch: Bei mir war ein Subblog gehackt worden, das das gleiche Theme verwendete wie das Hauptblog. Trägt man nun die geforderten Zeilen im Theme ein, muss man sich entscheiden, welches Blog man zuerst retten will, denn hieraus ergibt sich der einzutragende URL
    update_option( 'siteurl', 'https://bdjl.de' );
    update_option( 'home', 'https://bdjl.de' );

    Wie oben zu sehen, war das in meinem Fall die Hauptdomain (und das konkrete Theme: twentytwelve).

  4. Das beschriebenen Vorgehen über die functions.php von twentytwelve für das Hauptblog führte dazu, dass die Posts im Subblog mit dem gleichen Theme nicht mehr zu erreichen waren, weil für die nun die URLs des Hauptblogs galten … also lauter leere Seiten.
  5. Immerhin funktionierte ab diesem Punkt das Backend des Hauptblogs wieder. Hier stellte ich dann die Themes aller meiner Blogs in der Multisite Installation um auf twentyten. Nur das gehackte Subblog behielt twentytwelve.
  6. Jetzt wurde im Theme twentytwelve
    update_option( 'siteurl', 'https://bdjl.de/subblog' );
    update_option( 'home', 'https://bdjl.de/subblog' );

    die Haupt-URL des Subblogs eingetragen, die Seite einmal aktualisiert und: die Posts waren alle wieder da.

Dringend angeraten ist eine Passwortänderung für a) den Mail-Account und b) die Datenbank (MariaDB, MySQL). Weiter würde ich dazu raten, die Datenbank von WordPress nach der Reparatur zu dumpen und dann im Dump nach allen möglichen Strings zu suchen, die im Kontext dieses Überfalls irgendwie Sinn machen könnten. Weitere Schritte sind auch hier beschrieben:

https://codex.wordpress.org/FAQ_My_site_was_hacked

https://wordpress.org/support/plugin/easy-wp-smtp/

16.04 auf 18.04

Nur eine kurze Notiz zu meinen Erfahrungen beim Update von LXC oder auch KVM Maschinchen von Ubuntu 16.04 auf 18.04. Eigentlich läuft es nämlich erstaunlich rund.

  • Apache vergisst, dass PHP aktiviert war. Mit a2enmod lässt sich das leicht wieder fixen.
  • Die php.ini für PHP 7.2 muss man sich frisch einrichten. Übernommen wird da nix.
  • PHPMyAdmin funktioniert zwar noch nach dem Update, wirft aber bei der Betrachtung von Einzeltabellen mit Fehlermeldungen wie Warning in ./libraries/sql.lib.php#613
    count(): Parameter must be an array or an object that implements Countable nach dem User. Auf „Alles ignorieren“ klicken macht die Sicht wieder frei. Da sich der Fehler im Alltag für mich kaum auswirkt (ich nutze mysql meist direkt), habe ich mich noch nicht um eine Lösung gekümmert.
  • Opendkim bricht beim Update. Der Fehler mit status=78 lässt sich wohl nur korrigieren, wenn man opendkim zuerst purged und dann komplett neu installiert. Alle anderen Tipps, die ich mir ergooglete, halfen nicht weiter. Wer auch immer das erlebt, sollte nicht vergessen, seinen Key zu sichern. Meine Vermutung ist: Das könnte daran liegen, dass sich die Konfigurationsdateien zwischen den 16.04 und 18.04 Versionen zu arg unterscheiden.

nextCloud 15 mit LDAPs an LD-Server und Automount von Tausch und Home

Weil es so ein unschönes Gefummel war, dokumentiere ich hier für mich (und auch andere Benutzer von LD / SBE) die Anbindung der nextCloud per LDAPs an den LD-Server, die dafür sorgt, dass beim Login der Benutzer gleich noch deren Tausch- und Homeverzeichnisse in die nextCloud gelupft werden. Dass dann bei uns noch Collabora CODE dazukommt rundet die Sache schön ab.

Siehe zu diesem Thema auch den Vorgängerartikel.

Kurz zum allgemeinen Setup: Eine VM mit Ubuntu 18.04 LTS werkelt intern auf einem Virtualisierungshost, der mit seinen Netzwerkkarten in den jeweils für ihn wichtigen VLANs hängt. Auf diesem bridgen die VMs direkt in die VLANs rein. In Richtung Internet steht vor diesem VM-Host eine PFSense als Firewall in den jeweils relevanten Netzen.

Die VM für nextCloud etc. hat zwei virtuelle Netzwerkkarten: Eine zeigt via grauem VLAN in Richtung PFSense (damit in Richtung Internet) und trägt die öffentliche IP des Servers. Die andere Netzwerkkarte hängt als Bridge im grünen VLAN und wird vom LD-Server direkt versorgt. Über diese zweite („grüne“) Netzwerkkarte hole ich mir per LDAPs die Benutzerdatenbank und führe den SMB/CIFS-Mount der Homeverzeichnisse aus.

Netzwerkdiagramm

LDAPs Anbindung

Das Paket php-ldap muss an Bord und konfiguriert sein.

Hinweis: Den Zertifikatscheck kann man im nC LDAP Modul ausschalten für die ersten Tests – oder direkt auf der VM in /etc/ldap/ldap.conf durch den Eintrag TLS_REQCERT allow. Nicht schön, aber zum Testen eine Fehlerquelle weniger.

Die Server-IP mit vorangestelltem ldaps:// und im Feld Port 636 eintragen. Die zwei folgenden Felder können für LD-Server leer gelassen werden.

Da das automatische Auslesen der Base DN bei mir nicht funktioniert hat, musste ich diese von Hand angeben. In meinem Fall: ou=users,dc=kvfg-schule,dc=de

Beim LD-Server liegen die User in ldUserAccount.

Die Loginattribute wählt das von mir hier verwendete nC 15 dann von selbst richtig aus.

DIe passende Objektklasse ist posixGroup.

Das würde nun reichen, um die Benutzer in nC rein zu lassen und auch, um das Tauschverzeichnis automatisch einzubinden, aber nicht, um die Homeverzeichnisse der User automatisch zu mounten. Das liegt daran, dass nC aus dem LDAP die UUID nimmt, um die nC-Benutzernamen zu erstellen. Wir brauchen aber für den Automount der Homes unserer Benutzer deren uid (das ist dann gleichzeitig der Benutzername des Users). Es gilt demnach, nC zu überreden, die UUID zu ignorieren und stattdessen die uid der LDAP-Benutzer zu verwenden.

Auf der Registerkarte Expert finden wir diese Möglichkeit. Bei Internal Username Attribute muss uid eingetragen werden.

Hinweis: Im Reiter Advanced gibt es die Möglichkeit, die von nC lokal erstellten Benutzerverzeichnisse (im Datenverzeichnis von nC) mit %uid benamen zu lassen, statt mit der UUID. Das geschieht durch die Einstellungen oben nun automatisch so. Man darf die Angabe auf keinen Fall doppelt machen (also im Reiter Advanced und im Reiter Expert). Die Fehlermeldungen, die man nach einem Doppeleintrag erhält, beziehen sich auf Homeverzeichnispfade, die nicht aus dem LDAP gelesen werden können. Nicht wirklich hilfreich.

Das Debugging ist wenig witzig. Was hilft, ist hier schon ausführlich beschrieben worden, weswegen ich mir diese Ausführungen heute sparen will. Was hier und heute dazu kommt: Es lohnt der regelmäßige Blick in die Datenbank von nC (z.B. über phpmyadmin). Da dürfen bei den Benutzern keine UUIDs auftauchen (das sind kryptische Kombinationen aus Zahlen und Buchstaben), sondern ausschließlich deren uids (also deren Benutzernamen). Hat das nicht geklappt, darf man von Vorne beginnen. Es empfiehlt sich deswegen, zuerst eine Basiskonfiguration anzulegen und diese zu sichern, die dann wieder eingespielt werden kann, wenn man sich in eine blöde Ecke konfiguriert hat. Das ebenfalls sehr nervige LDAP-Caching von nC lässt sich mit einem beherzten Restart des Apachen beeinflussen.

SMB/CIFS Mount

Die Pakete libsmbclient php-smbclient php-smb und auch die cifs-utils müssen installiert und konfiguriert sein. Letzteres nicht nur zum Testen, ob der SMB-Mount überhaupt funktioniert, sondern auch, weil die anderen Pakete ohne die cifs-utils nicht rund laufen werden.

Nachdem den Benutzern von nC die Verwendung von SMB/CIFS erlaubt wurde, die Einträge wie im Bild aus dem Adminaccount heraus vornehmen. Dabei den Folder Name und die IP des SMB-Servers den eigenen Gegebenheiten anpassen.

Nicht irritieren lassen, dass die „Böbbel“ beim Admin rot bleiben. Da der nC-Admin nicht aus dem LDAP kommt, sondern ein rein lokaler nC-Benutzer ist, muss der SMB-Mount hier auf die Nase fallen.

Die Einträge Login-creditials, saved in session sorgen bei den LDAP-Benutzern aber später dafür, dass die automatischen Mounts klappen. Das $user sorgt für die Ersetzung des Namens für das Home-Share durch den Benutzernamen (die uid), der beim Login in der nC angegeben wurde. Deswegen ja auch das Gefrickel mit dem LDAP oben!

Die Benutzer müssen nun nur noch aufpassen, dass sie sich nicht mit dem Desktop-Client automatisch das gesamte Verzeichnis Tausch/Schule syncen 🙂

Wie man sich per Docker noch ein Collabora CODE auf die VM mit der nC holt, ist an vielen anderen Stellen im Netz schon ausführlich beschrieben worden. Für den Alttag würde ich dann 6GB RAM und 4 CPUs für die VM empfehlen: CODE wie auch nC ziehen zusammen ziemlich an den Ressourcen.

Eines noch: Moodle 3.6 bringt die Möglichkeit zur Anbindung an eine nextCloud mit.

Summa summarum: Wer braucht da noch Ella? DIY and federation are the key!