[Eisfair] davfs2 - testing

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> - Zertifikat:
> Ich möchte davfs2 von meinem E1-Server (Client) zu meinem Nextcloud-Server
> (Arch Linux basiert) nutzen. Das Zertifikat, das davfs2 nutzt, liegt gem.
> davfs2.conf-Manpage in /etc/davfs2/certs oder in ~/.davfs2/certs. Wenn ich
> das (selbst-signierte) NC-Server-Zertifikat auf E1 in /var/certs/ssl/certs
> ablege und in /etc/davfs2/certs/ einen Log.Link darauf setze, läuft's.
> o  Könnte man diesen LogLink nicht (via 'setup') konfigurierbar machen?
> o  Außerdem muss man den Namen des Zertifikates im davfs2.conf unter
> "trust_server_cert" eintragen und aktivieren (-#)

Das Serverzertifikat selbst auf dem Client abzulegen ist IMHO der falsche
Ansatz, denn bei jeder Änderung des Serverzertifikates (z. B.
Erneuerung, ...) musst du das wiederholen.

Der Client muss in der Lage sein, das angebotene Serverzertifikat prüfen zu
können, d. h. der Client benötigt das CA-Zertifikat, welches das
Serverzertifikat signiert hat.

> (BTW. Reicht es, das NC-Server-Zertifikat nach /var/certs/ssl/certs zu
> kopieren oder muss ich danach noch ein (Certs-)Skript laufen lassen?)

Immer wenn du in /var/certs/ssl/certs ein Zertifikat hinterlegst, ist ein
Rehash durchzuführen und auch die CRLs neu zu erzeugen; findet sich alles
im Certs-Manu.

> - nach einem Webdav-Mount zeigt "dh -h" bei /Size/ und bei /Avail/ (und
> folglich auch /Use%/) kuriose Werte (E = Exabyte):
> 
>          https://<NC-Server>/remote.php/webdav   16E   14G   16E   1%
>          /home/<user>/Nextcloud
> 
> Der "Used"-Wert ist plausibel.
> 
> Da das aber bei einem Debian 10 und einem Alpine Linux auch so aussieht,
> ist das sicherlich kein Problem des Eisfair-Paketes.

Da kann der Client (eis) garnichts dafür; die Webseite wird auf Serverseite
generiert!

-- 
Gruss Marcus