Ce que je ne comprends pas vraiment, c'est pourquoi tu insistes pour utiliser wedav1 ?
De mon expérience avec le module mod_dav d'Apache2 et aussi le module d'Owncloud à l'époque (vers 2013, en utilisant Nautilus et/ou un montage dav2fs pour la partie client), ça ne marche pas hyper bien, les clients donnent des erreurs incompréhensibles au bout d'un moment (style, "Serveur indisponible", "verrou actif sur le fichier", alors que j'étais juste en train de naviguer à travers les dossiers et que je suis le seul à utiliser ces dossiers; maintenant que j'y pense, il faut sûrement donner des instructions spéciales au serveur web pour la gestion du protocole HTTP dans ce cas, car il va y avoir beaucoup de requêtes et que ce n'est pas vraiment le comportement par défaut attendu pour des clients HTTP).
Le client de synchronisation quant à lui est clairement intéressant, puisqu'il ne surcharge pas le serveur web avec des requêtes HTTP fréquentes pour simplement naviguer à travers les fichiers. Le système de fichier local est efficace pour rechercher à travers les méta-données des fichiers et, si tu utilises des logiciels comme Tracker/Baloo, ils sont complètement fonctionnels (à l’exception du fait que Nextcloud ne synchronise pas les extended attributes).
Le client est capable d'écouter les modifications sur le poste local pour les envoyer au serveur. Dans l'autre sens, il retrouve automatiquement les modifications du serveur pour les appliquer en local. Seul les données modifiées passent à travers le réseau et donc la bande passante, la RAM et le CPU du serveur sont largement moins utilisées qu'avec le webdav.
Pour le chiffrement côté serveur, c'est bien écrit dans la documentation que son seul intérêt est pour l'envoi des données sur des "Remote Share" (style Google Docs, Dropbox, ...):
The primary purpose of the Nextcloud server-side encryption is to protect users’ files on remote storage, such as Dropbox and Google Drive, and to do it easily and seamlessly from within Nextcloud.
Or souvent, le but est d'utiliser Nextcloud est de se détacher de ces services, donc ça ne me surprend pas que peu de monde active ce chiffrement.
Sans ajouter que la majorité semble déléguer l'hébergement à OVH (qui utilise des VM) et donc n'ont aucune idée de la puissance machine requise par Nextcloud pour les auto-hébergés adeptes de machines de récupération.
J'utilise Nextcloud sur un laptop Acer acheté à l'époque de Windows Vista: Nextcloud ne consomme quasiment rien sur mon serveur (mais bon, évidemment, il n'est pas constamment en train de gratter les disques et envoyer des données puisque je n'utilise la fonctionnalité webdav qu’occasionnellement). C'est surtout Gitlab qui se goinfre de CPU et de RAM chez moi, mais c'est gérable grâce aux limitations de ressources par service proposées par les slice de systemd.
1 Note bien que je ne parle que de webdav, car c'est lui qui utilise le plus de ressources pour communiquer (CPU, RAM, bande passante) à cause de la nature et de la quantité de données: caldav et carddav ont beaucoup moins d'impact sur ces ressources, car les données finales à transmettre sont beaucoup plus petites que des milliers de fichiers.
[^] # Re: vocabulaire
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse au journal Retour d'expérience Nextcloud. Évalué à 4.
Ce que je ne comprends pas vraiment, c'est pourquoi tu insistes pour utiliser wedav1 ?
De mon expérience avec le module mod_dav d'Apache2 et aussi le module d'Owncloud à l'époque (vers 2013, en utilisant Nautilus et/ou un montage dav2fs pour la partie client), ça ne marche pas hyper bien, les clients donnent des erreurs incompréhensibles au bout d'un moment (style, "Serveur indisponible", "verrou actif sur le fichier", alors que j'étais juste en train de naviguer à travers les dossiers et que je suis le seul à utiliser ces dossiers; maintenant que j'y pense, il faut sûrement donner des instructions spéciales au serveur web pour la gestion du protocole HTTP dans ce cas, car il va y avoir beaucoup de requêtes et que ce n'est pas vraiment le comportement par défaut attendu pour des clients HTTP).
Le client de synchronisation quant à lui est clairement intéressant, puisqu'il ne surcharge pas le serveur web avec des requêtes HTTP fréquentes pour simplement naviguer à travers les fichiers. Le système de fichier local est efficace pour rechercher à travers les méta-données des fichiers et, si tu utilises des logiciels comme Tracker/Baloo, ils sont complètement fonctionnels (à l’exception du fait que Nextcloud ne synchronise pas les extended attributes).
Le client est capable d'écouter les modifications sur le poste local pour les envoyer au serveur. Dans l'autre sens, il retrouve automatiquement les modifications du serveur pour les appliquer en local. Seul les données modifiées passent à travers le réseau et donc la bande passante, la RAM et le CPU du serveur sont largement moins utilisées qu'avec le webdav.
En plus, seul le client est compatible avec le nouveau chiffrement end-to-end (E2E, client-à-client) annoncé en fin d'année 2017: https://nextcloud.com/blog/nextcloud-introducing-native-integrated-end-to-end-encryption/ (voir les commentaires).
Pour le chiffrement côté serveur, c'est bien écrit dans la documentation que son seul intérêt est pour l'envoi des données sur des "Remote Share" (style Google Docs, Dropbox, ...):
Or souvent, le but est d'utiliser Nextcloud est de se détacher de ces services, donc ça ne me surprend pas que peu de monde active ce chiffrement.
J'utilise Nextcloud sur un laptop Acer acheté à l'époque de Windows Vista: Nextcloud ne consomme quasiment rien sur mon serveur (mais bon, évidemment, il n'est pas constamment en train de gratter les disques et envoyer des données puisque je n'utilise la fonctionnalité webdav qu’occasionnellement). C'est surtout Gitlab qui se goinfre de CPU et de RAM chez moi, mais c'est gérable grâce aux limitations de ressources par service proposées par les slice de systemd.
1 Note bien que je ne parle que de webdav, car c'est lui qui utilise le plus de ressources pour communiquer (CPU, RAM, bande passante) à cause de la nature et de la quantité de données: caldav et carddav ont beaucoup moins d'impact sur ces ressources, car les données finales à transmettre sont beaucoup plus petites que des milliers de fichiers.