# Gradio Tunnel Dashboard Dashboard web per un server Linux che individua le porte in ascolto, permette di avviare e fermare tunnel tramite `gradio-tunneling` e mostra l'URL generato, tutto dal browser. ## Funzionalità principali - **Scanner portale intelligente** con caching TTL, riconoscimento del protocollo, utente, comando completo e link al container Docker quando disponibile. - **Dashboard unificata**: la sezione Porte mostra lo stato di ciascun port, mentre la tabella Tunnel permette di leggere l'output, aprire i log e interrompere i tunnel attivi. - **Controllo dei tunnel**: pulsanti Avvia/Ferma sincronizzati con lo stato del tunnel, badge visivi per sapere se una porta è occupata e aggiornamenti automatici ogni 4 secondi. - **Debug integrato**: pannello log per ogni tunnel con pulsante dedicato, e l'URL pubblico viene estratto dai log del processo. ## Scanner porte e metadati Il modulo `app/services.py` utilizza `psutil` per enumerare le connessioni `LISTEN`, deduce protocollo/utente/processo/comando e abbina i PID ai container Docker tramite `/proc//cgroup`. I risultati vengono memorizzati per 2 secondi per ridurre la pressione sulla CPU. La risposta `/api/ports` include ora: - `port`, `protocol`, `service`, `user`, `pid`, `command`, `container`, `local_address` Questi campi alimentano la tabella Porte e aiutano nelle decisioni manuali prima di aprire un tunnel. ## Interfaccia web - La tabella Porte mostra metadati completi e un badge Tunnel che indica se la porta è già in uso. Il pulsante **Avvia tunnel** rimane disabilitato quando un tunnel è presente. - La tabella Tunnel mostra il PID, lo stato, l'URL pubblico, l'ultimo log e il comando invocato. I pulsanti **Log** e **Ferma** permettono debug e cleanup rapidi. - Il pannello inferiore espone i log del tunnel selezionato per trovare errori di connessione o capire quando viene stampato l'URL pubblico. ## Avvio rapido ```bash python -m venv .venv source .venv/bin/activate pip install -r requirements.txt uvicorn app.main:app --host 0.0.0.0 --port 8000 ``` Apri `http://localhost:8000`. ## Configurazione Il comando usato per avviare i tunnel è configurabile con la variabile d'ambiente `TUNNEL_COMMAND`. Esempio: ```bash export TUNNEL_COMMAND="python -m gradio_tunneling --port {port}" ``` Se il comando `python -m gradio_tunneling` non funziona, usa la CLI installata dal pacchetto: ```bash export TUNNEL_COMMAND="gradio-tunneling --port {port}" ``` L'URL viene rilevato dalla prima stringa che contiene un link HTTP/HTTPS nel log del tunnel. La dashboard aggiorna automaticamente lo stato dei tunnel e mostra l'ultimo log per aiutare il debug quando l'URL non è disponibile. ## Push su Gitea con token Se hai un personal access token Gitea, esportalo come `GITEA_TOKEN` (es. `export GITEA_TOKEN=...`) e lancia `scripts/push-gitea.sh` dalla root del progetto. Lo script leggerà la variabile e spingerà il branch `main` verso `https://gitea.solarpi.net/truetype/dashgradio_tunnel.git` senza richiedere prompt interattivi. Puoi passare un branch diverso come primo argomento (`scripts/push-gitea.sh feature-branch`) e lo script si occuperà di costruire l’URL con il token. ## Test automatico Esiste uno script `scripts/auto-test.sh` che installa le dipendenze (`requirements.txt`) e lancia `pytest` contro le API principali (`/api/ports`, `/api/tunnels`). Basta eseguire `./scripts/auto-test.sh` dalla root del progetto; lo script fallirà se non trova `GITEA_TOKEN`/comment? Not needed. Sam lengths. ## Politica porte La parte critica di sicurezza del progetto è la politica che decide quali porte possono essere esposte tramite tunnel. Ci sono due layer di configurazione, entrambi opzionali: - `TUNNEL_WHITELIST` (es. `22,8000,9000`) o `TUNNEL_WHITELIST_FILE` (JSON con una lista o un oggetto `{ "whitelist": [80, 8888] }`) per **consentire solo** determinati numeri di porta. - `TUNNEL_BLOCKLIST` o `TUNNEL_BLOCKLIST_FILE` (stesso formato del whitelist) per **bloccare** porte critiche anche se l'utente le seleziona. Quando non viene esplicitata nessuna whitelist, il servizio blocca per default le porte sensibili `22, 23, 2375, 2376, 2377, 6443 e 9000`. Le richieste `/api/tunnels` restituiscono un errore 403 con il motivo della violazione se si prova ad aprire un tunnel vietato. La tabella "Porte in ascolto" ora mostra un badge **Policy** che indica se la porta è consentita o se è stata bloccata dal policy engine. ## Persistenza e audit Lo stato dei servizi e dei tunnel viene ora salvato in un database SQLite (`data/dash.db` nell'ambiente predefinito) così da non perdere il tracciamento dopo il riavvio del servizio. Puoi cambiare la posizione con la variabile `TUNNEL_DB_PATH`. - **`services`**: panoramica delle porte rilevate, con timestamp, utente, comando e attenzione alle policy. - **`tunnels`**: stato corrente (o ultimo) dei tunnel avviati, con PID, URL e log dell'ultima uscita. - **`tunnel_events`**: audit log con timestamp e messaggi (avvio, stop, errori). La dashboard espone un nuovo pannello "Audit tunnel" e le API `GET /api/history/events` e `GET /api/history/services` per leggere i log recenti direttamente dal browser o da script esterni. Ciò semplifica la ricerca di chi ha avviato un tunnel, quando è stato chiuso e con quale comando. ## Debug Nella sezione dei tunnel puoi aprire il pannello Log per vedere le ultime righe prodotte dal processo `gradio_tunneling`. Questo aiuta a capire se il tunnel non parte o se l'URL non viene stampato. ## Rilevamento servizi Docker La tabella delle porte mostra anche il nome del container Docker quando disponibile. Questo richiede che il processo abbia accesso al socket Docker locale. ## Dipendenze tunneling Il progetto usa `gradio-tunneling` (installato da GitHub tramite `requirements.txt`). Se stai usando un ambiente offline, installa manualmente il pacchetto nella venv prima di avviare il servizio.