Hello les amis de Fedora,

j'avais déjà regardé la chose (WebDAV + encfs), à l'époque avec Box.net, qui existe toujours est est très fiable, mais n'offre que 5G d'espace gratuit.

Hubic est plus "généreux", mais souffre de grave défauts de jeunesse : dimanche (17 juin 2012) par exemple, c'était planté de 14h00 jusqu'à lundi matin. Fâcheux si on a un besoin urgent de récupérer des données...

Bref, pour apporter ma pierre au moulin de ce post :

-1) davfs2 fonctionne parfaitement en "non-root"... c'est juste un peu "coriace" à mettre en place !
Vous pouvez certainement suivre (et adapter) le processus que j'ai décrit pour Ubuntu ici : http://doc.ubuntu-fr.org/davfs2
Le packaging étant différent sur Fedora, il est possible que le dpkg-reconfigure n'existe pas ou soit fait différemment. A mon avis, le seul truc que fait la commande dans ce cas (à vérifier !) est que ça met le suid de mount.davfs, de façon qu'un utilisateur non root puisse lancer la commande.

-2) je ne connaissais pas wdfs, ça fonctionne mais ça a l'air "pas fini" comme machin (du moins sur Ubuntu). En principe, un file-system qui utilise fuse devrait passer en daemon une fois lancé, sauf si on utilise l'option -f pour le forcer à ne pas le faire. Là, le machin reste constamment au premier plan !.. Donc si on veut faire un script et enchaîner sur le montage encfs, c'est moins évident !..

Je n'ai pas encore bien expérimenté avec wdfs, mais davfs a l'air d'être "écrit avec les pieds" pour ce qui concerne le multi-tâche. En effet, si on lance un transfert volumineux, tout est bloqué, même le listage de répertoire (un simple ls) ... jusqu'à ce que le transfert soit fini. Ca ressemble donc à une sérialisation complète de toutes les actions. Alors c'est sûr que comme ça c'est plus facile à coder, mais du coup ça rend le système très peu réactif, voire donne l'impression que tout est planté.

rsync ne fonctionne pas non plus avec davfs : dans le sens local => cloud, on récupère une erreur 22 (sans doute des caractères mal 'escapés'), dans l'autre sens, cela fonctionne, mais les dates sur le partage webdav sont celles de la création du fichier sur le cloud, et pas la date du fichier d'origine qu'on a copié !.. Donc si on fait une copie local => cloud (cp, puisque rsync ne marche pas dans ce sens !) plus un rsync cloud => local, on se prend une recopie intégrale... pas cool.

Je vais expérimenter avec wdfs, pour voir si outre son côté "pas fini", il présente les mêmes défauts de conception que davfs. Et au pire je tâcherai de me remettre à mon programme de montage distant de la Freebox V6 pour l'adapter à WebDAV !..


[EDIT] : bon, ben pas mieux pour wdfs, voici ce qu'on lit dans le README livré avec le source:
wdfs wrote:limitations of this implementation:
- wdfs is not (yet) multithread safe. it always uses fuse single thread mode.
- read/write of big files (~ 50 MB+) is slow, because the _complete_ file
will be GET/PUT on a request.
Pour que Rsync ne recopie pas intégralement les données il faut lui mettre l'option "checksum"
nIQnutn wrote:Pour que Rsync ne recopie pas intégralement les données il faut lui mettre l'option "checksum"
Certes... mais ça ne "résout" pas le problème !

Avec checksum, rsync va faire le checksum des données situées sur ton stockage WebDAV et donc il devra lire 100% des données. Tu gagnes juste le temps de réécriture en local, mais celui-ci est négligeable par rapport au temps de transfert. Qui plus est, même pas sûr que tu gagnes quoi que ce soit, parce que certes tu ne feras pas d'écritures locale, mais tu vas aussi faire le checksum local de 100% des fichiers ! Donc non seulement ça ne "résout" pas le temps énorme du rsync, mais ça empire probablement la chose. :hammer:

... enfin tout ça, à la base, c'est certainement qu'en plus d'une gestion déficiente du mutl-tâche, davfs doit probablement mal gérer les attributs des fichiers (à moins que ce ne soit OVH... à vérifier !)
9 jours plus tard
Salut à tous.

Je déterre le topic pour vous faire part de mon expérience (heureuse) avec messieurs Webdav et hubiC.
Voici la procédure pour monter votre dossier hubiC sur votre système (source). Certes, c'est pas exactement le sujet du topic, mais ça peut être utile :

Installer davfs2 : 
# yum install davfs2
Après avoir récupéré vos identifiants avec le script ici 
# echo "https://cloudnas1.ovh.com/votreespaceovh login password" >> /etc/davfs2/secrets
# mkdir /home/yourlogin/.davfs2
# chown yourlogin:yourlogin /home/yourlogin/.davfs2
# cp /etc/davfs2/secrets /home/yourlogin/.davfs2
# chown yourlogin:yourlogin /home/yourlogin/.davfs2/secrets
Je voulais monter le dossier dans /media, mais à chaque reboot tout disparaît... C'est normal ? Du coup, je l'ai mis dans /mnt 
# mkdir /mnt/hubiC
Bon, là, je suis passé par system-config-users (en root) au lieu de la ligne çi-dessous. C'est pas bien, je sais, mais bon... 
# usermod -aG davfs2 votrelogin
# chmod u+s /sbin/mount.davfs
Et enfin dans le fstab 
https://cloudnas1.ovh.com/identifiant/	/mnt/hubiC davfs defaults,noauto,user,uid=Val,gid=davfs2 0 0
Sans le noauto, ça plante au démarrage (normal, j'ai pas encore le réseau au boot).

Le problème qui est survenu est le suivant : 
$ mount /mnt/hubiC/
/sbin/mount.davfs: / is the home directory of user nobody.
You can't mount into another users home directory
Soit. J'ai donc demandé de l'aide à Google (ici). Réponse : 
$ awk -F: '($6 == "/") {print}' /etc/passwd
nobody:x:99:99:Nobody:/:/sbin/nologin
usbmuxd:x:113:113:usbmuxd user:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
nm-openconnect:x:995:993:NetworkManager user for OpenConnect:/:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
Et pour chaque ligne : 
# usermod -d /dev/null nobody
Sauf que ça ne marche pas pour dbus vu qu'il est loggé. Donc il faut redémarrer en init 1 pour modifier ça.

Et maintenant, ça marche. Et pour faire des backups sécurisés : DéjàDup avec mot de passe dans le dossier /mnt/hubiC. Nickel. Bon sauf que DéjàDup termine direct le backup et que mon réseau sature en upload le temps d'envoyer les fichiers - ce qui fait planter Nautilus. Du coup je sais pas trop si DéjàDup est "au courant" que l'upload est en cours ou s'il pense que tout est écrit (si c'est ça, ça veut dire que tout se met en cache quelque part sur mon disque - ce qui me fait un peu peur pour le jour où je ferai mon premier GROS backup...).

J'aurais toutefois une question : comment peut-on faire pour faire apparaître le dossier /mnt/hubiC comme un lecteur réseau (ou une clé USB), c'est à dire la possibilité de le monter en cliquant dessus dans Nautilus et de le démonter en cliquant sur le symbole "Eject" ? Non parce que devoir ouvrir un terminal et taper 
$ mount /mnt/hubiC
pour monter le bouzin, c'est pas super esthétique sous Gnome 3...
Pour avoir accès au dossier directement dans Nautilus
Nautilus -> Fichier -> Se connecter à un serveur
puis créer un signet
Tu as l'air d'avoir fait tout ce qui indiqué dans mon tuto Ubuntu, avec les adaptations correctes pour Fedora.

Pour ce qui est du montage via Nautilus, ici (Precise 64) ça fonctionne parfaitement sans avoir à créer de signet. Peut-être est-ce simplement parce que le point de montage se situe dans mon /home au lieu d'être dans /mnt

Ca me semble plus logique de le mettre dans le /home vu que c'est en fait un montage utilisateur, non visible des autres utilisateurs du PC.

Ah, et une petite astuce, quand tu donnes un tutoriel où il faut remplacer le nom d'utilisateur, le mieux est de le donner en utilisant la variable $USER, et si c'est pour désigner le 'home' de l'utilisateur, d'utiliser le raccourci : ~

Exemple: 
chown $USER:$USER ~/.davfs2
(Ca suppose tout de même que le user est dans un groupe du même nom, ce qui est généralement le cas pour l'utilisateur principal du PC !)

Ainsi donnée, la commande peut être copiée/collée par un utilisateur, sans qu'il ait à remplacer des bouts de la ligne de commande.
Ah et oui, davfs2 a un comportement désastreux.

C'est ce que j'expliquais plus haut, il a probablement été écrit "mono-thread". Cela fait que lorsque tu es en train de faire un upload (et c'est long en ADSL) les demande de listage (et Nautilus en fait plein sans même que tu le saches !) sont en attente. Par conséquent ton système semble "bloqué", et c'est assez moche. Un autre truc moche, c'est qu'il télécharge tout le fichier dans la cache avant de répondre aux ordres de lecture... ça c'est assez bourrin si on veut juste les premiers octets d'un très gros fichier !..
Si tu veux écrire un file-system Fuse, il FAUT faire un truc multi-tâche (multi-thread) sinon le FS présente le mauvais comportement décrit plus haut. Et si tu te débrouilles bien, il n'y a pas de raison de ne pas pouvoir traiter une demande de listage en parallèle d'une lecture ou d'une écriture.
J'ai fait ainsi sur mon file-system expérimental pour monter une Freebox à distance, et il est très réactif, sans commune mesure avec davfs !..

Et aussi, comme tu le constates, davfs2 utilise effectivement une cache.
Si tu avais suivi le tutoriel en entier, il y a un autre fichier à copier dans ~/.davfs2, c'est celui de la configuration. Ainsi tu peux configurer par utilisateur. Sinon davfs2 prendra le fichier dans son répertoire d'installation et c'est moche !.. Dans ce fichier de configuration tu peux jouer par exemple sur la taille de cache et bien d'autres choses.

Par défaut la cache est dans le répertoire ~/.davfs2/cache, et elle fait 50M.

Lorsque tu "démontes" proprement ton filesystem davfs, il va "synchroniser", c'est à dire qu'il terminera toutes les écritures en court avant de rendre la main. Donc, sauf si tu éteins "sauvagement" ton PC, en principe tout sera uploadé correctement.

Conclusion, compte tenu de l'état de davfs2, son usage est réservé à une manipulation de "petits fichiers", ainsi les effets de bord décrits plus haut n'ont plus trop d'impact.

... et une ré-écriture complète s'impose !.. Je suis dessus, mais j'avance pas vite (j'ai aussi un travail à temps plein et d'autres activités :roll: )
@nIQnutn : you made my day!
Ptin j'y avais même pas pensé, alors que ça fait exactement ce que je veux... Merci !

@Zakhar : ok. J'avais aussi lu des infos de ce genre sur davfs, mais j'avais pas creusé. C'est de l'optimisation après.
Par contre, en utilisant la technique magique du signet, est-ce que Nautilus utilise davfs ? Si oui, comment lui demander d'utiliser un FS multi-thread à la place ?
En toute logique, Nautilus doit utiliser ce qui figure dans le /etc/fstab comme montage signalés 'user'.

Et lorsqu'on clique sur un tel montage, il le monte !

Donc pour utiliser un autre FS il suffit que ce soit fait ainsi dans le /etc/fstab

Par exemple, pour monter sa Freebox on peut utiliser curlftpfs (qui lui est mieux écrit et davantage multi-tâche), et faire l'équivalent dans le /etc/fstab mais avec un montage curlftpfs au lieu de davfs
Tu veux dire qu'il faudrait que je modifie cette ligne de mon fstab 
https://cloudnas1.ovh.com/ID/	/mnt/hubiC davfs defaults,noauto,users,uid=Val,gid=davfs2 0 0
par 
https://cloudnas1.ovh.com/ID/	/mnt/hubiC curlftpfs defaults,noauto,users,uid=Val 0 0
?

Mais comment savoir si hubiC supporte le curlftpfs ?
lol non !

C'est certain que ça ne marchera pas !

Je citais la freebox en exemple (qui a un serveur ftp) et tu peux monter (à tester) avec 
ftp://user:password@mafreebox.freebox.fr/	/mnt/Freebox curlftpfs defaults,noauto,users,uid=Val 0 0
Ok. Bon le coup de la Freebox, ça ne m'intéresse que moyennement, mais merci pour le tuyau 😉

Mais quid de fusefs ? C'est multi-threadé ? J'arrive pas à trouver d'infos consistantes sur le Net... Et à priori, fusefs devrait marcher sur hubiC.
Connais pas fusefs...

Là j'essaye avec gvfs, il marche bien (c'est ce qu'utilise Nautilus) puisque c'est le machin de Gnome, mais la documentation est vraiment à chier... c'est à dire inexistante, il n'est même pas dans le 'man', et lancé avec --help, c'est plutôt laconique !

Avec gigolo, on peut faire un montage visible de Nautilus, et même en faire un signet, mais mon besoin c'est d'y accéder en ligne de commande, ce que ne permet pas la chose (ou je n'ai pas la doc pour le faire).

Si le seul besoin est d'y accéder via Nautilus, Gigolo, un signet, montage, et voila !
Mais comme on n'y a pas accès via un montage "normal", du coup pas possible de faire du encfs par dessus :/
Ok. C'est ce que j'ai fait, mais le coup du cache m'embête. Je vais essayer de voir si on peut utiliser un "FS réseau" multi-threadé avec Nautilus.
Avec Nautilus et sans encfs, oui, c'est natif et ça utilise gvfs (module DAV).

Il suffit d'aller dans "Aller à/Emplacement" et donner les coordonnées de ton montage. Ensuite tu mets un signet si tu veux éviter d'avoir à retaper à chaque fois.

Par contre, comme expliqué plus haut, ce n'est pas un réel "montage", mais plutôt un montage au sens Gnome (GIO) qui est donc inutilisable de programmes tels que VLC (par exemple pour lire ta musique directement).
Bien sûr, le contournement consiste alors à copier le fichier de musique sur le disque local et l'y lire... mais c'est moche !

Donc tout dépend de ton "use case" (c'est à dire de ce que tu veux faire exactement) qu'il faut bien que tu précises. Une fois que tu as fait le travail de préciser exactement ce que tu veux faire de ce montage, en général tu as à moitié trouvé la solution !..

Ne confondons pas "solution" et "besoin" ! Le post d'origine ici parle d'empiler un accès DAV avec ENCFS, c'est bien particulier. Si ce n'est pas exactement ce besoin que tu as... eh bien il y a des solutions bien plus simple.
2 mois plus tard
Lut,

je déterre un peu le topic.

J'ai pus faire une synchro via DAVFS. Pas de problème mais pour le cryptage ? encrypt m'oblige à avoir une version en claire sur mon DD ce qui me fait doublons.... PAs moyen de faire du lucks ?
llaumgui wrote:Lut,

je déterre un peu le topic.

J'ai pus faire une synchro via DAVFS. Pas de problème mais pour le cryptage ? encrypt m'oblige à avoir une version en claire sur mon DD ce qui me fait doublons.... PAs moyen de faire du lucks ?
Non, les fichiers "en clair" sont une vision théorique, ils ne sont stockés nulle part !
En réalité il est bien évident qu'à un moment donné tu as eu le fichier "en clair"... il a bien fallu que tu le sauvegardes et le chiffres ! Mais une fois chiffré, tu peux supprimer la version "en clair" si ça te chante (et si tu as confiance !).

Encfs fonctionne à partir du répertoire chiffré, qui lui doit exister (en local ou à distance si tu fais comme indiqué sur ce post) et te donne une vision "en clair", mais cette vision est juste la traduction de encfs et n'est réellement stockée nulle part même si ça apparaît dans ton arborescence.

Luks... bah non c'est pas du tout cet usage là !