Quando si migra invece di aggiornare sul posto

Per portare un Security Management Server a R82 ci sono tre strade. CPUSE aggiorna la macchina esistente in modo automatico. Advanced Upgrade resta sulla stessa macchina ma passa per il database: backup, esportazione del database, installazione pulita di R82, importazione. Migration and Upgrade fa la stessa cosa fra due macchine diverse: si esporta dalla sorgente, si installa R82 pulito su un server nuovo, si importa lì il database.

La distinzione conta perché decide la risposta a metà delle domande del modulo: se cambia l’hardware, se si passa a un’appliance diversa o se si vuole tenere in piedi il server vecchio fino al collaudo, la strada è la migrazione, non l’aggiornamento sul posto. Lo strumento è lo stesso in entrambi i casi, migrate_server, e vive in $FWDIR/scripts sul server di gestione; si lancia da Expert mode.

Preparare la sorgente

Prima di esportare vanno chiuse tutte le sessioni SmartConsole collegate al server e pubblicate le modifiche in sospeso: ciò che resta in una sessione aperta non è nel database e quindi non viaggia. Servono licenze valide sia sulla sorgente sia sulla destinazione e un Service Contract registrato nel Check Point User Center che copra gli aggiornamenti.

Poi vanno installati gli Upgrade Tools della versione di destinazione, che si scaricano da sk135172 e si installano con CPUSE come pacchetto offline. L’installazione si verifica così:

cpprod_util CPPROD_GetValue CPupgrade-tools-R82 BuildNumber 1

Il Pre-Upgrade Verifier si lancia con la stessa utility che poi esporta:

cd $FWDIR/scripts
./migrate_server verify -v R82

Vanno controllati anche gli spazi: sulla destinazione la partizione /var/log deve essere almeno un quarto di quella della sorgente, e per Advanced Upgrade e migrazione il disco deve avere spazio pari ad almeno cinque volte la dimensione del database esportato. La configurazione IPv4 o IPv6 della destinazione deve corrispondere a quella della sorgente, e si cambia semmai dopo.

Esportare, trasferire, importare

L’esportazione produce un unico archivio con database di gestione e configurazione di Check Point:

./migrate_server export -v R82 /var/log/export_db
./migrate_server export -v R82 -skip_upgrade_tools_check /var/log/export_db

La seconda forma serve quando il server non raggiunge Internet e il controllo della disponibilità di tool più recenti fallirebbe. I log non partono con il database: si aggiunge -l per portarli senza indici oppure -x per portarli con gli indici, indicando il numero di giorni. Il flag --exclude-licenses esclude le licenze dal salvataggio, e questo è un motivo in più per non usarlo a cuor leggero.

Prima e dopo il trasferimento si calcola l’impronta dell’archivio con md5sum e lo si copia in modalità binaria. Sulla destinazione serve un’installazione pulita di R82 completata con il First Time Configuration Wizard, senza però avere fatto la configurazione iniziale da SmartConsole, con gli stessi Upgrade Tools installati e una licenza valida verificabile con cplic print. Se l’indirizzo IP cambia, il nuovo indirizzo si dichiara prima dell’import nel file /var/log/mdss.json. L’importazione è simmetrica all’export:

./migrate_server import -v R82 /var/log/export_db.tgz

Il comando ferma e riavvia da solo i servizi Check Point, quindi non serve anticiparlo con cpstop. L’esito si legge nel log dell’operazione sotto /var/log/opt/CPshrd-R82/, mentre un’operazione fallita lascia traccia in $CPDIR/log/.

Dopo l’import

Se l’IP è cambiato si emettono le nuove licenze nello User Center per il nuovo indirizzo, si installano dalla CLI o dal Gaia Portal, si rimuove la licenza vecchia e si attende un paio di minuti oppure si riavviano i servizi con cpstop e cpstart. Poi si installa SmartConsole R82, si aggiorna la versione degli oggetti dei server dedicati, si esegue Install database selezionando tutti gli oggetti e si collauda l’ambiente prima di spegnere il server vecchio.

Trappole tipiche d’esame

  • Backup completo vuol dire anche certificati e licenze. L’export porta con sé il database di gestione, e quindi la Internal Certificate Authority e i certificati; le licenze ci sono a meno che non le si escluda. Uno snapshot Gaia non copre questo caso, perché si reimporta solo su hardware dello stesso modello.
  • Gli Upgrade Tools appartengono alla versione di destinazione. Vanno installati sia sulla sorgente sia sulla destinazione, e senza di essi nemmeno il Pre-Upgrade Verifier gira.
  • Senza pubblicare, il lavoro resta nella sessione. Le modifiche non pubblicate e le sessioni SmartConsole aperte sono la causa silenziosa di un database importato incompleto.
  • La destinazione deve essere pulita. Importare su un server già configurato da SmartConsole, o con un Jumbo Hotfix Accumulator diverso quando si importa fra server di pari versione, è la via più rapida per un database corrotto.
  • L’integrità si verifica prima della policy. Impronta md5sum prima e dopo il trasferimento, cplic print, controllo degli oggetti in SmartConsole e Install database: solo dopo si installa la policy. Saltare questi passaggi sposta il guasto al momento peggiore.
  • Il cambio di IP si dichiara prima. Il file preparato sulla destinazione prima dell’import, le nuove licenze e l’aggiornamento di indirizzo e topologia nell’oggetto del server sono tre passi distinti, e le domande ne omettono uno.