Schlagwort-Archive: NextCloud

BitBastelei #607 – WebDAV

BitBastelei #607 - WebDAV

(330 MB) 00:00:00

2024-09-01 10:00 🛈

Wenn man in internen Netzen Ordner freigeben möchte, dann haben sich Protokolle wie SMB oder NFS durchgesetzt. Insbesondere durch dynamische Ports und teils historische Verschlüsselungsoptionen ist der Einsatz im Internet aber oft mit vielen Kopfschmerzen verbunden. Mit WebDAV gibt es eine alternative, welche in den meisten Betriebssystemen nativ unterstützt wird. Da es auf HTTP/HTTPS basiert, also das Protokoll für Webseiten, ist die Einrichtung auf Netzwerkseite sehr einfach und benötigt keine zusätzlichen Ports.

Inhalt

  • 00:00 Was ist WebDAV
  • 01:21 HTTP Basics
  • 04:15 WebDAV-Erweiterungen
  • 05:57 WebDAV vs. SMB vs. NFS
  • 08:34 WebDAV-Server per nginx
  • 19:00 Client: Linux (GUI)
  • 20:27 Client: Linux (CLI/fstab)
  • 22:28 Client: Windows
  • 23:44 WebDAV-Server per NextCloud
  • 26:23 Fazit

Fehler und Ergänzungen

  • 25:05 Jein. Neuere Versionen können auch so konfiguriert werden, dass die Daten nur auf Bedarf geladen werden. Die Clients müssen aber installiert und konfiguriert werden, was ggf. aufwändiger als WebDAV ist. Auch hatte der Client bei mir immer wieder Bugs, welche den Betrieb störten.

Links zum Thema

Transparenz

Es handelt sich um frei verfügbare Protokolle und Softwarepakete, welche ich auch selbst nutze.

adlerweb // BitBastelei 2024-04-26 18:40:50

Hinweis für Admins: Mit Version 28 wurden einige Scripte von .js auf .mjs umgestellt. Sollte euer Webserver die Endung nicht kennen und das als text/html statt application/javascript einstufen knallt es.

Zum Testen: curl -I https://your.nextcloud.tld/apps/settings/js/esm-test.mjs

Für nginx: mjs für application/javascript in der mime.types im Config-Ordner ergänzen.

github.com/nextcloud/server/is

adlerweb // BitBastelei 2023-11-23 21:45:16

Die ehemalige IT-News-Redaktion aus Hannover clickbaitet wieder rum.

"Cloud-Computing-Software ownCloud und angreifbar"

Ja, nein. Bei Nextcloud gibt es nur eine DoS-Lücke, die im Zusammenhang mit externem Storage auftreten kann und authentifizierte Nutzer vorauszusetzen scheint. Der zugehörige Patch ist seit knapp einem Monat verfügbar.

github.com/nextcloud/security-

Qt5: LoadLibrary-Fehler mit RDP unter Windows (ATI, OpenGL, Nextcloud)

Das Qt-Framework wird von vielen Projekten genutzt um grafische Oberflächen auf allen Betriebssystemen einheitlich entwickeln zu können. Bekannte Softwarepakete, welche Qt nutzen, sind unter Anderem: Nextcloud-Client, Owncloud-Client, FileZilla, Quassel, Mumble, MiniTube, Bitcoin-Qt, Scribus, LuminanceHDR, Audacious, Clementine, LMMS, VLC, AviDemux-qt, Shotcut, OpenShot, LibreCAD, FreeCAD, OpenSCAD, QOwnNotes, Calibre, KeePassX, KeePassXC, Wireshark und BlueStacks.

Eigentlich eine praktische Sache, jedoch mit einem Haken: Mit Qt5 versuchte man viele grafische Operationen per Hardwarebeschleunigung zu erledigen. Dies sorgt für schnellere Programme und weniger Systemlast. Für die Ansteuerung der Grafikkarte nutzt man hierbei OpenGL, welches auf allen gängigen Betriebssystemen verfügbar ist. Leider tritt man sich hierbei auch einige Probleme ein, so ist z.B. Windows dafür bekannt qualitativ zweifelhafte Treiber zu verteilen, welche stark auf Gaming optimiert sind, aber bei anderen Operationen gerne ins Straucheln kommen.

Ein recht verbreitetes Problem tritt dann auf, wenn eine AMD-Grafikkarte wie z.B. Radeon oder im System steckt, man jedoch auf den Windows-Rechner per Remote Desktop (RDP) zugreift. Windows lädt – auch wenn RDP genutzt wird – die Grafikkartentreiber. Ein Fehler in den ATI-Treibern, welcher bereits seit Ende der 2010er-Jahre bekannt ist, führt jedoch dazu, dass in RDP-Sitzungen Grafikoperationen nicht in Software ausgeführt oder von der Grafikkarte berechnet und zurückgegeben werden, sondern sie versuchen diese Trotzdem komplett in der GPU zu verarbeiten und brechen die Anfrage letztendlich ab. In vielen Anwendungen äußert sich das in fehlenden Grafikelementen oder Fehlermeldungen. So lässt sich z.B. der Nextcloud-Client gar nicht starten und Quittiert den Versuch die GUI per RDP zu öffnen mit einem fatalen Fehler. Es ist somit nicht möglich die Software per RDP zu starten.

Fehlermeldung NextCloud-Client: „LoadLibrary failed with error 87: The parameter is incorrect.“

Glücklicherweise kann man sich hierbei einer Eigenheit von „Shared Libraries“ zu nutze machen, welche peeter123 auf GitHub vorschlägt: Jede App bevorzugt seine eigene Version, nur wenn sie selbst nichts mitliefert wird auf jene des Systems zurückgegriffen. Im Falle des OpenGL-Bugs kann man also einfach statt der Microsoft/ATI-Version eine weniger kaputte nutzen. Hierzu eignet sich z.B. die Variante des Mesa-Projektes, welche die OpenGL-Operationen nicht direkt an die Grafikkarte sendet. Um diese nun einzubinden lädt man auf der Releases-Seite die letzte Release-Version für mingw herunter (mesa3d-xx.yy.zz-release-mingw.7z), öffnet diese (z.B. mit 7Zip) und kopiert aus dem Ordner x64 (für 64-Bit-Systeme) die Datei „opengl32.dll“ in den Ordner des betroffenen Programms, also z.B. C:\Program Files\Nextcloud. Hierdurch greift die Änderung nur für diese eine App und beeinflusst nicht alle installieren Programme. Fortan sollten die Operationen der Software ohne GPU-Treiber laufen und die Applikation somit auch per RDP lauffähig sein.

Durch diese Änderung verliert man zur potentiell etwas Geschwindigkeit in der betroffenen App, dies sollte bei aktuellen Systemen aber nicht groß auffallen – insbesondere, wenn man diese ohnehin nicht häufig aktiv nutzt. Immerhin ist die Software so auch remote nutzbar. Mit fortschreitender Migration auf Qt6 sollte sich das Problem mit der Zeit auch ganz von selbst erledigen: Dies nutzt statt OpenGL die jeweiligen Funktionen des Betriebssystems, welche auch auf Windows nicht ganz so kaputt sind.

BitBastelei #376 – Telearbeit/Videochat mit NextCloud

BitBastelei #376 - Telearbeit/Videochat mit NextCloud

(83 MB) 00:18:52

2020-03-14 14:00 🛈

Aktuell ist digitale Kommunikation wichtiger als jemals zuvor. Besprechungen, Unterricht, Vereins-Meetings: Jede Veranstaltung, die nun online statt vor Ort durchgeführt werden kann hilft die Verbreitung von SARS-CoV-2 zu verlangsamen und so die Krankenhäuser zu entlasten. Mit Nextcloud lässt sich recht einfach ein System einrichten, welches den sicheren Austausch von Dateien, digitale Zusammenarbeit und Videochats zulässt.

Wegen der Aktualität und den vielen Anfragen etwas früher als Üblich

Inhalt

  • 01:15 Installation von NextCloud
  • 06:11 Benutzer anlegen und verwalten
  • 06:47 Dateien hochladen und verwalten
  • 07:20 Dateien und Ordner mit anderen teilen
  • 11:47 Online-Office mit OnlyOffice
  • 13:15 Video-Konferenzen mit NextCloud Talk

Hinweise und Ergänzungen

Verbindungsprobleme?

In Kombination mit älteren IPv4-Anschlüssen kann es in der gezeigten Variante zu Verbindungsproblemen kommen. Da ich keine Anschlüsse ohne IPv6 bzw. öffenliche IPs habe war mir das nie aufgefallen. Abhilfe schafft es auf dem Server zusätzlich einen TURN-Server zu installieren. Hierzu ist zwingend ein Konsolenzugriff erforderlich. Eine Anleitung findet sich z.B. unter https://help.nextcloud.com/t/howto-setup-nextcloud-talk-with-turn-server/30794.

Maximale Nutzerzahl / Zentraler Server

In der aktuellen Form baut Talk P2P-Verbindungen auf, das heißt, dass jeder Client sein Video für jeden anderen Teilnehmer codieren und versenden muss. Kurz: Je mehr Teilnehmer desto leistungsfähiger muss CPU und Internetanschluss sein. Empfohlen werden maximal 4 Teilnehmer. Abhilfe könnte ein zentrales Backend schaffen, dies ist aktuell aber kostenpflichtig. Für größere Konferenzen empfiehlt es sich daher ein anderes System wie BBB oder Jitsi (siehe unten) zu nutzen.

Andere Anforderungen?

Weitere Projekte, die helfen können:

  • Mumble -> Voice-Only-Chat
    Benötigt sehr wenig Ressourcen. Der Server Murmur ist in wenigen Minuten eingerichtet. Für die Teilnahme gibt es Apps für PC (Windows/Linux/MAC), Mobil (Android/iOS) und viele weitere, teils obskure Systeme.
  • Big Blue Button -> Ebenfalls ein Video-Chat. Teilnahme klappt mit fast allen Browsern. Virtuelles Whiteboard, Screensharing, etc. Für Schulen und Webinare gedacht. Einfach einzurichten. Normaler Rootserver sollte ~25 Nutzer schaffen.
  • Jitsi Meet -> System ähnlich zum hier gezeigten Nextcloud Talk.
    Teilnahme per Chrome-Browser oder App. Normaler Rootserver sollte ~15 Nutzer schaffen. Einrichtung ist eher kompliziert. Eine Liste öffentlicher Instanzen gibt es unter https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instances.

[NextCloud/EN] No login possible after Update to 13.0.4 due to encryption app

I ran into some trouble while Updating to NC 13.0.4 regarding encryption. As long as Encryption was installed and enabled no login was possible – WebDAV and Clients received HTTP/503, WebUI didn’t show the login form but only „Bad Signature“. Also occ failed with the same error – „bad signature“. The previously working version was afair 13.0.1, since downgrading isn’t supported I can’t say much for .2 and .3. Inside the log (see below) I could see the error being caused by the encryption module. There might be the odd encrypted folder still present in old accounts, but since it never worked for me reliably it’s disabled for everything currently in use. External solutions are IMO the way to go.

{"reqId":"xyz","level":4,"time":"2018-07-20T17:53:17+00:00","remoteAddr":"xyz","user":"--","app":"webdav","method":"PROPFIND","url":"\/remote.php\/dav\/files\/xyz\/","message":"Exception: {\"Exception\":\"Sabre\\\\DAV\\\\Exception\\\\ServiceUnavailable\",\"Message\":\"OCP\\\\Encryption\\\\Exceptions\\\\GenericEncryptionException: Bad Signature\",\"Code\":0,\"Trace\":\"#0 [internal function]: {closure}(*** sensitive parameters replaced ***)\\n#1 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/event\\\/lib\\\/EventEmitterTrait.php(105): call_user_func_array(Object(Closure), Array)\\n#2 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(466): Sabre\\\\Event\\\\EventEmitter->emit('beforeMethod', Array)\\n#3 \\\/var\\\/www\\\/html\\\/3rdparty\\\/sabre\\\/dav\\\/lib\\\/DAV\\\/Server.php(254): Sabre\\\\DAV\\\\Server->invokeMethod(Object(Sabre\\\\HTTP\\\\Request), Object(Sabre\\\\HTTP\\\\Response))\\n#4 \\\/var\\\/www\\\/html\\\/remote.php(72): Sabre\\\\DAV\\\\Server->exec()\\n#5 \\\/var\\\/www\\\/html\\\/remote.php(167): handleException(Object(OCP\\\\Encryption\\\\Exceptions\\\\GenericEncryptionException))\\n#6 {main}\",\"File\":\"\\\/var\\\/www\\\/html\\\/remote.php\",\"Line\":70}","userAgent":"Mozilla\/5.0 (Windows) mirall\/2.3.2 (build 1) (Nextcloud)","version":"13.0.4.0"}

The usual literature suggests to disable the encryption module using occ – not quite helpful in my case. Deleting the encryption app on FS-level did revive occ and Web but the App now failed due to missing encryption. My solution was to disable encryption using SQL instead of just deleting it:

UPDATE `oc_appconfig`
SET `configvalue` = 'no'
WHERE `oc_appconfig`.`appid` = 'core'
AND `oc_appconfig`.`configkey` = 'encryption_enabled';