Questa fonte è un ottimo esempio dell'utilizzo di ZimaOS come host appliance, invece di cercare di trasformare il suo livello di sistema in sola lettura in una distribuzione desktop. Poiché ZimaOS non dispone di un normale apt ambiente o un desktop X.Org integrato, l'autore ha creato l'intero stack kiosk all'interno di Docker: Debian + X.Org + Chromium per il display, oltre a un piccolo container nginx per la dashboard locale.
Il risultato era un kiosk touchscreen funzionante da 22 pollici, collegato a una ZimaBoard 2 1664. Si tratta di una build avanzata della community, non di una modalità desktop supportata da IceWhale. Utilizza il networking dell'host, l'accesso diretto a grafica e input e un container kiosk privilegiato; gli utenti dovrebbero quindi comprendere i compromessi in termini di sicurezza e accesso ai dispositivi prima di replicarla.
Il kiosk esegue uno stack desktop all'interno di Docker
Il Dockerfile di origine parte da Debian Bookworm Slim e installa X.Org, libinput, Openbox, Chromium, utilità X11, font e Mesa. L'host rimane ZimaOS; lo spazio utente grafico risiede nel container.
Questo è esattamente il tipo di isolamento dei carichi di lavoro che il modello appliance di ZimaOS è progettato per incentivare.
La GPU Intel viene esposta al container kiosk
La guida utilizza modesetting driver e trasferisce il dispositivo Intel DRM al container. L'autore ha rilevato in particolare che il supporto Mesa richiesto necessitava dei backport di Bookworm per lo stack grafico N100 utilizzato da ZimaBoard 2.
L'hardware attuale di ZimaBoard 2 utilizza un Intel N150, quindi chi ricrea la guida dovrebbe verificare il supporto attuale di Mesa/X.Org invece di presumere che il dettaglio storico dell'N100 sia identico.
L'input touch passa attraverso il livello input/Udev dell'host
Il segnale video utilizzava HDMI/miniDP, mentre il controller touchscreen era collegato tramite USB. La guida analizza /proc/bus/input/devices, associa il dispositivo evento corretto in X.Org e condivide /run/udev in modo che il container possa identificare l'hardware di input.
Un container nginx separato serve la dashboard
Il codice sorgente viene eseguito nginx:alpine su una porta diversa da quella di ZimaOS (8888 nell'esempio) e monta i file della dashboard in sola lettura. Chromium apre quell'URL locale in modalità kiosk.
L'utilizzo di un container web separato rende i file della dashboard facili da aggiornare senza ricostruire il container grafico.
Non riutilizzare la porta 80 di ZimaOS per il dashboard
La guida specifica chiaramente che ZimaOS utilizza già la porta 80 per il proprio dashboard. Se Chromium apre la pagina sbagliata, verifica la porta del dashboard personalizzato e il KIOSK_URL valore invece di modificare inaspettatamente ZimaOS.
L'autore ha aggiunto una soluzione basata sugli eventi del puntatore per i tocchi
Nel dashboard della fonte, un piccolo movimento del dito poteva impedire a Chromium di attivare i tradizionali onclick gestori. L'autore ha sostituito la gestione dei clic con pointerup oltre a una soglia di movimento.
Quel JavaScript è specifico dell'applicazione. Le interfacce web moderne progettate per il tocco dovrebbero preferire controlli adatti al puntatore e al tocco invece di eseguire globalmente gestori onclick stringhe.
La modalità privilegiata è il principale compromesso per la sicurezza
La fonte avvia il container kiosk con --privileged. Ciò fornisce un accesso ampio ai dispositivi e al kernel dell'host ed è molto più permissivo rispetto a un normale container per dashboard.
Se riproduci la build, verifica innanzitutto se è esplicito /dev/dri, i mount dei dispositivi di input e di udev, oltre a capability limitate e specifiche, sono sufficienti. Mantieni il dashboard su una LAN affidabile.
La fonte usa unless-stopped per il ripristino automatico
Entrambi i container nginx e kiosk usano restart: unless-stopped comportamento, in modo che il display ritorni dopo un riavvio di ZimaOS. Conserva il Dockerfile, la configurazione di X.Org, l'entrypoint e il dashboard in uno spazio di archiviazione persistente /DATA archiviazione.
L'attuale ZimaOS può pacchettizzare tutto in modo più riproducibile con Compose
L'attuale ZimaOS supporta le importazioni standard di Docker Compose/YAML. Invece di gestire diversi file lunghi docker run comandi, un utente esperto può esprimere entrambi i servizi, le policy di riavvio, i dispositivi, i volumi e la rete in un unico file Compose revisionato.
Usa l'attuale modello Compose di ZimaOS.
FAQ del kiosk touchscreen
ZimaOS deve avere apt o un ambiente desktop installato sull’host?
No. La fonte mantiene intenzionalmente X.Org, Openbox, Mesa e Chromium all’interno di Docker.
È una modalità desktop ufficiale di ZimaOS?
No. È una build della community che IceWhale ha chiesto di condividere con attribuzione.
Perché il container kiosk è ad alto rischio rispetto a una normale app?
La fonte gli assegna la modalità privilegiata e l’accesso diretto alla grafica e agli input, riducendo così l’isolamento di Docker.
