Vai al contenuto

Box di test MDMTESTGANZ1

Verifica e installazione stage del 28/10/2026, autorizzate da Mattia. Questa procedura riguarda il solo mini PC di prova, non i box dei clienti.

Accesso e servizi

  • SSH: bsqsecurity@192.168.200.165, porta 22. Credenziali nella guida GANZ originale, non riprodotte qui.
  • Identificativo applicativo confermato nella configurazione: MDMTESTGANZ1. L'hostname del sistema è bsqsecurity.
  • Ubuntu 24.04.3 LTS su HP ProDesk 400 G5 Desktop Mini.
  • GANZ associato: https://192.168.200.164:8443/.
  • Apache e MySQL girano direttamente sull'host. Apache pubblica /var/www/html, con applicazioni PHP relative ad allarmi, comandi e controlli; la loro funzionalità non è stata verificata.

Telecamere del GANZ

Verifica in sola lettura del 28/10/2026 tramite GET /api/network/vsources/ sul GANZ associato: una sorgente configurata e connessa, canale MDM 1, IP 192.168.200.166, configurazione AI presente. Lo stato connected corrisponde al valore GANZ 0. Non sono stati acquisiti snapshot né aperti flussi video. Queste sorgenti sono distinte dal Frigate remoto ascoltato dallo shadow.

Raggiungibilità verificata anche dal computer di Mattia e dal box: porte TCP 80, 443 e 554 aperte; HEAD http://192.168.200.166/ restituisce HTTP 200 da entrambi. Non verificati autenticazione, handshake TLS o streaming RTSP.

Installazione attiva

Voce Valore verificato
Directory operativa /home/bsqsecurity/installation
Repository e branch mdm_installation, stage
Commit d02dbaeedf52d1bb96f428c1b927e15dd8f3d6aa
Container internal_server
Immagine 407138933921.dkr.ecr.eu-west-1.amazonaws.com/mdm8670650/installation:3.9.0-stage
Digest ECR sha256:b7eaf521c23f7e82a4d52961467acd323474edfbb4a8bd6a5aa0ca49a6c094c8
Canale stage
Detector GANZ, mantenuto dalla configurazione precedente
Pannello da usare https://mdm.dev.midpanel.bsqdev.uk/
HTTP e signaling https://mdm.dev.midserver.bsqdev.uk/
MQTT del midserver 170.10.0.107:1883
Video SRT srt://mdm.dev.ome.bsqdev.uk:9999?mode=caller&streamid=live/app

panel.bsqdev.uk è il pannello di produzione. L'indirizzo VPN dev 172.16.16.252:1883 non rispondeva dal box durante la verifica; 170.10.0.107:1883 era raggiungibile.

La configurazione di ambiente viene caricata da AWS Secrets Manager (mdm/installation/stage) tramite il loader ufficiale. Il file generato infra/environments/stage/.infra.generated.env e il database hanno permessi 600. Non copiarne i contenuti nella documentazione.

La configurazione stage ufficiale mantiene anche LOGSERVERBASEURL=https://api.bsqcontrol.it, il backend BSQ condiviso. Il collegamento MDM HTTP/MQTT e il video puntano al dev; non è stata verificata l'isolazione di ogni integrazione BSQ. Non sono stati inviati allarmi di prova.

Passaggio dalla 3.2.9

  1. Preparata una checkout separata del branch remoto stage, inclusi i submodule e le dipendenze bloccate da uv.lock.
  2. Scaricata l'immagine ECR aggiornata: quella inizialmente in cache era precedente. Confrontati con la checkout i file di avvio, modello applicativo, migrazione iniziale e Compose.
  3. Inizializzato un database SQLite nuovo, schema 7, importando MAC, credenziali/indirizzo del GANZ e impostazioni compatibili della precedente configurazione JSON. Le opzioni enable_webRtc e enable_screen_shot sono state riportate nei nuovi campi enable_webrtc ed enable_screenshot.
  4. Impostata l'installazione come configurata, ambiente stage. I/O di tipo GANZ con indirizzo del dispositivo associato; nessuna tromba configurata, provider notifiche assente, inserimento automatico disabilitato.
  5. Fermato il vecchio internal_server, conservata integralmente la directory precedente nel backup e collocata la checkout stage nel percorso operativo originale.
  6. Riutilizzati la FIFO e lo script execpipe.sh esistenti. Lo script è stato copiato senza modifiche e il lettore riavviato sul percorso operativo; il crontab è rimasto identico. Nessun nuovo launcher o cron.
  7. Avviato lo stack con il comando ufficiale, dalla directory operativa:
uv run mdm up ganz stage

Il progetto Compose resta installation. Il profilo GANZ/stage avvia internal_server e installation-dsniff-1 (dsniff:1.0.0). Non avvia Frigate, Mosquitto o un nuovo wrapper locale.

Shadow separato

frigate_wrapper_shadow usa l'immagine frigate_wrapper:3.5.0-stage, configurazione in /home/bsqsecurity/shadow/config e API sulla porta 5050. Riceve gli eventi MQTT dal Frigate remoto 172.16.16.66:1883, legge le sue API sulla porta 5000 e invia gli eventi a fake_centre.py su 127.0.0.1:8099.

Il simulatore salva foto in /home/bsqsecurity/shadow/received. Al controllo erano presenti 3.170 JPEG e circa 455 MB di file. Gli eventi configurati erano new e update. Lo shadow non è una modalità che impedisce le scritture: il wrapper espone anche comandi MQTT di controllo della detection. Non è stato modificato per l'installazione GANZ stage.

Ricognizione successiva del 28/10/2026: il container shadow è attivo sulla porta 5050, ma fake_centre.py non risulta in esecuzione e la porta 8099 non è in ascolto. Lo script è ancora presente su disco; la destinazione locale dei suoi webhook non è quindi disponibile al momento del controllo. Nessun servizio riavviato durante questa verifica.

Backup e rollback

Directory privata sul box: /home/bsqsecurity/backup/stage-cutover-20261028T151536Z/.

  • original-config-and-compose.tar.gz: configurazione originale, Compose, tag e script; 59.067.013 byte. SHA-256: e3e188563c381e5867079988fe3446851bdcda5a25ed7472e05c78d6f73461ba.
  • installation-original/: intera directory della precedente installazione, con le modifiche locali preservate. La FIFO è stata trasferita nell'installazione attiva.
  • manifest.json: riferimenti delle immagini e dei container, percorsi e stato del passaggio.
  • Immagine originale conservata anche con tag locale mdm-local-rollback:3.2.9-20261028t151536z.

Il rollback richiede di fermare i due container stage e il lettore della FIFO, conservare la directory stage, ripristinare installation-original come /home/bsqsecurity/installation, riportarvi la FIFO, riavviare il lettore esistente e avviare il solo internal_server con il Compose e i tag originali. Non rimuovere volumi o directory dati. Il rollback non è stato eseguito come prova.

Esito e limiti

  • internal_server:3.9.0-stage in esecuzione, zero riavvii al controllo; nessun errore nei primi log Docker controllati.
  • API locale /openapi.json: HTTP 200.
  • Configurazione SQLite riletta dopo l'avvio: MDMTESTGANZ1, stage, configurata.
  • Il midserver dev registra POST /common/installation/sync_state/MDMTESTGANZ1?expireTime=120 con HTTP 200.
  • Apache e MySQL ancora attivi. Crontab invariato.
  • Non verificati login e visualizzazione della riga nel pannello, comandi MQTT dal pannello, I/O fisico, allarmi, Telegram, snapshot o live video.