4. Moduli per OpenWISP

Quattro moduli nostri completano OpenWISP. I primi tre sono piccole app Django: due estendono la pagina del device, una quella dell'organizzazione; il quarto è l'agente che gira sui router. Il playbook openwisp2 installa già le tre app: questo capitolo spiega cosa fanno e cosa controllare.

openwisp-netconsole

Repository · scheda Netconsole nella pagina del device.

I router mandano i messaggi del kernel al server con netconsole (UDP 6666), in tempo reale, anche negli ultimi istanti prima di un blocco o di un kernel panic, quando il syslog non fa più in tempo. rsyslog li salva in /opt/router-logs/netconsole-<nome del device>/, e la scheda li mostra aggiornati ogni pochi secondi, con i file ruotati da scaricare.

• Lato server: Play 5 di openwisp2 (rsyslog, gruppo router-logs in sola lettura per OpenWISP, script di rotazione).
• Lato router: template Netconsole (target in configfs, controllo ogni 5 minuti, nome del device come userdata). Serve il firmware NINUX con kmod-netconsole compilato con NETCONSOLE_DYNAMIC.
• Rotazione dei log: si regola da OpenWISP, pagina Monitoring → Rotazione dei log dei router (solo superuser). Default: ogni giorno o oltre 50 MB, 15 giorni, al massimo 30 file.
• API per l'app: GET /api/v1/netconsole/device/<uuid>/logs/ (da 0.2).

openwisp-luci

Repository · pulsante LuCI ↗ nella pagina del device.

Apre l'interfaccia web del router in una nuova scheda passando dal server: il router deve essere raggiungibile solo dal server, non dal browser.

• Un host per router: https://<uuid>.luci.ninux-nnxx.it, così cookie e sessioni di un router non arrivano agli altri. Servono il DNS *.luci e il certificato luci.ninux-nnxx.it (capitolo 2); il Play 6 si ferma se il certificato manca.
• Link monouso da 60 secondi, poi un cookie __Host- legato a utente, device e password; nginx chiede a OpenWISP a ogni richiesta se l'utente può ancora.
• Accesso automatico per i superuser: OpenWISP crea via SSH una sessione LuCI per l'utente di servizio admin del router. Nessuna password sul server. Gli altri, e chi vuole entrare come root, usano il login di LuCI.
• Router con la gestione sulla wan: la regola Allow-LuCI-OpenWISP apre la 443 solo dal server.
• API per l'app: POST /api/v1/luci/device/<uuid>/link/ (da 0.3; usare almeno la 0.3.1 per aprirla dall'app).

Cookie di sessione di OpenWISP

I sottodomini *.luci sono dello stesso dominio di OpenWISP: il cookie di sessione di OpenWISP deve chiamarsi __Host-sessionid, che i sottodomini non possono sovrascrivere. Il playbook lo imposta.

openwisp-luci-theme

Repository · riquadro Tema LuCI dei router nella pagina dell'organizzazione.

Ogni organizzazione sceglie logo, nome, colori e modalità Base/Avanzato del tema LuCI sui suoi router.

• Logo caricato: SVG (meglio), PNG, JPEG, WebP o GIF fino a 32 KB. Arriva al router dentro la configurazione, come data: URI: si vede anche senza Internet. Gli SVG con script o riferimenti esterni vengono rifiutati.
• Dimensioni del logo: LuCI lo mostra alto 28 pixel e largo al massimo 220 (24 × 150 sul telefono). Serve quindi un logo orizzontale, largo fino a circa 8 volte l'altezza, senza margini vuoti. Per PNG, JPEG, WebP e GIF usa il doppio, 56 × 440 al massimo, così resta nitido sugli schermi ad alta densità.
• Campi vuoti: lasciano il valore globale del playbook (ninux_luci_*). Le variabili scritte nel singolo device vincono comunque.
• Aggiornamento dei router: salvando il riquadro OpenWISP ricalcola la configurazione dei device dell'organizzazione, che la scaricano al controllo successivo. Serve il template Tema LuCI ninux assegnato ai router.
• Permessi: superuser e gruppo Administrator modificano, Operator vede.
• Esempio: l'organizzazione Basilicata ha il logo Ninux, il nome «NINUX Basilicata», l'arancione Ninux (#d93d1c, scuro #ff6a45) e la modalità Base. Il WRT3200ACM di test l'ha ricevuto da solo un paio di minuti dopo il salvataggio.

Dove arrivano i valori

Contesto globale del playbook → variabili dell'organizzazione e del gruppo → riquadro del tema → variabili del device (vincono). Il template Tema LuCI ninux non ha default values apposta: OpenWISP li copierebbe nelle variabili di ogni device e vincerebbero sul riquadro. I valori per tutti (ninux_luci_mode, ninux_luci_allow_advanced e gli altri ninux_luci_*) stanno nel playbook, tag context.

openwisp-config (fork)

Repository · l'agente che gira sui router.

È il fork dell'agente ufficiale con le correzioni ai segnali SIGUSR1/USR2: senza, l'agente poteva morire al primo ciclo dopo l'avvio o durante l'applicazione di una configurazione, lasciando il router fermo su «config modificata». Il problema è segnalato upstream in openwisp-config#283.

Il firmware NINUX lo prende dal branch fix/sigusr-handlers-startup del fork, con il feed in config/build.yml di ansible-ninux-openwrt:

src-git openwisp_config https://github.com/mikysal78/openwisp-config.git;fix/sigusr-handlers-startup

Quando la correzione arriverà upstream, si tornerà al pacchetto ufficiale.

Controllo

• Nella pagina di un device ci sono le schede/pulsanti Netconsole e LuCI ↗.
• Netconsole mostra righe recenti per un router con il template Netconsole.
• LuCI si apre (da superuser, già autenticata come admin).
• Nella pagina dell'organizzazione c'è il riquadro Tema LuCI dei router.
• curl -X OPTIONS https://openwisp.ninux-nnxx.it/api/v1/luci/device/00000000-0000-0000-0000-000000000000/link/ risponde 405 (API presente) e non 404.