Seit 1-2 Jahren benutze ich zim als Desktop Wiki aus dem Debian Repository. Mal mehr oder weniger intensiv.
Da ich nun alle Rechner zu Hause auf Bullseye umgestellt habe und ich bei fast allen eine Neuinstallation vorgenommen habe, fehlt mir nun ein Rechner übergreifendes Wiki.
Vor der Umstellung hatte ich es nur auf einem Rechner, dem Tuxedo. Ich habe es auf owncloud syncronisiert.
Da es damit momentan unter Bullseye noch Probleme gibt, habe ich mich nach einer Alternative umgesehen.
Da ich Kunde der Telekom bin, habe ich auch ein kleines Kontingent in der MagentaCloud.
Warum also nicht das mal nutzen?
Meine Idee ist, dass ich von allen Rechnern auf ein- und dasselbe Notizbuch zugreifen kann.
Die "echten" Collabrationstools wie z.B. QOwnNotes erschlagen mich mit den Features und sind in diesen Fall außerdem mit der QT Library, was ich ja eigentlich sonst nicht benötige, also weiterhin zim.
Nun denn, ans Werk.
MagentaCloud stellt einem den Dienst via WEBDAV zur Verfügung, man muß im account-manager
nur ein Password bei WebDAV-Passwort vergeben und sich den Benutzernamen dazu merken.
Nun gibt es mehrere Möglichkeiten, wie man WEBDAV in Linux einbindet, am rundesten finde ich, wenn man es mountet und allen Usern zur Verfügung stellt. Aus der Beschreibung von davfs: "davfs2 ist so konzipiert, dass es sich vollständig in die Dateisystem-Semantik von Unix-ähnlichen Systemen (mount, umount, etc.) einfügt. davfs2 macht Einhängen durch unprivilegierte Benutzer so einfach und sicher wie möglich. Das erschließt die Möglichkeit, auf solche Ressourcen wie auf ein typisches Dateisystem zuzugreifen, was die Verwendung durch Standardanwendungen ohne eingebaute Unterstützung für WebDAV erlaubt."
Auf seinem Rechner installiert man mit apt install davfs2 die Unterstützung.
Damit es als Drive im Verzeichnis der User auftaucht, muß folgende Zeile in der /etc/fstab hinzugefügt werden:
URL zum WEBDAV Mount Verzeichnis Filesystem Optionen
https://webdav.magentacloud.de /home/bed/MagentaCloud/ davfs uid=1000,users,rw,_netdev 0 0
Für bed natürlich den eigenen Login Namen einsetzen, das Verzeichnis kann natürlich beliebig genannt werden, Hauptsache es ist vorhanden und man hat im Hinterkopf, dass es ein Remote Verzeichnis ist, deshalb finde ich den Namen ganz passend. Das _netdev sorgt dafür, dass das Verzeichnis nur gemountet wird, wenn das Netz aktiv ist und man keine Hänger beim booten oder im Flugzeugmode hat.
Jetzt noch denselben Verzeichnisnamen im Home Directory anlegen: mkdir /home/bed/MagentaCloud/
Jetzt empfehle ich einen probe mount, um zu sehen ob Benutzername und password richtig sind.
# mount /home/bed/MagentaCloud/
Gib bitte den Benutzernamen für den Server https://webdav.magentacloud.de an; wenn du keinen angeben willst, drücke Return.
Benutzername: xxx@xx.xx
Gib bitte das Passwort von xxx@xx.xx für den Server https://webdav.magentacloud.de
an; wenn du keines angeben willst, drücke Return.
Passwort:
Ist das erfolgreich, dann erscheint bei df -h
u.a. dieser Eintrag.# df
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
https://webdav.magentacloud.de 1333333332 800000000 533333332 61% /home/bed/MagentaCloud
sieht gut aus?
Ok, dann können die Einstellungen auch permanent gemacht werden, damit der unprivelegierte User das Password nicht mehr eingeben muß.
cat /etc/davfs2/secrets
https://webdav.magentacloud.de xx@xx.xx Geheimes_P@ssw0rd
Update: ab 2022 ist Magentacloud offenbar auf owncloud Instanzen. Deshalb:
https://magentacloud.de/remote.php/webdav xx@xx.xx passw-word-geheim-hihi-haha
Hinweis: WEBDAV und damit auch davfs ist kein vollwertiger Ersatz für ein anständiges Network Filesystem, wie NFS, sondern auf eine https aufbauende Krücke.
In der FAQ ist auch erläutert, warum man unter Umständen lange auf ein unmounten warten muß, z.B. auch beim Runterfahren des Rechners. Siehe zless /usr/share/doc/davfs2/FAQ.gz
Mit meinen Worten kurz zusammen gefasst: Beim hochladen von Dateien wird erst lokal eine Kopie angelegt und dann Häppchenweise die Datei hochgeladen. Das ist also lange noch nicht zu Ende, auch wenn der cp Befehl schon lange beendet ist.
Ein ls -l im Zielverzeichnis kommt auch dann erst zurück, wenn das kopieren wirklich beendet ist.
Das kann man schön verfolgen, wenn man parallel per Browser in der MagentaCloud verfolgt, was passiert. Erst nach vollständigem Transfer erscheint der Dateiname korrekt und mit richtigen Angaben zur Größe.
Mein Versuch zeigt bei mir (34Mit upload) doch knapp 6 Minuten für 720 MB. Also nix für Ungeduldige 
Hier habe ich inzwischen gelernt, dass man tunlichst die Größe des Buffers im Auge behalten sollte.
Siehe hier
Dann ist die Geschwindigkeit erheblich besser.
Doch nun zum eigentlichen Thema.
Zim
Ich hatte ja bereits eine weile zim benutzt, ich habe das einfach komplett an den neuen Ort kopiert und dann wie im Screenshot zu sehen, als neues Notizbuch hinzugefügt und das alte kann man dann entfernen.
Falls sich das plugin Quellcode Ansicht nicht aktivieren lässt, also nicht wie rechts GtkSourceView - OK steht. Dann bitte überprüfen, ob die Libbraries installiert sind.
ii libgtksourceview-3.0-1:amd64 3.24.11-2 amd64 shared libraries for the GTK+ syntax highlighting widget
ii libgtksourceview-3.0-common 3.24.11-2 all common files for the GTK+ syntax highlighting widget
ii libgtksourceview-4-0:amd64 4.8.0-1 amd64 shared libraries for the GTK+ syntax highlighting widget
ii libgtksourceview-4-common 4.8.0-1 all common files for the GTK+ syntax highlighting widget
Sollte nach einem Neustart von zim immer noch kein aktivieren möglich sein, dann hilft ein Reboot. Jedenfalls bei mir. Eigentlich peinlich, aber da ich wegen eines Kernelupdates eh booten mußte, hatte sich das gleich mit erledigt.
Im Handling ist es nun überhaupt kein Unterschied mehr, wo und was ich mit zim mache. Ich bin momentan mit dieser Lösung sehr zufrieden.
Aber bitt beachtet die Kommentare, man kann das natütlich auch anders lösen.
Denn diese Lösung ist nämlich von einer funktionierenden Internetverbindung und der MagentaCloud abhängig. Großer Mist, wenn man es eilig hat, aber man nicht an sein Wiki kommt
Apropos Netz und Zuverlässigkeit.
Ich habe mal unterschiedliche Sachen mit der MagentaCloud und dem davfs probiert. Es ist doch ziemlich robust, Gewaltsames unmounten, oder reboot richten so direkt keinen Schaden an. Ich habe ja bereits angemerkt, dass der davfs2 daemon mit einer lokalen Kopie arbeitet. Wenn die Transaktion, also das kopieren einer Datei fehl schlägt, dann bleibt die alte Kopie im cache erhalten. Wie man auf dem Screenshot sieht.
Wird der Kopiervorgang nun erneut angestoßen, wird mit einer neuen Kopie im Cache gearbeitet, zu erkennen am Timestamp und der zufälligen Extension am Namen.
Wie ich bereits schrieb, ist das zurück kehren des Prompts beim kopieren nicht das Signal, dass der Kopiervorgang abgeschlossen ist, was man hier auch schön verfolgen kann, wie lange das ls -ltr (mein Alias ltr) gebraucht hat.
Die runden 3 GIB habe knapp 60 Minuten benötigt. Da nun der Kopiervorgang erfolgreich war, befindet sich nun im Cache nur noch die Leiche des ersten durch reboot unterbrochenen Kopierversuchs.
Außerdem weiß ich nun auch, dass MagentaCloud mit 3 GB Dateien umgehen kann und das Protokoll nicht bei 2GB schlapp macht, wie es teilweise heißt. Die Grenze wird bei 4GB liegen, vermute ich. (Hinweise darauf fand ich bei der Telekom)
Um den Fass die Krone aufzusetzen:
Update: Mit owncloud geht es genauso 
Happy I am
... und da wird bei df -h auch der per quota mir zugeordnete Speicher korrekt angezeigt. Nicht wie bei MagentaCloud, wo nur merkwüdige Werte angezeigt werden.
Seit heute Morgen ist die Version weltweit verfügbar.
Auf die Gefahr hin, nicht der einzige in den Planets zu sein, will ich dennoch zum heutigen Release von Squeeze gratulieren. Noch ist es auf debian.org nicht zu lesen, auf 
