[1fichier] "Montez" votre stockage 1fichier en une commande simple !

Zakhar · Le 03/02/2019, à 08:50

(3 février 2019) Version 1.0.2

Nouveautés par rapport à la 1.0.0

Fix : rare "race condition" qui peut provoquer l'affichage d'un répertoire vide à tort.
Modification API : l'API pour récupérer l'espace libre a été limitée à 1 appel toutes les 5 minutes.
Optimisation : suppression des locks en écriture, on se base sur l'état du serveur.
Optimisation : suggestion team 1fichier, le rafraîchissement de l'espace libre n'est demandé que si nécessaire.
Fonctionnalité : possibilité de créer un répertoire
Documentation : enrichissement des pages du manuel pour expliquer les nouveautés et les effets de bord possibles.

IMPORTANT
Il serait étonnant que vous soyez tombé dans le "bug" signalé (race condition), il est cependant important de mettre à jour la version pour la modification que 1fichier a fait de l'API permettant la récupération de l'espace libre.
En effet, la limitation à 1 appel par 5 minutes de cette API a été faite suite à des abus.

1fichierfs était déjà optimisé pour ne pas appeler cette API à tort et à travers, mais de fait elle était appelée : à chaque opération d'écriture (renommage, suppression, etc...) et à chaque refresh (par trigger, par temps, ou suite à une erreur récupérée). Cela pourrait alors vous faire passer pour quelqu'un qui "abuse" dans ces cas d'usage particulier, avec un possible bannissement temporaire de votre IP.
La présente version de 1fichierfs respecte la limitation qui vient d'être mise : même si un rafraîchissement a été demandé, l'API ne sera pas appelée de nouveau si elle a déjà été appelée dans les 5 minutes précédentes.
Pour les détails des possibles effets de bord transitoires, vous pouvez consulter le manuel.

Dernière modification par Zakhar (Le 03/02/2019, à 08:55)

jaxx21 · Le 04/02/2019, à 08:22

Merci à toi pour la mise à jour. Ca évitera le ban temporaire.

Zakhar · Le 05/02/2019, à 18:47

Mais cette API (pour récupérer les quotas) est décidément bien instable ! Ce soir elle ne rend plus les quotas...
Le côté positif c'est que ça teste la branche du programme qui vérifie que le JSON est bien ce qu'on attend. Comme ce n'est pas le cas, le programme se comporte ainsi que programmé, c'est à dire qu'il dit qu'il y a un espace libre de 0 sur 2To, et continue son travail normalement.

Ça me rassure sur ces parties du codes qui ne sont testées qu'en cas de comportement "bizarre" du serveur !

La log système est aussi normale pour la réponse inattendue du serveur :

$ grep 1fichierfs /var/log/syslog
Feb  5 18:25:08 zakhar-PC 1fichierfs: [1fichierfs     0.826159] ERROR: Unexpected/Ignoring: did not find cold_storage key in json response (URL=https://api.1fichier.com/v1/user/info.cgi)

Edit :
La team 1fichier vient de répondre (super rapide !) qu'effectivement c'était en refonte, et ça devrait être livré demain.
Je coderai les éventuelles modifications ce W.E., et en attendant on vivra avec un driver qui prétend qu'il n'y a pas d'espace libre.

Dernière modification par Zakhar (Le 05/02/2019, à 18:58)

Zakhar · Le 09/02/2019, à 19:15

(9 février 2019) Version 1.0.4

Nouveautés par rapport à la 1.0.2

Fix : réparation de la version 32bits. (Si vous utilisez la 64bits, vous n'êtes pas concernés).
Modification API : l'API pour récupérer les quotas a été totalement refondue, elle semble désormais logique et stable. Le programme a été adapté pour nouvelle API.
Amélioration : les tailles maximales/libres retournées sont plus logiques, tenant compte du hot_storage.
Amélioration : protection du fichier refresh contre les effacements, renommage, etc...
Modification ATTENTION : le refresh-time est désormais en minutes. Cela évite de créer du spam avec un refresh-time trop bas et de risquer le bannissement.
Documentation : mise à jour des pages du manuel pour expliquer les nouveautés.

La mise à jour va vous faire récupérer la fonctionnalité de restitution de l'espace libre et consommé.
En effet, l'API utilisée a changé deux fois... mais là ça semble être bon.
Le retour est plus logique, l'espace total est calculé ainsi : hot + cold autorisé
L'espace disponible est : cold autorisé - cold (ou zéro si cold est déjà au dessus de cold autorisé)

ATTENTION : comme expliqué dans le "changelog", si vous utilisiez le paramètre --refresh-time, veuillez noter qu'il est désormais en minutes.

Donc si vous lanciez avec :

--refresh-time=1200

Ce qui était précédemment 1200 secondes (donc 20 minutes), il faut désormais lancer avec :

--refresh-time=20

Pour avoir le même effet.

Cette modification a été faite pour éviter que vous ne génériez du 'spam' en appelant trop les APIs ls.cgi, si vous aviez voulu mettre un paramètre trop bas comme 1 seconde, et ainsi être banni temporairement.
Le minimum de rafraîchissement est donc désormais à 1 minute (car zéro veut dire pas de rafraîchissement), ce que la team 1fichier considère comme "raisonnable".

Dernière modification par Zakhar (Le 09/02/2019, à 21:03)

Zakhar · Le 23/02/2019, à 11:46

(23 février 2019) Version 1.0.5

Nouveautés par rapport à la 1.0.4

Modification API : l'API pour renommer les répertoires est enfin complète (à ma suggestion). Le programme peut donc désormais renommer/déplacer des fichiers ou des répertoires.
Amélioration : sur la gestion des permissions, prise en compte des options noexec, nosuid.
Bugs mineurs : sur la gestion du refresh après une opération d'écriture en cas d'erreur.

La mise à jour est mineure, il n'y a pas d'urgence à la faire si vous n'aviez pas l'intention de renommer/déplacer des répertoires.
Les bugs mineurs sur le "refresh" sont contournables en forçant le rafraîchissement.

C'est cependant la version "complète"... en attendant la "future direction" ci-dessous.

Future direction :
La partie écriture en montant une "union" fonctionne unitairement via un script, mais ce n'est pas très pratique ni très stable.
En effet, aufs ne comprend pas très bien qu'on ait un filesystem sensé "read-only" qui peut toutefois faire des opérations d'écriture.

La direction future est donc d'inclure l'option écriture.
Compte tenu des possibilités de l'API, la seule façon "réaliste" de le faire passe par une écriture sur un support local puis un "upload" une fois que le fichier a été fermé.
On pourrait se passer de cela si le FTP était accessible via la clé d'API (ma suggestion) mais ce n'est pas le cas actuellement.

Soyez patient pour la partie écriture... ça prendra un peu de temps !

Dernière modification par Zakhar (Le 23/02/2019, à 12:04)

jaxx21 · Le 27/02/2019, à 17:16

Merci pour tes avancés. J'ai réinstallé ton script sur un vps en 2 ou 3 lignes à partir de ton ppa et tout fonctionne niquel.

sudo add-apt-repository ppa:alainb06/astreamfs
sudo apt-get update
sudo apt-get install 1fichierfs

ca met la dernière version en date il me semble que tu avais dit.

Donc, pas de crash, ca tourne impec.Rapide dans plex. Le Rename, et surtout le "delete", une tuerie, car j'avais pas mal de sous dossier, et sur leur site direct, ça voulais pas effacer a cause de dépendance qu'il disent, même si tous les dossiers étaient vides. Trop naze. Que la, par FTP, je vais dans le dossier 1fichier et boom.je delete tout. Ils ont appliqué la règle du 2 To de cold storage, ils m'ont effacé (après plusieurs relance) plusieurs To. Donc très utile le delete de dossiers vides..

Merci pour ton travail acharné

Zakhar · Le 27/02/2019, à 18:34

C'est pas fini car il y a encore des modifications de l'API... enfin, ça va dans le sens de la simplification du driver, donc c'est tout bon !..

Oui, ils ont activé les "quotas". Personnellement je ne conserve pas les films de vacances de Tonton Jules que j'ai déjà visionnés, donc je n'ai pas le problème.

Après, un des disques de mon NAS donne des signes de faiblesse, et les prix au To qu'ils facturent sont très "raisonnables" quand on compare à racheter un disque, et gérer un NAS + électricité et tout le tintouin. Donc quand la partie écriture sera à peu près opérationnelle, je songe à prendre une "extension" pour y mettre mes sauvegardes. On verra !..

jaxx21 a écrit :

ca met la dernière version en date il me semble que tu avais dit.

Oui c'est bien ça. Tu peux le vérifier en faisant :

$ 1fichierfs -V
Copyright (C) 2018-2019  Alain Bénédetti
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under the conditions of the GPLv3 or later, at your convenience.
Full license text can be found here: https://www.gnu.org/licenses/gpl-3.0.html

1fichierfs: version 1.0.5
FUSE library version: 2.9.4
fusermount version: 2.9.4
using FUSE kernel interface version 7.19

Tu dois avoir la version 1.0.5 de 1fichierfs.
Les versions de FUSE library et fusermount et kernel sont peut-être différentes de celles affichées ici, qui sont celle de ma Ubuntu 16.04LTS

jaxx21 a écrit :

Que la, par FTP, je vais dans le dossier 1fichier et boom.je delete tout.

Ah, tu veux dire que tu accèdes en FTP aux fichiers de ton serveur.
Mais oui, quel que soit le mode d'accès (SSH, FTP, partage réseau, ...), si tu supprimes un répertoire ça va automatiquement supprimer aussi tout ce qui est dedans récursivement, et le driver s'occupe de passer les bons appels d'API pour faire ça sur ton compte 1fichier.
Dans le cas d'une grosse arborescence à supprimer c'est effectivement infiniment plus pratique que sur l'interface web où tu ne peux supprimer qu'un répertoire vide.... et il faut donc commencer au plus profond de l’arborescence en supprimant manuellement les trucs 1 par 1... pénible !

Dernière modification par Zakhar (Le 03/03/2019, à 18:57)

Zakhar · Le 09/03/2019, à 10:07

(9 Mars 2019) Version 1.0.8

Nouveautés par rapport à la 1.0.5

Modifications API : les 3 opérations concernées -mv fichiers et répertoires- et liens durs sont désormais atomiques dans tous les cas. Le programme est adapté.
Documentation : la documentation est mise à jour pour refléter cela -c'est une simplification, plus besoin d'expliquer la non-atomicité !..
Bugs mineurs documentation : les exemples de la documentation dataient d'avant le changement de refresh-time en minutes. Correction faite.

Sauf si vous faites beaucoup de renommages (liens durs...) il s'agit d'une version mineure.
L'API reste rétro-compatible avec les versions de 1fichierfs précédentes.

Dernière modification par Zakhar (Le 09/03/2019, à 10:08)

Zakhar · Le 27/03/2019, à 21:47

[Information]

L'API est H.S. depuis hier, mardi 26 mars 2019 autour de 21:30 (HTTP 502). Donc déjà 24h de panne à l'heure de ce post.
Pas de nouvelle de la team 1fichier sur le retour en fonctionnement.
Le driver générique (astreamfs) fonctionne toujours parfaitement, avec l'aide du script joint, mais bien sûr n'offre pas les fonctions suppression, renommage, etc...

[Edit] API en fonction à nouveau - Jeudi 28 mars 2019 - 7:30.

Dernière modification par Zakhar (Le 28/03/2019, à 07:31)

Zakhar · Le 28/03/2019, à 21:07

(24 Mars 2019) Version 1.0.9

Nouveautés par rapport à la 1.0.8

Modifications API - Optimisation majeure : l'API listant les sous-répertoires d'un répertoire donné, permet désormais de récupérer aussi les fichiers contenus dans ce répertoire. Cela permet une optimisation majeure : pour lister le contenu d'un répertoire, on passe de deux requêtes à une seule. La différence de vitesse est très notable quand on affiche l'arborescence avec un navigateur de fichier ou autre.
Optimisation : les algorithmes de suppression et renommage ont été améliorés pour ne pas rafraîchir les répertoires quand ce n'est pas nécessaire. L'amélioration sera particulièrement visible si on supprime un grand nombre de fichiers dans un même répertoire.
Bug mineur : la date des répertoires n'était pas récupérée depuis le serveur. Correction effectuée.
Amélioration (résilience) : il y a désormais un time-out de connexion à 30 sec. Cela évite de trop attendre en cas de panne de la liaison ou du serveur.

Pas de corrections majeure, mais les optimisations réalisées grâce aux changement des APIs valent le coup de faire la mise à jour. Le driver est visiblement bien plus réactif pour le listage et le parcours de arborescence, ou quand on a beaucoup de suppressions à faire.

Piste future (avant la partie "write") : l'optimisation sur la lecture des répertoires + fichiers va permettre une simplification majeure de l'organisation de la gestion de l’arborescence. Cela n'apportera pas de fonctionnalité, mais permettra d'avoir un programme plus simple, donc plus maintenable, et avec moins de bugs potentiels.

Dernière modification par Zakhar (Le 28/03/2019, à 21:10)

lynn · Le 28/03/2019, à 21:36

Bonjour Zakhar,

J'ai mis à jour mon système et la version de 1fichierFS est passée de 1.0.8 à 1.0.9 mais par contre, j'ai l'erreur suivante :

[1fichierfs     0.235853] ERROR: Ignoring: did not find "items":[{...}] for `/` (id=0)!

Ma ligne de montage

1fichierfs -o --api-key=@${_key},refresh-file=000_refresh.txt,refresh-time=2 "${_mount_point}"

Que dois-je faire (ou ne pas faire...) pour que ça refonctionne ? Merci.

Zakhar · Le 28/03/2019, à 22:03

Est-ce bloquant ?
En principe l'erreur est juste journalisée.
Je jette un oeil.

[Edit] Oui je vois... si ça se produit sur la racine, ça va bloquer. Le contournement en attendant que je corrige, c'est simplement de mettre un fichier quelconque à la racine, ainsi l'erreur n'arrivera pas.
Une fois que ce sera corrigé, tu pourras enlever le fichier qui permet de countourner le bug.
Désolé !

Merci du signalement.

[Edit 2]
... mais en fait c'est très étrange, ce bug ne peut arriver que si le répertoire concerné est totalement vide. Je l'ai sur un de mes répertoires de test qui est totalement vide.
Mais il n'est bloquant que sur la racine. Donc si tu rencontres le bug, ça veut dire que ta racine est totalement vide... et dans ce cas je ne vois pas bien l'intérêt de monter le truc... sauf effectivement pour m'aider à debugger, ce qui est louable !

Peux-tu me dire si tu es dans ce cas ?

[Edit 3] Comme cette partie de code disparaîtra avec le remaniement annoncé, je vais juste mettre en WARNING au lieu de ERROR, ce qui rendra le message non bloquant dans tous les cas.

[Edit 4] Comme je vois que tu as mis un "refresh" très court, assorti d'un fichier de refresh, c'est peut-être effectivement un cas d'usage d'avoir un stockage cloud vide, y copier à l'instant T la vidéo de vacances de Tonton Jules, regarder la vidéo en stream, puis la supprimer du cloud une fois vue. Dans ce cas, effectivement, le montage + rafraîchissement est utile même quand on a parfois un stockage vide. Effectivement, cet usage n'était pas prévu/testé !

En tout cas la modification rapide est faite et packagée. Désormais tu devrais juste avoir un warning sans conséquence, même en cas d'usage de stockage distant vide.

Il faut attendre quelques minutes que les serveurs du PPA compilent et mettent en ligne la version, et tu devrais pouvoir à nouveau faire un update/upgrade.
C'est la version 1.0.9.1

La modification cite Lynn@ubuntu et explique brièvement le cas.

[Edit 5] PPA a fini son travail, tu peux faire l'update.

Dernière modification par Zakhar (Le 28/03/2019, à 23:01)

lynn · Le 29/03/2019, à 06:49

Le stockage me sers surtout de façon temporaire et c'est vrai quand je n'en ai plus besoin il est souvent vide.

Merci pour la résolution (très rapide) du bug.

Zakhar · Le 29/03/2019, à 18:24

Pas de problème Lynn !

Je mettrai dans les tests ton cas d'usage d'un stockage potentiellement vide. Ce sont des cas "aux limites" auxquels on ne pense pas forcément quand on développe.

Zakhar · Le 06/04/2019, à 12:53

(6 Avril 2019) Version 1.0.10

Nouveautés par rapport à la 1.0.9

Modifications API - Simplification majeure : suite à la modification de l'API de listage des répertoires (cf 1.0.9 ci-dessus), une simplification majeure sur la façon de récupérer la liste de fichiers a été réalisée dans le programme.
Bug mineur : en cas d'erreur 403 sur l'API permettant de lire l'espace disponible, dans certains cas cette donnée n'était plus jamais mise à jour. L'algorithme a été complètement revu, cela devrait désormais se mettre à jour dans tous les cas (au bout de 5 minutes, contrainte de l'API 1fichier).
Amélioration (résilience) : dans le cas improbable (et normalement "impossible"...) où la taille du fichier ne correspond pas à ce qu'on a en cache, le programme ne se met pas à boucler en demandant des tickets de téléchargement.
Documentation : corrections mineures dans le manuel (français et anglais).

Dois-je mettre à jour ?
La présente version n'apporte aucune nouvelle fonctionnalité (sauf correction du bug mineur signalé).
C'est juste la fin du "nettoyage" consécutif au changement de l'API de listage des répertoires. Malgré les évolutions (bug mineur corrigé, meilleure résilience), le programme s'est réduit d'une 100aine de lignes tant la simplification apportée par cette nouvelle API est majeure.
Moins de code = moins de bugs potentiels... c'est toujours bon à prendre !..

Donc en résumé, hormis si vous avez constaté le bug mineur signalé, la mise à jour est totalement facultative.

Dernière modification par Zakhar (Le 06/04/2019, à 12:56)

bingox · Le 02/05/2019, à 04:03

Merci pour ton projet , mais peut on utiliser 1fichierfs avec windows ? a l'aide de winfsp http://www.secfs.net/winfsp/ par exemple (fuse pour windows)

et pour les autres distro ?

Dernière modification par bingox (Le 02/05/2019, à 04:05)

Zakhar · Le 02/05/2019, à 12:20

Bonjour Bingox, et merci pour ton intérêt envers mon projet.

Pour les autres distributions, il s'agit de compiler à partir du source. Les explications sont sur le premier post. Le code source est disponible sur mon Gitlab.

En gros ça fait 3 commandes :
- 1 pour récupérer le code (git clone)
- 1 pour récupérer les libraires pour compiler (fuse et curl, via apt sur les debian-like ou dnf sur le Red-hat like)
- 1 commande pour compiler (make)

De façon non officielle, si tu parles d'une autre distribution Ubuntu que les LTS, tu peux toujours essayer de récupérer le .deb du PPA et tester s'il marche. C'est cochon, mais il n'y a pas tant de différence que ça d'une version à l'autre et parfois c'est Ok de faire ainsi.

Pour ce qui concerne les autres OS, j'ai cité l'existence d'un équivalent très proche de fuse sur Mac, et merci pour l'indication de l'existence d'une tentative de copier les bonnes choses sur l'OS de Redmond.

Malheureusement, je n'ai pas de Mac, et j'ai éradiqué les O.S. propriétaires de mon informatique personnelle depuis des lustres. Il s'ensuit que je n'ai aucune compétence en la matière.

Aussi, compte tenu de la politique de racket toujours pratiquée par Redmond, je n'ai pas du tout l'envie de m'y mettre, d'autant que ça ne m'est d'aucune utilité, et donc ne me "rapporte" rien... Je ne fais bien sûr pas ce projet pour que ça me "rapporte", je le fais avant tout parce que ça me plaît de le faire, et que ça me permet d'avoir des fonctionnalités qui m'intéressent et ne sont disponibles nulle part ailleurs. Donc quelque part, ce que mon propre projet me "rapporte", ce sont ces fonctionnalités. Mais précisément, le faire sur l'O.S. propriétaire ne me "rapporterait" même pas ça, vu que je ne l'utilise plus depuis des années.

On voit également que Redmond n'a plus de compétences techniques, il ne font que de la "décoration". Le dernier exemple en date est Edge dont le moteur est désormais Chromium. Il ne reste donc d'Edge que l'interface utilisateur (la déco !). Et c'est sage de leur part de rester dans leurs compétences. Dans la même veine, ils ont introduit dans 10 le WSL, Subsystem For Linux. J'ignore la complétude de ce travail, un "Wine" inversé (trop drôle et symptomatique), mais si tu as moyen d'avoir WSL, si ça se trouve mon projet marche directement sans aucune re-compilation, et c'est sans doute alors la façon la plus simple !
Après, est-ce que l'univers Linux ainsi ouvert par WSL est accessible au reste de la machine... je te laisse regarder et nous faire un retour.
Ce serait intéressant d'avoir ce témoignage, ne serait-ce que pour faire progresser notre connaissance collective !..

Maintenant, le source est ouvert et disponible à tous. Donc si tu veux faire une tentative avec la librairie que tu cites, et encore merci pour l'information, ce serait avec plaisir que je t'aiderai s'il y a des écueils non spécifiques aux O.S. propriétaires (qui sont aussi fort mal documentés si on veut faire ce genre d'outils).

S'agissant de GPL, ton travail devra aussi être en GPL bien sûr... désolé pour le "cancer" !..

En fait, une fois que je serai satisfait du travail (de gros morceaux sont encore en devenir), je vais peut-être regarder pour d'autres O.S., mais la priorité sera à Android qui est bien plus pertinent pour un tel logiciel. Par exemple introduire la fonctionnalité dans VLC (qui propose déjà d'autres clouds), l'OS propriétaire que tu cites étant de plus en plus exclusivement en entreprise, les particuliers se satisfont de mieux en mieux du smartphone seulement (il est vrai que ce dernier fait de plus en plus de choses).

Dernière modification par Zakhar (Le 02/05/2019, à 12:38)

bingox · Le 05/05/2019, à 13:13

Bonjour , je ne sais pas si tu connais rclone mais c'est un super outil ! , il donctionne comme rsync pour cloud storage , il y a 2 jours quelqu'un a fait un pull request dans le github du projet pour ajouter 1fichier : https://github.com/ncw/rclone/pull/3162 , j'ai testé et ca marche , mais quand je monte 1fichier et j'essaie de streamer , j'ai pas la possibiliter de seek , donc juste la possibilite de regarder depuis le debut , peux tu jeter un coup d'aoeil sur le pull request stp ?

Zakhar · Le 05/05/2019, à 14:17

Bonjour Bingox,

oui je vois le principe.

Mais justement, mon projet évite d'avoir à faire ce genre d'intégration !

rclone cherche à intégrer tout un tas d'accès distants dans son logiciel. L'intégration de ces accès distant ne permet donc qu'une chose : utiliser les fonctionnalités de rclone.
Quand tu as un logiciel qui fait autre chose, il faut recommencer l'intégration !..

La "philosophie" de 1fichierfs, a l'instar des principes Unix/Linux, est à l'opposé. 1fichierfs réalise juste un "montage" générique mais ne fait aucune fonctionnalité particulière. L'utilisateur peut ensuite utiliser ce montage générique pour faire ce que bon lui semble... dont utiliser rclone avec le mode "The Local Filesystem"... puisque une fois le montage réalisé, les fichiers apparaissent comme "locaux" depuis un logiciel lancé en userspace.
Cette "architecture" en couches est à mon sens plus polyvalente et permet davantage de choses. Le seul avantage (potentiel) de l'intégration spécialisée est éventuellement une optimisation, car on n'implémente que les fonctions nécessaires au logiciel intégrateur.

C'est donc l'alternative que je te propose :
- tu fais un montage avec 1fichierfs
- si tu veux utiliser rclone, tu utilises le mode "The Local Filesystem".

Personnellement, je n'ai aucune difficulté à répliquer ma sauvegarde distante (mes CD audio que j'ai patiemment reapé!) vers un support local avec rsync.

Commande :

rsync -a --delete -v  /home/zakhar/Secure/Musique/ /mnt/Cold/Divers/Musique/

Il faudrait cependant que tu expliques ce que tu veux faire (par exemple dans quel sens tu copies, etc...) parce que évidemment, le montage hérite des limitations du cloud qui le supporte.

Limitations :
- Essentiellement c'est du read-only (pour le moment)
- Sauf si le montage est fait explicitement en read-only, on peut cependant en plus supprimer fichiers/répertoires, renommer/déplacer fichiers/répertoires, faire un lien (dur) sur une fichier.
- Les dates des fichiers sont celles de l'enregistrement sur le serveur.
- Les droits d'accès sont simulés. Ils sont calculés à partir des droits d'accès du répertoire de montage, et de paramètres comme le umask, ou le fait qu'on soit en read-only forcé ou pas.

Sécurité :
Pour une utilisation d'un "cloud" en mode "sauvegarde", je recommande évidemment de chiffrer la sauvegarde !
Il ne faut pas être naïf au point de faire confiance aux clouds qui vous promettent de chiffrer eux-mêmes... s'ils le font, ils ont la clé de chiffrement/déchiffrement, et donc les données ne sont plus secrètes pour le prestataire ou un de ses employés indélicats.
En réalité, il faut que vous chiffriez vous-mêmes, avec une clé qui vous est propre et que vous conservez bien soigneusement.

Pour cela j'utilise encfs, monté par dessus 1fichierfs.

Pour des raisons de sécurité avec encfs, il faut que vous conserviez localement le fichier .encfs6.xml qui contient nombre d'informations sur les paramètres de chiffrement. Stocker ce fichier en même temps que vos sauvegardes sur le cloud pourrait faciliter les attaques de déchiffrement par force brute.

La commande de montage est donc par exemple :

ENCFS6_CONFIG=/home/zakhar/.config/.1fichier_encfs6.xml  encfs /home/zakhar/1fichier/.crypt/ /home/zakhar/Secure/ --extpass="secret-tool lookup encfs passwd"

Dans cette commande, j'ai utilisé secret-tool qui permet d'enregistrer la "phrase de passe" (une 40aine de caractères !) dans le trousseau de clés Gnome et de le déverrouiller avec le mot de passe de session. Vous pouvez plus simplement taper le mot de passe quand encfs vous le demande.

Cela explique la commande rsync ci-dessus.
Mes sauvegardes sont dans ~/Secure, qui est fait la version en clair de ~/1fichier/.crypt

Ainsi ne sont stockés sur 1fichier, sous le répertoire .crypt, que des fichiers et répertoires aux noms cabalistiques, et tout cela est chiffré.
On est ainsi protégé du fournisseur de cloud lui-même, et/ou de ses éventuels employés indélicats.

Vous voyez bien, faire tout ceci avec rclone devient déraisonnable.
Avec l'architecture "en couche", il n'y a aucun problème, on empile les couches :
- Montage 1fichierfs
- Montage encfs
- rsync (ou tout logiciel local comme vlc, rythmbox pour ma musique sauvegardée, etc...)

Vu des logiciels locaux, il n'y a aucune "implémentation spéciale" à faire puisque les fichiers apparaissent comme locaux !

Inconvénient : on ne peut bien sûr plus utiliser les fichiers déposés sur le cloud avec les outils que proposerait le fournisseur de cloud (visualisation, suites comme Google Doc), puisque précisément les fichiers que le fournisseur de cloud voit ne sont qu'une suite d'octets sans significations, avec des noms de fichier bizarres.

P.S.: quant au pull, désolé... Python n'est pas mon fort, j'arrive juste péniblement à le lire. Bon oui, j'ai corrigé un bug en Python dans apparmor. La correction a été diffusée dans les releases suivantes d'Ubuntu... mais c'était l'exception !.. Je n'ai aussi plus de compte chez GitHub, je me suis dépêché de migrer vers GitLab lorsque Redmond a mis la main dessus ! Et en tout cas bon courage si tu parviens à faire l'intégration.

P.S.2: je compatis si tu es contraint d'utiliser la soupe de Redmond. L'architecture "en couche" n'est pas son fort... même l'architecture tout court car rien de fondamental n'a changé depuis XP où ils étaient vraiment à leur sommet. Exemple, NTFS (on ne devrait jamais mettre "New Technology" dans l'acronyme !) a soufflé ses 25 bougies en juillet dernier... et à part des sous-versions, rien de bien nouveau sur une brique aussi fondamentale que le filesystem !..
Les seules évolutions sont mineures ou cosmétiques. Des outils tels que fuse qui permettent précisément de tirer la pleine puissance du modèle en couche sont par contre légion chez le Pingouin (oui, c'est un manchot) !..
Si donc telle est ta contrainte, je comprends alors rclone, puisque c'est du python-passe-partout... et compatis à ta douleur !

P.S.3 : as-tu essayé avec WSL ? Le résultat pourrait être intéressant !.. Mais WSL est peut-être réservé à la version "entreprise"... ceux qui sont encore assez fous pour payer un O.S., et je comprendrais que tu n'aies pas envie de claquer 200€ pour faire un test ! Vive le logiciel propriétaire.

Alternative gratuite : donc si WSL n'est pas une option compte tenu du prix, Linux étant libre et dans la plupart des cas gratuit (avec des exceptions comme Red Hat utilisé en entreprise), tu peux faire deux choses :
-1) Utiliser une clé USB avec un Linux bootable pour faire ta synchro
-2) Installer VirtualBox (c'est libre et gratuit-non-libre pour les add-ons)
- Mettre la version Linux de ton choix dans VirtualBox (je te conseille Ubuntu 18.04 si tu n'as pas envie de compiler 1fichierfs)
- Depuis ton Linux virtualisé, tu fais un montage du répertoire de ton hôte vers lequel tu veux synchroniser (ça se fait "à la souris" dans Configuration/Dossier Partagés de ta VM... pas besoin de commande !)
- Tu peux alors installer 1fichierfs et utiliser à ton choix rclone ou rsync (natif) pour réaliser ta synchro descendante, et ce sans quitter ton O.S. hôte, mais en y lançant juste la machine Virtuelle.
(C'est le modèle "en couches" tu vois Host/VM/Linux/Montage vboxsf/Montage 1fichierfs/Outil de synch !.. et en bonus tu te familiariseras un peu plus avec Linux... ça vaut des sous sur un CV )

Dernière modification par Zakhar (Le 05/05/2019, à 15:04)

xxx31fr · Le 06/05/2019, à 20:27

Zakhar a écrit :

Bonjour Bingox,
- Tu peux alors installer 1fichierfs et utiliser à ton choix rclone ou rsync (natif) pour réaliser ta synchro descendante, et ce sans quitter ton O.S. hôte, mais en y lançant juste la machine Virtuelle.
(C'est le modèle "en couches" tu vois Host/VM/Linux/Montage vboxsf/Montage 1fichierfs/Outil de synch !.. et en bonus tu te familiariseras un peu plus avec Linux... ça vaut des sous sur un CV :D)

Hello,
Le coup de "ça vaut des sous sur un CV", rajoute alors le clutering/provisioning/scripting et là ça deviendra intéressant.

J'ai par contre une galère avec FUSE qui est utilisé par rclone et consort pour monter un stockage cloud comme une disque réseau.
je cherche un moyen pour faire du torrent directement sur du Google drive.
le problème avec le montage FUSE, c'est que ça fait sauter le point de montage quand je veux faire du torrent, et y a pas de remount auto.
vous n'avez pas une petite idée de comment résoudre ce problème?

cordialement,

Dernière modification par xxx31fr (Le 06/05/2019, à 20:29)

Zakhar · Le 06/05/2019, à 20:40

xxx31fr a écrit :

J'ai par contre une galère avec FUSE qui est utilisé par rclone et consort pour monter un stockage cloud comme une disque réseau.

C'est probablement pas fuse, mais le driver qui plante !
Par exemple, très étrangement, encfs crashe de façon systématique quand on essaye de lire un .mp4, tandis que quand on lit un .mkv tout va bien.
Sans doute qu'avec un .mp4, la séquence des ordres de lectures fait tomber le driver dans un état inconnu et c'est donc un bug. A l'occasion, il faudra que je le signale... s'il y a encore quelqu'un qui corrige encfs !..

En l'occurrence, pour le problème que tu cites xxx31fr, c'est sans doute un bug de driver de Google Drive qui plante le truc. Donc le mieux, si tu sais reproduire, c'est de signaler le bug aux auteurs de ce driver fuse.
Tu peux sinon tenter un script de remontage, mais le mal sera fait, ton torrent aura été coupé et peut-être dans un état instable si le driver a écrit la moitié des choses avant de se planter.

Aussi, les stockages cloud ne sont pas fait pour ce genre de chose. L'écriture sur un stockage cloud se fait en un bloc (par objets), tandis que torrent va écrire des petits bouts dans tous les sens, donc faire du "random write". Ce n'est alors vraiment pas l'idéal d'utiliser un cloud pour ce genre d'usage. Au mieux ça sera horriblement lent !..

Par contre pour la partie échange, ça ne pose pas de problème. Par exemple, j'ai laissé les iso d'Ubuntu en partage Torrent sur ma Freebox jusqu'à un quota de 100 en up, et faire ça sur un cloud ne poserait pas (trop) de problème vu qu'on est encore en lecture. Mais le fait que ce soit de la lecture aléatoire n'arrangerait pas les choses !..

xxx31fr a écrit :

Hello,
Le coup de "ça vaut des sous sur un CV", rajoute alors le clutering/provisioning/scripting et là ça deviendra intéressant.

Ah oui, le "développeur full-stack" ! ;-)

Dernière modification par Zakhar (Le 06/05/2019, à 20:41)

bingox · Le 07/05/2019, à 10:21

@Zakhar , lors de l'audit de encfs on a trouvé des failles , vaut mieux chercher un alternatif : https://nuetzlich.net/gocryptfs/comparison/

@xxx31fr evite le torrent avec google drive ca ne va pas marcher (limite api) , prends une seedbox si tu veux seeder

Dernière modification par bingox (Le 07/05/2019, à 10:26)

Zakhar · Le 07/05/2019, à 18:29

bingox a écrit :

@Zakhar , lors de l'audit de encfs on a trouvé des failles , vaut mieux chercher un alternatif : https://nuetzlich.net/gocryptfs/comparison/

Merci pour le lien, très intéressant.

On parle beaucoup de "problèmes de sécurité" pour encfs... mais personne ne les décrit vraiment.

Ces "problèmes" ne sont d'ailleurs pas cachés, puisque si tu l'installes en console (apt get install encfs) tu as un gros message te l'indiquant. Mes connaissances en crypto sont trop superficielles pour vraiment juger de la pertinence de ces "failles". De ce que ça a l'air d'expliquer, il faut que l'attaquant observe les fichiers et leurs modifications successives. Un usage "standard" cloud en sauvegarde simple ne sera donc pas dans les conditions de ce risque. Le risque survient plutôt sur un répertoire local utilisé en lecture/écriture qui serait chiffré par encfs, avec un attaquant déjà sur la machine (... et si l'attaquant est déjà sur la machine... n'est-ce pas déjà "game over" ?)

Cependant, j'en comprends suffisamment pour déduire que si on met le .encfs6.xml au même endroit que les fichiers chiffrés (comportement par défaut), ça va bien sûr aider à casser les clés... dans certaines conditions. En effet, ce fichier est en clair et indique un certains nombre de choses sur la façon dont le chiffrement a été fait. Déjà il indique que c'est du encfs... et donc quelqu'un qui veut casser sait où chercher.

Donc précisément, c'est pourquoi j'ai recommandé de ne PAS utiliser le comportement par défaut, mais garder le fichier .encfs6.xml en local (ce qui est possible et documenté).

Maintenant, si j'avais à regarder une alternative, je pencherais plutôt vers ecryptfs qui a été intégré dans le kernel. Je m'étais mis un bookmark pour regarder d'ailleurs, mais pas encore eu le temps. Et c'est vrai, comme le dit ton comparatif : la documentation de ecryptfs n'est pas terrible !..

Bon, affaire à suivre en tout cas, et merci encore pour le comparatif. Si encfs me fait d'autres plantages plus sérieux, je songerai plus fermement à en changer.

P.S.: si tu cherchais une solution multi O.S., il me semble qu'il existe des portages de encfs aussi (sur Mac c'est évidemment trivial avec MacFuse) : https://encfsmp.sourceforge.io/

Dernière modification par Zakhar (Le 07/05/2019, à 18:35)

Zakhar · Le 11/05/2019, à 16:24

Bonjour, utilisateurs de 1fichierfs.

Non, le développement n'est pas arrêté pour le cas où vous vous le demandiez, la dernière version publiée ayant déjà plus d'un mois !

En réalité j'ai ouvert une branche pour l'écriture, mais en constatant que la team 1fichier a fait le minimum côté serveur pour cela, c'est très très galère de faire quelque chose de potable. Aussi, je l'ai mise de côté temporairement et me suis consacré à ré-architecturer une partie du code qui en avait besoin.

L'héritage avec astreamfs qui est purement "read-only" a ses limites y compris dans la façon dont on gère l'arborescence et la lecture des fichiers. Comme l’arborescence est dynamique dans 1fichierfs, l'architecture copiée de astreamfs avait un problème : quand un "refresh" était fait, les tickets de download ouverts étaient perdus. Ce n'est pas bien dramatique, mais ça fait des requêtes et du temps pour rien. Au milieu d'un film qu'on a mis en pause, ça peut contribuer à générer des "freeze".

Aussi, dans la période, il y a un lot de correction de bugs plus ou moins mineurs.

Au global, la version n'apporte pas de fonctionnalités majeures, mais devrait avoir moins de bugs mineurs et être plus réactive.

(11 Mai 2019) Version 1.1.1

Nouveautés par rapport à la 1.0.10

Bug mineur : l'argument -o subtype avait un bug (sauf si on laissait la valeur par défaut: 1fichierfs).
Bug mineur : les chaînes json postées n'étaient pas encodées. En pratique on ne pouvait donc pas renommer/lier sur des noms contenant '\' ou '"'. A noter que '\' est de toute façon refusé par le serveur via l'API, mais curieusement accepté sur l'interface web !.. Discordance signalée (et non corrigée).
Bug potentiel : 1fichierfs utilise maintenant essentiellement CLOCK_MONOTONIC_COARSE, ce qui le rend plus rapide, mais surtout insensible aux changements de date/heure provoqués par l'utilisateur qui auraient pu provoquer des effets bizarres.
Bug : le nombre de blocs occupés par un fichier n'était pas calculé. Ainsi certains utilitaires comme 'du' ou 'ls' donnaient des valeurs incohérentes selon les paramètres utilisés.
Bug : suite à un copier/coller abusif, l'utilisation de la fonction 'lien dur' (copie pour 1fichier) désactivait totalement le nettoyage différé du RCU. L'usage de cette fonction créait donc une fuite mémoire.
Amélioration (architecture) : séparation des données servant à l'affichage de l'arborescence et au streaming. Les "tickets de download" sont désormais bien conservés toute leur durée de validité. Aussi, le 'close' ('release' pour fuse) ne ferme pas le stream. Sur les petits fichiers (moins de 16k), cela a pour conséquences qu'ils sont relus en mémoire dans les 5 minutes suivant la fermeture, quel que soit le paramètre de cache du kernel. Les fonctions 'open' et 'close' ('release') sont maintenant sans lock. Aussi, l'empreinte mémoire est diminuée (en usage "normal") par ce changement, d'autant que l'on ne stocke plus toute la structure 'stat' sur les fichiers, mais seulement les 2 données utiles : taille et date de création.
Documentation : la documentation indique bien maintenant qu'en cas d'erreur sur un fichier celle-ci demeure tant qu'on n'a pas provoqué de refresh.

Faut-il mettre à jour : comme vous le voyez, pas de correction majeure, mais des optimisations et des corrections de bugs qui ne vous avaient peut-être pas gêné ! Donc c'est vous qui voyez.

Piste future: avant de reprendre la partie écriture, je vais sans doute regarder un //TODO assez ancien : les statistiques. Cela sera indispensable de toute façon pour la partie "write" : pour vérifier si l'écriture sur le serveur est bien achevée !..

Dernière modification par Zakhar (Le 11/05/2019, à 16:37)

jaxx21 · Le 17/05/2019, à 09:48

Vraiment un gros merci, tout est parfait. En effet l'écriture est très attendue, et je sais que c'est du gros boulot. Prend ton temps, Merci encore. Ton Api simplifie la vie. Plex tourne niquel avec
ha oui, as tu le nombre d'utilisateur qui utilise ton plugin? car seulement toi l'a fait. Quand il sera connu encore plus, faudra le faire monnayer meme si ce n'est pas la politique des coders/utilisateurs linux.

Dernière modification par jaxx21 (Le 17/05/2019, à 09:49)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 03/02/2019, à 08:50

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#52 Le 04/02/2019, à 08:22

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#53 Le 05/02/2019, à 18:47

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#54 Le 09/02/2019, à 19:15

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#55 Le 23/02/2019, à 11:46

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#56 Le 27/02/2019, à 17:16

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#57 Le 27/02/2019, à 18:34

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#58 Le 09/03/2019, à 10:07

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#59 Le 27/03/2019, à 21:47

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#60 Le 28/03/2019, à 21:07

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#61 Le 28/03/2019, à 21:36

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#62 Le 28/03/2019, à 22:03

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#63 Le 29/03/2019, à 06:49

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#64 Le 29/03/2019, à 18:24

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#65 Le 06/04/2019, à 12:53

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#66 Le 02/05/2019, à 04:03

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#67 Le 02/05/2019, à 12:20

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#68 Le 05/05/2019, à 13:13

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#69 Le 05/05/2019, à 14:17

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#70 Le 06/05/2019, à 20:27

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#71 Le 06/05/2019, à 20:40

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#72 Le 07/05/2019, à 10:21

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#73 Le 07/05/2019, à 18:29

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#74 Le 11/05/2019, à 16:24

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#75 Le 17/05/2019, à 09:48

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

Pied de page des forums