Crash de Plex Media Server et googledrive-ocaml-fuse

Après quelques mois de fonctionnement sans problèmes particuliers de Plex en duo avec googledrive-ocaml-fuse dont l’installation à été expliquée dans ce billet, hier soir il m’a été impossible  d’accéder à Plex. Comme cela était déjà arrivé par le passé, le service plexmediaserver se met en carafe et il faut donc le relancer.

service plexmediaserver stop
service plexmediaserver start

Tout simplement… sauf qu’hier, le service n’a pas voulu se stopper, ni même se relancer. Le status m’indiquait que le service était en train de s’arrêter mais visiblement bloqué sur cet état d’arrêt. Je pensais alors qu’un petit ps -u plex afin de récupérer le PID du processus Plex Media Server suivi d’un kill <PID> suffirait pour tuer le service et pouvoir le relancer. Cependant, j’ai été un peu surpris lorsque j’ai exécuté le kill puis refait un ps -u plex pour m’assurer de la bonne exécution que le processus apparaissait en <defunct>.

Je me retrouvais donc avec un processus zombie qui ne voulait visiblement pas partir. Bien que je pense que le processus parent soit tout simplement init, je voulais en être sur, et un ps -ef –forest me l’a confirmé, car le parent avait pour PID 1. J’allais devoir lancer un telinit U pour relancer init et le forcer à dégager ce zombie.

Une fois cette instruction envoyée, j’ai pu relancer le service normalement et Plex semble avoir fonctionné quelques minutes, avant un nouveau crash. Cette fois-ci, avant de vouloir arrêter et relancer le processus, je demande à voir le statut. Malgré tout, il fonctionne, mais l’interface est inaccessible. Quelque chose que je n’avais pas vu au départ me saute aux yeux désormais : Plex ne peut fonctionner correctement car /dev/sda1 est plein. Surpris, je vérifie avec un df et en effet, son utilisation était à 100%.

En réalité, après trois mois d’utilisation et des centaines d’épisodes de série ou de films téléchargés sur le serveur depuis Google Drive, le cache de googledrive-ocaml-fuse était arrivé à saturer le disque dur. Surprenant, car j’avais configuré le cache pour qu’il utilise au maximum 10 Go – peut-être une mauvaise idée compte tenu de la taille du disque virtuel qui est de 40 Go. Cela signifie que le système et les applicatifs ont grossi d’eux-mêmes avec les mises à jour entre autres. J’ai donc nettoyé le cache de googledrive-ocaml-fuse.

eval `opam config env`
googledrive-ocaml-fuse -cc

Et, là :

J’ai pu relancer le service, et Plex respire et peut de nouveau streamer proprement.

Maintenant, afin d’éviter que cela se reproduise, deux solutions : soit réduire la taille du cache à 5 Go, soit augmenter la taille du disque virtuel. J’ai réalisé dans l’urgence une réduction de la taille du cache à 5 Go dans le fichier de configuration (voir cet article pour plus de détails) et je ferai ce week-end ou un peu plus tard une extension à 60 Go du disque virtuel de mon serveur Plex pour pouvoir rétablir le cache à 10 Go, ce qui devrait empêcher de futurs crashs.

Mise en place de google-drive-ocamlfuse

Je passe pas mal de temps à regarder les meilleures options pour coupler Google Drive à Plex, et je me suis heurté récemment à un problème par rapport à l’API de Google Drive en utilisant rClone. Lorsque Plex analyse les bibliothèques pour la première fois, il passe par rClone qui émet une requête à l’API. Cependant, lorsqu’on a énormément de médias (dans mon cas, 4,6 To), les requêtes se multiplient et le compte utilisé dépasse le quota ; quota remis à zéro toutes les 24 heures. Cela peut s’avérer problématique car Plex ne peut du coup indexer tout correctement en une fois. Ce souci est dû au fait que rClone ne garde pas en cache l’arborescence des fichiers, ce qui fait qu’il doit interroger Google en permanence, au lieu de simplement la télécharger une fois et s’y référer lors des accès, en faisant évidemment des mises à jour périodiquement ; comme si un livre n’avait pas de table des matières pour lister les chapitres. Bien que ce soit une évolution prévue dans la prochaine version de rClone (1.37), en attendant, j’ai préféré opter pour une autre solution afin de satisfaire également ma curiosité.

Au lieu d’utiliser donc rClone pour coupler mon Plex à Google Drive, je vais utiliser google-drive-ocamlfuse, que je vais abréger par la suite en GDO, qui remplit le même rôle mais qui ne fonctionne qu’avec Google Drive, là où rClone est nettement plus polyvalent.

Je pars du principe que vous êtes avec un compte utilisateur root ou en utilisateur standard ayant une élévation grâce à sudo en ce qui concerne les premières commandes. Mon serveur Plex fonctionne sur Debian Jessie mais l’installation est presque Plug’n’Play sur Ubuntu (ajout d’un repository au préalable, voir sur cette page).

1. Installation

Si l’application est disponible pour certaines distributions (Ubuntu, ArchLinux…), elle n’est pas disponible directement pour Debian. Il y a donc des manipulations à réaliser en plus. Ces manipulations ont été traduites directement depuis la page Wiki officielle du projet, je les ai quelque peu clarifiées en même temps.

Dans un premier temps, il faut installer entre autres les paquets CAML, fuse, puis également make puisqu’on va devoir compiler depuis la source de l’application.

apt-get install opam ocaml make fuse camlp4-extra build-essential pkg-config

Ensuite, si le groupe fuse n’existe pas déjà sur le système, il faut le créer et ajouter le compte qui lancera l’application. Pour ma part, je me sers d’un compte générique tout simple et non de mon compte utilisateur.

groupadd <username> fuse

Ensuite, sur le répertoire de fuse, on va appliquer les bonnes autorisations afin que l’utilisateur qui va lancer google-drive-ocamlfuse puisse utiliser fuse :

chown <username> /dev/fuse
chmod 660 /dev/fuse

Attention : on ne manquera pas d’exécuter les instructions suivantes avec l’utilisateur qui exécutera GDO.

Puis, on installe ce qui est nécessaire au téléchargement et à la complication de google-drive-ocamlfuse (opam est un gestionnaire de paquets ocaml). Tout comme ce qui est indiqué dans la manipulation, j’ai laissé les options par défaut et cela fonctionne très bien.

opam init (option par défaut : N)
opam update
opam install depext
eval `opam config env`
opam depext google-drive-ocamlfuse (si des paquets système manquent, ils seront installés)
opam install google-drive-ocamlfuse (valider l’installation des paquets ocaml, le make du paquet ocamlnet est plutôt long, c’est normal)

Et voilà, GDO est installé et prêt à être lancé !

2. Premier lancement et autorisation



Si la machine sur laquelle est installé GDO possède un navigateur web, alors le premier lancement et l’authentification auprès du compte Google est aisée.

Sinon – ce qui a été mon cas –, il faut obtenir des identifiants développeurs auprès de Google (il existe le même type d’identifiant sur Amazon, par exemple) et les renseigner dans l’application via le terminal.

En se rendant sur cette page, on s’identifie à son compte Google, puis on crée un projet auquel on donne un nom sans intérêt, puis on active l’API Drive, comme sur la capture d’écran :

Sur le site pour les développeurs de Google, il suffit d’aller sur le tableau de bord et d’activer l’API Google Drive

Puis, on va procéder à la création des identifiants dont on a besoin. Naturellement, quelques paramètres sont à choisir, mais rien de très complexe, au final on ne donnera qu’un nom qui apparaîtra sur la page d’authentification un peu plus tard :

On choisira ici « ID client OAuth » car notre application a besoin de pouvoir accéder au contenu du Drive

A la fin de la création, deux identifiants sont communiqués : un ID Client et un Secret Client. Il convient de les noter par exemple dans un notepad car on va en avoir besoin juste après.

De retour sur le terminal, on exécute l’application, avec quelques paramètres :

google-drive-ocamlfuse -headless -id <client ID>.apps.googleusercontent.com -secret <secret ID>

Une URL apparaît alors dans le terminal. On copie-colle cette URL dans un navigateur web (donc, sur une autre machine), et il suffit de se connecter à son compte Google et à valider… notre propre application à s’authentifier. Une fois que l’autorisation est donnée, un token apparaît – qui n’est valide que 15 minutes, il me semble. C’est ce token qu’attend GDO pour finir d’être initialisé. Une fois cette manipulation terminée, l’application à accès au Drive.

Il reste un point à noter : en cas de redémarrage du système, on ne pourra plus relancer l’application ; elle apparaîtra comme introuvable. Il faudra relancer l’instruction suivante pour « réanimer » OPAM :

eval `opam config env`

Si l’on est amené à redémarrer fréquemment le serveur, il est tout à fait possible de placer cette instruction dans un script qui sera exécuté au démarrage par exemple.

3. Configuration

Avant tout lancement, il convient de passer en revue le fichier de configuration afin de modifier ce qui doit l’être pour un bon fonctionnement, et dans mon cas, éviter de générer trop de requêtes à l’API afin d’éviter d’être de nouveau bloqué.

Le fichier de configuration se trouve dans le répertoire de l’utilisateur qui a installé l’application – d’où l’intérêt de ne pas le faire en root, mais avec le compte qui exploitera le Drive. Un éditeur de texte comme nano fera le job pour y accéder :

cd #
nano  .gdfuse/default/config

Je ne vais pas passer en revue toutes les options, cependant je vais parler de celles qui me paraissent les plus importantes ou intéressantes :

  • metadata_cache_time : intervalle de temps entre deux requêtes à Google pour voir si le contenu a changé.
  • read_only : comme son nom l’indique, cela permet de monter le Drive en lecteur seule. J’ai choisi cette option à true car je ne fais que de la lecture sur les fichiers.
  • download_docs : cette option permet de choisir si l’on veut télécharger ce qui est stocké sur Google Documents. Je l’ai passé à false dans une optique de limiter le trafic et les appels à l’API.
  • delete_forever_in_trash_folder : ce paramètre peut être dangereux si réglé sur true, car si les fichiers sont supprimés de la corbeille sur la machine, ils sont définitivement supprimés ; en étant sur false, l’application ne les supprime pas du Drive mais ne les affiche plus, il faut donc se connecter sur l’interface web pour les restaurer.
  • shared_with_me : affiche ou non dans un répertoire /shared les fichiers partagés depuis d’autres Drive.
  • max_download_speed, max_upload_speed : sans équivoque, permet de contrôler la bande passante.
  • max_cache_size : en Mo, il s’agit du cache local concernant les fichiers accédés. Plex permettant de diffuser des films, j’ai augmenté le cache par défaut de 512 Mo à 5 Go.

Quelques options dans le cadre d’une utilisation avec Plex sont intéressantes :

stream_large_files : par défaut sur false, cette option permet de choisir si le serveur garde en cache le fichier qui dépasse la limite choisie dans le paramètre large_file_threshold_mb. Je l’ai laissée à false afin de récupérer le fichier une fois pour toutes et minimiser le trafic depuis et vers le Drive en permanence.

A noter que si cette option est sur true, il est possible de régler le nombre et la taille des tampons grâce à memory_buffer_size et read_ahead_buffers (par défaut, 3 tampons de 1 Mo). On peut également limiter la consommation en RAM de ceux-ci avec max_memory_cache_size. A noter que les valeurs à exprimer sont en octets (réels, c’est-à-dire 1048576 pour 1 Mo).

Si besoin, il est possible de trouver toute la documentation avec toutes les options possibles sur cette page. Globalement, les paramètres par défaut sont plutôt satisfaisants et nécessitent que peu de réglages manuels.

4. Montage

Maintenant que tout est prêt, on va pouvoir passer au montage du Drive et à l’accès aux fichiers.

google-drive-ocamlfuse /home/test/media/

Si tout s’est bien passé, le montage est instantané et il n’y a aucun retour, il suffit de naviguer dans le répertoire monté pour accéder aux fichiers. Afin de démonter le Drive, il suffit d’appeler fuse avec cette commande :

fusermount -u /home/test/media/

Et voilà, on a couplé – avec tout de même un peu plus de difficulté qu’avec rClone – Google Drive et un système GNU/Linux.

Page Github de google-drive-ocamlfuse
Page d’accueil des API Google

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.