Domande aperte
Aggiornato al 27/10/2026. Quando una domanda trova risposta: spostarla nella pagina giusta e, se è una decisione, in decisioni.md.
Bloccanti per il piano
| # |
Domanda |
Stato |
Serve per |
| A1 |
Macchine di test per i box. |
Disponibili a breve (data non importante). Proposta di configurazione in decisioni.md (P7). |
T1.1, T1.5 |
| A2 |
Le regole della VPN permettono davvero ai box di raggiungere tutto? |
Confermato da Michele (28/10): la rete non è segmentata, per scelta. Resta aperto come problema R3. La prova da un box serve ancora a sapere esattamente cosa raggiungono i box. |
T0.4 |
| A3 |
Chi gestisce Cloudflare per bsqdev.uk? |
Accesso disponibile (30/10): Michele ha condiviso le credenziali di Cloudflare su Passbolt. Resta da decidere chi ne è responsabile (M-7). Rischio R6 ridotto. |
T0.7 |
| A4 |
Serve una nuova VM per la prod? Serve un altro IP pubblico? |
IP: chiuso (D19): non ci sono altri IP pubblici e non servono. VM: da decidere (P1). |
T6.2, T6.3 |
| A5 |
Nome del nuovo dominio su Route 53 e chi lo registra. |
Lo registra Lorenzo (D16). Il "dominio creato da Marco" è bsqdev.uk stesso, su Cloudflare, con credenziali condivise (Michele, 30/10): non esiste un altro dominio da riusare. Ora che il team può gestire bsqdev.uk, va riconfermato se il nuovo dominio su Route 53 serve ancora (D16 era nata dalla mancanza di accesso). |
T6.1 |
| A6 |
Finestra di manutenzione accettabile per il cambio di midserver. |
Aperto. |
Fase 8 |
Dettaglio A2: cosa dicono le regole lette il 27/10
- La lettura del 27/10 ha trovato una regola allow any → any con traffico reale (148 stati, 48 GB) e l'ha attribuita al gruppo di interfacce "WireGuard", valutato prima della singola interfaccia WG_VPN. Secondo Michele (30/10) le regole sono invece sull'interfaccia WG_VPN: va riletto dove sta l'allow any.
- Michele (30/10): gli
AllowedIPs dei box comprendono solo 172.16.16.1, 172.16.16.253 e 172.16.16.254. Limitano cosa il box manda nel tunnel, ma sono configurati sul box e .253 porta a tutte le porte di ServerIT (pfsense-rete-vpn.md).
- Non sono state lette le regole Floating, che vengono prima di tutto: vanno controllate (Firewall → Rules → Floating).
- Il firewall di Cava non conta per questo caso: il traffico box → midserver resta tutto dentro pfSense.
- La prova da questo PC non è significativa: il PC è collegato alla VPN aziendale di Cava, non alla VPN dei box.
Da chiedere a Michele entro il 30/10/2026
Michele lascia l'azienda (presente fino al 30/10, poi disponibile a distanza per un periodo). Ha ricevuto la documentazione da rivedere. Domande prioritarie (attività T0.9):
| # |
Domanda |
| M-1 |
Rivedere rischi-e-problemi.md e pfsense-rete-vpn.md. Fatto (30/10). |
| M-2 |
Documentazione WireGuard e FreePBX: ricevuta il 30/10 (A15). |
| M-3 |
Sistema di Michele: dove gira ogni parte e come si riavvia. Risposta (30/10): il Raspberry è installato in centrale operativa. Ogni ora fa anche il controllo di presenza dell'operatore: suona un buzzer, l'operatore deve premere un pulsante entro 60 secondi, altrimenti un relè manda un allarme a un istituto di vigilanza esterno. Se il buzzer non suona, il Raspberry è fermo e va segnalato: è il modo in cui il Raspberry stesso viene controllato. Gli avvisi vanno al gruppo Telegram "Controllo Infrastrutture"; il database non ha backup. Resta aperto: come si riavvia e dove stanno script e cron. |
| M-4 |
Quali sono le voci controllate in system_controls e cosa fare quando scatta un avviso. Risposta (30/10): l'elenco è la tabella system_controls.system (ogni infrastruttura controllata con il suo argomento Telegram); gli avvisi vanno nel gruppo "Controllo Infrastrutture", finora seguito da Michele come reperibile e ora anche dall'ufficio IT. Resta aperto: cosa fare per ogni avviso e chi è reperibile dopo l'uscita di Michele. |
| M-5 |
Come si ripristina una VM da backup Proxmox? Risposta (30/10): dalla scheda Backup della VM, Restore. Già usato per creare copie veloci del sistema e per migrare i server (proxmox.md). |
| M-6 |
Il fermo di luglio 2026. Risposta (30/10): manutenzione programmata di Netsons sulla propria rete; server fermo 5 ore di notte; risolto da Netsons. |
| M-7 |
Elenco degli account amministrativi da passare a chi resta. Risposta (30/10): sono tutti nel Passbolt di Michele; nessuno gli ha ancora detto a chi passarli. Da decidere (Emanuele/Enrico): chi riceve gli accessi prima che Michele esca. |
| M-8 |
Contatti e contratto Netsons. Risposta (30/10): assistenza, IP e dischi si chiedono dalla piattaforma (area clienti) di Netsons; l'accesso va passato con gli altri (M-7). |
| M-9 |
Il dominio creato da Marco. Risposta (30/10): è bsqdev.uk, su Cloudflare, credenziali condivise (A5). |
| M-11 |
Proxy nginx del master verso gli slave nei siti multi-box. Risposta (30/10): Nginx Proxy Manager è su tutte le macchine; sul master si creano degli stream verso il midserver, uno per MQTT e uno per le API; sullo slave si modifica a mano il JSON di configurazione dell'installation con gli endpoint del master e le porte esposte (dettaglio). Resta aperto: quali porte e quale file JSON, da leggere su un sito reale. |
| M-12 |
Configurazione dei GANZ (canali, algoritmi, zone, Event Action verso il box): procedura completa, dato che finora i GANZ sono stati consegnati già configurati. Inoltre: modello esatto dell'apparato GANZ (in laboratorio "AI Box", senza uscita RTSP) e se lavora in modalità 8 o 16 canali; se il tamper detection e il video loss del GANZ sono configurati da qualche parte; se la telecamera di laboratorio ha un flusso secondario (s1 oggi coincide con s0); se il GANZ accetta come sorgente un URL RTSP del box (restream); se in qualche impianto c'è anche il VMS GANZ CORTROL (vedi connessioni-telecamere.md). Risposta (30/10): non esiste una guida interna; usare la documentazione del GANZ (manuale del produttore). Le altre domande della riga restano aperte. |
| M-10 |
Cosa c'è dietro 171.16.16.100. Risposta (30/10): il peer WireGuard del firewall dell'ufficio di Cava (A7). Porte 1996/2000: 1996 vecchio sistema MDM di Marco Lucchese, 2000 monitoraggio degli impianti GANZ. |
Importanti, non bloccanti
| # |
Domanda |
Stato |
| A7 |
Cosa c'è dietro 171.16.16.100? |
Chiuso (Michele, 30/10): è l'IP del peer WireGuard del firewall dell'ufficio di Cava. Tutto il traffico della rete aziendale (postazioni della centrale, PC dei dipendenti, Raspberry) esce da lì. |
| A8 |
Chi ha cambiato l'immagine di phpMyAdmin il 27/10 alle 08:32 UTC? |
Aperto (last e .bash_history su ServerIT). |
| A9 |
Cluster master/slave: quali impianti hanno più box? |
Codice analizzato il 28/10 (cluster-master-slave.md). Il cluster della 3.8 non è usato da nessun box. Esistono però siti multi-box "vecchi" già in produzione (stack indipendenti, slave raggiungibili solo dal proxy del master), invisibili al censimento. Come sono collegati è chiarito (Michele, 30/10: cluster-master-slave.md); restano da elencare quali sono e quanti nodi hanno. Convenzione dei codici: <MAC> master, <MAC>-01, <MAC>-02 slave (uguale al cluster 3.8): i siti multi-box si possono contare dalle chiavi Redis con suffisso, non da BSQ, che ha solo il master (30/10). |
| A11 |
Composizione dei 66 peer VPN. |
Quasi chiuso: il database del Raspberry di Michele elenca 68 impianti (37 MDM, 31 GANZ); 65 coincidono con i peer di pfSense. Secondo Michele (30/10) i peer sono solo impianti dei clienti, senza PC dei dipendenti: il peer in più è quindi un impianto da identificare. Resta da distinguere, tra i GANZ, gli impianti interni e quelli della società esterna, e da collegare gli impianti MDM ai MAC in Redis (T0.5). |
| A12 |
I 3 box offline (uno dal 26/10, due da agosto) sono dismessi? |
Aperto. |
| A14 |
Le 4 migrazioni MDM previste entro fine anno (call dell'11/08) sono ancora in programma? |
Aperto (Enrico). |
| A15 |
Documentazione WireGuard e FreePBX di Michele: dove si trova? |
Chiuso (30/10): riportata in nuovo-peer-wireguard.md, preparazione-pc-ubuntu.md e freepbx-trombe.md. |
| A16 |
Il ripristino da backup Proxmox è mai stato provato? |
Sì (Michele, 30/10): ad aprile 2026, durante la migrazione tra le macchine. Manca la procedura scritta (M-5). |
Dal censimento del 28/10/2026
| # |
Domanda |
Chi può rispondere |
| A17 |
5 box MDM rispondono su SSH ma non sulla porta 5005 (API locale): servizio fermo, firewall locale o versione diversa? |
Lorenzo / Mattia (accesso SSH ai box) |
| A18 |
13 impianti GANZ non rispondono da Cava: VPN scollegata, spenti o filtrati? Sono della società esterna? |
Michele, pfSense (handshake) |
| A20 |
Cosa gira sulla porta 80 dei box (/alarm/operativecenter/alarm.php) e come arriva l'allarme alla centrale? È installato da televigilanza-mdm? |
Michele (domanda da aggiungere al passaggio di consegne) |
| A21 |
Chi ha l'accesso SSH a chiave sui box, per raccogliere i tag delle immagini ECR con il censimento? |
Lorenzo / Michele |
| A22 |
~~Filtro type_id != 2~~: esclude gli impianti Ajax. ~~installation.code è sempre il MAC?~~ Sì, il MAC univoco del box master. ~~Impianti con più box?~~ In BSQ solo il master; gli slave <MAC>-01, <MAC>-02 esistono solo nel sistema MDM (30/10). ~~Quali type_id sono videosorveglianza?~~ 1 GANZ, 2 Ajax, 3 Frigate (30/10). Chiusa. |
MDM-019 |
| A23 |
Gli operatori ricevono oggi avvisi di telecamera coperta o spostata? Da quale sistema arrivano gli eventi camera_moved/camera_covered (tipi 23 e 24 della Lambda qalarm), visto che il box MDM non li manda? Il modulo tlcmoved è mai stato in uso? (anti-manomissione) |
da chiedere a Michele |
| A24 |
Comportamenti del box stage da decidere con la centrale: (1) il box rifiuta l'inserimento se detector, trombe o ingressi non sono sani: è voluto? chi viene avvisato? (2) inserimento/disinserimento automatico a orario dal box: convive con gli automatismi del sistema vecchio? (3) il box manda eventi anche direttamente su Telegram (cliente, centrale, guasti): va tenuto? (funzioni del box) |
da decidere (Lorenzo, Mattia, centrale) |
| A25 |
P4: portare tutti i box alla 3.2.9 prima del cambio di midserver (T9.1)? Pro: il midserver v3 si prova contro una sola versione. Contro: un giro di aggiornamenti in più sugli impianti (circa 14 box). Alternativa: provare la v3 con tutte le versioni del parco (3.1.9, 3.2.1, 3.2.2, 3.2.9); l'import della nuova versione supporta già dalla 3.1.9 (migrazione). |
da decidere (Lorenzo, Mattia) |
| A19 |
~~Due righe del database del Raspberry hanno lo stesso IP VPN: quale è quella vera?~~ Probabilmente IP riusato: la riga ganz è disattivata, senza Sonoff e con un cliente diverso; la riga mdm è attiva e corrisponde al box trovato dal censimento. Da confermare con Michele se gli IP VPN vengono riassegnati dopo una dismissione. |
Michele |
Già risolte (per memoria)
- 27/10/2026:
- midserver per la prod: v3;
- versioni dei box: 3.1.9–3.2.9;
- la 3.8 andrà in prod: sì;
- box con PIN: 0;
/request/call e connect/scp: non usati (0 chiamate in 30 giorni);- 29 contro 38: MySQL contiene i backup, il registro è in Redis;
- il router è pfSense e la VPN è WireGuard su pfSense;
171.16.16.0/24 è la rete aziendale di Cava;- il midserver di prod è la VM 500;
- Proxmox ed ewelink non sono raggiungibili da internet;
- dominio di prod: nuovo, su Route 53;
- VM 400 inutilizzata.
- A10, commit
6dd5e6b: non è nella v3. Di più: nella v3 manca proprio la pagina che quel commit modifica (GET /installation/live_stream/<token>), quella che apre l'app Protexia. È un'incompatibilità bloccante, vedi parità.
- A13,
chat/snapshot: è una funzione del 2024. L'operatore chiedeva al box una foto di una telecamera da mandare in una chat: il midserver pubblicava q_security/chat_snapshot, il box rispondeva con la foto su POST chat/snapshot. Oggi nessuno pubblica quel topic, né nella v2 né nella v3: non serve implementarlo. Le funzioni di chat recenti (chat di gruppo, notifiche) stanno in qAlarm 2 e nell'app Protexia. Le chiamate di qAlarm 2 al midserver esistono tutte nella v3 (14 su 14, verificato).