Nachdem ich gerade 10 Minuten brauchte, um eine aus Versehen in Libreoffice gelöste rechte Seitenleiste wieder anzudocken:
Wer den Desktop unter KDE über mehrere Monitore hinweg liegen hat, kann wohl so oft Strg Umschalten F10 drücken, wie er will – es passiert schlicht gar nix. Also darauf achten, dass
nur noch ein Libreoffice Fenster offen ist (also alle Dialogfenster geschlossen sind)
für den Andockvorgang das Hauptfenster von Libreoffce auf den Monitor legen, von dem aus es nicht „weiter nach rechts“ geht.
Und schwupp sitzt sie nach Strg Umschalten F10 wieder am rechten Rand, wo sie auch hingehört.
2022-04-09T05:19:00.304230963Z -e ERR: Use of domain variable is not supported. First host/domain who tries to connect to COOL is always allowed.
2022-04-09T05:19:00.304248902Z To allow multiple host and its aliases use something like this and pass it as env variable:
2022-04-09T05:19:00.304251820Z aliasgroup1=https://domain1:443,https://its-alias|its-second-alias:443
2022-04-09T05:19:00.304254556Z aliasgroup2=https://domain2:443,https://its-alias:443
2022-04-09T05:19:00.304256886Z For more info: https://sdk.collaboraonline.com/docs/installation/CODE_Docker_image.html
und darf die .env sowie die docker-compose.yml anpassen. Zuerst zur .env:
Was tut man nicht alles? Ich hab hier eine VM mit W10Edu 20H2, die gelegentlich gestartet wird, um damit z.B. Wireshark zu testen, Updates zu installieren, eine einzelne Datei in MSO anzusehen oder mit W10 Privacy nachzusehen, was ich alles unter Arch nicht erdulden muss.
Trotzdem wuchert das Ding über die Zeit vor sich hin und will gelegentlich geschrumpft werden. Das geschieht hier so:
Erst einmal aus W10 heraus mit sdelete Platz schaffen:
sdelete -z "C:"
Dann die VM runterfahren und mit VBoxManage die VDI komprimieren:
vboxmanage list hdds
vboxmanage modifymedium disk /pfad/zur/vm/w10edu.vdi --compact
Am Schluss nach Geschmack wegsichern mit tar – oder auch nicht.
Ist besonders schön im Firefox bedienbar, bietet auch „Ihr dürft nur gucken“-Links zum Teilen, lässt sich in Nextcloud integrieren und macht im Docker keinen Ärger.
Für die Schule ausgerollt und in die Nextcloud integriert – für die Community macht das Frank noch am Wochenende.
Bleibt der Traum von einer Tafel mit der Mächtigkeit von Mebis.
Da mein HP Color Laserjet 2550 nur noch gelb (und ein klein wenig magenta – links das Bild von der Testseite vor der Reparatur und rechts das Bild danach) drucken wollte, fand ich bei Roland eine Anleitung zur Reparatur, die Mut machte, das mal selbst zu probieren.
Leider war der Link zum sehr hilfreichen / unbedingt notwendigen Service Manual bei ihm tot. Hier ist ein noch funktionierender. Benötigt wird Kapitel 5 „Removal and replacement“. Mensch ist sonst ziemlich verloren – zumindest wenn es wieder an den Zusammenbau geht.
Entfernt werden mussten:
alle Innereien des Druckers (Tonerkartuschen etc.)
rechte und linke Seitenwand
Deckplatte, Rückwand und hintere Abdeckung
Metallkäfig mit der Steuerelektronik auf der Seite des Bedienfeldes
um an den Käfig mit dem rotary-drive (siehe Bilder unten von nach der Reparatur) heran zu kommen, der das defekte Bauteil (solenoid) enthält.
Dieser Metallkäfig selbst ist noch relativ einfach entfernbar. Da dieser jedoch komplett zerlegt werden muss
beide Motoren entfernen
Metallkasten in zwei Teile zerlegen
Solenoid ausbauen
sei allen empfohlen, hier bei jedem Schritt den ursprünglichen Zustand zu fotografieren. Das spart erheblich Zeit und Nerven beim Zusammenbau. Wer das, wie ich, vergisst, ist beim Zusammenbau um jedes Bild im Netz froh, das den ursprünglichen Zustand zeigt [1, 2] 😉
Ich behalf mir hier als Ersatz für den kaputten Filz mit sechs Lagen masking tape der weihnachtlichen Sorte:
Am Ende blieben hier nur zwei abgebrochene Plastiklaschen und zwei Schräubchen über, für die ich beim besten Willen keinen passenden Ort mehr finden konnte. Fast wie bei Ikea. Tut aber auch so.
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
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.
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.
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:
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.
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.
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.
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 Advancedund 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!
Als Notiz für die, die es brauchen: Für EDS-Lite können TrueCrypt-Container (ja – auch VeraCrypt geht, aber das Schutzniveau muss ja nicht in und für jeden Fall so gesetzt werden) mit den Einstellungen oben schneller auf dem Rechner, als auf dem Tablet angelegt werden:
