Question existentielle :
Est-ce que ca vaut encore la peine d'utiliser webdav et ses serveurs(nextcloud)/clients(davfs2) spécialiste des freezes et des surcharges réseaux/mémoire ou vaut-il mieux chercher une alternative ?
Webdav peut-il un jour devenir utilisable correctement (comme SSHFS), ou ce FS est-il voué, par design, a être pourris jusqu'à son dernier jours ?
Forum général.général Webdav est-il pourri par concept ou voué à être utilisable dans le futur ?
20
jan.
2019
# Au boulot!
Posté par ʭ ☯ . Évalué à 5.
Tu as trouvé la raison d'optimiser, au boulot!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Au boulot!
Posté par voxdemonix . Évalué à 4. Dernière modification le 20 janvier 2019 à 16:50.
Justement, la question est "est-ce optimisable (par l'évolution du dev, pas par la config) jusqu'à aboutir à une alternative à SSHFS" ou au contraire le protocole est tel qu'il l'en empêche ?
J'ai l'impression que SSHFS a un fonctionnement "par block" alors que webdav fonctionne uniquement "par fichier" (comme FTP si je ne m'abuse).
Après on peut se poser la question du "est-il mieux d'évoluer webdav, ou plus tôt de tenter de dev pour corriger les défauts de sshfs (les permissions unix)?".
[^] # Re: Au boulot!
Posté par Eh_Dis_Mwan . Évalué à 4.
Pourquoi ne pas essayer les montages nfs ou smbfs ? Jamais utilisé webdav mais est ce peut être lié au démon httpd? As tu les mêmes limitation sur un mini serveur web python par exemple ?
[^] # Re: Au boulot!
Posté par LaBienPensanceMaTuer . Évalué à 6.
NFS et Samba vont être difficilement utilisable sur internet ('fin … ils le sont, mais c'est pas nécessairement une excellente idée) … WebDAV a vraiment été conçu pour ça quant à lui.
[^] # Re: Au boulot!
Posté par voxdemonix . Évalué à 2. Dernière modification le 21 janvier 2019 à 13:04.
Pas mal de commentaires sur ubuntu-fr déconseillent ces deux FS pour autre chose que du LAN car la sécurité serait très moyenne.
[^] # Re: Au boulot!
Posté par ʭ ☯ . Évalué à 2.
la sécurité serait très moyennela sécurité est absente
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Mauvais coupable
Posté par LaBienPensanceMaTuer . Évalué à 5.
Tu tires à boulet rouge sur WebDAV en notant trois problèmes:
Ne confonds pas protocole (ce qu'est WebDAV), implémentation (ce qu'est Nextcloud) et déploiement (ce que tu sembles avoir fait sur un hard trop léger).
WebDAV est un vieux proto qui, si il est correctement implémenté et déployé est tout à fait utilisable.
Personnellement, je l'utilise de temps à autre depuis ma connection fibre sur un serveur dédié, et je ne note pas de problème particulier.
[^] # Re: Mauvais coupable
Posté par voxdemonix . Évalué à 2. Dernière modification le 21 janvier 2019 à 12:38.
Les freezes et surconsommation disque et réseau c'est côté client (client linux davfs2).
Client dont je ne suis pas sur qu'il évolue encore (la dernière news sur leur site semble dater de 2016).
Sur Android (avec Total Commander ou Nextcloud Apps), c'est un peu plus fluide.
Habituellement on me dit plus tôt l'inverse ^ ^ (on parle de minimum 4 machines dédiées, le tout conçu justement pour tenter de scaller webdav qui reste bloqué en lecture/écriture à 27Mo/s alors que SFTP monte a +-45Mo/s, FTP a +-80Mo/s et glusterfs a 120Mo/s)
Pour une utilisation type FTP ça passe, mais en utilisation plus intensive (utiliser son remote storage comme si c'était un disque local), les problèmes sont vite là :
Par exemple monte un dossier avec webdav et avec SSHFS (pour comparer) :
lance une vidéos avec VLC : avec SSHFS la vidéos se lance quasi directement même avec un fichier de 20Go, le lecteur pouvant récupérer les données dont il a besoin. Avec webdav la vidéos se lancera quand le fichier aura été téléchargé totalement en local. Et si tu quittes VLC (car crash par exemple), le fichier est supprimé localement, si tu relances la lecture il faut de nouveau attendre.
lance une conversion de fichier vidéos avec HandBrake : D'abord Handbrake va vouloir analyser le fichier, donc il va le télécharger et freeze jusqu'à se que le fichiers soit téléchargé au complet. Ensuite Handbrake analyse le fichier, tu l'ajoutes a la liste et … le fichier est supprimé localement. Donc quand tu vas lancer ta conversion, ton fichier va, à nouveau, être téléchargé en intégralité.
Il y a quelques semaines j'ai eu aussi un coups pas mal :
Mon cache webdav est en ram (donc limité sous les 10Go). alors que je me promenais dans mes fichiers, le gestionnaire de fichier (ou d'aperçu je sais pas trop), s'est mis à télécharger un .iso de +20Go depuis un sous-dossier. (bien entendu, je l'ai vu quand ma machine était freeze a 99,9% de ram utilisé)
Un autre problème très très désagréable, c'est la gestion du cache : A plusieurs reprise j'ai eu le coups d'un cache de plusieurs Go (1) ou du point de montage qui se monte quand même alors que le serveur est down.
1 entre autre sur un RPI qui n'utilisait webdav que pour exporter ses backups et logs, le système était full avec 12 Go consommé par le cache webdav
[^] # Re: Mauvais coupable
Posté par NeoX . Évalué à 4.
ftpfs/curlftpfs
tu as essayé ftpfs plutot que davfs ?
les deux utilisent fuse il me semble, parfois c'est fuse qui fout la grouille dans les performances (c'etait le cas avec NTFS à une epoque)
[^] # Re: Mauvais coupable
Posté par voxdemonix . Évalué à 2.
Internet semble un peu radin en matière d'infos à son propos.
A-t-il un fonctionnement en mode block façon SSHFS ou plus tôt en mode fichier façon FTP/SFTP/Webdav ? :)
[^] # Re: Mauvais coupable
Posté par NeoX . Évalué à 4.
quelle importance de savoir comment fonctionne le FTPfs comparé à SSHfs ?
tu as des performances meilleurs en FTP, tu veux de la performance, alors utilise FTP.
à toi de tester selon tes besoins.
mais vu que ca se base sur cURL et Fuse,
tu dois pouvoir trouver comment il gere en regardant comment ces derniers gerent les accés
[^] # Re: Mauvais coupable
Posté par LaBienPensanceMaTuer . Évalué à 4. Dernière modification le 21 janvier 2019 à 17:32.
Ok, vu ton utilisation, peut être que le protocole même n'est pas adapté à ce que tu souhaites faire …
Tu demandes à un filesystem "émulé" au dessus de HTTP des performances d'un vrai FS réseau … c'est un peu utopique.
Pour un tel usage, je m'orienterai plus en effet sur du NFS ou du samba…
Si c'est pour une utilisation à travers du net, peut être que cela aurait du sens d'utiliser un miroir local …
Mais au final, vu les tests que tu sembles avoir déjà effectués, tu es plus câlé que moi sur le sujet ;-)
Je crois que je vais prendre ce post pour ce qu'il est: un gros coup de gueule contre WebDAV :)
[^] # utiliser apache côté serveur
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Une «astuce» pour avoir du webdav fonctionnel : utiliser apache et bannir nginx. Après avoir galéré des mois en pensant que notre code tracim/wrbdav était buggue, on a découvert une bonne raison pour que ça marche mal en prod : on avait un frontal/proxy nginx. En le remplaçant par apache, tout est rentré dans l'ordre.
Nginx implémente un support partiel de webdav, là où apache fait ce qu'il dit qu'il fait.
Depuis ça marche plutôt bien. Bon, on fait pas de streaming… mais webdav est clairement pas fait pour ça.
Je crois pas que webdav fonctionne en mode block…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: utiliser apache côté serveur
Posté par voxdemonix . Évalué à 1.
Bon a savoir pour l'astuce de nginx, j'ajouterai la mise en garde dans mes tutos sur nextcloud. ;)
Non je ne pense pas non plus. A voir si on peut corriger ce gros défaut ou si la seule solution est de se tourner vers une alternative.
Je suis étonné que les solutions de cloud libre se sont tournées vers ce protocole plus tôt que de tenter d'adapter SSHFS ou tout autres protocoles mieux élaboré.
[^] # Re: utiliser apache côté serveur
Posté par LaBienPensanceMaTuer . Évalué à 3.
C'est pas trop étonnant … C'est pour mieux "pénétrer" le marché ;-)
Quasi tout les OS grand public du marché supporte DAV nativement. SSHFS par contre …
[^] # Re: utiliser apache côté serveur
Posté par lolop (site web personnel) . Évalué à 3.
WebDAV ça passe sur les protocoles du web, ssh c'est souvent fermé.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Mauvais coupable
Posté par voxdemonix . Évalué à 1. Dernière modification le 22 janvier 2019 à 00:44.
Un coups de gueule et deux vrais questions :
Webdav peut-il/va-t-il évoluer afin de combler ses problèmes? (et les clients vont-ils implémenter tout cela ou sont-ils mort?)
N'est-ce pas mieux de ce tourner vers une autre alternative (si oui, laquelle?) ou de tenter de corriger les problèmes de l'une d'entre elles (par exemples SSHFS qui a le bon comportement mais qui dépends des users/permissions unix ce qui est bloquant)
Je vais jeter un oeil à NFS et Samba mais il me semble les avoir déjà testé si ma mémoire ne me joue pas trop de tour.
Mais l'idée d'un add-on pour nextcloud qui permettrait l'accès aux données via un autre protocole (SSH) me taraude depuis un moment.
Je ne demande rien, je suis l'utilisateur finale qui veut que "ça just work sans savoir que ça éxiste". 😋
Avant j'utilisais SFTP sur un bête NAS, puis un jour, en lisant un commentaire sur ubuntu-fr, j'ai découvert SSHFS qui fut une vrai révolution.
La je trouverai trop cool de découvrir la même révolution avec webdav ^ ^
[^] # Re: Mauvais coupable
Posté par LaBienPensanceMaTuer . Évalué à 3. Dernière modification le 22 janvier 2019 à 12:10.
Comme je le dis un peu plus haut, le point fort de DAV c'est sa portabilité: tout les OS grand publics du marché le supporte nativement (cherche "WebDAV drive windows" et "WebDAV drive mac" tu verras que les tutos pullullent).
Si les gens de NextCloud/OwnCloud & co se sont orientés vers WebDAV c'est aussi par soucis de simplicité d'intégration:
Pouvoir faire du SSHFS depuis du code PHP (ce qu'est NextCloud) demanderait probablement une brique logicielle supplémentaire pour ouvrir un port SSH, en faire une configuration, mapper les backend de stockage NextCloud vers du SSH, le point le plus complexe de mon point de vue: faire cohabiter deux mondes (une appli web et du code système qui agirait sur des ports réseau et sur un stockage qui n'en est pas un, avec des permissions POSIX qui n'en sont pas …) parait compliqué.
Alors qu'en WebDAV, le point d'entrée c'est un script PHP controllé par NextCloud & co: la "transformation" en pseudo-FS, la gestion des permissions est juste triviale :)
En gros, pour avoir un add-on "propre" SSHFS pour Owncloud/Nextcloud, il faudrait plutôt raisonner à l'enver:
Créer un FS Fuse pour pouvoir monter un backend de stockage owncloud comme un FS standard (en réussissant à trouver une façon de mapper des permissions owncloud vers des permissions unix … dur dur).
Partager via SSHFS le montage de FS.
L'inverse, à savoir Owncloud qui "émulerait" du SSHFS au dessus de HTTP serait totalement délirant et tout aussi peu performant (toujours de mon point de vue).
[^] # Re: Mauvais coupable
Posté par voxdemonix . Évalué à 1. Dernière modification le 22 janvier 2019 à 17:19.
Boaf.
Sur Windows 10 lors de mes tests il y a 2-3 ans, les montages webdav étaient pètés à chaque reboot par l'OS. (un bug qui changeait l'hostname du montage pour une raison inconnue (OneDrive pas vouloir de concurence? :P))
Sur Ubuntu/Debian il faut installer le paquet davfs2.
Sur Android il n'est tout simplement PAS intégré (google pas vouloir de concurence?). Il faut passer par un logiciel tiers (dont aucun que j'ai testé ne permet l'accès au montage aux autres apps de l'appareil).
Je suis du même avis, ré-inventer la roue n'aurait aucun sens et du SSH en PHP c'est un tantinet laggy (on peut le tester via les montages distants dans nextcloud).
Mon idée visait plus tôt une passerelle entre le démon SSH et Nextcloud. Les sessions pourraient peut-être être "automatisées" par LDAP (vu que les deux projets ont l'air compatible). Le gros soucis étant, comme tu as évoqués, les permissions (surtout si on utilise un remote storage sur les serveurs qui vont recevoir les connexions clientes webdav/SSHFS/SFTP).
Par contre si peut-être pourrait-on donner accès aux données de l'utilisateurs via SSHFS, il est quasi impossible de gérer les partages et les multi-sources.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.