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.

4 Comments

Linear

  • brainmue  

    Ich würde es einfach Lokal nutzen und dann den Ordner einfach mit RClone synchronen. Damit hast Du das WebDav Mount Problem weg und es funktioniert in der Praxis ziemlich gut. Außerdem kannst Du gleich auch noch andere Dinge mit synchronen. So setzte ich das auf jeden Fall ein und ich bin total zufrieden damit.

    • bed  

      Stimmt allerdings. Nur das funktioniert nur, wenn es zu mindestens eine gewisse Zeit gibt, bei der die Geräte parallel an sind. Das ist hier nicht der Fall. Es sind 2 Laptops, bei denen immer nur einer an ist. Selten könnten noch 1-2 Geräte - auch Notebooks - sein, die mal davon profitieren können. Ich brauche also einen Ort, der immer online ist. Vorher war es meine Owncloud, jetzt mal die Magentacloud. Einfach mal ne weile verwenden und dann sehen.

      • brainmue  

        Ne, so meinte ich das auch nicht. Ich schiebe es von jedem Gerät immer wieder auf meine NextCloud rauf. Also die ist quasi der Zentrale Punkt und das wäre bei Dir einfach die Magentacloud. Mir geht es mit RCloud nur darum, dass ich das nicht so tolle einbinden vom WEBdav umgehen kann und damit bin ich deutlich mehr zufrieden.

        • bed  

          Ahh, ok, verstanden. Na ich gucke mal ein paar Tage. Wenn es häufiger zu Problemen kommt ist dein Ansatz auf jeden Fall robuster! Bin eigentlich sonst eher für lokale Datenhaltung, die geht wenigstens auch, wenn mal wieder die Verbindung down ist,. Oder die Cloud geklaut ist :-)

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Standard emoticons like :-) and ;-) are converted to images.
BBCode format allowed
Markdown format allowed