PlugArr 0.7.1

PlugArr ne savait pas qu'une version plus recente de LUI-MEME existait. Signale a l'usage : « je viens de lancer la 0.6 et elle ne detecte pas la 0.7 pour se mettre a jour ».

C'etait juste, et le trou etait beant.

Ce qui manquait

La 0.6.0 a livre plugarr upgrade, qui aligne les images des services sur le catalogue du binaire en cours. Elle supposait donc qu'on avait deja telecharge le binaire du jour — et rien, nulle part, ne le disait. __version__ n'etait qu'affiche : aucune ligne du code ne demandait a GitHub s'il existait mieux.

Trois endroits le disent desormais, choisis parce que ce sont ceux ou l'on se demande « suis-je a jour ? » :

• plugarr upgrade, en premier, avant meme de parler des images — aligner les services sur le catalogue d'un binaire perime n'a qu'un interet limite ;
• plugarr doctor ;
• le bouton chercher les mises a jour de la console, qui ne regardait que les images : on pouvait tout avoir a jour sauf l'outil qui le dit.

PlugArr 0.7.1 est disponible (vous avez la 0.6.0)
https://github.com/yannickuhrig1/plugarr/releases/tag/v0.7.1
Cette commande aligne les services sur le catalogue de la version que VOUS lancez :
telechargez la nouvelle d'abord.

Une seule requete, a la demande, jamais en boucle. /releases/latest ignore d'office brouillons et preversions : personne n'est pousse vers une version d'essai.

C'est un confort, et il se comporte comme tel

La verification ne leve jamais. PlugArr marche parfaitement hors ligne, et un NAS derriere un pare-feu ne doit pas voir une erreur rouge parce qu'il ne joint pas GitHub.

La nuance qui compte : un echec rend « on ne sait pas », jamais « pas de mise a jour ». Les confondre laisserait quelqu'un sur une version perimee en croyant etre a jour. Le quota horaire de l'API publique — 60 requetes — a son propre message plutot qu'un « interdit » trompeur.

Un defaut trouve en lisant le message produit

Il annoncait « vous avez la 0.7.0 » a quelqu'un en 0.6.0 : cli et autoupdate lisaient chacun leur propre __version__, deux lectures separees qui peuvent diverger. Le resultat porte maintenant la version a laquelle la comparaison a ete faite, et c'est elle qu'on affiche.

Trouve en lisant la sortie, pas en relisant le code — les tests passaient.

---

plugarr.exe est attache a cette release. 893 tests.

PlugArr 0.7.0

Reinstaller par-dessus une installation existante ne perd plus les reglages. Demande a l'usage.

C'etait pire que « pas propose »

install construisait sa configuration de zero et ne lisait jamais le stack.yml present. Mesure sur une installation d'essai :

	avant	apres reinstallation
Identifiant	yannick	plugarr
VPN	mullvad + cle WireGuard	desactive
Profils Recyclarr	choisis	vides
Mot de passe console	pose	perdu

Le VPN est le cas grave : il disparaissait en silence, et l'installation affichait meme « Aucun VPN n'est configure ». Quelqu'un qui reinstalle pour reparer autre chose se retrouvait avec son trafic torrent en clair.

La reprise repare un defaut bien plus ancien

qBittorrent, Jellyfin, autobrr et les autres ne stockent leur mot de passe que hache : PlugArr ne pouvait pas le relire, en generait un nouveau, l'annoncait, et le service le refusait. C'est la panne aux messages incomprehensibles de la 0.1.11 — « reponse illisible », « HTTP 401 ».

Mais quand c'est PlugArr qui a installe, le mot de passe est dans son stack.yml. Il n'a jamais eu besoin de le relire ailleurs. Reprendre les identifiants precedents fait donc coincider ce qui est annonce et ce qui est en place. Les ports decales a la main suivent aussi.

Active par defaut, jamais silencieuse

Perdre un VPN en silence est pire que reprendre sans demander. Mais le recapitulatif liste ce qui a ete repris, service par service, et un choix Repartir de zero le refuse :

Installation existante detectee : reglages repris.
  Reglages : identifiant, mot de passe de la console, profils de qualite, VPN (mullvad)
  Identifiants conserves : qbittorrent, sonarr

Une option donnee a la main prime toujours sur l'heritage, sinon elle serait sans effet et personne ne comprendrait pourquoi. --repartir-de-zero en ligne de commande, un choix a l'ecran de recapitulatif dans l'assistant.

Gluetun est couvert par la : tous ses reglages vivent dans stack.yml. Son dossier ${CONFIG_ROOT}/gluetun ne contient que servers.json, un cache de 7 Mo qu'il regenere — verifie, il n'y a rien a y garder.

Un troisieme piege d'heritage d'exceptions

Apres BadZipFile en 0.5.2 : yaml.YAMLError herite d'Exception, pas de ValueError. Un stack.yml corrompu faisait donc remonter l'erreur brute au lieu d'etre traite comme « illisible, on repart de zero ». Converti a la source dans migrations.lire, comme la fois precedente. Trouve par un test ecrit avant le correctif.

L'identifiant a son bouton de copie

Demande a l'usage. On le recopie autant que le mot de passe — dans un formulaire de connexion, juste avant lui — et lui seul n'en avait pas. Il reste affiche en clair : ce n'est pas un secret, c'est le bouton qui manquait. Verifie dans un navigateur, pas seulement dans le HTML.

---

plugarr.exe est attache a cette release. 877 tests.

PlugArr 0.6.0

Une installation ancienne se rattrape en une commande.

plugarr upgrade

PlugArr savait mettre a jour UN service. Il ne savait pas mettre a jour sa propre installation quand c'est lui qui change : quelqu'un qui a installe il y a six mois et telecharge le binaire du jour n'avait aucune commande a lancer.

Quatre etapes, dans cet ordre parce qu'il compte : migrer stack.yml, aligner les images sur le catalogue, regenerer docker-compose.yml et .env, rejouer le cablage. Le cablage passe en dernier — une etape ajoutee depuis peut dependre d'une image plus recente, l'inverse jamais.

On ne redescend jamais une version

Le tag deploye vit dans stack.yml et non dans le code, precisement pour qu'on puisse mettre Sonarr a jour sans attendre PlugArr, ou rester delibrement sur une version ancienne. Un upgrade qui ramenerait tout au catalogue annulerait ce choix sans le dire.

Il ne propose donc que ce qui avance, compare des nombres et non des chaines — 4.9.5 vient avant 4.16.1, ce que l'ordre alphabetique inverse — et affiche ce qu'il ecarte, avec sa raison :

 Images a aligner sur le catalogue
+---------+-----------+-----------+
| Service | Installee | Catalogue |
+---------+-----------+-----------+
| Sonarr  | 3.0.10    | 4.0.19    |
+---------+-----------+-----------+
ignore : radarr : 9.9.9 est deja plus recent que 6.3.0
ignore : prowlarr : maison et 2.5.2 ne se comparent pas

Un service saute en silence donne l'impression d'avoir tout aligne. --dry-run montre le plan sans rien ecrire.

stack.yml portait une version, et rien ne la lisait

Ce n'etait pas un detail d'hygiene. Pydantic ignore les champs qu'il ne connait pas : une version ancienne lisant un stack.yml recent en jetait une partie, et la premiere ecriture la detruisait — install, generate et la rotation d'un mot de passe reecrivent tous ce fichier.

Le cas arrive des qu'on revient en arriere : on essaie une nouvelle version, quelque chose deplait, on relance l'ancien binaire. Rien ne le signalait.

La perte a ete reproduite avant d'etre corrigee :

version lue          : 2
champ futur garde ?  : False
champ futur reecrit ?: False

PlugArr refuse desormais de lire un fichier plus recent que lui :

stack.yml is at version 2, this version of PlugArr reads up to 1.
Update PlugArr: going on would erase the settings it cannot read.

Les migrations tournent sur le dictionnaire brut, avant validation : apres pydantic, « absent » et « valeur par defaut » sont indistinguables, et une migration qui a besoin de cette difference ne peut plus la voir. Un test le verrouille en posant une migration qui ne peut reussir que dans le bon ordre.

Un point de la feuille de route qui ne demandait pas ce qu'il annoncait

« Rejouer les etapes de cablage qui ont change depuis la version installee » supposait de versionner chaque etape et de maintenir cette table a chaque modification — pour ne gagner que du temps d'execution, puisque wire est idempotent par construction. upgrade rejoue tout, et le dit.

---

plugarr.exe est attache a cette release. 860 tests, dont 23 nouveaux.

PlugArr 0.5.2

Un plantage trouve en lancant l'executable publie, pas en relisant le code : tous les tests passaient.

plugarr restore plantait sur un fichier qui n'est pas une archive

BadZipFile: File is not a zip file
[PYI-49480:ERROR] Failed to execute script 'launcher' due to unhandled exception!

zipfile.BadZipFile herite d'Exception, pas de ValueError ni d'OSError. Les deux appelants — la ligne de commande et l'ecran de restauration de l'assistant — attrapaient ces deux-la, et la laissaient donc passer.

C'est exactement la panne que la 0.1.12 avait corrigee pour wire, revenue par une autre porte : une commande qu'on lance justement parce que quelque chose ne va pas, et qui repond par une trace Python.

La conversion se fait maintenant dans lire_manifeste, une fois, plutot qu'en elargissant l'except de chaque appelant. C'est ce qui garantit qu'un troisieme appelant en beneficiera, et un test verifie les deux points.

plugarr restore faux.zip
faux.zip is not a readable archive

Deux messages restaient francais

stack.yml introuvable. Lancez d'abord plugarr install et le tableau du contenu d'une archive. Ils ne se voyaient que la, et seule l'execution du binaire les a fait apparaitre.

---

plugarr.exe est attache a cette release. Aucun changement de configuration.

PlugArr 0.5.1

Le chemin d'ECHEC parle anglais aussi. La 0.5.0 couvrait tout ce qu'on voit quand l'installation se passe bien. Restaient les messages qu'on ne lit que quand quelque chose casse.

Ce qui manquait

qBittorrent n'est jamais devenu disponible
  cause : qBittorrent n'a pas repondu en 300s
  action : verifiez que qBittorrent est demarre

Ces phrases-la vivaient dans quinze modules clients, wiring.py, vpncheck.py et l'orchestrateur, sous forme de WiringError levees profondement dans le code. Elles finissent dans le rapport final et dans plugarr.log — le fichier qu'on demande de joindre a un rapport de bug.

Un utilisateur anglophone tombant sur une panne reelle lisait donc du francais au milieu d'un rapport anglais. C'est desormais :

qBittorrent never became available
  cause : qBittorrent did not answer within 300s
  action : check that qBittorrent is running

Le controle de fuite VPN suit, et c'est celui dont le verdict compte le plus : « NOT PROTECTED: the tunnel exits on YOUR own public address ». Aucune adresse IP n'apparait dans ces phrases, et cela n'a pas change.

Le catalogue dedoublonne, et c'est ce qui rend l'exercice tenable

Le meme « X n'est jamais devenu disponible » servait neuf sites d'appel — qBittorrent, Jellyfin, autobrr, qui, Silo, Audiobookshelf, DroppedNeedle, Seerr, SABnzbd. Une seule entree au catalogue les couvre tous.

540 phrases au total, contre 377 a la 0.5.0. scripts/audit_traductions.py les verifie dans les deux sens et tourne en CI.

Les fichiers ecrits sur le disque aussi

docker-compose.yml, .env, .gitignore, administration.cmd et le script de demarrage automatique portaient un en-tete francais. Ce ne sont pas des messages a l'ecran, mais ils se lisent : on ouvre son .env pour retrouver un mot de passe.

Verifie en les ecrivant pour de vrai, dans les deux langues :

# Generated by plugarr. Holds secrets: NEVER commit it.
# Written by plugarr. These files hold your passwords, your API keys
rem Generated by `plugarr autostart`. Delete this file to stop

Un pluriel perdu, rattrape par un test

Envelopper « 2 deja configures » avait fait disparaitre l'accord francais. Deux cles plutot qu'une : le francais accorde, l'anglais ne change pas, et une cle unique aurait force l'une des deux langues a etre fausse.

Ce qui reste en francais

Deux gabarits HTML et un bloc JavaScript. Ce sont des structures, pas des phrases : les traduire reviendrait a maintenir deux copies d'une page.

---

plugarr.exe est attache a cette release. Aucun changement de configuration : une installation existante garde tout.

PlugArr 0.5.0

PlugArr parle anglais. L'assistant, la ligne de commande, le preflight, le rapport et la page d'acces, avec un menu de langue sur l'ecran d'accueil.

Deux langues, et elles cessent de se confondre

	Ou	Ce que ca change
Langue de PlugArr	ecran d'accueil, ou --lang fr|en	l'assistant, la ligne de commande, le rapport, la page d'acces
Langue des services	ecran des chemins, ou --langue <code>	ce que Sonarr, Radarr, Prowlarr, Jellyfin et Silo afficheront dans leur interface

Le second reglage existait depuis la 0.1.11. Mais il etait seul, donc ambigu : l'ecran annoncait « langue des interfaces » sans dire lesquelles, et rien ne disait que PlugArr, lui, ne parlait que francais.

Sans rien regler, PlugArr suit la langue du systeme : un francophone le trouve en francais, tout le monde d'autre en anglais. Le choix est retenu dans stack.yml, donc plugarr serve et plugarr doctor repondent ensuite dans la langue de l'installation, meme sur un serveur dont la session est en anglais.

Rien n'oblige a garder les deux ensemble : on peut vouloir l'outil en anglais et sa mediatheque en francais.

La cle de traduction est la phrase francaise

Inventer des cles (ecran.accueil.titre) ajoute un dictionnaire a tenir, et une cle mal orthographiee s'affiche telle quelle a l'utilisateur. Ici une phrase absente du catalogue retombe sur le francais, comprehensible au pire.

Et les widgets traduisent au passage plutot que phrase par phrase. Envelopper cent-cinquante appels a la main aurait pose la question a chaque ligne ecrite : la vraie question n'aurait pas ete de savoir si on en oublierait, mais combien. Une phrase oubliee ne casse d'ailleurs rien — elle s'affiche simplement en francais a quelqu'un qui a demande l'anglais, sans erreur ni avertissement.

C'est pour ca que le garde-fou est mecanique. scripts/audit_traductions.py releve les 377 phrases affichables — appels a t(), libelles de widgets, notes du catalogue, sous-titres d'ecran, origines des PUID/PGID — et echoue s'il en manque une ou si le catalogue porte une entree morte. Il tourne en CI, et il a deja attrape une entree posee deux fois.

Un defaut que seul un vrai montage pouvait reveler

Select attend (libelle, valeur) et recevait (valeur, libelle). Le code fr devenait alors illegal, et l'assistant mourait au montage de l'ecran d'accueil. Tous les tests passaient.

Les captures existent dans les deux langues

Le README anglais montrait jusqu'ici des captures francaises, ce qui annulait le travail de traduction pour le seul lecteur a qui il s'adresse. scripts/screenshots.py produit desormais les deux jeux.

Et la console d'administration a enfin une image. C'est la seule partie du produit qu'on garde apres l'installation — on la rouvre pour retrouver un port, un mot de passe, ou pour arreter un service — et elle n'apparaissait nulle part. screenshots.py ne pouvait pas la produire : il exporte des ecrans Textual, elle est du HTML servi par plugarr serve. Elle a maintenant son propre script, avec les memes precautions : secrets d'illustration, adresse de machine fixe, et date figee — celle du jour rendrait le fichier different a chaque execution.

Deux libelles ne se voyaient que la, et sont restes francais jusqu'a ce qu'on regarde : les boutons de chaque service et l'etat en cours de verification.

Ce qui reste en francais

Environ 140 chaines, presque toutes des messages d'erreur : « qBittorrent n'est jamais devenu disponible », « le config.xml pre-seme a peut-etre ete ecrase ». Le chemin nominal est entierement couvert ; ce sont les chemins d'echec qui ne le sont pas encore.

---

plugarr.exe est attache a cette release, construit et controle par la CI. Aucun changement de configuration : une installation existante garde tout, et lit sa langue depuis son stack.yml.

PlugArr 0.3.0

Deux services de plus, cables et verifies contre des instances reelles : Audiobookshelf et Seerr. Quatorze au total.

Et un defaut de PlugArr trouve en les integrant, qui touchait tout le monde depuis le debut.

Les identifiants des *arr n'etaient pas appliques sans redemarrage

PUT config/host repond 202, accuse reception, et ne change rien avant que l'application reparte. Sonarr et Radarr restaient donc inaccessibles avec les identifiants annonces, alors que tout paraissait pose : methode d'authentification relue a « forms », mot de passe present.

Ecarte par l'experience plutot que par raisonnement : ce n'est pas une question de caracteres speciaux dans le mot de passe genere — un mot de passe purement alphanumerique etait refuse exactement pareil. Un redemarrage, et la connexion passe.

C'est le meme piege que pour la cle API, ou seule la reecriture du config.xml suivie d'un redemarrage fonctionnait. L'etape redemarre desormais le conteneur et reverifie.

Audiobookshelf

Il remplit books et audiobooks, les deux bibliotheques que PlugArr rangeait depuis la 0.1.12 sans que personne ne les lise. Compte, deux bibliotheques et leurs analyses, poses et relus.

Les medias sont montes en lecture seule : il lit, il n'organise pas. Et /metadata est un volume distinct de /config — les confondre gonflerait les sauvegardes de centaines de Mo pour rien.

Trois pieges releves contre une instance reelle, et deux d'entre eux etaient des artefacts de ma propre mesure avant d'etre compris :

• il met quarante secondes a demarrer — migrations, declencheurs SQLite, ANALYZE. Sonde plus tot, / repond 404 et on conclut a une image cassee ;
• sa base SQLite se lit avec son journal -wal, ou pas du tout. Sans lui, la table users parait vide pendant que /status annonce isInit: true ;
• POST /init ne rend AUCUN jeton. 200 avec un corps vide, la ou l'accueil de Silo en renvoie deux. Sans connexion explicite ensuite, l'appel suivant repond 401.

Seerr

Successeur commun de Jellyseerr et d'Overseerr. Il declare Sonarr et Radarr, dossier anime compris, puis ferme son accueil en dernier : l'inverse laisserait une instance qui se croit prete et ne peut rien demander.

Son compte administrateur EST le compte Jellyfin. PlugArr ne lui genere aucun mot de passe : en annoncer un serait mentir.

Son image embarque sa propre specification OpenAPI et valide chaque corps contre elle. Confortable — un champ manquant est nomme dans la reponse — mais elle ment par omission, et chaque message renvoyait ailleurs que la cause :

erreur recue	cause reelle
INVALID_URL	hostname est l'hote SEUL ; port, useSsl, urlBase sont lus mais non declares
NO_ADMIN_USER	serverType est obligatoire, la specification le donne pour facultatif
hostname already configured	l'adresse n'est acceptee qu'UNE fois — l'omettre au premier appel rend l'erreur inverse

Trois essais reels et la lecture de son code compile pour les trouver.

Verifie, pas suppose

Installation complete depuis l'executable, relue depuis les applications :

15/15 liens etablis
Sonarr   sonarr:8989  dossier=/data/media/tv   anime -> /data/media/anime
Radarr   radarr:7878  dossier=/data/media/movies  disponibilite -> released
accueil ferme : True

Restent a venir

Shelfarr — desormais possible, il a besoin d'Audiobookshelf comme destination. Puis Shelfmark.

DroppedNeedle reste bloque, et pas par moi : il telecharge par slskd ou SABnzbd, aucun des deux au catalogue. L'inscrire aujourd'hui donnerait un service incapable de telecharger quoi que ce soit.

---

769 tests. Feuille de route : ROADMAP.md.

PlugArr 0.2.1

Votre configuration se sauvegarde et se restaure. C'est le filet qui manquait : jusqu'ici, reinstaller signifiait ressaisir tous vos indexeurs, vos profils et vos bibliotheques.

Ce qui est archive, et pourquoi

PlugArr regenerait deja tout ce qu'il avait genere — mots de passe, cles API, ports, tous dans stack.yml. Il ne savait rien de ce que vous aviez saisi ensuite : vos indexeurs vivent dans la base de Prowlarr, vos profils dans celle de Sonarr. C'est cela qu'une reinstallation perdait.

Trois emplacements, et le troisieme est celui qu'on oublie :

Le repertoire du projet	stack.yml, .env, docker-compose.yml — sans eux, aucun service ne se rouvre
CONFIG_ROOT	vos indexeurs, vos profils, votre travail
Les volumes Docker	la base de Silo n'est pas sous CONFIG_ROOT

Une sauvegarde qui n'archive que des dossiers aurait manque la base de Silo en silence, et la restauration aurait rendu un Silo qui redemarre en boucle. Le genre d'oubli qui ne se revele que le jour ou l'on en a besoin.

Les conteneurs sont arretes pendant la copie. Une base SQLite copiee a chaud donne un fichier valide en apparence et inutilisable en pratique. --live existe pour qui accepte ce risque ; le manifeste le consigne et la restauration en avertit.

DATA_ROOT n'est jamais touche. Vos medias ne sont pas une configuration.

Le test qui compte

Verifie sur une pile reelle, pas simule. Un temoin pose dans Sonarr, sauvegarde, destruction totale — conteneurs, volumes, dossiers — puis restauration vers un autre chemin :

TEMOIN RETROUVE : True
plugarr-silo : Up 40 seconds (healthy)     des le premier demarrage
12/12 liens etablis, 0 crees a ce passage

Zero cree. Apres restauration, tout le cablage existait deja.

La restauration est dans l'assistant

Elle avait d'abord ete laissee en ligne de commande, au motif qu'un bouton serait dangereux. L'argument etait faible : la ligne de commande a exactement le meme pouvoir.

La vraie raison designe le bon endroit. La console d'administration commence par lire un stack.yml ; sur une machine fraichement formatee il n'y en a pas, puisque c'est ce que l'archive contient. Un bouton la-bas aurait ete inutilisable dans le seul cas ou il sert.

L'assistant, lui, demarre sans rien. Restaurer une sauvegarde est donc propose des son premier ecran. Un bouton Examiner l'archive montre date, pile, services et emplacement d'origine avant d'ecraser quoi que ce soit, et signale une archive prise a chaud. Le bouton Restaurer reste inerte tant que l'examen n'a pas reussi.

Un champ permet de reposer la configuration ailleurs que son emplacement d'origine, les chemins etant reecrits — pour un changement de machine ou de lettres de lecteur.

La sauvegarde, elle, a son bouton sur la page d'administration.

Aussi

Les empreintes des cinq prochains services sont relevees et epinglables : Seerr, Audiobookshelf, Shelfarr, Shelfmark, DroppedNeedle. Un obstacle reel est documente sur Audiobookshelf, dont l'initialisation ne correspond pas a sa documentation — il n'entrera au catalogue qu'une fois cable et verifie.

---

740 tests. Feuille de route : ROADMAP.md.

PlugArr 0.2.0

arrsenal devient PlugArr. Le nom disait « un tas d'outils », ce que propose n'importe quel depot de compose *arr. Ce qui distingue ce projet est qu'il les branche ensemble.

L'ancienne URL du depot redirige : vos liens et vos douze anciennes versions continuent de fonctionner.

Ce qui change pour vous

	avant	maintenant
Executable	arrsenal.exe	plugarr.exe
Conteneurs	arrsenal-sonarr	plugarr-sonarr
Icone	aucune	sept tailles, 16 a 256 px

Vos installations existantes ne sont pas touchees. Leur nom de pile est ecrit dans leur stack.yml : elles gardent leurs conteneurs arrsenal-* et continuent de tourner. PlugArr lit les DEUX marqueurs, plugarr.managed et arrsenal.managed, donc scan et adopt les reconnaissent toujours.

Ce point etait le seul vrai risque du renommage. discovery.py identifie les piles par un label et jamais par leur nom — un choix pris apres que des heuristiques de nom eurent produit des faux positifs. Renommer ce label aurait rendu chaque installation existante invisible, et une installation qu'un outil ne voit plus est une installation qu'il proposera de recreer par-dessus.

L'executable a enfin une icone

Il n'en avait aucune : Windows lui collait celle, generique, de tout binaire console.

Elle est engendree par un script, scripts/icone.py, et non commitee comme un binaire opaque que personne ne peut relire. Deux decisions y sont documentees :

• fond transparent, pas la tuile sombre. Une tuile anthracite gravee dans l'icone devient une tache noire sur une barre des taches claire, au milieu d'icones qui, elles, savent s'adapter ;
• le canal alpha vient de la chroma, pas de la luminosite. Le fond du visuel est un gris neutre et la marque est saturee : la distance a l'axe des gris les separe proprement. Un seuil de luminosite mangeait le bas du jambage violet.

L'assistant aux couleurs de la marque

Textual construit toutes ses nuances a partir du theme : poser les trois couleurs du logo suffit a teindre chaque ecran. Les captures de la documentation sont regenerees.

Sous le capot

Le renommage mecanique a casse toutes les elisions francaises — « qu'arrsenal sait faire » devenait « qu'plugarr sait faire ». Vingt-cinq occurrences, reparees une a une.

Verifie de bout en bout depuis l'executable renomme : 19 liaisons sur 19, conteneurs plugarr-*, 717 tests.

---

Tout le contenu de la 0.1.12 est inclus : le controle de fuite VPN, les huit bibliotheques, le lecteur RSS de qBittorrent, et les trois pannes de cablage sous tunnel.

Feuille de route : ROADMAP.md.

arrsenal 0.1.12

Huit bibliotheques dont l'anime, le lecteur RSS de qBittorrent allume, et arrsenal verifie enfin que votre trafic torrent sort bien par le VPN.

Le VPN, verifie et non promis

arrsenal ecrivait network_mode: service:gluetun dans le compose et considerait l'affaire close. Or ce reglage se perd : une installation lancee par-dessus une pile existante, depuis une configuration sans VPN, recree les clients torrent sur le reseau nu. Sans un mot.

arrsenal doctor et le bouton diagnostic font desormais trois controles :

1. la structure du conteneur — hors ligne, instantanee ;
2. la sortie reelle, demandee au serveur de controle de Gluetun depuis l'interieur du client torrent. Ce test ne peut pas reussir par accident : seul un conteneur partageant la pile reseau de Gluetun voit ce 127.0.0.1. Verifie dans les deux sens ;
3. le tunnel ressort-il ailleurs que chez vous ? Un tunnel qui reboucle sur la connexion du domicile ne protege de rien, et les deux premiers controles le declarent pourtant bon.

Aucune adresse IP n'est journalisee, ni celle du tunnel ni la votre. Le journal est le fichier qu'on demande de joindre aux rapports de bug.

Trois pannes sous VPN, meme racine

Un client torrent sous VPN passe en network_mode: service:gluetun : il perd son nom sur le reseau, c'est gluetun qu'il faut viser. Trois endroits l'ignoraient.

ECHEC prowlarr/downloadclient/transmission
  Unknown exception: Name does not resolve (transmission:9091)

Sonarr, Radarr et Lidarr se cablaient tres bien sur les MEMES clients au meme instant, ce qui rendait la panne illisible. Flood, lui, repondait « impossible de se connecter au client ».

Verifie sur un vrai tunnel, monte pour l'occasion — serveur WireGuard local, gluetun en fournisseur custom : 11 liaisons sur 11.

Huit bibliotheques

Films, series, anime, musique, spectacles, livres, livres audio et logiciels. Chacune a son dossier de telechargement, son dossier de rangement et sa categorie qBittorrent qui envoie l'un vers l'autre. Les quatre dernieres n'ont pas encore d'application qui les pilote, et arrsenal ne pretend pas le contraire : elles rangent les telechargements manuels.

Sonarr recoit deux dossiers racine. Ce n'est pas du rangement : Sonarr traite l'anime comme un type de serie a part, avec ses propres conventions de nommage, et melanger les deux fait renommer les series normales selon des regles anime.

Le lecteur RSS de qBittorrent

Le piege, verifie contre une 5.2.3 installee par arrsenal :

rss_processing_enabled       = True
rss_auto_downloading_enabled = False   <- eteint

Le moteur est livre actif mais le telechargement automatique eteint. Une regle ecrite dans cet etat ne se declenche jamais, et rien ne l'explique. C'est desormais allume. arrsenal n'ajoute ni flux ni regle : ils dependent de vos traqueurs, exactement comme les indexeurs.

Sept autres corrections

• Une seconde installation ecrasait la premiere. Docker identifie une pile par son nom, jamais par son repertoire, et ce nom etait fige. Le preflight rassurait meme : « port occupe par votre propre pile arrsenal », vrai du nom et faux de l'installation. --project-name existe, l'assistant le demande, le preflight avertit.
• La console d'administration n'avait plus aucun JavaScript depuis la 0.1.8. Une chaine ouverte sur deux lignes et trois apostrophes francaises non echappees emportaient le script entier. Demarrer, arreter, redemarrer, faire tourner une cle : rien ne repondait. Le HTML etait pourtant bien forme et tous les tests passaient — il a fallu ouvrir la page dans un navigateur.
• Une bibliotheque ajoutee n'atteignait pas les installations existantes. install cree l'arborescence, wire non, et Sonarr refuse un dossier racine absent.
• wire n'attendait pas que les services soient prets et rendait une trace Python quand l'attente expirait.
• arrsenal promettait un .gitignore qu'il n'ecrivait pas.
• La cle privee WireGuard et le mot de passe de Flood etaient en clair dans docker-compose.yml. Ils passent par le .env.
• Le conseil de fin citait Prowlarr meme absent.

Deux boutons sur la console

Un diagnostic, qui n'existait qu'en ligne de commande. Et une recherche de mises a jour : elle tournait deja toutes les quinze minutes, mais en silence, sans qu'on puisse la declencher ni savoir quand elle avait eu lieu.

---

713 tests. Feuille de route : ROADMAP.md.