GPTWOL può essere eseguito su ZimaOS come applicazione Docker personalizzata, ma la parte importante del file YAML della community non riguarda le vecchie credenziali di esempio. L’applicazione necessita della rete dell’host per poter inviare pacchetti Wake-on-LAN sulla rete locale, di uno spazio di archiviazione persistente per il database e i dati cron e di una porta web che non sia già utilizzata da un altro servizio.
La discussione di gennaio 2026 è utile come configurazione funzionante di riferimento, ma sia GPTWOL sia ZimaOS si sono evoluti. La documentazione attuale di GPTWOL richiede ancora la rete dell’host per Wake-on-LAN, mentre le versioni attuali di ZimaOS offrono un flusso di lavoro YAML più completo. Considera il file sorgente un punto di partenza e verifica le opzioni upstream attuali prima di importarlo.
Cosa configurava il file YAML della community
La definizione dell’applicazione condivisa utilizzava l’immagine misterbabou/gptwol:latest, network_mode: host e restart: unless-stopped. Inoltre, rendeva persistente lo stato di GPTWOL tramite due cartelle dell’host mappate in /app/db e /etc/cron.d.
La configurazione sorgente esponeva l’interfaccia di GPTWOL sulla porta 99 e impostava un fuso orario per le attività di riattivazione pianificate. Questi valori non sono universali. Scegli una porta libera sull’host e utilizza il fuso orario corrispondente alla macchina che esegue il container.
Perché GPTWOL utilizza la rete dell’host
La documentazione upstream attuale di GPTWOL indica che il container deve utilizzare la modalità di rete dell’host per inviare comandi Wake-on-LAN sulla LAN. È diverso da una normale applicazione web, che spesso può rimanere isolata dietro la rete bridge di Docker e una singola porta pubblicata.
La rete dell’host cambia anche il modo in cui devi considerare le porte. L’applicazione ascolta direttamente sulla rete dell’host ZimaOS, quindi la porta selezionata per GPTWOL deve essere libera. Se la pagina web non si apre, verifica la porta configurata e controlla se un altro servizio è in ascolto su quella porta prima di modificare impostazioni non correlate del router.
Configurazione Docker attuale di GPTWOL documenta la modalità di rete richiesta, i percorsi di archiviazione, le opzioni di autenticazione e le funzioni di pianificazione.
Non riutilizzare le credenziali di accesso di esempio
Il file YAML della community abilitava l’autenticazione locale e utilizzava credenziali di esempio semplici. Sono una testimonianza di come l’utente originale aveva configurato l’app, non un’impostazione predefinita sicura da copiare in una nuova installazione.
Se abiliti l’autenticazione locale, sostituisci qualsiasi nome utente e password di esempio pubblici prima della prima distribuzione reale. Le versioni attuali di GPTWOL supportano anche OIDC. In ogni caso, il progetto upstream sconsiglia di esporre direttamente il servizio su Internet senza un’autenticazione adeguata.
Wake-on-LAN è solitamente una funzione di controllo della LAN. Se devi attivarlo quando sei lontano da casa, preferisci un livello di accesso remoto sicuro invece di esporre direttamente l’interfaccia web di GPTWOL su una porta pubblica.
Importare o modificare il file YAML nell’attuale ZimaOS
La discussione di gennaio 2026 precede l’attuale esperienza YAML di App Store 2.0. ZimaOS 1.7 ha introdotto la modifica YAML nativa per le applicazioni e ZimaOS 1.7.1 ha ulteriormente migliorato la compatibilità del salvataggio YAML. Di conseguenza, le schermate o la posizione dei pulsanti del post originale potrebbero non corrispondere più all’interfaccia attuale.
Mantieni semplice la definizione del servizio Compose: immagine, rete dell’host, criterio di riavvio, valori d’ambiente richiesti e volumi persistenti. Non trasferire metadati x-casaos obsoleti solo perché comparivano in un file esportato, a meno che il flusso di lavoro attuale delle app di ZimaOS non ne abbia effettivamente bisogno.
Note di rilascio di ZimaOS 1.7.1 descrivono gli attuali miglioramenti alla compatibilità YAML.
GPTWOL non può abilitare il WOL su un dispositivo di destinazione che non lo supporta
GPTWOL invia il pacchetto di riattivazione; non rende compatibile con la riattivazione un computer che non lo è. La macchina di destinazione deve avere Wake-on-LAN abilitato nel firmware e nel sistema operativo, e la scheda di rete deve poter continuare a ricevere il magic packet nello stato di alimentazione previsto.
Prima di eseguire il debug del container, verifica che il dispositivo di destinazione possa essere riattivato tramite un altro strumento WOL noto e funzionante sulla stessa LAN. Se funziona, prova GPTWOL. Se nessuno strumento riesce a riattivare il dispositivo, verifica prima il BIOS, la scheda di rete, lo stato di spegnimento e il percorso di rete del dispositivo di destinazione.
