OBELISK R82 FIX9 - AMMINISTRAZIONE E CASI PARTICOLARI

Per la prima installazione segui INSTALL_IT.txt. Questa guida serve per
configurazioni diverse da quelle predefinite, manutenzione, backup e recupero.
Consulta solo la sezione che ti occorre:
1. Percorsi, PHP e indirizzo web
2. Database remoto e permessi
3. Pianificazione e conservazione
4. Interruzioni e recupero completo
5. Backup delle configurazioni
6. Aggiornamenti, controlli e pulizia delle copie
7. Scadenza licenza e accesso ai dati
8. Dispositivi e monitoraggio delle chiamate

1. PERCORSI, PHP E INDIRIZZO WEB

Per un'altra cartella direttamente sotto /var/www/html, aggiungi a tutti i
comandi install.sh --path=/var/www/html/tuo-sito. Se il PHP CLI è diverso,
aggiungi --php=/percorso/assoluto/php. Mantieni gli stessi valori per --resume
e per i comandi di pianificazione. Non estrarre il kit nel sito web.
Usa un terminale SSH interattivo: non esiste una modalità di installazione non
presidiata. Tieni il kit nella propria cartella: il controllo d'integrità rifiuta
anche i file estranei. Non esiste un comando di disinstallazione; pianifica la
rimozione separatamente, senza eliminare configurazioni PBX o sorgenti SQL condivise.

--database=nome identifica il database SORGENTE di CDR e registro code.
Il nome del database applicativo viene chiesto separatamente. Mantieni il
valore sorgente nelle successive esecuzioni. --base-url=https://pbx.example.com
indica il server web, senza /obelisk; puoi usare anche http://IP:porta.
--resume riusa l'indirizzo salvato, salvo la correzione esplicita descritta al punto 4.
--check-existing controlla un server con sito o lavori Obelisk già presenti:
non aggiorna il sito e non autorizza a cancellarlo o sovrascriverlo.

FILE CUSTOM DI ASTERISK

Le direttive attive #include, #tryinclude e #exec non sono supportate in questi
tre file sotto /etc/asterisk: queues_custom_general.conf,
extensions_custom.conf e manager_custom.conf. Bloccano il controllo preliminare
(--check o --check-existing) e l'installazione, anche con AMI existing o manual.
I file sono esaminati prima della scelta AMI: tale scelta non aggira il controllo.
Le direttive commentate sono distinte da quelle attive.

Conserva una copia dei file custom e delle configurazioni richiamate. Prima di
riprovare, fai esaminare dall'amministratore PBX direttive, dipendenze e relativa
configurazione di code, dialplan e AMI. Non eliminare o commentare direttive
alla cieca per superare il controllo. L'installer non segue né riscrive l'albero
delle dipendenze; quando lo rifiuta, conserva il contenuto custom esistente.
Ogni modifica necessaria al PBX va pianificata e verificata esplicitamente.

PHP CLI e PHP web possono avere configurazioni diverse. Abilita ZIP su entrambi
per gli aggiornamenti. Sodium e PHP a 64 bit servono per 2FA e backup; il backup
richiede anche zlib. Il server web deve applicare le regole .htaccess distribuite.
I browser devono raggiungere www.gstatic.com per Google Charts e il provider
configurato per le mappe (predefinito tile.openstreetmap.org).

Durante l'installazione vengono creati brevemente file di prova innocui nella
nuova cartella, prima di creare gli oggetti del database. Un file pubblico deve
essere raggiungibile e i percorsi riservati devono risultare protetti. Poi
vengono rimossi i file di prova invariati e le cartelle di prova vuote.
Questo controllo resta obbligatorio in HTTP e HTTPS.

HTTP è consentito dopo un avviso e la conferma dell'operatore. In HTTPS viene
prima verificato il certificato. Se la verifica fallisce (certificato autofirmato,
scaduto, nome/IP non corrispondente o CA non riconosciuta), l'installer mostra
il motivo e chiede se continuare. L'accettazione riguarda soltanto questa prova
del sito: non importa CA nel sistema né modifica TLS di SMTP, AI o licenze.
Anche il browser può richiedere la propria conferma quando apri il sito.

IP privati e nomi interni sono ammessi. Non serve un dominio pubblico. Se il
nome pubblico punta a un NAT irraggiungibile dal PBX, usa un indirizzo interno
che raggiunga lo stesso sito, oppure configura DNS locale o /etc/hosts.
L'installer non cambia DNS, non sceglie automaticamente un indirizzo loopback
e non passa da HTTPS a HTTP: usa l'indirizzo che hai scelto.

Errori di collegamento, sito errato o file riservati accessibili interrompono
la verifica. Accettare il certificato non permette di ignorare questi errori.
--check controlla i prerequisiti; la prova web effettiva avviene installando.

DIAGNOSTICA DELLA SONDA WEB

Se ricevi un redirect HTTP (3xx), verifica l'indirizzo finale previsto, protocollo,
porta e virtual host. La sonda non segue i redirect. L'indirizzo scelto deve
raggiungere direttamente i file del sito, compresi i controlli sui percorsi
riservati; un redirect alla pagina di accesso non ne dimostra la protezione.
Per un errore del server (5xx), controlla configurazione ed error log del server
web all'ora indicata. AllowOverride di Apache senza il permesso FileInfo può
rifiutare direttive del file .htaccess distribuito: è una possibile causa,
non una diagnosi automatica. Leggi il log prima di modificare la configurazione.
Anche una risposta HTTP non valida o interrotta ferma la sonda. Esamina risposta
e log del server o proxy, correggi la causa e ripeti l'installazione o la ripresa
supportata. Questi errori non certificano la protezione degli accessi.

La pulizia rimuove soltanto i file di prova dal contenuto ancora corrispondente
e le cartelle di prova vuote. Contenuti cambiati o inattesi restano conservati;
una pulizia incompleta interrompe l'installazione. Esamina la destinazione prima
di riprovare: non cancellare alla cieca cartelle o contenuti del cliente per
superare il controllo. Per correggere l'indirizzo salvato, segui --resume al punto 4.

2. DATABASE REMOTO E PERMESSI

L'account applicativo remoto deve esistere e poter accedere dal PBX. Le sue
credenziali restano invariate. Serve SELECT sulle sorgenti FreePBX, accesso ai
dati Obelisk, CREATE TEMPORARY TABLES e i diritti previsti su procedure/eventi.
L'amministratore SQL prepara gli oggetti e i soli permessi dichiarati sulle
tabelle applicative; il piano li mostra prima delle modifiche. --check non
assegna permessi. Il sito non necessita di CREATE/ALTER sulle tabelle applicative.

All'account applicativo serve anche DROP per il reset esplicito dei report
(truncate_cons): MySQL/MariaDB lo richiedono per TRUNCATE. Limita questo diritto
alle seguenti 11 tabelle del database Obelisk: out_all_n_risp, qagent, qname,
queue_answer, queue_connect, queue_enterqueue, queue_ringnoanswer, queue_stats,
queue_unanswer, storep e storep_out. Non concederlo sulle sorgenti FreePBX,
sull'intero database o globalmente (*.*).

Per un nuovo account locale, l'installer assegna DROP su quelle tabelle. Per un
account remoto esistente, il DBA deve fornire gli eventuali diritti DROP mancanti:
la concessione automatica dei permessi sulle tabelle non li aggiunge. Questo
account è distinto da quello amministrativo per aggiornamenti e ripristino
(sezione 6).

Per obelisk_job_health bastano SELECT, INSERT e UPDATE: non servono DELETE o
CREATE. Dopo aver creato l'oggetto, installer e aggiornamenti possono assegnare
i permessi dichiarati se l'amministratore SQL è autorizzato a concederli.
I permessi sulle sorgenti e gli altri diritti restano invariati.

Su MySQL l'amministratore deve poter creare la vista obelisk_routine_grants e
leggere i metadati dei permessi delle procedure. L'account locale riceve SELECT
sulla sola vista, non su mysql.*. Per un account remoto, SELECT sul database
Obelisk copre anche la vista; in assenza, il DBA deve concedere SELECT sulla
vista prima di riprendere con --resume. MariaDB non richiede questa vista.

Non cambiare i permessi durante un aggiornamento o il suo recupero: il database
non distingue due concessioni identiche concorrenti. L'eventuale rollback
revoca soltanto i diritti aggiunti e registrati dal proprio piano.

INVIO EMAIL E FUSO ORARIO

In Amministrazione > Sistema e utility, la sezione email comprende
Autenticazione SMTP. Lasciala attiva per usare nome utente e password.
Disattivala solo se il server di posta autorizza il centralino a inviare senza
credenziali: i valori salvati sono conservati e non vengono inviati. Indica
sempre un mittente valido in questa modalità. La cifratura SMTP resta separata.
Una configurazione incompleta o un mittente non valido vengono segnalati
nei controlli amministrativi; correggili prima di inviare report o avvisi.

Il fuso del centralino configurato per i report vale anche per Oggi e gli altri
periodi rapidi dei report non AI. Deve corrispondere al fuso dei dati FreePBX;
cambiarlo non converte le date delle chiamate già importate.

3. PIANIFICAZIONE E CONSERVAZIONE

Un’installazione completata abilita i lavori pianificati Obelisk e richiede
l’attivazione dei relativi eventi SQL. Controlla lo stato riportato. Per ciascuna
funzione servono comunque licenza, impostazioni SMTP o AI quando previste.

Cancellazione e conservazione delle registrazioni hanno interruttori distinti
in Amministrazione. Scegli i criteri di conservazione prima di abilitare la
cancellazione. La sola attivazione di un lavoro non abilita questi interruttori.

Le registrazioni la cui analisi era già sospesa restano sospese dopo un
aggiornamento. In Amministrazione apri «Stato delle analisi automatiche»,
controlla la causa segnalata e usa «Rimetti in attesa» per rimettere in
attesa la registrazione interessata. Puoi anche selezionare più registrazioni,
come descritto in GESTIONE DEGLI AGGIORNAMENTI. L’aggiornamento non azzera i
tentativi e non riavvia automaticamente le analisi sospese.

Conserva il kit originale. I comandi per la pianificazione sono:

  sudo bash install.sh --disable-jobs
  sudo bash install.sh --activate-jobs

Aggiungi le stesse opzioni --path e --php usate per l’installazione. I comandi
gestiscono lavori ed eventi Obelisk e non arrestano FreePBX.

4. INTERRUZIONI E RECUPERO

Se l’installazione si ferma dopo aver salvato il proprio stato, correggi il
problema segnalato e riprendila dallo stesso kit, con le stesse opzioni di
percorso e PHP:

  sudo bash install.sh --resume

Se l'indirizzo web era sbagliato e la verifica web non è ancora riuscita, puoi
correggerlo durante la ripresa, per esempio:

  sudo bash install.sh --resume --base-url=http://192.168.1.10:8080

Usa l'indirizzo e la porta effettivi, senza /obelisk. La correzione è consentita
solo prima dell'avvio delle modifiche a database, sistema e sito. Le altre
impostazioni restano salvate; la prova web viene ripetuta completamente, con
nuova conferma per HTTP o certificati non validi. Non cancellare lo stato per
forzare un cambio dopo questa fase.

Se durante questa ripresa inserisci credenziali SQL amministrative diverse da
quelle già salvate, l’installer le verifica e chiede se sostituirle nel profilo
privato degli aggiornamenti. Conferma solo se intendi usare il nuovo account o
la nuova password per quel database. Il server, la porta, i database e il tipo
di connessione devono restare gli stessi. Se rifiuti, il profilo rimane intatto
e puoi riprendere successivamente. Profili illeggibili, non protetti o riferiti
a un’altra destinazione vengono conservati e richiedono una verifica del DBA.
Questa conferma riguarda la prima installazione interrotta; non modifica account
SQL, permessi o credenziali dell’account usato normalmente dal sito.

Non eliminare lo stato di installazione né sostituire il kit per forzare un
nuovo tentativo. Conserva il log diagnostico indicato dall’installer. Rimuovi
credenziali e dati personali prima di condividere eventuali informazioni diagnostiche.

RECUPERO DEL PROFILO SQL PRIVATO (SOLO SE SEGNALATO)

Se un'interruzione lascia il profilo SQL con un collegamento temporaneo,
il controllo può rifiutarlo. Non cancellare file o cambiare permessi a mano.
Termina eventuali processi di installazione/aggiornamento e, dalla cartella
del kit originale, esegui l'anteprima con il percorso effettivo del sito:

  sudo python3 support/recover_sql_profile.py /var/www/html/obelisk

Solo se compare PREVIEW OK, conferma con:

  sudo python3 support/recover_sql_profile.py /var/www/html/obelisk --apply

La verifica conserva il contenuto del profilo e rimuove soltanto il collegamento
temporaneo riconosciuto. Durante entrambi i comandi non devono esserci installer
o aggiornamenti attivi. Non serve arrestare FreePBX o SQL. Se compare STOP,
conserva i file e richiedi assistenza. Dopo RECOVERED riprendi l'operazione
interrotta con il kit e le opzioni originali. Non è un passaggio di installazione.

BACKUP COMPLETI E RECUPERO

Conserva un backup completo del database Obelisk: dati, viste, procedure, eventi,
trigger e definizione del database con charset e collation. Se il dump non
include CREATE DATABASE, annota la definizione e ricrea il database di destinazione
con gli stessi charset e collation prima del ripristino. Conserva separatamente
gli account SQL e i relativi permessi. Copia anche kernel_settings.php, la licenza,
la chiave di cifratura 2FA configurata e gli audio che vuoi mantenere. Conserva
la cartella privata di stato indicata al termine dell’installazione sotto
/var/lib/obelisk-installer/ e /etc/cron.d/obelisk. Il solo kit originale non
sostituisce quello stato. Mantieni anche i normali backup di FreePBX e delle sorgenti.

Prova il recupero in una destinazione isolata, dove eventi SQL e lavori Obelisk
non possano avviarsi automaticamente prima della verifica. Un secondo database
sullo stesso server SQL attivo non basta come isolamento. Ripristinando un dump
con il client MariaDB/MySQL conserva i commenti con --comments, affinché i
metadati delle procedure restino disponibili. Il backup del database non include
audio esterni né file di configurazione privati.

La chiave di cifratura 2FA è un file esterno al database SQL. Il percorso
predefinito è data/obelisk_2fa.key.php nel sito; se lo hai modificato usa quello
effettivo. La perdita di questo file impedisce di decifrare i segreti 2FA esistenti.

Su MySQL conserva l’account definer di obelisk_routine_grants e i permessi con cui
legge i metadati. Una vista ripristinata resta legata al nome del database
originale. Per un database di destinazione diverso, l’amministratore SQL deve
risolvere la vecchia vista e predisporre esplicitamente quella nuova con:

  sudo php utility/provision_routine_guard.php --interactive

Esegui il comando dalla cartella del sito installato con il PHP CLI corretto.
L’utility chiede database, amministratore SQL e account applicativo esistente;
la password amministrativa non viene mostrata né salvata. Concede soltanto
SELECT sulla vista limitata e rifiuta viste in conflitto o legate a un altro
database. Non importa dati, non modifica procedure e non cambia le collation.

5. BACKUP E RIPRISTINO DELLE CONFIGURAZIONI

Apri Amministrazione > Backup e ripristino. Scegli una password per l’archivio
di almeno 12 caratteri Unicode e al massimo 1.024 byte UTF-8. Spazi e accenti
restano parte della password. I backup precedenti mantengono la compatibilità. Conferma la tua
password amministratore e scarica il backup. Questa funzione richiede Sodium,
zlib e interi a 64 bit nel PHP web; Verifica installazione segnala le dipendenze
mancanti. Conserva archivio e password separatamente, al sicuro e fuori dal server.

La pagina mostra i limiti di caricamento del PHP che serve il sito, che possono
essere diversi da quelli del PHP CLI. Per supportare archivi fino al limite
applicativo di 16 MiB, imposta nel PHP web upload_max_filesize ad almeno 16M e
post_max_size ad almeno 20M; abilita caricamento file e lettura dei dati POST.
La pagina riserva 16 KiB del limite della richiesta agli altri campi del modulo.
Limiti più bassi funzionano con archivi più piccoli, ma un backup scaricato può
richiedere di aumentarli prima del ripristino. La pagina spiega i caricamenti
rifiutati e non cambia le impostazioni PHP. Anche server web e proxy possono
rifiutare richieste prima che arrivino a PHP: adegua i loro limiti se necessario.

Per ripristinare, carica un archivio creato da questa funzione, inserisci la sua
password e quella del tuo account amministratore, poi controlla l’anteprima.
Conferma la sostituzione di utenti e impostazioni attuali. Assicurati di conoscere
credenziali e secondo fattore di un amministratore presente nell’archivio.
Le sessioni esistenti vengono chiuse. Le app di autenticazione già associate
restano valide; i vecchi codici di recupero vengono invalidati e devono essere
rigenerati dopo l’accesso. Prima della sostituzione viene conservata una copia
protetta della configurazione attuale. Puoi scaricarla dalla stessa pagina
confermando la tua password amministratore; usa la stessa password dell’archivio
che hai inserito per il ripristino. Se il ripristino si interrompe, segui il
comando di recupero mostrato: il sito resta in manutenzione fino al completamento.

L’archivio comprende credenziali e permessi utenti, associazioni 2FA, preferenze,
viste operative, scenari salvati, aspetto e testi personalizzati, opzioni
applicative supportate, alias di operatori e code, selezione delle linee,
normalizzazione dei numeri e catalogo geografico. Connessioni database e AMI,
percorsi dei file e regole IP/proxy della destinazione vengono conservati.
L’archivio non trasferisce licenza, audio, analisi e storico, sorgenti CDR/registro
code né definizioni personalizzate di procedure o eventi SQL. Mantieni anche i
backup completi descritti sopra. Se un vecchio archivio contiene destinatari
dei report non validi, l’anteprima chiede di correggerli o lasciare vuoto il
campo sostitutivo: controllalo prima di confermare. Questo non impedisce di
creare il backup della configurazione esistente. Formati o versioni di archivio
non supportati vengono rifiutati prima della sostituzione.

6. AGGIORNAMENTI DELL’APPLICAZIONE E DEL DATABASE

Carica uno ZIP compatibile in Amministrazione > Aggiornamenti, controlla il piano
dei file e del database ed esegui il comando di applicazione esatto mostrato.
Il pacchetto include i file applicativi e gli eventuali passi del database
necessari per la versione di partenza. Non copiare file PHP e non importare SQL separatamente per
aggirare questa procedura.

Da R81 Fix19, Fix20, Fix21, Fix22, R82, R82 Fix1, R82 Fix2, R82 Fix3, R82 Fix4, R82 Fix5, R82 Fix6, R82 Fix7 o R82 Fix8, applica il singolo ZIP di aggiornamento R82 Fix9. Lo schema resta 4;
la procedura conserva la copia SQL completa e le copie dei file. Non serve un
nuovo pacchetto preparatorio. Per versioni precedenti completa prima il percorso
previsto fino a Fix19.

I nuovi siti vengono creati con schema 4. Per versioni non elencate, richiedi
il pacchetto e il percorso compatibili con la versione installata.

Per gli aggiornamenti coordinati, l’esecutore privilegiato usa un profilo
amministrativo SQL sotto /etc/obelisk, fuori dal sito e leggibile soltanto da root.
L’installer conserva la connessione amministrativa già verificata, per database
locali e remoti. L’autenticazione locale tramite socket può funzionare senza
password; quando serve, la password viene conservata soltanto in questo profilo
protetto. Se il profilo manca su un sito esistente, il normale comando di
aggiornamento chiede utente amministrativo SQL e password nascosta in una
sessione SSH interattiva. Per l’autenticazione locale tramite socket senza
password, lascia vuota la password. Connessione e permessi necessari vengono
verificati prima della manutenzione, anche se il profilo esiste già.
Non servono script aggiuntivi o file da creare manualmente. Un profilo esistente
non viene sovrascritto automaticamente né reso meno protetto. Le normali richieste
web non ricevono queste credenziali.

Prima delle modifiche strutturali, l’esecutore conserva una copia completa del
database Obelisk e dei file interessati e sospende le lavorazioni coinvolte.
Al completamento riapre l’applicazione. Se l’operazione si interrompe, conserva
il piano e le copie di recupero. Riapri quel piano in Amministrazione >
Aggiornamenti e usa «Mostra comando di applicazione» per proseguire oppure
«Mostra comando di ripristino» se il ripristino del database è già iniziato.
Segui l’esito nel terminale e lo stato del piano. Non eliminare marcatori di
manutenzione e non modificare i progressi per forzare la riapertura del sito.
Il ripristino coordinato richiede la conferma esplicita --restore-database e
riporta anche i dati al momento della copia: le modifiche successive vengono perse.

Piano e copie dei file sono conservati sotto data/updates/ nel sito. Le copie
complete del database e la diagnostica riservata sono conservate separatamente
sotto /var/lib/obelisk/schema-updates/, in cartelle legate al sito e al piano.
Queste copie SQL non vengono scaricate dalla pagina Backup e ripristino.
Usa il comando di eliminazione delle copie proposto dal pannello per un piano
concluso, come descritto in GESTIONE DEGLI AGGIORNAMENTI. Conserva le copie finché
serve il rollback. Non cancellare manualmente le cartelle del piano.

La copia di recupero dell’aggiornamento è distinta dal backup delle configurazioni.
Gli aggiornamenti conservano kernel_settings.php e le regole .htaccess
personalizzate. Le licenze esistenti sono conservate; non occorre riattivare
una licenza valida dopo l’aggiornamento.
I file già presenti ma assenti dal nuovo
inventario non vengono eliminati automaticamente. Per controllare e integrare
le regole di protezione web gestite da Obelisk, esegui dalla cartella del sito
installato con il PHP CLI corretto:

  sudo php utility/web_protection.php --dry-run
  sudo php utility/web_protection.php --apply

Il primo comando mostra l’anteprima. Il secondo applica soltanto le regole di
protezione gestite, conservando quelle personalizzate aggiuntive; non elimina
file applicativi dismessi. Poi esegui Verifica installazione. Non eliminare
indiscriminatamente file o protezioni.

CONTROLLI E CREDENZIALI PER GLI AGGIORNAMENTI

Dalla cartella del sito, con lo stesso eseguibile PHP CLI usato per aggiornare:

  sudo php utility/update.php --status --id=ID_DEL_PIANO
  sudo php utility/schema_profile.php --check

Il primo comando legge lo stato del piano indicato. Il secondo controlla il
profilo esistente e l'accesso SQL senza migrazioni, copie dei dati o modifiche
agli eventi; può predisporre la cartella privata della diagnostica. Non crea
un profilo mancante: in quel caso usa il comando di applicazione del pannello.

Lo stato prepared, senza manutenzione, consente di ripetere il comando dopo
aver risolto la causa indicata. Dopo rolled_back o failed_rolled_back il piano
è chiuso: per riprovare, carica di nuovo lo ZIP e usa il comando del nuovo piano.
Con recovery_required conserva tutte le copie e segui l'indicazione di ripresa
o ripristino; non forzare la riapertura del sito.

DIAGNOSTICA DI TRASFERIMENTI E COLLATION

Prima della migrazione allo schema 4, il controllo dell'aggiornamento esamina
le risposte da trasferimento mancanti che la migrazione dovrebbe inserire.
Con update_transfer_counters_invalid, usa queue_stats_id e invalid_fields
nel risultato JSON o nella diagnostica indicata per individuare la riga rifiutata.
I nomi info1/info2/info3 indicano rispettivamente i contatori canonici di attesa,
conversazione e posizione, non necessariamente colonne omonime della sorgente:
la mappatura dipende dal tipo di evento.
L'amministratore PBX/SQL deve verificarla alla fonte ed effettuare esplicitamente
le eventuali correzioni. I contatori non validi non vengono corretti automaticamente
né saltati. Un'installazione già allo schema 4 non ripete questo recupero storico.
Quando lo schema 4 viene verificato come base esistente, vengono controllate
procedura e collation, senza scandire le risposte da trasferimento mancanti.
La verifica dell'aggiornamento non è una scansione o riparazione generale di
tutte le righe storiche dei report.

Per un'anteprima storica separata, dalla cartella del sito installato usa il PHP
CLI corretto e sostituisci le date con l'intervallo da esaminare:

  php utility/repair_report_data.php --from YYYY-MM-DD --to YYYY-MM-DD --preview

Il comando mostra soltanto l'anteprima dell'intervallo scelto. Esamina eventuali
queue_stats_id e invalid_fields prima di decidere una riparazione. Non sostituisce
la verifica della sorgente né il recupero di un aggiornamento. Per applicare una
riparazione storica servono separatamente --apply --maintenance-confirmed e la
preventiva sospensione degli eventi SQL di elaborazione e dei cron di questa
installazione, come indicato da --help.

IMPORT ORDINARIO DELLE CODE: ERRORE 1048

Un errore 1048 dell'import può dipendere da un contatore di trasferimento non
valido, ma il solo messaggio di stato non dimostra questa causa. Se il batch è
stato annullato, l'evento sorgente può non essere ancora presente in queue_stats.
Il DBA può esaminare i candidati al trasferimento del prossimo batch sorgente
con questa query di sola lettura. Sostituisci SOURCE_DB, APP_DB e QUEUELOG_TABLE
con i nomi configurati del database sorgente, database applicativo e tabella
queue-log:

  SELECT pending.id, pending.event, pending.data1, pending.data2,
         pending.data3, pending.data4, pending.data5
  FROM (
      SELECT q.id, q.event, q.data1, q.data2, q.data3, q.data4, q.data5
      FROM `SOURCE_DB`.`QUEUELOG_TABLE` q
      JOIN `APP_DB`.`obelisk_import_state` s ON s.job = 'queue'
      WHERE q.id > s.cursor_id AND q.id <= s.source_high
      ORDER BY q.id LIMIT 5000
  ) pending
  WHERE pending.event IN ('TRANSFER', 'BLINDTRANSFER', 'ATTENDEDTRANSFER')
  ORDER BY pending.id;

L'elenco contiene candidati, anche potenzialmente validi: non dimostra che tutte
le righe siano errate. Verifica formato e contatori degli eventi interessati
alla fonte prima di pianificare una correzione esplicita. Non cambiare cursor_id,
non eseguire UPDATE o DELETE e non disabilitare lo strict mode SQL per aggirare
l'errore. Conserva lo stato dell'import e i dettagli diagnostici per la verifica.

COLLATION NON COERENTI

update_database_routine_collation_mismatch indica che la collation predefinita
attuale del database differisce dal contesto di creazione della procedura queue.
update_database_event_collation_mismatch riguarda invece la collation di creazione
di un evento SQL. Il DBA deve confrontare il valore predefinito del database con
i metadati SHOW CREATE dell'oggetto coinvolto e verificare la configurazione voluta.
Obelisk non cambia automaticamente le collation e non ricrea oggetti per aggirare
i controlli. Conserva definizioni, backup, piano e riferimento diagnostico.

Leggi prima lo stato con utility/update.php --status --id=ID_DEL_PIANO, usando il
comando di stato sopra. Quando il piano offre la verifica, copia l'esatto
«Mostra comando di verifica» da Amministrazione > Aggiornamenti: --check richiede
--id e --plan-hash di quel piano e può usare il programma preparato con --root.
Non sostituirlo con un comando di un altro piano. Dopo la correzione del DBA,
ripeti quel controllo. Se l'applicazione è già fallita, segui lo stato registrato:
failed_rolled_back richiede un nuovo piano; recovery_required richiede la ripresa
o il ripristino indicati, conservando tutte le copie. Non eliminare stato o
marcatori di manutenzione.

La nuova copia SQL richiede spazio libero locale almeno pari a tre volte la
stima di dati e indici del database Obelisk, con un minimo di 16 MiB, oltre allo
spazio per i file. Durante il ripristino non viene creata una seconda copia SQL:
rimane il controllo dei 16 MiB per i file di avanzamento. Questi controlli non
misurano lo spazio disponibile sul server SQL remoto.

Per un account amministrativo SQL dedicato, il DBA deve prevedere sul database
Obelisk SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER,
EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT e TRIGGER;
PROCESS globale; delega di EXECUTE e ALTER ROUTINE; lettura dei metadati degli
account e dei privilegi delle routine e visibilità delle definizioni SQL.
I diritti aggiuntivi per ricreare definers diversi, utenti di sistema o funzioni
con log binario dipendono dal motore e dagli oggetti presenti. Il controllo
--check verifica questi requisiti effettivi e non concede permessi. L'account
usato normalmente dal sito rimane separato dall'account amministrativo.

Se cambia la password SQL amministrativa, fai aggiornare dal DBA soltanto il
profilo di questo sito sotto /etc/obelisk/schema-updater-<identificativo>.json,
identificandolo tramite application_root. Mantieni proprietario root, directory
0700 e file 0600; non copiare il profilo nel sito e non stampare le credenziali.
Non modificare host, porta o database per aggirare un errore. Esegui poi il
controllo --check e ripeti il comando del piano. Il normale aggiornamento non
sostituisce automaticamente un profilo esistente.

GESTIONE DEGLI AGGIORNAMENTI

In Amministrazione > Aggiornamenti il dettaglio mostra l’impronta SHA-256 dello
ZIP e le versioni dello schema previste. «Mostra comando di verifica» prepara un
comando da eseguire in SSH sul piano selezionato: verifica file, profilo SQL e
requisiti senza applicare l’aggiornamento o attivare la manutenzione. L’esito ha
una data e vale per quel momento; l’applicazione ripete comunque i controlli.
Un profilo mancante viene configurato dal normale comando di applicazione.
La verifica separata è disponibile per i nuovi piani preparati dopo questo
aggiornamento. Per i piani precedenti resta valida la normale applicazione,
che include i controlli preliminari.

Se applicazione o ripristino devono usare il programma di aggiornamento già
installato perché il nome della versione non è supportato o la preparazione non
contiene tutti i componenti, il dettaglio mostra il motivo. Le verifiche di
compatibilità restano obbligatorie. Se mancano componenti necessari anche nel
programma installato, i relativi comandi non sono disponibili: verifica
l’integrità dell’installazione. La pulizia usa il programma installato. La verifica
usa il programma indicato dal comando del piano. Usa sempre quel comando:
non sostituirlo con uno conservato da un precedente aggiornamento.

Per i piani conclusi, «Mostra comando per eliminare le copie» richiede conferma
e prepara il comando SSH di pulizia. Elimina lo ZIP, i file preparati e le copie
di recupero dei file e del database. I dati applicativi correnti non cambiano.
La voce resta nell’elenco con «Copie eliminate» e quel rollback non è più
disponibile. Se la pulizia si interrompe, ripeti il suo comando. È bloccata
durante aggiornamenti, manutenzione o recuperi incompleti. Le dimensioni delle
copie sono rilevate dal comando privilegiato e riportate con la data di misura;
«Non misurato» non significa zero. Nessuna copia viene eliminata per anzianità.

In «Stato delle analisi automatiche» puoi filtrare il motivo della sospensione,
selezionare fino a 20 audio della pagina corrente e premere «Rimetti in attesa i
selezionati». Conferma il numero proposto. Gli elementi modificati nel frattempo
o già elaborati non vengono riavviati. Cambiare pagina o filtro azzera la
selezione. Il risultato distingue gli audio rimessi in attesa da quelli saltati.
Il «Registro accessi» mostra inoltre motivo e identificativo archivio per le
operazioni di backup configurazioni, quando questi dati sono disponibili.

MANUTENZIONE FACOLTATIVA: FILE APPLICATIVI RITIRATI

Dopo un aggiornamento completato, puoi controllare eventuali file applicativi
ritirati con questo comando di sola anteprima:

  sudo /usr/bin/php /var/www/html/obelisk/utility/retired_files.php --dry-run

Sono candidabili soltanto ImportSqlUpgrade.php, JsonConfig.php e
utility/upgrade_import_sql.php, se identici alle versioni originali riconosciute
e assenti dall’inventario della versione installata. File modificati o ancora
in uso restano conservati; dati, impostazioni, audio e copie di recupero sono esclusi.
Per eliminare i candidati, usa il plan_hash mostrato dall’anteprima:

  sudo /usr/bin/php /var/www/html/obelisk/utility/retired_files.php --apply --plan-hash=HASH_DELL_ANTEPRIMA

Se qualcosa cambia o l’operazione viene interrotta, genera una nuova anteprima.
La pulizia non parte automaticamente durante aggiornamenti o installazioni.
Mantieni i pacchetti originali per l’eventuale recupero dei file ritirati.
Per riallineare separatamente le regole web gestite, usa utility/web_protection.php
prima con --dry-run e poi con --apply; le direttive personalizzate restano conservate.

Documentazione operativa: https://obsk.io/it/manuals/
Licenze delle componenti: assets/vendor/notices/THIRD_PARTY_NOTICES.txt nella cartella
Obelisk installata (consultabile anche dal browser allo stesso percorso).

LINGUA DELLE UTILITY
Puoi scegliere la lingua delle istruzioni e degli esiti leggibili:
  sudo -u asterisk php utility/check_installation.php --lang=it
  sudo -u asterisk php utility/clean.php --dry-run --lang=it
Sono disponibili it, en ed es. La verifica usa it se non scegli una lingua;
la pulizia usa la lingua configurata per i report. I codici diagnostici
rimangono compatibili. --dry-run non elimina dati.
Nel JSON della pulizia, i nuovi lettori usano action_code, reason_code e
reason_code_counts (code_schema_version=1), con codici inglesi. I precedenti
action, reason e reason_counts restano disponibili per i lettori esistenti.

REGISTRAZIONI ED ESPORTAZIONI
Un download avviato durante la registrazione comprende i byte presenti
all'apertura del file. Attendi la fine della chiamata e ripeti il download
per ottenere l'audio completo.
I CSV proteggono i campi testuali dalle formule. Telefoni e identificatori
possono avere un apostrofo iniziale: importali come testo nel foglio di calcolo
per conservare prefissi e zeri iniziali. Il CSV non memorizza tipi di cella.

ANTEPRIMA DELLE REGOLE WEB
Nel piano di aggiornamento, .htaccess è indicato separatamente come blocco
gestito. Il comando di verifica mostra se verrà creato, modificato o lasciato
invariato. Le direttive esterne al blocco Obelisk vengono conservate.
Se il file viene modificato dopo l'aggiornamento, il rollback si ferma.
Conserva piano e copie di recupero: l'amministratore deve confrontare le
versioni del file e conciliare le personalizzazioni prima di riprovare.

7. SCADENZA LICENZA E ACCESSO AI DATI

Nei 14 giorni prima della scadenza compare un avviso amministrativo.
Alla scadenza, dalla pagina di attivazione scegli Accesso amministrativo e
accedi con le normali credenziali e 2FA. Puoi rinnovare, consultare i registri,
verificare l'installazione ed esportare un backup delle configurazioni.
Questo archivio non comprende CDR, storico dei report o audio: per quelli
mantieni il backup completo SQL e dei file descritto in questa guida.
Il ripristino di configurazioni e le modifiche operative richiedono una licenza valida.

Le attività AI, logger e report periodici attendono il rinnovo. Gli avvisi di
sicurezza, la manutenzione tecnica e gli import SQL restano attivi; le
cancellazioni seguono soltanto le opzioni già abilitate. I cron restano
pianificati e riprendono al rinnovo. Le anteprime non cancellano dati.

ALTRE VERSIONI DELL'AMBIENTE
L'installer ammette anche Debian 13 e PHP successivi; verifica la combinazione
con FreePBX e i suoi moduli. I requisiti minimi non certificano ogni combinazione.
Una demo non riparte reinstallando sullo stesso server. Per cambiare server o
cartella, richiedi al fornitore il trasferimento della licenza.

8. DISPOSITIVI E MONITORAGGIO DELLE CHIAMATE

Il Monitor interni usa le identità e le associazioni dei dispositivi configurate
in FreePBX (AMPUSER e DEVICE). Un endpoint PJSIP creato fuori da queste
associazioni, o un trunk con un nome numerico, non diventa un interno visibile
soltanto perché il suo identificativo è un numero. Le letture AMI di entrambe
le directory devono riuscire: in particolare database show DEVICE è necessario.
Se il catalogo non è disponibile, il Monitor non può ricostruire gli interni;
verifica connettività, credenziali e risposta AMI prima di modificare i dispositivi.

Un interno può avere più dispositivi, anche con identificativi 98xxx, 99xxx o
altri numeri. Obelisk usa l'associazione registrata in FreePBX, non il prefisso.
La Dashboard sceglie fra i dispositivi con una chiamata PJSIP osservata,
applicando le stesse priorità di stato delle carte del Monitor. Un dispositivo
senza chiamate osservate non nasconde una chiamata presente su un altro alias.
Resta un solo pulsante. Se la chiamata è sul dispositivo alias, il comando usa
quel dispositivo. La selezione riguarda il dispositivo, non una specifica
conversazione fra più chiamate presenti sullo stesso dispositivo.

Occupato o DND senza una chiamata osservata non fanno comparire il comando.
La pausa in coda, da sola, non impedisce di monitorare una chiamata presente.
I permessi dell'utente continuano a determinare i comandi disponibili. Al clic
viene ricontrollata l'associazione e la presenza del bersaglio: la chiamata può
essere terminata o il dispositivo può essere cambiato dall'ultimo aggiornamento.
Una richiesta accettata indica la conferma AMI del comando, non la conferma
che l'audio sia già collegato. L'audio dipende dallo stato corrente della chiamata
e del dispositivo; durante lo squillo può non esserci ancora una conversazione.
Se falliscono le letture aggiuntive necessarie al monitoraggio, la Dashboard
conserva code e statistiche disponibili ma non propone il comando di ascolto.

NOMI E DESCRIZIONI

Usa testo semplice per nomi e descrizioni delle code e dei trunk. I nuovi tag
HTML non sono accettati dall'editor. La formattazione presente nei valori
precedenti viene rimossa dalla presentazione, mantenendo il testo leggibile;
i dati già salvati e gli archivi di configurazione non sono riscritti per questo.
Accenti, apostrofi e simboli del testo semplice restano utilizzabili.
