Irgendein Update (vermutlich im Dezember 21) zerschoss mir hier den Mount des schulweiten Tauschverzeichnisses in die Nextcloud. Mit den folgenden Einstellungen tut es dann wieder:
Hinweis: Mit smbclient -L 10.16.1.1 gucken, was der LD-Server so rausposaunt.
Lange war ich auf der Suche nach einem möglichst kooperativ verwendbaren Whiteboard und denke nun: ich würde fündig.
https://github.com/cracker0dks/whiteboard
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.
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.
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#63Diese 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.
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.
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.
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.
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!
