Amazon Cloud chiffré, rClone : retours d'expérience
Voici plusieurs semaines que j’ai définitivement laissé tomber le couple acd_cli/encFS pour chiffrer le contenu multimédia que je compte stocker sur mon Cloud Amazon. J’utilise maintenant rClone et commence à avoir une “infra” automatisée, certes encore perfectible, mais néanmoins pleinement opérationnelle pour les films, les séries et la musique. J’en profite donc pour vous faire un retour et distiller aussi quelques suggestions d’organisation et de configuration.
J’ai conscience que mon tutoriel est relativement indigeste mais il faudra cependant en passer par là ne serait-ce que pour installer FUSE et rClone et configurer ce dernier.
- Chiffrement
- Précautions
- Options de montage
- Films, séries & musique sur Amazon
- Autres téléchargements sur Amazon
- Accès au contenu
Globalement : ça poutre !
Mes films et séries se téléchargent tous seuls sur Usenet/BitTorrent avec CouchPotato et SickRage. Ils sont renommés puis déplacés, dans le cas de Usenet, ou copiés, pour BitTorrent afin qu’ils restent en seed, vers mon Cloud Amazon chiffré. Pareil pour la musique, via HeadPhones. Les jeux/softs sont en général tous dans des dossiers donc simples à déplacer/copier dès réception aussi. Pareil pour les documentaires, concerts and co qui sont soit sous la forme fichier.extension soit /dossier/fichier.extension et qui peuvent donc être balancés tels quels dans le Cloud.
J’ai plus de mal en revanche pour les BDs vu que leur upload est tout sauf normé : on a des fichiers simples, des fichiers dans des dossiers, des .rar, même des .zip (ça existe encore ça ?) et des nommages tout aussi ubuesques nom.bd.extension, [tag1].[tag2].nom.bd.extension, [tag1].[tag2].nom.bd.[année].[site].[uplaoder].extension… bref, y’a à boire et à manger comme on dit et il est absolument impossible d’automatiser des déplacements/copies automatisées de fichiers dans ces conditions sous peine de se retrouver avec un sacré bordel ingérable à l’arrivée.
Heureusement que je ne fais ça qu’à des fins de test et que je ne suis pas un vrai pirate, ça m’énerverait ;-)
Et j’ai accès à tout, partout :
- Emby/SubSonic/Ubooquity d’installés sur mon serveur “Amazon” (qui DL et gère tout ça),
- SubSonic sur smartphone,
- Dossier chiffré Amazon monté sur mes PC chez moi, sous Linux,
En effet rClone supporte maintenant l’écriture (w, write) en sus de la lecture (r, read). Ce qui veut dire que pour prendre ou envoyer un contenu sur/depuis son remote rClone on peut tout simplement utiliser les commandes classiques de Linux telles que la copie (cp, le déplacement (move) et l’effacement (rm). Plus besoin d’utiliser les commandes spécifiques rClone telles que rclone copy ou rclone move. Concrètement ça veut dire que SickRage et CouchPotato sont à même de déplacer eux-mêmes des fichiers sur le remote, plus besoin d’ajouter un script comme celui-ci.
En revanche rClone ne supporte pas encore le rw. Il ne pourra par exemple pas permettre de seeder un contenu via un client BitTorrent.
Pourquoi chiffrer ?
C’est la 1ère question qui revient souvent dans les échanges que j’ai sur ACD. Déjà je ne conçois pas de mettre des documents personnels en ligne sans les chiffrer. J’ai rien de particulier à cacher, pour autant, l’intérieur de ma maison n’est pas filmé. C’est ce que j’appelle la vie privée et mon droit à ce qu’elle le reste autant que possible.
Ensuite, dans notre contexte, il ne faut pas oublier qu’Amazon est une société américaine et de fait en lutte “active” contre le piratage en ligne (DMCA). Au-delà du fait qu’ils se réservent le droit d’accéder à nos données pour des besoins inhérents à leur métier et notre expérience client, on peut supposer qu’en proposant un stockage illimité (1024Po en ce moment) pour 70€/an ils se doutent que ça va être prisé des “pirates”, surtout si des offres telles que PlexCloud se développent. Oh ?! Tout va bien, on peut toujours utiliser Plex pour lire un contenu hébergé sur Amazon, via rClone justement. Il est alors très fortement recommandé de chiffrer le contenu piraté que vous pourriez y déposer afin d’éviter toute alerte via leurs bots ou techniciens.
Utiliser en bonne intelligence, pour rester “sous les radars”
La majorité des utilisateurs ayant rapporté un blocage (même temporaire) de leur compte Amazon expliquent que la société leur reprochait des input/output fréquents, depuis plusieurs IP et à des débits très élevés. En effet ce Cloud est loué pour une utilisation “normale” aka y déposer des documents pro/privés, des photos etc. Pas pour envoyer des To de données, 24/7, depuis 1 ou plusieurs serveurs en 1 ou 10Gbps et avec plusieurs accès en lecture tous les soirs “après le dîner”, quand tous ceux avec qui on partage notre Plex/Emby Cloud veulent se regarder un film :)
Le but est de se noyer dans la masse le plus possible afin de ne pas se faire bloquer (et non fermer) son compte. De mon point de vue il faut s’astreindre à 2 règles :
- N’envoyer des données qu’à petite dose : vitesse et transferts parallèles limités : –checkers, –transfers, –bwlimit,
- Si possible n’utiliser qu’une seule IP pour envoyer des données “multimédia”, du moins pas plus de 2 (serveurs).
Options de montage
J’utilise les mêmes pour toutes les machines, peu importe que leur rôle soit d’uploader ou d’accéder seulement au contenu. J’ai pu tester la lecture via Emby mais ni Plex (que je n’utilise pas) ni Kodi, n’ayant pas assez de débit Internet pour l’instant. Comme indiqué dans le tutoriel j’utilise notamment les options spécifiques de rClone pour Amazon.
Voici mon script.
#!/bin/bash # Montage remote ACD chiffré /usr/sbin/rclone mount \ --allow-non-empty \ --allow-other \ --max-read-ahead 2G \ --acd-upload-wait-per-gb=3m0s \ --acd-templink-threshold 9 \ --checkers 2 \ --transfers 2 \ --bwlimit 100M \ --timeout 10m0s \ --ignore-existing \ --no-check-certificate \ --retries 5 \ --stats 0 \ --log-file /root/ACD.log \ ACD_Enc: /home/aerya/Enc_ACD/ & exit # Montage remote ACD /usr/sbin/rclone mount \ --allow-non-empty \ --allow-other \ --max-read-ahead 2G \ --acd-upload-wait-per-gb=3m0s \ --acd-templink-threshold 9 \ --checkers 2 \ --transfers 2 \ --bwlimit 100M \ --timeout 10m0s \ --ignore-existing \ --no-check-certificate \ --retries 5 \ --stats 0 \ --log-file /root/ACD.log \ ACD_Emby: /home/aerya/ACD/ & exit
- –allow-non-empty : permet de monter le remote rClone dans un dossier non vide
- –allow-other : option FUSE qui donne l’accès rw (read:write) aux Users de la machine. Mais pas au root
- –no-modtime : pas de prise en compte des dates de modification des fichiers. Ça ne me sert pas et permet de gagner un peu de temps d’exécution (selon le volume de données à traiter)
- –max-read-ahead 2G : taille de la mémoire cache allouée à rClone. Dépend évidemment de la RAM de votre machine, permet de gagner un peu de temps de traitement de données
- –acd-upload-wait-per-gb=3m0s : permet de contourner le bogue de latence d’Amazon pour les fichiers de plus de 1 et surtout 10Go. J’ai notamment laisser tomber acd_cli à cause de ça. Avec ce paramètres rClone peut attendre jusqu’à 3 minutes pour “voir” le fichier qu’il vient de déposer sur Amazon. S’il ne le voit pas, il prend alors ça comme une erreur et recommence le process d’upload
- –acd-templink-threshold 9 : permet de forcer le DL (téléchargement, lecture…) d’un fichier de plus de 9Go via HTTP(S) afin d’éviter un bogue d’Amazon sur les fichiers de plus de 10Go
- –checkers 6 : nombre de process de contrôle d’un fichier lors de son transfert
- –transfers 5 : nombre de transferts simultanés
- –bwlimit 200M : limite de bande passante. Je préfère restreindre à 200Mbps sur des serveurs de 1Gbps, rien ne presse et ça permet de ne pas être en haut des statistiques côté Amazon ;)
- –timeout 0 : durée du idle pour les I/O. Le 0 permet de forcer la déconnexion d’Amazon dès que rClone n’a plus de données à traiter. Là encore c’est histoire de tenter de rester discret
- –ignore-existing : ignore tous les fichiers déjà présents dans le remote. Permet de gagner du temps (avec 20 Go ça irait vite mais 20To c’est déjà plus long…)
- –no-check-certificate : en lien avec –acd-templink, permet de se passer du contrôle du certificat SSL du lien HTTPS de téléchargement
- –retries 3 : retente 3 fois l’action entreprise en cas d’échec
- ACD_Enc: /home/aerya/Enc_ACD/ & : nom du remote rClone, chemin/de/montage/local
Plus de détails sur ces commandes et les autres sur le site de rClone.
Envoyer films et séries automatiquement sur Amazon
J’utilise ed2k, Usenet, BitTorrent et FTP. Autrement dit certains contenus récupérés doivent nécessairement rester en partage sur le serveur. Je peux donc déplacer une partie du contenu récupéré (Usenet/FTP) mais dois seulement copier l’autre (BitTorrent/ed2k). Comme je suis très certainement un cas “à part”, je vais prendre l’exemple des gens qui utilisent uniquement BitTorrent. Le postulat étant que vous avez monté vos remotes Amazon, ou au moins le chiffré, sur votre serveur.
Pour les séries, films et musique j’utilise l’autoDL via SickRage (pour la VF) et Sonarr (VO), CouchPotato et HeadPhones avec rTorrent/ruTorrent :
- SickRage : mon tutoriel
- Sonarr : tutoriel GitHub
- CouchPotato : mon tutoriel
- Jackett, pour utiliser des trackers FR via CouchPotato : mon tutoriel
- HeadPhones : tutoriel Mondedie
- rTorrent/ruTorrent : script Bonobox (Mondedie)
- SickRage + CouchPotato + ruTorrent : script RatXaBox (Mondedie)
- Mon remote ACD chiffré est monté dans /home/dan/Enc_ACD
- Dedans j’ai créé les dossiers /Films /Séries /Flacs…
- SickRage dit à rTorrent de mettre les séries téléchargées dans /home/dan/Series,
- CouchPotato lui dit de mettre les films dans /home/dan/Films,
- HeadPhone lui fait placer tout ça dans /home/dan/Flacs.
- SickRage va ensuite chercher les séries à traiter dans /home/dan/Series, les renomme puis les copie dans /home/dan/Enc_ACD/Series
- CouchPotato va ensuite trouver les films dans /home/dan/Films, les renomme puis les copie dans /home/dan/Enc_ACD/Films
- HeadPhones fait pareil, de /home/dan/Flacs vers /home/dans/Enc_ACD/Flacs.
Et c’est tout. Il faut juste bien penser à sélectionner “copie” dans le post-process des logiciels afin que les fichiers restent en seed le serveur. Voici la configuration de SickRage comme exemple.
Copier tous les téléchargements sur Amazon
ruTorrent permet, via son plugin AutoTools, de copier tous les téléchargements vers Amazon. Pour se faire il suffit de l’activer et de sélectionner le remote chiffré Amazon comme dossier cible pour les téléchargements complétés. Et bien évidemment toujours en mode “copie” afin de les conserver en seed sur le serveur.
Sauf que si on reste comme ça tout est alors copié à la racine de notre Cloud Amazon chiffré. Et tout comme pour les films, séries et musique, c’est plus sympa de tout trier dans des dossiers. Il faut donc créer autant de dossiers que de “catégories de téléchargement” qu’on souhaite. Voici me concernant :
dan@ACD2:/home/dan/Enc_ACD# ls Animes Comics Concerts Docs Ebooks Films Flacs Jeux Series Softs Spectacles Stuff
Puis il faut ensuite charger le .torrent dans la catégorie souhaitée. Pour ça il y a 2 solutions à savoir créer les mêmes dossiers dans le /WatchDir et activer cette fonctionnalité dans AutoTools ou alors, plus simple à mon goût, utiliser un plugin qui permet d’ajouter un .torrent directement depuis un lien .torrent sur un site. Pour ça je vous recommande l’excellent Remote-Torrent-Adder (Chrome/Vivaldi) pour lequel vous pouvez suivre ce tutoriel de Mondedie.
Il n’y a alors qu’à cliquer sur le lien de téléchargement du .torrent sur le site, sélectionner votre client BitTorrent configuré et… mettre le nom de votre dossier cible :) Mettons que je veuille télécharger un fichier dans mon dossier /Stuff :
Lecture
Pour accéder aux données sur le Cloud chiffré il suffit de :
- Monter le remote ACD chiffré sur une machine,
- Sélectionner le dossier souhaité comme source : /home/dan/Enc_ACD/Flacs pour SubSonic, /home/dan/Enc_ACD/Films /Séries /Concerts etc pour Emby et ainsi de suite.
