GPTWOL peut fonctionner sur ZimaOS en tant qu’application Docker personnalisée, mais l’élément important du fichier YAML de la communauté ne réside pas dans les anciens identifiants d’exemple. L’application a besoin du réseau de l’hôte pour envoyer des paquets Wake-on-LAN sur le réseau local, d’un stockage persistant pour sa base de données et ses données cron, ainsi que d’un port Web qui n’est pas déjà utilisé par un autre service.
Le fil de discussion de janvier 2026 constitue un instantané utile d’une configuration fonctionnelle, mais GPTWOL et ZimaOS ont tous deux évolué. La documentation actuelle de GPTWOL exige toujours le réseau de l’hôte pour le Wake-on-LAN, tandis que les versions récentes de ZimaOS proposent un flux YAML plus complet. Considérez le fichier source comme un point de départ et vérifiez les options actuelles en amont avant de l’importer.
Ce que le fichier YAML de la communauté configurait
La définition d’application partagée utilisait l’image misterbabou/gptwol:latest, network_mode: host et restart: unless-stopped. Elle assurait également la persistance de l’état de GPTWOL dans deux dossiers de l’hôte montés dans /app/db et /etc/cron.d.
La configuration source exposait l’interface GPTWOL sur le port 99 et définissait un fuseau horaire pour les tâches de réveil planifiées. Ces valeurs ne sont pas universelles. Choisissez un port libre sur l’hôte et utilisez le fuseau horaire correspondant à la machine qui exécute le conteneur.
Pourquoi GPTWOL utilise le réseau de l’hôte
La documentation actuelle en amont de GPTWOL indique que le conteneur doit utiliser le mode réseau de l’hôte pour envoyer des commandes Wake-on-LAN sur le réseau local. Cela diffère d’une application Web ordinaire, qui peut souvent rester isolée derrière le réseau bridge de Docker et un seul port publié.
Le réseau de l’hôte modifie également la manière dont il faut considérer les ports. L’application écoute directement sur le réseau de l’hôte ZimaOS, le port sélectionné pour GPTWOL doit donc être libre. Si la page Web ne s’ouvre pas, vérifiez le port configuré et assurez-vous qu’aucun autre service ne l’utilise avant de modifier des paramètres non liés du routeur.
Configuration Docker actuelle de GPTWOL décrit le mode réseau requis, les chemins de stockage, les options d’authentification et les fonctionnalités de planification.
Ne réutilisez pas les identifiants de connexion d’exemple
Le fichier YAML de la communauté activait l’authentification locale et utilisait des identifiants d’exemple simples. Ils montrent comment l’utilisateur source avait configuré l’application, mais ne constituent pas une valeur par défaut sécurisée à copier dans une nouvelle installation.
Si vous activez l’authentification locale, remplacez tout nom d’utilisateur et tout mot de passe d’exemple public avant le premier déploiement réel. Les versions actuelles de GPTWOL prennent également en charge OIDC. Dans tous les cas, le projet en amont déconseille d’exposer directement le service sur Internet sans une authentification appropriée.
Le Wake-on-LAN est généralement une fonction de contrôle du réseau local. Si vous devez le déclencher lorsque vous êtes absent de chez vous, privilégiez une couche d’accès distant sécurisée plutôt que de placer directement l’interface Web de GPTWOL sur un port public.
Importer ou modifier le fichier YAML dans la version actuelle de ZimaOS
Le fil de discussion de janvier 2026 est antérieur à l’expérience YAML actuelle de l’App Store 2.0. ZimaOS 1.7 a introduit la modification native des fichiers YAML pour les applications, et ZimaOS 1.7.1 a encore amélioré la compatibilité lors de leur enregistrement. Les captures d’écran ou l’emplacement des boutons présentés dans la publication originale peuvent donc ne plus correspondre à l’interface actuelle.
Gardez la définition du service Compose simple : image, réseau de l’hôte, politique de redémarrage, variables d’environnement requises et volumes persistants. Ne reprenez pas d’anciennes métadonnées x-casaos simplement parce qu’elles figuraient dans un fichier exporté, sauf si le flux actuel des applications ZimaOS en a réellement besoin.
Notes de version de ZimaOS 1.7.1 décrivent les améliorations actuelles de compatibilité YAML.
GPTWOL ne peut pas activer le WOL sur une cible qui ne le prend pas en charge
GPTWOL envoie le paquet de réveil : il ne rend pas compatible un ordinateur qui ne prend pas en charge le réveil à distance. La machine cible doit toujours avoir le Wake-on-LAN activé dans son micrologiciel et son système d’exploitation, et sa carte réseau doit rester capable de recevoir le paquet magique dans l’état d’alimentation souhaité.
Avant de dépanner le conteneur, vérifiez que la cible peut être réveillée par un autre outil WOL fiable sur le même réseau local. Si cela fonctionne, testez ensuite GPTWOL. Si aucun outil ne parvient à réveiller la cible, commencez par dépanner son BIOS, sa carte réseau, son état après extinction et le chemin réseau.
