Auteur/autrice : Enguerrand

Pas de commentaire

Impossibilité de monter rClone avec Amazon Drive

  de

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

Pas de commentaire

Utilisation de rClone avec Amazon Drive

  de

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.
Pas de commentaire

Installation d’X2Go sur Debian Jessie

  de

X2go est une application client/serveur qui permet de rediriger l’affichage d’un serveur X sur une autre machine. Dans mon cas personnel, j’ai une machine sous GNU/Linux Debian Jessie qui me permet de surfer sur internet et d’exécuter quelques applications graphiques, j’ai donc un environnement graphique MATE auquel j’accède via la console VMware, mais cela n’est pas toujours pratique (besoin de s’identifier côté VMware, de lancer la console et de se connecter ensuite à la machine). Afin de pouvoir me connecter à la machine comme je me connecterai en RDP à une machine Windows, je vais donc installer le composant serveur d’X2go sur ma machine GNU/Linux et le client sur les systèmes à partir desquels je vais accéder à Debian.

X2go se sert de SSH pour communiquer avec le serveur X présent sur le serveur. Cela signifie que tous les flux sont sécurisés et qu’il est nécessaire que le port 22 soit en écoute afin que l’on puisse se connecter, bien qu’il soit possible de modifier le port d’X2go.

Installation du serveur 

Ajouter le dépôt pour les paquets d’X2go, car ils ne sont pas fournis par défaut dans les dépôts officiels de Debian. On créé un fichier x2go.list dans /etc/apt/sources.list.d et on y ajoute la ligne suivante :



deb http://packages.x2go.org/debian jessie main

Puis on y installe le premier paquet x2go-keyring qui va permettre de communiquer avec les dépôts d’X2go et de gérer la partie sécurité de ceux-ci. Étant donné qu’il n’est pas encore installé, on aura un message d’avertissement lors de la mise à jour de la liste, il est à ignorer et ne reviendra pas par la suite.

apt-get update 
apt-get install x2go-keyring
apt-get update

Et enfin, on installe le paquet x2goserver, et toutes les dépendances nécessaires qui seront ajoutées automatiquement.

apt-get install x2goserver

Installation du client et configuration d’un hôte

 

Il est possible de récupérer le setup d’installation pour la plateforme désirée sur le site d’X2go. Dans cet exemple, je vais partir sur un client pour Windows. L’installation est des plus standard : suivant, suivant, suivant…

Une fois l’installation terminée, il faut configurer la session à ouvrir :

Le chemin peut-être laissé par défaut, tandis qu’il est nécessaire de saisir le serveur, l’identifiant de connexion, et le mot de passe associé. Le type de session indique l’environnement graphique que l’on va ouvrir : dans mon cas, j’ai choisi MATE mais de nombreux autres environnements sont disponibles : KDE, GNOME, XFCE… Dans les autres onglets sont disposés plusieurs autres paramètres : la vitesse de connexion, le partage réseau de dossiers, la gestion du copier-coller, l’écoute du périphérique audio de la machine serveur, etc. Une fois tous les paramètres saisis, il est possible de se connecter ; il faudra accepter le hash de la clef SSH du serveur, et si vous êtes sous Windows en fonction de vos GPO ou de vos réglages, autoriser l’application à communiquer à travers le pare-feu.

Et voilà ! Une simple exécution du client, un double-clic sur la connexion et je peux accéder à ma machine de la même manière que j’ouvrirais une session RDP sur une machine Windows.

Pas de commentaire

Le KB2919355 n’est jamais disponible au téléchargement via Windows Update sur Windows Server 2012 R2

  de

Le KB2919355, ce patch récalcitrant apparu il y a quelques années en portant le nom de « Update 1 » pour les systèmes Windows de bureau, est un patch cumulatif de mises à jour également disponible pour Windows Server 2012 R2 ayant posé quelques soucis lors de ses premiers jours. Nécessaire pour certaines applications ainsi que globalement pour la sécurité du système par les failles qu’il corrige, j’ai été confronté plusieurs fois de manière aléatoire sur plusieurs serveurs à une indisponibilité dans Windows Update ; c’est-à-dire que Windows Update ne se voyait jamais proposer le téléchargement et l’installation de ce KB uniquement sur certains de mes serveurs virtuels, sans qu’il n’y ait jamais de variable commune.

Et c’est exactement cette absence de paramètre commun qui était étrange : 1 vCPU et 1 Go de RAM pour mes deux contrôleurs de domaine installés initialement en Core, 4 vCPU et 4 Go de RAM sur un serveur classique sans rôle avec interface graphique, des serveurs qui ne sont fatalement pas dans la même OU, qui ne se voient pas gérés de la même manière au niveau de ma GPO Windows Update… De plus, ils étaient installés avec le même ISO, utilisant la même licence.

Voulant éviter autant que possible une installation à la main, j’ai donc essayé plusieurs remèdes :

Le premier, la désactivation de Windows Update, la suppression du répertoire SoftwareDistribution localisé dans C:\Windows et la relance du service. Cela permet de réinitialiser Windows Update et son cache, et ainsi de repartir comme si vous n’aviez jamais installé de KB sur le système (c’est-à-dire que Windows Update perd son historique, les mises à jour restent installées). Avant de réaliser la suppression du répertoire, j’ai quand même procédé à une copie de sauvegarde au cas où.

net stop wuauserv
rd c:\windows\softwaredistribution /s /q
net start wuauserv

Pas mieux après cette tentative.

Le deuxième essai aura été celui de désactiver la GPO influant sur Windows Update (indiquant à mes serveurs de télécharger les mises à jours sans les installer). Même en indiquant aux serveurs de ne plus rechercher les mises à jour automatiquement et en lançant une recherche après un redémarrage, point de salut.

Troisième tentative de correction avec l’outil DISM, afin de vérifier que tous les composants systèmes sont bien installés et ne sont pas endommagés.

dism /online /cleanup-image /scanhealth

Et… tout va bien sur le système.

Quatrième et dernière commande, sans espoir :

sfc /scannow

Espoir vain, bien évidemment. Mes serveurs ne présentaient aucun bug, aucune corruption et étaient en parfait état de marche. Mais pour autant, j’avais toujours une disparité au niveau des patchs déployés car certains de mes serveurs avaient eu le droit à l’Update 1 et pas les autres.

En réalité, ce qui empêche Windows Update de voir ce gros KB2919355 de presque 900 Mo, c’est le KB2919442, qui pour des raisons inconnues, n’est pas toujours visible par Windows Update, il faut donc l’installer à la main. Il pèse 10 Mo et est disponible sur le site de Microsoft.

Une fois ce patch ridicule installé, on relance Windows Update et… miracle !

Le patch tant attendu apparaît et est enfin disponible au téléchargement, et à l’installation. Une fois toute l’opération déroulée, on retrouve parmi les changements esthétiques les boutons sur l’écran d’accueil.