Hallo!
Ich mounte meinen Nextcloud-Inhalt ins home der Benutzer mit pam.
Dazu verwende ich (wegen der Notwendigkeit eines gültigen Zertifikats) den externen Domainnamen.
Das macht das ganze wohl langsam, wie ich hier (ziemlich unten, unter der Grafik) gelesen habe.
Meine NC steht in Rot, genau wie der IPFire natürlich, sie benutzen wegen Virtualisierung ein Kabel, es geht zu einem Router von BelWü.
Frage an die IPFire- bzw. Virtualisierungs-Profis:
Kann ich dem Virtualisierungs-Host sagen: Die und die IP bitte gleich INTERN umleiten, also gar nicht erst das kabel raus?
Der IPFire kann da wohl nichts richten, oder?
Muss ich bei BelWü fragen, dass sie mir diese IP gleich intern umleiten und nicht zweifach über unsere dünne Internetanbindung?
Ich mounte meinen Nextcloud-Inhalt ins home der Benutzer mit pam.
Dazu verwende ich (wegen der Notwendigkeit eines gültigen Zertifikats)
den externen Domainnamen.
Das macht das ganze wohl langsam, wie ich hier (ziemlich unten, unter
der Grafik) https://github.com/owncloud/core/issues/23649 gelesen habe.
Meine NC steht in Rot, genau wie der IPFire natürlich, sie benutzen
wegen Virtualisierung ein Kabel, es geht zu einem Router von BelWü.
Frage an die IPFire- bzw. Virtualisierungs-Profis:
Kann ich dem Virtualisierungs-Host sagen: Die und die IP bitte gleich
INTERN umleiten, also gar nicht erst das kabel raus?
Der IPFire kann da wohl nichts richten, oder?
Muss ich bei BelWü fragen, dass sie mir diese IP gleich intern umleiten
und nicht zweifach über unsere dünne Internetanbindung?
ich würde mal bei BelWü anrufen und die fragen, ob der Cisco nicht
schlau genug ist sowas gleich zu machen.
Das können die dem bestimmt einstellen.
ich wäre der Meinung gewesen, das kann der IPFire richten, oder das der das bisher auch macht. Aber gut, kann sein, dass es der Belwuerouter macht. Meine NC steht in Orange, warum nicht auch bei dir?
bei mir wurde es mit der Zeit langsam, vermutlich anzahl der DAten, die bei mir in der NC liegen, aber sicher bin ich da nicht.
probier mal, ob du nicht doch den internen Namen, statt des externen Namens nehmen kannst. Ich glaube, bei mir geht das (in orange) und man kann ein gültiges Zertifikat umgehen.
In jedem Fall bin ich an der Lösung interessiert: belwue-router - am besten jeden Cisco-befehl mitschreiben. Ich brauch das nämlich auch unbedingt, zumal wenn das Internet weg ist und weg bleibt…
Das davfs2 des Ubuntu 16.04 kommt mit einem ungültigen Serverzertifikat klar. Lösung ist, in die Konf-datei /etc/davfs2/davfs2.conf auf dem Client
trust_server_cert /etc/davfs2/certs/owncloud.pem
einzutragen, wobei die Datei owncloud.pem bei mir ein per letsencrypt erstelltes Zertifikat ist (nicht der private key, sondern das public zertifikat).
Dann funktioniert es auch mit Zugriff auf den internen Namen (obwohl der nicht im Zertifikat steht).
Bei mir ist im Zertifikat: humboldt-gymnasium.ka.schule-bw.de und von außen ist das Zert. gültig. Intern nutze ich jetzt https://cleese/ und es funktioniert, obwohl cleese der falsche Name ist. Vorteil: selbst bei Internetausfall funktioniert intern die Cloud noch.
Allerdings: Es löst vermutlich nicht dein Problem, genauso wie es meines auch nicht löst, dass der Zugriff auf die Cloud langsam ist. Vielleicht liegt es in deinem Fall ja auch an der Menge der Owncloud-Daten und nicht an der Auflösung des Namens und dem Routing.
Ich greife das Thema mal auf. Gibt es eine Lösung, wie man die Nextcloud per Pam-Mount performant nutzen kann? Nach einer Umstellung der Clients von 16.04 auf 18.04 haben wir nämlich das selbe Problem. In 16.04 war der Zugriff einigermaßen gut. Jetzt im 18.04er Client ist der speed grottig. Die Pam-Mount configs haben wir 1:1 kopiert…
Wie vor zwei Jahren: Ich glaube, es kann an caching liegen, aber ich glaube noch mehr, dass es daran liegt, dass die Dateimanager unglaublich viele Anfragen stellen um thumbnails zu machen, größen zu berechnen usw. D.h. bei der Umstellung von 16.04 auf 18.04 hat sich das Verhalten deines Dateimanagers evtl. geändert. Hast du mal Nemo probiert?
andere frage: Hast du die Cloud über einen reverse proxy laufen oder sprichst du die IP-ADresse direkt an?
es kann nicht am Dateimanager liegen, er macht pam-Mount, also mount.davfs2. Da läuft ja noch garkein Nemo o.ä. Björn hat auf der letzten Fobi erzählt, bei ihm liefe das ganz gut. Er hat wohl das Zertifikat der Cloud importiert (bei mir mit letsencrypt eher nervig) und sonst keine Configs gemacht, also auch kein Caching aktiviert. Angeblich funktioniert der Mountpoint einigermaßen performant.
Was man testen könnte:
/etc/davfs2/davfs2.conf löschen und schauen, ob es dann deutlich schneller geht.
Bin gespannt, ob wir das noch hinkriegen, wäre nämlich ein wichtiges Feature.
Hi Max,
ja, klar machen die Dateimanager kein eigenes mount. Ich meinte, dass das Verhalten, wie neugierig die so sind eben die Performance schluckt, z.B. liegt nach einfachem öffnen bei mir im Cache gleich das komplette PDF einer Datei im Root-verzeichnis der Cloud, weil der wohl ein Vorschaubild des PDFs nur so generiert…
ABer egal: der dateimanager wird wohl nicht der Flaschenhals sein.
ICh habe jetzt auch lmn v7 und 18.04 als client und jetzt ist es bei mir auch olle langsam.
Aber ich habe auch einen reverse proxy: das ist sch… für die Cloud.
Hallo Tobias und Max,
Nemo hab ich schon probiert. Ist genauso lahm. Einen Reverse Proxy setzen wir für die Cloud nicht ein.
Wir haben den Mount auch auf einem Windows System getestet. Da ist die Geschwindigkeit gut.
Wenn man nicht über pam sonder direkt im file-explorer einbindet, dann ist die Geschwindigkeit auch normal.
Ich bin Björns Netzwerk-Kollege am RWG, er ist genauso ratlos wegen der Performance in 18.04. Deshalb schreibe ich euch an. Aber der Tipp mit dem Cert war gut, Max. Björn konnte sich nicht mehr daran erinnern. Kann sein, dass es daran liegt. Aber ich kann es erst morgen testen.
HI zusammen, du kannst statt /etc/davfs/davfs.conf zu löschen auch die Parameter darin ändern, z.B. „trust_cert“ zu aktivieren, dass er jedes ZErt. akzeptiert. Ich kann mich nicht erinnern, dass irgendeine Spielerei mal zum Erfolg führte, aber das muss nichts heißen, weil ich a.) eher kleiner Performance hatte, aber gut genug und b.) nicht genug Zeit an den Parametern zu drehen.
Ich erinnere mich auch, dass Max mal einen nicht gefixten Bug in davfs-quellcode erwähnt hatte.
Ich habe den Cloud-Mount abgeschalten, solange es so schlecht läuft, ich bin aber auch mal an einer Lösung interessiert und helfe mit.
Hallo,
ich hab insomniamäßig mal von daheim (Ubuntu 18.04)
sudo mount -t davfs https://owncloud.eichendorff-gymnasium.de/owncloud/remote.php/webdav/ /media/test
probiert und es läuft wie geschmiert (so schnell wie ein samba-mount über ssh-Tunnel) also deutlich schneller als in der Schule mit 16.04. Weiß der Geier, woran das liegt. Ich vergleiche mal die Versionen…
bei 18.04 davfs2 1.5.4-2
bei 16.04 davfs2 1.5.2-1.2
mal sehen, ob ich das bei 16.04 upgedatet kriege…
Was auch noch interessant ist: Wenn ich eine größere Menge Dateien (mehr als 50 MB) über PAM auf die NextCloud ziehe, dann ist es am Anfang schneckenlam und zuckelt mit ein paar Byte/s vor sich hin und plötzlich nach ca. 30s gibt er Gas und der Upload ist ratzfatz durch.
Leider uach nicht bei mir. Ich habe auch 18.04, dieselbe Version und ein manuelles mounten ist jetzt, wo keine außer mir eingeloggt ist nicht besonders schnell.
Hm, vllt. sollten wir mal einen testcase einrichten: eine ZIP-Datei erstellen mit X Dateien und Y Ordnern, der Größe XY und dann mal schauen, bei wem das wie lange dauert…
Hallo Tobias,
also ich finde vor allem das Datei-Browsen langsam, deshalb teste ich jetzt immer in einem Ordner mit du -sch *, es braucht aber immer gleich lange, mein Gefühl hat betrogen. Und zwar egal ob:
mein Laptop daheim
mein Laptop in grün
xenial-client
im Nemo braucht ein Rechter-Mausclick auf Eigenschaften nur 1/6 der Zeit vom davfs.mount.
so was blödes.