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!

Zulip raus und Matrix rein

Seit August betrieb ich auf einer VM einen Zulip-Server zum Testen. Ich dachte, dass sich das Ding in der Familie evtl. ausbreiten würde, als Ergänzung zu unserem XMPP-Server. Dem war aber nicht so, was vor allem daran lag, dass die Android-App von Zulip wenig intuitiv daher kam und weil die Inhaltsverschlüsselung für Chats fehlte. Jetzt also Matrix-Synapse mit OLM als Verschlüsselung – wie einst Zulip hier im Haus auf einer VM betrieben mit ddnss als DynDNS Betreiber.

So richtig datenschutz-sauber ist Matrix bzw. die Android App Riot nicht. Auch dann nicht, wenn man die build aus FDroid verwendet. Diesbezüglich führt unser XMPP-Server weiterhin das Feld an und bleibt deswegen auch die Kommunikationszentrale der Familie. Aber was bei den ersten Tests von Matrix sofort überzeugte, ist die Zuverlässigkeit, mit der auch die dicksten Anhänge zugestellt werden.

Was ebenfalls für Matrix spricht ist die einfache Installation und Konfiguration. XMPP – selbst mit Prosody – und die gefühlt immer verwickelten Konfigurationsorgien bei den benötigten XEP-Modulen sind da schwerer in den Griff zu bekommen.

Mako refresh

Bela hat Lewins altes Mako überarbeitet, einen frischen Akku eingesetzt und den gammeligen Power Button ausgetauscht. Dank einiger Anleitungen auf Youtube und Fingerfertigkeit war das ganze Projekt in nicht einmal 1,5 Stunden abgeschlossen – inklusive Installation eines frischen LineageOS. Die meiste Zeit ging für das Entfernen der Rückwand drauf, was ich übernahm.

Ich selbst nutze auch noch ein Mako und will es nicht hergeben. Läuft hier seit vielen Jahren stabil mit wöchentlich frischem LineageOS und FDroid als Appstore. Der einzige Nachteil ist die ranzige Kamera, die extrem viel Sonnenlicht benötigt, um gute Bilder zu machen.