Compiler Transmission de A à Z sur votre NAS

Le film ci-dessous est une exécution réelle de Bucket & Code Server IDE 1.0.0-55 sur un NAS où rien n'est encore configuré. Il commence à l'écran de première configuration et se termine par le paquet QTS Transmission signé et installé, qui répond dans le navigateur, puis par le téléchargement d'une compilation arm_64 du même paquet. Ce guide parcourt le film chapitre par chapitre : ce que fait la personne, ce que montre l'écran et ce que vérifie le script.

Walkthrough · 6:26. Transmission de A à Z, de la première configuration au paquet arm_64 Bucket & Code Server IDE 1.0.0-55 · NAS x86_64

Préparermodules, environnement, runtimes
ProjetPaquet à partir des sources
Recettescinq, la passerelle, le service
Compilerdeux apps, make qpkg
Installersignature, déploiement de test, arm_64

Les images sont des plans extraits de l'exécution, du panneau et de l'éditeur ; seules les tuiles de la Vue d’ensemble proviennent de la version 1.0.0-62. L'adresse et le nom du NAS sont masqués dans chaque image et apparaissent sous la forme nas.local et NAS.

01Ce que montre le film, ce qu'il vous faut

L'exécution a duré 25 min 7 s ; le film dure 6:26. Il coupe le milieu de toute attente de plus de 10 secondes et indique à l'endroit de la coupure la durée réelle de l'attente. Tout passage de plus de 10 secondes sans clic est lu à quatre fois la vitesse et signalé par 4×.

Un script pilote le navigateur : il clique dans le panneau, tape chaque fichier du projet terminé dans l'éditeur et vérifie chaque étape auprès de l'API du panneau avant de passer à la suivante. Le panneau, l'éditeur, la compilation et les paquets sont réels. Le projet terminé est l'exemple Transmission (client BitTorrent, recettes propres), sous Projets de l’éditeur, sur l'onglet Exemples de la page Apps ; Voir le code en montre les fichiers.

Un NAS avec Bucket & Code Server IDE 1.0.0-55 ou plus récent, sur un processeur x86_64. Le paquet arm_64 est une compilation croisée faite sur ce NAS.
Un compte administrateur dans le panneau. Sur une nouvelle installation, l'écran de première configuration le crée.
Un accès à Internet pour le NAS : il télécharge le système de fichiers racine de l'environnement de compilation, les toolchains et les sources des recettes, et vérifie chaque téléchargement par son sha256.
Pour le paquet signé, un certificat de signature de code que QNAP vous a délivré (section 07).

02Première configuration

Film 0:00 · dans l'exécution 4 s

Une nouvelle installation n'a aucun compte, donc le panneau s'ouvre sur un seul écran, Définir le mot de passe administrateur, pour le compte administrator. Saisissez deux fois un mot de passe d'au moins 10 caractères et appuyez sur Définir le mot de passe et se connecter. L'écran accepte le mot de passe pendant 60 minutes après le démarrage du paquet, et seulement depuis le réseau local.

Le script vérifie que le panneau est connecté en tant que administrator et ne réclame plus de premier administrateur.

03Modules, environnement, Go, Python et QDK

Film 0:06 · dans l'exécution 59 s

La page Vue d’ensemble montre chaque module sous forme de tuile, et une nouvelle installation n'exécute que le cœur. Activez Git (Forgejo) et l'Éditeur (VS Code dans le navigateur) avec leurs interrupteurs jusqu'à ce que les deux tuiles indiquent en cours. Chaque compte du panneau a un compte Forgejo du même nom, donc l'assistant de nouveau projet propose désormais administrator comme propriétaire d'un dépôt.

La vue d'ensemble de Bucket & Code Server IDE 1.0.0-62 sur x86_64 : les tuiles Git, SVN & Bucket et Éditeur en cours

Sur la page Toolchains, la liste des environnements est vide et propose le builder Ubuntu 24.04 avec un seul bouton, Créer cet environnement. L'environnement ubuntu2404-builder est là au bout de 22 secondes. Dans le catalogue en dessous, Installer ajoute Go 1.27 et Python 3.13 (onglet Runtimes) ainsi que QNAP QDK 2.5.0 (onglet QNAP). Go compile la passerelle du projet, Python exécute l'outil qui écrit la liste vendor de l'interface web, et QDK empaquette les paquets QTS.

Toolchains : l'environnement ubuntu2404-builder et, dans le catalogue, QNAP QDK 2.5.0 (qbuild) marqué comme installé

Le script vérifie que Git et l'Éditeur sont en cours d'exécution, que ubuntu2404-builder figure dans la liste des environnements et que go-1.27-x86_64, python-3.13-x86_64 et qdk-2.5.0-x86_64 sont installés.

04Nouveau projet

Film 0:52 · dans l'exécution 24 s

Sur la page Projets, Nouveau projet demande d'abord le modèle. Choisissez Paquet à partir des sources et nommez le projet Transmission ; le nom devient celui du paquet. À l'étape Service, choisissez Application web : un service en arrière-plan avec son port web et le bouton Ouvrir de l'App Center. L'étape Compilation ne demande aucun environnement : la ligne ENV du Makefile du projet donne aux deux apps le builder Ubuntu 24.04. Laissez Compiler juste après la création désactivé, parce que la recette de départ désigne encore une source factice et qu'une première compilation échouerait. Créer le projet crée le dépôt Forgejo avec son premier commit.

Nouveau projet, étape Progression : Paquet à partir des sources, Transmission ; dépôt Forgejo et premier commit terminés ; Ouvrir le projet, Ouvrir dans l’éditeur et Ouvrir dans Forgejo

Ouvrir dans l’éditeur ouvre le projet dans l'éditeur. Son dossier contient recipes/transmission/ (la recette de départ), recipes.txt, un Makefile pour deux apps, licenses.txt, qpkg/ et scripts/. Le script vérifie que le pipeline du projet liste les apps transmission et transmission-arm64 et que l'Explorateur montre recipes.

05Les recettes

Film 1:18 · dans l'exécution 12 min 12 s

La bibliothèque n'a pas de recette pour Transmission ni pour son interface web, le projet apporte donc cinq recettes à lui dans recipes/, chacune dans un dossier avec recipe.json et build.sh : ces deux-là, plus libnatpmp, miniupnpc et libdeflate, que la bibliothèque a aussi ; dans les applications du projet, les copies du projet remplacent celles de la bibliothèque. curl, OpenSSL, zlib et libevent viennent de la bibliothèque. Votre première recette explique les deux fichiers.

La recette de départ · 14 s

recipes/transmission/recipe.json reçoit l'archive de la version 4.1.3 de Transmission avec son sha256, les recettes dont elle a besoin (curl, OpenSSL, zlib, libevent, libnatpmp, miniupnpc et libdeflate), l'édition de liens statique et une vérification. build.sh lance CMake pour le démon et pour transmission-remote, transmission-create, transmission-edit et transmission-show, avec les tests, les traductions et la documentation désactivés.

Quatre autres recettes · 1 min 17 s

Dans la palette de commandes, Bucket: New recipe demande un nom et écrit les deux fichiers à partir de la recette de départ. Le script crée ainsi libnatpmp 20230423, miniupnpc 2.3.3, libdeflate 1.26 et transmission-web 4.1.3 et remplit pour chacune la source, le sha256 et les étapes de compilation. Transmission lie les trois bibliothèques sous forme d'archives statiques. L'interface web est du HTML, du CSS et du JavaScript, construits à partir de web/ de la même archive de version.

L'éditeur : le dossier recipes du projet avec libdeflate, libnatpmp, miniupnpc, transmission et transmission-web, et le build.sh de transmission-web ouvert

La liste vendor · 1 min 7 s

esbuild et Sass construisent l'interface web, et recipes/transmission-web/vendor.txt fige leurs paquets npm, une ligne par paquet avec le sha256, l'adresse et la destination. Le terminal de l'éditeur écrit le fichier à partir du package-lock.json de la version, et l'outil signale 30 files: 30 checked against the lockfile's sha512. Le fichier terminé compte 41 lignes, dont 11 de commentaires.

eval "$(bvs use python-3.13-x86_64)"
python3 /usr/bin/bucketvs/share/bucketvs/tools/npm-vendor.py package-lock.json CACHE-DIR \
  --dev --roots esbuild esbuild-sass-plugin fast-deep-equal \
  --platform linux-x64-glibc --platform linux-arm64-glibc --allow-install-scripts \
  > recipes/transmission-web/vendor.txt

build.sh contient le sha256 du fichier entier, et la compilation vérifie chaque paquet une seconde fois avant de le décompresser. npm ne s'exécute jamais, et aucun script d'installation ne s'exécute.

La liste des recettes, la passerelle, les scripts, les licences et les icônes · 6 min 38 s

recipes.txt nomme ce que construisent les deux apps : transmission, transmission-web et cacert, le lot de certificats CA contre lequel curl vérifie les trackers HTTPS. L'App Builder ajoute ce dont chacune a besoin.

gate/ contient trgate, un programme Go sans module extérieur. Les réglages par défaut de Transmission n'ont pas de mot de passe et n'acceptent les appels RPC que depuis le NAS lui-même ; ouvert au réseau sans mot de passe, il servirait quiconque atteint le port 9091. Le paquet ne démarre donc transmission-daemon qu'une fois un mot de passe choisi : trgate occupe le port et y sert une page de configuration, écrit le mot de passe sous la forme salée que Transmission stocke, puis lance le démon sur le même port. Le paquet ne génère aucun mot de passe, donc aucun n'est écrit dans un fichier ni dans les journaux système de QTS.

scripts/make-qpkg.sh est l'empaqueteur du modèle, dont trois endroits sont remplis : KEEP, les chemins que le paquet prend dans chaque app ; own_programs, qui construit trgate pour chaque architecture ; et own_licences, qui ajoute les textes de licence que licenses.txt ne peut pas fournir. licenses.txt indique la licence de chaque recette que le paquet contient, et LICENSE est la licence du code propre du projet. Le script tape ces dix fichiers. Les trois icônes de qpkg/icons/ y sont ajoutées avec Upload..., sur ce dossier dans l'Explorateur.

Le service · 40 s

Dans la vue du projet, la carte Service et paquet contient les blocs qui écrivent le script de démarrage et d'arrêt du paquet, et les clés de qpkg.cfg. En partant du préréglage Application web, le script aboutit à neuf blocs : le dossier de données Transmission sur le volume ; le compte transmission dans le groupe arr, propriétaire de ce dossier (mode 700) ; le port web 9091 ; trgate comme démon du compte, avec 40 secondes pour s'arrêter ; une attente du port 9091 ; une ligne de journal ; et les contrôles d'état running et port_open. L'onglet Paquet règle le nom affiché Transmission, la version 4.1.3, le chemin de la page web /transmission/web/, le port web 9091 et 60 secondes d'attente de QTS au démarrage et à l'arrêt. Enregistrer montre le plan avec le diff de chaque fichier, et Faire le commit le valide.

La carte Service et paquet, onglet Paquet : nom affiché Transmission, version 4.1.3, chemin de la page web /transmission/web/, port web 9091, 60 secondes au démarrage et à l'arrêt

La vérification · 30 s

Chaque enregistrement vérifie les recettes du projet et liste les constats dans la vue Problèmes. Le script attend No problems have been detected in the workspace, et le rapport du projet liste alors cinq recettes et aucune erreur. make lint donne les mêmes constats dans le terminal.

Commit et push · 1 min 42 s

Dans le Contrôle de code source, le script indexe toutes les modifications, les valide sous le message Transmission from source et les pousse. Le dépôt distant du projet est son dépôt Forgejo en HTTPS, donc l'éditeur demande le nom et le mot de passe du compte, que Forgejo partage avec le panneau. Le script attend qu'il ne reste rien de non validé et que rien ne devance le dépôt distant, puis relit les trois icônes depuis Forgejo et les compare octet par octet à celles du projet.

06Compilation et make qpkg

Film 5:13 · dans l'exécution 10 min 1 s

Compiler dans la vue du projet exécute le Makefile du projet. Il compile les deux apps l'une après l'autre dans le builder Ubuntu 24.04, toutes deux en statique : transmission pour le processeur x86_64 de ce NAS et transmission-arm64 pour aarch64, en compilation croisée. Chaque app compile 13 recettes dans l'ordre de leurs dépendances : cacert, OpenSSL, zlib, nghttp2, zstd, c-ares, curl et libevent de la bibliothèque, puis libnatpmp, miniupnpc, libdeflate, transmission et transmission-web du projet. Cela a pris 8 min 1 s. Les vérifications de la compilation croisée ne s'exécutent que là où qemu-user est enregistré ; ailleurs, la compilation les note comme non exécutées. Le script vérifie que les dernières compilations des deux apps sont terminées et désignent le projet Transmission.

La vue du projet après la compilation : Build terminé, et le panneau Sortie avec les lignes the App Builder built transmission et the App Builder built transmission-arm64

Les paquets se construisent dans le terminal de l'éditeur, dans le dossier du projet (2 min 0 s). Go doit être dans le chemin, parce que make qpkg construit trgate pour chaque architecture :

eval "$(bvs use go-1.27-x86_64)"
make qpkg

make qpkg empaquette avec QDK la dernière compilation réussie de chaque app et écrit Transmission_4.1.3_x86_64.qpkg et Transmission_4.1.3_arm_64.qpkg dans build/qpkg/build/, d'environ 30 Mo chacun. Un paquet contient les cinq programmes de Transmission, trgate, l'interface web, le lot de certificats CA, le BusyBox que la compilation ajoute à chaque paquet, et share/licenses/ avec un NOTICE et les textes de licence de chaque composant.

07La signature

Pas dans le film · dans l'exécution 3 s

C'est la seule étape hors du panneau. Le déploiement de test n'installe que des paquets signés et ne contourne jamais la vérification de signature de l'App Center, et le NAS de l'exécution n'a aucun fichier de signature de code, donc make qpkg a construit les deux paquets sans signature. Le script les copie sur un ordinateur qui détient un certificat de signature de code que QNAP a délivré à l'auteur de ce guide, les y signe avec qbuild de QDK, vérifie les signatures et recopie les paquets dans build/qpkg/build/. Le certificat et sa clé privée ne vont jamais sur le NAS. La liste Versions marque ensuite les deux paquets comme signés.

Versions : Transmission_4.1.3_arm_64.qpkg et Transmission_4.1.3_x86_64.qpkg, tous deux marqués comme signés

Vous signez avec un certificat à vous. Placez certificate et private_key, ainsi que ca_certs pour la chaîne, à côté de qpkg/qpkg.cfg ou dans le dossier que nomme QPKG_CERT_DIR, et make qpkg signe lui-même les paquets ; le .gitignore du modèle garde ces fichiers hors de git. Sans eux, les paquets ne sont pas signés et le déploiement de test les refuse. Ce qu'un NAS fait d'un paquet non signé relève de la décision de son propriétaire dans l'App Center, et ce guide ne recommande pas d'installer des paquets non signés.

08Déploiement de test et première connexion

Film 5:53 · dans l'exécution 32 s

Sur la page du projet, Déploiement de test (réservé aux administrateurs) installe le paquet x86_64 sur ce NAS avec qpkg_cli, comme l'App Center installe un fichier, et la tâche attend que l'App Center confirme. Le paquet reste installé jusqu'à ce que vous le retiriez avec Supprimer de ce NAS ou dans l'App Center. La tâche a duré 18 s.

La vue du projet après le déploiement de test : 4.1.3 installé sur ce NAS, Transmission 4.1.3 installé, et les lignes de qpkg_cli dans le panneau Sortie

Ouvrez http://<NAS>:9091/, ou appuyez sur Ouvrir dans l'App Center. La page de la passerelle, Choose the web interface password, demande un nom d'utilisateur (admin sauf si vous le changez) et deux fois le mot de passe, d'au moins 8 caractères. Appuyez sur Start Transmission. La page indique que Transmission démarre, puis transmission-daemon prend le port et le navigateur demande le nom d'utilisateur et le mot de passe que vous avez choisis. La page les accepte pendant 60 minutes après le démarrage du paquet, depuis un ordinateur du réseau propre au NAS, par l'adresse IP du NAS ou par son nom.

Une fois connecté, le navigateur affiche l'interface web de Transmission sans aucun transfert. Le script vérifie que le titre de la page est Transmission Web Interface et que le RPC indique la version 4.1.3 (838877323f).

09Le paquet arm_64

Film 6:20 · dans l'exécution 23 s

Un clic droit sur la ligne arm_64 de la liste Versions ouvre son menu, et Télécharger enregistre Transmission_4.1.3_arm_64.qpkg (30 290 058 octets). Le script compare la taille du fichier à celle de la liste.

Un NAS x86_64 ne peut pas exécuter ce paquet, donc le script le vérifie sous émulation. scripts/qemu-test.sh décompresse le téléchargement sur un ordinateur Linux où qemu-user est enregistré et l'y exécute. Les 22 vérifications réussissent en 19 s :

les programmes sont des exécutables AArch64 statiques, et BusyBox et transmission-daemon s'exécutent ;
la passerelle sert la page de configuration, transmission-daemon ne tourne pas avant que le mot de passe soit défini, et un POST sans l'en-tête de la page est refusé (403) ;
après la configuration, le RPC répond, session-get indique la version 4.1.3, un mauvais mot de passe est refusé (401), l'interface web répond, et ni la sortie ni settings.json ne contient le mot de passe ;
transmission-daemon récupère le .torrent netinst de Debian en HTTPS, ce qui exige le lot de certificats CA du paquet, puis le torrent est supprimé ;
un TERM envoyé à la passerelle termine transmission-daemon, et la passerelle se termine avec 0.

Dans cette exécution, aucun NAS ARM n'a fait tourner le paquet.

10Guides connexes

Votre première recette parcourt la recette de départ, la vérification et make qpkg avec un petit programme, cmatrix.
Une app personnalisée à partir de vos recettes construit une app de l'App Builder qui utilise les recettes d'un projet en plus de celles de la bibliothèque.
Transmission dans l'App Center est l'exemple publié. Son paquet x86_64 vient d'une exécution antérieure du même script sur 1.0.0-55 ; son SHA-256 figure sur cette page.
Le guide de l'utilisateur de Bucket & Code Server IDE décrit Nouveau projet, la vue du projet, Toolchains, l'App Builder et la signature de code d'un paquet.