Da CentOS a Debian 12: come si migra un centralino Sangoma PBXact senza fermare l’azienda

Chi ha un Sangoma PBXact o un FreePBX 16 in produzione ha in casa due cose che convivono male: un centralino che funziona benissimo e un sistema operativo che dal 30 giugno 2024 non riceve più aggiornamenti di sicurezza. Finché non succede niente, non succede niente. Il problema si presenta il giorno in cui esce una vulnerabilità che non verrà mai chiusa, oppure il giorno in cui un assessment di sicurezza lo mette per iscritto e qualcuno deve firmare.

Il passaggio alla versione 17 non è un aggiornamento. È una reinstallazione con travaso, perché cambia il sistema operativo sotto: FreePBX 17 e PBXact 17 girano ufficialmente solo su Debian 12 “Bookworm”, e la ISO storica su CentOS non viene più pubblicata. Al suo posto ci sono lo script di installazione su Debian e una ISO che lo incapsula. Questa frase, letta da chi ha i numeri dell’azienda su quel centralino, spaventa. Giustamente.

Questo è il racconto di una migrazione FreePBX 17 eseguita su un impianto reale in un’azienda manifatturiera, non su un laboratorio: cinquanta interni, telefoni fissi Yealink, tre trunk SIP (uno verso le linee esterne attraverso un SBC AudioCodes virtuale, due verso le altre sedi del gruppo), cordless wifi Ascom i63 in mano a chi si muove in stabilimento. Fermo effettivo del centralino: un minuto.

Il minuto non è un vanto. È la conseguenza di dove è stato messo il lavoro.

Migrazione FreePBX 17: perché non è un aggiornamento

C’è una differenza che vale la pena mettere in chiaro, perché è la fonte di quasi tutte le sorprese. Il comando fwconsole ma upgradeall aggiorna i moduli FreePBX dentro la stessa versione maggiore: è manutenzione ordinaria e si fa senza pensarci. Il salto dalla 16 alla 17 è un’altra cosa, perché sotto cambia la distribuzione Linux.

Il percorso supportato da Sangoma per arrivare alla 17 da una versione precedente è il modulo Backup and Restore. Non è un ripiego di chi non ha voglia di fare le cose per bene: è la procedura ufficiale. Si installa Debian 12, si installa FreePBX 17 con lo script pubblicato da Sangoma, si ripristina il backup del vecchio sistema.

Cosa cambia sotto il cofano:

Componente	FreePBX 16 (impianto di partenza)	FreePBX 17 e PBXact 17
Sistema operativo	CentOS 7, fuori supporto dal 30 giugno 2024	Debian 12 “Bookworm”
Installazione	ISO Sangoma	script di installazione su Debian pulita, oppure una ISO che installa Debian e avvia lo stesso script
PHP	versione legata alla distribuzione	8.2, con supporto di sicurezza dichiarato fino a dicembre 2026
Asterisk	fino alla 20	fino alla 22, predefinita
Aggiornamenti futuri di versione	reinstallazione	in linea, senza reinstallare

L’ultima riga è il motivo per cui questa migrazione si fa una volta sola. È l’ultimo travaso.

Il vincolo su PHP 8.2 e i moduli commerciali

Un vincolo da conoscere prima di mettere le mani sulla macchina: i moduli commerciali Sangoma sono testati esclusivamente su PHP 8.2. Chi decide di “modernizzare” installando una versione di PHP più recente rompe i moduli a pagamento, cioè esattamente quelli che il cliente ha comprato.

Cambiare versione e cambiare piattaforma sono problemi diversi

Va detto anche cosa questo caso non è. Qui si cambia versione restando sulla stessa piattaforma, con la configurazione che si porta dietro. Quando invece è il produttore a uscire dal mercato il problema è di natura diversa, perché non c’è nessun percorso di travaso previsto: lo abbiamo trattato nella guida alla sostituzione di un centralino Panasonic o Selta.

La verifica che viene prima di tutte: PJSIP o chan_sip

Questo è il punto in cui una migrazione si mette male, e va controllato prima ancora di scaricare Debian.

Asterisk 21 non contiene più il driver chan_sip, e nemmeno la 22, oggi predefinita nella 17. Sangoma documenta un ripiego con Asterisk 20 sulla 17, ma è tempo comprato, non una soluzione. Se i trunk e gli interni del sistema di partenza sono ancora su chan_sip, dopo il ripristino non si registra niente, e il problema non è il backup: è che quel driver non esiste più.

Nel caso raccontato il passaggio a PJSIP era già stato completato in un intervento precedente, quindi la migrazione è partita da una situazione pulita. È metà della ragione per cui è filata liscia, e va detto senza giri di parole: se sei ancora su chan_sip, la conversione è un progetto a sé. Si fa prima, sul sistema vecchio che funziona, con il tempo per verificare trunk per trunk. Farla nella stessa finestra della migrazione significa avere due cause possibili per lo stesso guasto, di notte, con l’azienda che apre alle otto.

Preparare il sistema che stai per spegnere

Sembra controintuitivo aggiornare una macchina destinata alla dismissione. È invece il passaggio che rende il backup ripristinabile.

Il ripristino su FreePBX 17 funziona meglio se il backup arriva da un sistema con i moduli allineati all’ultima versione disponibile. Quindi, in ordine: fwconsole ma upgradeall per portare tutti i moduli FreePBX alla versione corrente, poi aggiornamento dei pacchetti del sistema operativo per quanto ancora possibile su una distribuzione fuori supporto, poi backup completo.

E il backup si scarica in locale, fuori dalla macchina. Un backup che resta solo sul server che stai per spegnere non è un backup, è un file.

Le licenze e i due reset che nessuno ti dice

Il deployment ID di un sistema Sangoma è legato all’hardware. Per usarlo su una macchina nuova va prima sganciato dalla vecchia, e la procedura è documentata: si fa dal portale Sangoma oppure dal modulo System Admin del PBX.

C’è un dettaglio che quasi nessuno conosce prima di sbatterci contro, e che vale da solo la lettura di questo articolo: il reset dell’hardware lock è disponibile due volte in autonomia. Dopo il secondo, l’opzione sparisce dall’interfaccia e per ottenerne un altro bisogna aprire una richiesta al supporto Sangoma e aspettare.

Sull’ordine delle operazioni c’è una domanda che Sangoma ha messo nelle FAQ ufficiali, segno che gliela fanno tutti: prima si attiva il deployment o prima si ripristina il backup? La risposta è: prima si attiva, poi si ripristina.

Nell’intervento raccontato la sequenza è stata: sgancio della licenza dal vecchio sistema tramite il portale, caricamento della licenza sul nuovo da console, e solo dopo il caricamento del backup.

Costruire il nuovo sistema in parallelo, con i trunk spenti

Debian 12 su macchina virtuale, installazione di FreePBX 17 con lo script ufficiale, aggiornamento di tutti i pacchetti del sistema operativo e dei moduli all’ultima versione disponibile, poi il ripristino del backup.

E qui arriva la contromisura al rischio più concreto dell’intera operazione. Sangoma avverte in modo esplicito di disabilitare o cancellare i trunk dopo il ripristino, perché due sistemi che registrano lo stesso trunk nello stesso momento rendono imprevedibile il comportamento delle chiamate in ingresso. La chiamata arriva a uno dei due centralini, e quale dei due lo decide il caso. Il cliente se ne accorge quando un suo cliente si lamenta che nessuno risponde.

Nel caso raccontato i trunk sono rimasti spenti sul sistema nuovo per tutta la fase di preparazione. Non disabilitati “quasi”, non lasciati configurati con l’idea di stare attenti: spenti. Sono stati accesi al momento del taglio e non un minuto prima, e nello stesso momento sono stati spenti sul sistema vecchio.

Il trunk verso le linee esterne passa da un SBC AudioCodes virtuale, che resta l’unico apparato esposto verso l’operatore e non va toccato durante la migrazione: cambia soltanto l’indirizzo del centralino a cui consegna le chiamate. Su come si configura in sicurezza quel perimetro, con DMZ, access list, TLS e SRTP, c’è la guida dedicata alla configurazione sicura di un SBC.

Lo switch degli indirizzi IP

Qui c’è la scelta che ha prodotto il minuto di fermo, ed è una scelta di metodo, non un trucco.

La procedura descritta praticamente ovunque è: spegni il vecchio, accendi il nuovo. Funziona. Ma ha un difetto strutturale che si manifesta esattamente nel momento peggiore: se qualcosa non torna, sei fermo, con l’azienda al telefono, e il ripristino della situazione precedente richiede tempo che in quel momento non hai.

L’alternativa costa una riga di configurazione in più e cambia completamente il profilo di rischio. Il nuovo sistema nasce su un indirizzo IP di servizio, si valida con calma nei giorni precedenti, e al momento del taglio si scambiano gli indirizzi: il nuovo prende l’IP di produzione, il vecchio resta acceso e raggiungibile su un altro indirizzo della stessa rete.

Aspetto	Spegni il vecchio, accendi il nuovo	Scambio degli indirizzi IP
Riconfigurazione dei telefoni	necessaria se l’IP del centralino cambia	nessuna, i telefoni continuano a puntare allo stesso indirizzo
Tempo di rollback	ripristino del sistema precedente, ore	un altro scambio di indirizzi, minuti
Verifica a posteriori	il vecchio è spento, non si confronta più niente	il vecchio è vivo e interrogabile per giorni
Confronto di configurazioni in caso di dubbio	impossibile senza riaccendere	immediato
Costo aggiuntivo	nessuno	due macchine accese per qualche giorno

Perché il metodo più diffuso ha il rientro peggiore

Detto senza diplomazia: il metodo più diffuso è anche quello con il piano di rientro peggiore, e l’unico vantaggio che offre è non tenere accesa una seconda macchina virtuale per qualche giorno. Su un impianto da cinquanta interni quel risparmio non esiste.

La finestra giusta è la pausa pranzo, non le tre di notte

Sulla scelta della finestra vale lo stesso ragionamento controintuitivo. Il taglio è stato fatto in pausa pranzo, il momento più scarico della giornata lavorativa. Non alle tre di notte. Su un impianto validato in anticipo il taglio dura un minuto, e conviene farlo quando in azienda c’è ancora qualcuno in grado di accorgersi che qualcosa non va e di dirtelo mentre sei collegato, invece di scoprirlo dalle segnalazioni del mattino dopo.

Il collaudo, nell’ordine in cui va fatto

I tre tipi di dispositivo si comportano in modo diverso, e saperlo evita di dichiarare un guasto dove c’è solo un timer che non è ancora scaduto.

Cosa si verifica	Come si forza	Comportamento osservato
Telefoni fissi Yealink	riavvio degli apparati	registrati e operativi subito dopo il riavvio
Cordless wifi Ascom i63	spegnimento e riaccensione del terminale, oppure nessuna azione	registrati subito se riavviati, altrimenti alla scadenza della registrazione precedente
Trunk verso le linee esterne, via SBC AudioCodes	accensione del trunk	immediata
Trunk fra le sedi	accensione dei trunk	immediata
Instradamento in ingresso e in uscita	chiamata reale su ogni percorso	manuale, una per una

I cordless wifi non si comportano come i telefoni fissi

Il punto sui cordless merita attenzione perché è quello che genera più falsi allarmi. Ci sono due strade e vanno conosciute entrambe. Se il terminale si spegne e si riaccende, si registra subito, come un telefono fisso. Se invece lo si lascia in mano alla persona che sta lavorando, si registra da solo alla scadenza del timer di registrazione, senza che nessuno tocchi niente. Nel frattempo, per qualche minuto, sembra che non funzioni.

Quale delle due si usa dipende da quanti terminali ci sono e da dove sono. Su pochi apparati raggiungibili conviene forzare e chiudere la verifica in due minuti. Su una flotta distribuita in stabilimento, dove i terminali sono in tasca a persone che stanno lavorando, girare i reparti per riavviarli uno per uno costa più tempo dell’attesa: si lascia scadere il timer e si verifica dopo. La cosa da non fare è dichiarare un guasto nei minuti intermedi, che è l’errore più comune di chi collauda una migrazione per la prima volta.

Registrazione non significa instradamento

L’ultima riga della tabella è quella che non si può saltare. La registrazione di un trunk dice che il centralino e l’operatore si parlano, non dice che le chiamate arrivano dove devono. L’instradamento si verifica chiamando, percorso per percorso, in ingresso e in uscita, comprese le sedi collegate dai trunk interni.

Se in questa fase compaiono audio a senso unico, voce a scatti o chiamate che cadono dopo pochi secondi, spesso la causa non è il centralino nuovo ma la rete che lo circonda, e conviene partire dalla tabella sintomo, causa e rimedio della guida ai problemi audio del VoIP invece di rimettere mano alla configurazione appena ripristinata.

I firmware alla fine, mai all’inizio

Aggiornare i firmware dei telefoni prima della migrazione significa cambiare due variabili nello stesso momento. Se poi un apparato non registra, non si sa se la colpa sia del centralino nuovo o del firmware nuovo, e si perde un’ora a capirlo.

L’ordine corretto è: prima si porta l’impianto sul nuovo centralino, si verifica che tutto sia registrato e che l’instradamento funzioni, e solo a quel punto si aggiornano i firmware, fissi e cordless, all’ultima versione disponibile. Con l’EndPoint Manager il provisioning è già centralizzato, quindi l’aggiornamento è una campagna e non cinquanta interventi manuali.

Sui terminali VoWiFi l’allineamento dei firmware non è un dettaglio estetico: tocca il comportamento di registrazione e di roaming, che è quello che tiene in piedi la voce di chi cammina. Netframe è Ascom Certified Partner e su questi apparati l’aggiornamento fa parte della consegna, non è un’attività opzionale da rimandare. Sul confronto fra voce su Wi-Fi e DECT aziendale, e su quando conviene l’una o l’altra soluzione negli ambienti dove le persone si muovono, c’è una guida dedicata; i requisiti radio, il roaming e il collaudo in chiamata sono nella guida sui telefoni Wi-Fi di reparto con Ascom i63 su Cisco Catalyst 9800.

Cosa non è passato in automatico

Niente. Configurazione, interni, code, instradamenti e moduli commerciali (EndPoint Manager e Class of Service) sono passati con il ripristino, senza interventi manuali di recupero.

Ma la ragione per cui è andata così va detta, altrimenti il lettore conclude che sia automatico e prenota la migrazione per il venerdì pomeriggio. Il sistema di partenza era allineato all’ultima versione dei moduli. I trunk erano già PJSIP da un intervento precedente. Il sistema di destinazione è stato aggiornato prima del ripristino, non dopo. Le licenze sono state spostate prima di caricare il backup.

La migrazione è filata liscia perché le cose difficili erano state fatte prima, in momenti separati e senza fretta. Non perché la procedura sia banale.

Il piano di rientro

È la domanda che il cliente fa per prima, e la risposta deve esistere prima di iniziare.

Se il nuovo sistema non registra, o se l’instradamento non torna, si riscambiano gli indirizzi IP e si riaccendono i trunk sul sistema vecchio, che è ancora acceso, con la sua configurazione intatta, e che non è mai stato toccato durante l’operazione. Tempo di rientro: quanto ci mette a riavviarsi un’interfaccia di rete.

Il prezzo di questo approccio è tenere due macchine virtuali accese per qualche giorno, finché non si è certi. È il prezzo più basso a cui si possa comprare un piano di rientro.

Netframe, system integrator IT dell’Emilia-Romagna con sede a Modena, progetta e migra centralini telefonici VoIP su piattaforme 3CX, FreePBX e PBXact di Sangoma, Kalliope e Alcatel-Lucent Enterprise, con progetti in tutta Italia.

Domande frequenti

Si può aggiornare FreePBX 16 a FreePBX 17 senza reinstallare?

No, perché cambia il sistema operativo sotto: la 17 gira ufficialmente solo su Debian 12. Il percorso supportato da Sangoma è installare Debian 12 con FreePBX 17 e ripristinare il backup del sistema precedente con il modulo Backup and Restore. Dalla versione 17 in avanti gli aggiornamenti di versione dovrebbero tornare a essere in linea, senza reinstallazioni.

Le licenze dei moduli commerciali si perdono nella migrazione?

No, si spostano insieme al deployment ID, che va prima sganciato dal vecchio sistema. Attenzione però al limite: il reset dell’hardware lock è disponibile due volte in autonomia, dal portale Sangoma o dal modulo System Admin, e dopo il secondo serve una richiesta al supporto. Va usato quando il sistema nuovo è pronto, non per fare prove.

Quanto dura il fermo del centralino durante la migrazione?

Dipende da dove si mette il lavoro. Con il sistema nuovo costruito e validato in parallelo, il taglio consiste nello scambio degli indirizzi IP e dura circa un minuto. I telefoni fissi tornano operativi al riavvio; i cordless wifi si registrano subito se spenti e riaccesi, oppure da soli alla scadenza della registrazione precedente. Il tempo vero della migrazione sta nei giorni prima, non nella finestra.

Cosa succede se i trunk sono ancora su chan_sip?

Asterisk 21 e 22, le versioni installate da FreePBX 17, non supportano più quel driver. La conversione a PJSIP va pianificata come intervento separato e va fatta prima, sul sistema esistente. Farla insieme alla migrazione significa avere due cause possibili per ogni guasto che si presenta.

CentOS 7 non è più supportato: il centralino smette di funzionare?

No, continua a funzionare esattamente come prima. Quello che si è fermato sono gli aggiornamenti di sicurezza del sistema operativo, che è un problema diverso e più serio: significa che le vulnerabilità scoperte dopo il 30 giugno 2024 su quella base non verranno mai corrette. Per chi ha obblighi di conformità, o semplicemente un security assessment da superare, è la ragione per cui la migrazione smette di essere rimandabile.

Fonti

• Sangoma, documentazione FreePBX 17: piattaforma supportata, ISO e script di installazione, PHP 8.2, Asterisk 21 e 22
• Sangoma, Version 17 FAQ: percorso di aggiornamento tramite Backup and Restore, ordine fra attivazione e ripristino, compatibilità dei moduli commerciali con PHP 8.2
• Sangoma, Upgrade to PBXact 17: sequenza di installazione, attivazione del deployment e ripristino della configurazione
• Sangoma, How to Remove a Deployment ID / License File from your PBX: reset dell’hardware lock e limite dei due reset in autonomia
• FreePBX.org, annuncio ufficiale dell’installazione su Debian: avvertenza sulla disabilitazione dei trunk dopo il ripristino
• Red Hat, ciclo di vita di Red Hat Enterprise Linux 7 e conseguente fine del supporto di CentOS Linux 7 al 30 giugno 2024 (fonte consultata in forma descrittiva, senza collegamento diretto)

Fonti verificate il 28 agosto 2026.