Impossibilité de monter rClone avec Amazon Drive

Pour faire suite au billet que j’ai posté quelques jours auparavant concernant la possibilité de monter Amazon Drive sur un système GNU/Linux grâce à rClone, je reviens sur deux erreurs que je rencontre depuis hier soir.

Le code erreur 429 Too Many Requests renvoyé par l’API d’Amazon Cloud Drive indique que l’application dépasse le quota de requêtes qu’elle est autorisée à faire à l’API. Dans le cadre d’Amazon Cloud Drive – que je vais abréger ACD par la suite – les limites de requêtes à l’API ne sont pas faites par utilisateur, mais par application. Chaque application étant déclarée à ACD avec deux identifiants, ACD sait le nombre d’utilisateurs pour chaque application et étend le quota de requêtes en fonction de celui-ci. Cependant, comme pour acd_cli évoqué dans le précédent article, rClone semble malgré tout avoir dépassé les limites autorisées.

Cette limite soudaine d’overquota pourrait s’expliquer par le fait que de nombreux utilisateurs d’acd_cli sont venus sur rClone suite au blocage d’acd_cli (qui à ce jour, ne fonctionne plus et affiche une erreur d’authentification). En réalité, comme l’indique le deuxième message 401 Unathorized, le problème n’est plus lié à un quelconque quota, mais à une mauvaise authentification. Une mauvaise authentification qui est due à ACD.

En effet, il semblerait qu’ACD bloque petit à petit toutes les applications open-source sur Linux. La première étape passe par une très forte restriction du quota sur l’API, pour finir avec une pure interdiction de se connecter en bloquant les deux identifiants liés à l’application. Pour l’instant, le développeur de rClone a pris contact avec ACD mais sans retour positif.

Il n’y a donc actuellement plus de moyen simple de connecter Amazon Cloud Drive à un système GNU/Linux en utilisant FUSE, ce qui permettait d’accéder à l’intégralité d’ACD sans avoir à avoir une copie locale des données (et donc, de nécessiter une capacité de stockage équivalente). Il existe des solutions sous Windows comme NetDrive que j’ai utilisé quelques temps, mais leur efficacité est moindre (volume de données qui transite bien plus élevé, souplesse moindre, temps de requête plus élevé). Pour ma part, je suis déjà en train de migrer mes 5 To de données sur un autre service en attendant d’acquérir un NAS et de tout rapatrier à la maison afin d’avoir un deuxième miroir au cas où.

Thread sur le forum de rClone à propos des erreurs 429
Thread sur le forum de rClone concernant son bannissement sur ACD

Utilisation de rClone avec Amazon Drive

Mise à jour du 18 mai 2017 : à partir de ce jour, Amazon Cloud Drive a décidé de bannir rClone des applications autorisées à se connecter à l’API, ce qui signifie qu’il n’est plus possible à ce jour d’utiliser rClone pour se connecter et accéder aux fichiers stockés sur un compte Amazon Cloud Drive. J’ai rédigé un billet concernant le dysfonctionnement en date du 19 mai 2017 (cliquez pour y accéder).

J’utilise deux serveurs Plex pour mes séries, films, musiques et autres contenus multimédias, afin que je puisse y accéder depuis tous mes appareils sans perdre la continuité de ceux-ci. Le stockage est déporté sur Amazon Cloud Drive et non en local, pour sa capacité « illimitée » (en réalité, elle semble être de 100 To, ce qui laisse tout de même une marge plus qu’énorme). Cependant, afin que Plex puisse voir les fichiers d’Amazon Cloud Drive (abrégé ACD par la suite), il faut une application sur le système – non pas pour synchroniser les fichiers auquel cas le stockage en ligne est inutile – mais pour simuler leur présence afin que Plex puisse les détecter et y accéder si la lecture est demandée.

Jusqu’à hier, j’utilisais une application nommée acd_cli. Cependant, depuis hier soir, elle ne semble plus fonctionner, car il semblerait que le quota de requêtes fixé par Amazon a été dépassé. En effet, Amazon applique un quota de requêtes par heure sur l’API en fonction du nombre d’utilisateurs d’une application donnée. Il y a plusieurs workarounds proposés par le développeur d’acd_cli mais j’ai préféré sauter sur l’occasion pour abandonner cette solution temporairement (elle est toujours installée sur le système, mais je ne monte plus ACD avec acd_cli) et passer sur rClone, qui fait exactement la même chose, mais qui peut fonctionner avec bien plus de fournisseurs de stockage en ligne.

Je vais partir du principe que vous possédez déjà un système GNU/Linux Debian prêt à l’utilisation et que vous avez obtenu une élévations de droits, avec su ou en précédant les instructions de sudo. J’ai procédé à l’installation sur un serveur équipé de 4 vCPU, 4 Go de mémoire vive et avec un disque dur de 60 Go.

1. Prérequis

Tout d’abord, mettre à jour le système, puis installer FUSE ainsi que screen – si vous ne connaissez pas screen, il s’agit d’un outil permettant de simuler un terminal pour une application – puisqu’il nous sera utile lorsqu’on aura monté ACD avec rClone. rClone étant compressé au format zip, unzip sera nécessaire.

apt-get update && apt-get dist-upgrade
apt-get install fuse screen unzip

2. Téléchargement et installation de rClone

Le lien de la version peut évoluer avec le temps, mais un autre lien existe pour référence dans un script par exemple, il est possible d’utiliser l’un des deux liens, au choix (à noter qu’il est également possible d’installer rClone via git) :

wget https://downloads.rclone.org/rclone-v1.36-linux-amd64.zip

ou

wget https://downloads.rclone.org/rclone-current-linux-amd64.zip

Une fois que le fichier est récupéré, on va le décompresser (bien sûr, adapter le nom du fichier à la version récupérée, ou à current si vous avez pris le deuxième lien) :

unzip rclone-v1.36-linux-amd64.zip

On va se placer dans le répertoire extrait, puis copier le contenu vers /usr/sbin/rclone afin de pouvoir commencer à configurer l’application et à l’exécuter :

cd rclone-v1.36-linux-amd64
cp rclone /usr/sbin

L’installation est terminée, il faut désormais configurer l’application.

3. Configuration de rClone

On peut lancer l’assistant de configuration en saisissant :

rclone config

Si cela ne marche pas (ce qui m’est arrivé avec un autre utilisateur que root…), il faut simplement rajouter /usr/sbin devant rclone :

/usr/sbin/rclone config

L’assistant apparaît, et c’est là qu’on va déclarer notre compte ACD. On créé donc un nouveau « remote ». Plusieurs paramètres vont être à saisir, il faut être vigilant lors de cette partie sous peine d’avoir à reconfigurer le compte :

  • Le nom : dans cet exemple, je l’ai appelé amazondrive. Ce nom sera utilisé dans l’instruction permettant de monter ACD.
  • Le type de compte à monter : plusieurs choix sont disponibles, mais le « 1 » est Amazon Cloud Drive, il faut donc saisir 1.
  • Les Amazon Application Client ID et Client Secret sont utiles si vous êtes développeur Amazon et que vous utilisez votre propre application. Etant donné que rClone n’est pas votre propre application, les champs sont à laisser vides.
  • On refuse la configuration automatique : en effet, on a besoin d’une clé d’authentification qui permet de lier rClone à ACD : clé qu’on récupère lorsqu’on s’identifie sur ACD et qu’on autorise rClone à lire et écrire sur ACD, lors de l’étape suivante.
L’étape qui consiste à récupérer la clé d’authentification peut être un peu plus chiante si vous n’avez pas d’environnement graphique sur le serveur sur lequel vous installez rClone.

Si vous avez un environnement graphique avec un navigateur web : ouvrez un terminal avec le même utilisateur que vous avez utilisé jusqu’ici, puis saisissez : rclone authorize amazon cloud drive.
Si vous n’avez pas d’environnement graphique : répétez la procédure d’installation de rClone sur un système Windows, GNU/Linux ou encore OS X, mais sans la configuration. Saisissez simplement rclone authorize amazon cloud drive.
Dans les deux cas, une fenêtre de navigateur va s’ouvrir, avec un prompt d’identification. On va donc saisir l’identifiant et le mot de passe du compte ACD, et autoriser rClone à accéder à ACD. Une fois que la manipulation est faite, la fenêtre va afficher un « Success » et la clé sera affichée dans le terminal. Il est possible de la copier-coller temporairement dans un fichier texte, mais il faudra surtout la coller une fois que l’assistant de configuration le demande, c’est-à-dire, juste après avoir demandé de saisir « rclone authorize amazon cloud drive ». Il est très important de prendre toute la clé, c’est-à-dire accolades comprises.
Il ne reste plus qu’à confirmer la clé, et la configuration est terminée. rClone peut se connecter à ACD sans problèmes, il ne reste plus qu’à monter ACD.

4. Montage d’ACD

Il est nécessaire d’avoir un répertoire vide dans lequel on va monter ACD. Dans cet exemple, on va lancer rCloud avec l’utilisateur amazon, on va donc monter ACD dans son répertoire personnel :
rclone mount amazondrive: /home/amazon/
Le problème, c’est que rClone occupe le terminal. Ce qui peut être gênant si il n’est pas possible de laisser le terminal SSH ouvert par exemple. C’est pourquoi on va utiliser screen qui va nous permettre de simuler un terminal pour rClone afin qu’on puisse quand même couper la connexion SSH sans pour autant tuer le processus rClone.
On créé le nouveau terminal, que l’on va nommer rcloneacd :
screen -S rcloneacd
Une fois dans ce screen – lorsque l’on a validé la commande précédente – on peut donc saisir de nouveau la commande de montage. Attention, il n’est pas possible sans workaround de créer un screen si vous avez utilisé une élévation de droits ou un changement d’utilisateurs avec su. Il faut donc lancer le screen en tant qu’utilisateur simple et ensuite effectuer une élévation de droits si besoin, dans le screen. Lorsque rClone est lancé et le partage monté, il suffit de presser CTRL+A puis D pour quitter le screen sans le fermer.
Il est possible d’y accéder de nouveau au terminal exécutant rClone en saisissant cette commande :
screen -R rcloneacd

Enfin, pour démonter ACD :

fusermount -u /home/amazon

Normalement, le répertoire /home/amazon/ contient tous les fichiers de votre ACD, mais virtuellement. Cela signifie que grâce à FUSE, votre système voit les fichiers comme si ils étaient présents, et une bonne majorité d’applications sont également bernées. En cas d’accès en lecture ou en écriture, rClone se charge de télécharger les données, et FUSE de les rendre exploitable comme si ils étaient disponibles sur un système de fichiers standard.

J’ai testé C14, le service d’archivage d’Online

Il y a un peu moins de 2 mois, je me faisais cambrioler, perdant mon ordinateur, ainsi que mon disque dur de sauvegarde TimeMachine. Heureusement, étant sous macOS et utilisateur d’iCloud, j’ai pu conserver l’intégralité de mes fichiers.

N’étant jamais à l’abri d’une perte de données du côté des serveurs d’Apple, d’un piratage de compte ou d’une mauvaise manipulation, j’ai voulu m’abonner à un service d’archivage de fichiers, me permettant de conserver mes documents les plus importants. Cependant, ces services sont souvent dimensionnés pour les entreprises ou coûteux en fonction du volume de données – il faut croire que pour l’instant, un système de stockage en ligne comme Dropbox, Onedrive ou Amazon Drive suffisent pour la majorité des utilisateurs.

Mais si il s’agit de simple stockage de fichiers en ligne sans aucune garantie de quel type, des services comme C14 d’Online ou Amazon Glacier sont orientés vers la sauvegarde et l’archivage légal. C’est exactement ce que je recherchais : un espace de stockage sécurisé, avec des garanties contractuelles, et des tarifs qui restent tout à fait raisonnables tant qu’on s’en sert pas comme un cloud standard avec des modifications, des uploads et downloads à tout va. Une sauvegarde de dernier recours si une situation comme celle-ci avait à se reproduire.

Je me suis donc orienté vers la solution d’Online, nommée C14, car moins chère que les concurrents principaux, et moins complexe à la compréhension tarifaire souvent orientée entreprise chez la concurrence. La création d’un compte est gratuite ; cependant un moyen de paiement est nécessaire pour utiliser le service car je suis facturé en fonction de l’utilisation que j’en fais.

Hiérarchiquement, on possède des coffres-forts, qui sont comme des gros répertoires. Leur création est gratuite.

Et ensuite, les archives en elles-même, qui sont les bases de la facturation. On y stocke – presque – autant que l’on veut (à la limite de 40 To par coffre-fort). Chaque opération sur ces archives est facturée.

Je vais y créer une archive pour y déposer des fichiers. J’y choisis le nom, une description, puis plusieurs paramètres dont l’intérêt dépend de la criticité des fichiers que je vais y déposer. Je laisse les paramètres standard car ils suffisent à mon usage. Le transfert en SFTP est rapide et le plus simple.

Une fois que l’archive est créée, un login et un mot de passe temporaire SFTP m’est fourni : comme je l’ai choisi précédemment, cet accès est ouvert pendant 2 jours. Au-delà des 2 jours, l’archive se verrouille et enclenche la tarification, ce qui signifie que je n’ai plus accès directement à ces fichiers à moins de demander le désarchivage. Celui-ci fonctionne de la même manière : en fonction des paramètres choisis, un accès est ouvert et je peux y récupérer les fichiers (ou en déposer de nouveaux). Tout le trafic qui passe au moment où l’archive est ouverte n’est pas facturé.

Un système de versioning existe : cela signifie qu’un désarchivage et un réarchivage ne supprime pas l’archive. Une deuxième est créée, avec un timestamp différent, afin de pouvoir conserver un delta de données si nécessaire. Il est également possible de forcer l’archivage si l’on ne souhaite pas attendre la fin du délai.

Les opérations se font plutôt rapidement, il s’agit généralement de quelques minutes pour des archives de petites tailles, mais cela peut prendre plus de temps pour des archives importantes (débit annoncé par Online : 650 Mo/seconde).

Chaque archive possède son historique, qui peut être exporté en CSV. A chaque opération, le coût en annoncé. Les fichiers dedans sont cryptés, et Online utilise une clé propre à chaque archive liée à votre compte pour décrypter les fichiers. Pour plus de sécurité, il est possible de demander à Online de ne pas se souvenir de clé permettant de décrypter les fichiers, mais en contrepartie, la clef sera demandée pour chaque opération, il convient donc bien de la garder en sécurité quelque part sinon l’archive sera inexploitable.

En 2 mois, les services m’ont coûté… 5 centimes HT par mois. Il est vrai que je n’ai pas énormément de données stockées (environ 10 Go de photos, archives de travail, documents personnels, factures…), ce qui bénéficie à ce prix très faible. Pour l’instant, je n’ai pas de reproches à faire à ce service, qui servira essentiellement si jamais mon ordinateur ainsi que mon disque de sauvegarde sont dérobés et que j’ai un problème d’accès à mes données sur iCloud suite à un piratage. Mais depuis mon cambriolage, la peur de perdre les données était très présente car 2 des 3 emplacements n’étaient plus accessibles. Pour quelques centimes par mois, je suis plus serein. Les vrais plus de l’offre d’Online par rapport à la concurrence étant la simplicité de l’interface et la compréhension de la tarification. Le prix plus faible se paye par rapport au nombre plus faibles de datacenter sur lesquels stocker les données, et peut-être des performances plus faibles, mais je n’ai ici pas moyen réel de vérifier, ou encore un support moins accessible.