Che cosa fa Central Deployment e da dove si lancia

Central Deployment è il modo con cui si installano pacchetti software su molti dispositivi gestiti senza collegarsi a ciascuno via SSH. Si usa dalla vista Gateways & Servers di SmartConsole, dal menu Actions della barra strumenti: da lì si scelgono Install Hotfix/Jumbo, l’aggiornamento di versione con Version Upgrade, oppure la disinstallazione di un hotfix già presente.

Le famiglie di pacchetti sono tre: hotfix singoli e Jumbo Hotfix Accumulator, pacchetti di upgrade a una versione maggiore, e la rimozione di hotfix o Jumbo installati in precedenza. Il pacchetto arriva dal Check Point Cloud oppure dal Package Repository locale del Management Server; al momento dell’installazione si sceglie la sorgente del download fra Automatic, Gateway e Management.

Una singola operazione accetta fino a 30 destinazioni e ne installa al massimo 10 in parallelo. Il pulsante Verify esegue i controlli preliminari, cioè compatibilità del pacchetto con la destinazione e spazio libero su disco, prima che l’installazione parta davvero.

Prerequisiti e perimetro di supporto

Perché una destinazione sia utilizzabile servono quattro condizioni: il profilo di permessi dell’amministratore deve includere il permesso di scrittura SmartUpdate, sulla destinazione deve girare l’ultimo CPUSE Deployment Agent, il SIC fra Management Server e destinazione deve essere stabilito, e sulla destinazione deve essere installata una policy attiva. Per i download dal cloud il Management Server deve raggiungere il Check Point Cloud.

Le destinazioni supportate sono Security Gateway, membri ClusterXL in High Availability, cluster VSX che non siano in VSLS, Log Server e Security Management Server secondari. Il cluster si seleziona come oggetto intero: non si sceglie un singolo membro.

Restano fuori dal supporto SmartConsole collegata attraverso un proxy, ClusterXL in Load Sharing, i cluster VRRP, i Security Group su Maestro e su Scalable Chassis 40000 e 60000, e i cluster ElasticXL. Sulle appliance Spark con Gaia Embedded il download dal cloud non è disponibile e il pacchetto va aggiunto a mano al repository.

Su un cluster ClusterXL in High Availability lo strumento verifica lo stato dei membri, aggiorna prima gli standby, abilita il funzionamento Multi-Version Cluster, provoca il failover verso i membri già aggiornati e solo allora aggiorna l’ex membro attivo, per poi riportare il cluster allo stato normale. Si può decidere se agire su tutti i membri o solo su quelli non attivi. A installazione finita, le policy di Threat Prevention interessate vanno reinstallate.

Compatibilità fra Security Gateway e Management Server

La regola d’ordine è netta: i Management Server si aggiornano prima dei Security Gateway e dei cluster, e prima dei Log Server e dei SmartEvent Server dedicati. Un management più vecchio dei dispositivi che gestisce non è una configurazione da cui partire.

I percorsi verso R82 non sono tutti diretti: da R81.20, R81.10, R81 e R80.40 si arriva a R82 in un passo solo, mentre da R80.30, R80.20, R80.20.M1 e M2, R80.10 e R77.30 serve un aggiornamento intermedio. L’elenco delle versioni di Security Gateway che un management R82 può gestire è pubblicato a parte, nelle Release Notes e in sk113113: è una lista da consultare, non da dedurre.

Serve inoltre un Service Contract valido e registrato nel Check Point User Center che copra gli aggiornamenti: il file del contratto risiede sul Management Server e viene scaricato sui gateway durante l’aggiornamento.

La compatibilità si legge poi negli indicatori di stato della vista Gateways & Servers: nessun colore significa aggiornato, il giallo segnala un Jumbo Hotfix Accumulator non allineato alla versione raccomandata, il rosso dice che la versione installata sul gateway non è supportata, il grigio che l’informazione non è disponibile, per versione incompatibile, per assenza di contatto con il Download Center da oltre trenta giorni, per aggiornamenti limitati o per licenza mancante.

Trappole tipiche d’esame

  • Verify non è un backup. Il controllo preliminare guarda compatibilità e spazio su disco, non salva nulla. Prima di aggiornare vanno presi il backup del database del Management Server e la copia di sicurezza dei gateway: nelle domande che chiedono «che cosa manca in questa procedura» la risposta è quasi sempre quella.
  • Snapshot e backup non sono intercambiabili. Uno snapshot Gaia si reimporta solo su appliance o server dello stesso modello hardware da cui è stato esportato, e occupa molto spazio; come rete di sicurezza ordinaria la documentazione preferisce Backup and Restore.
  • Aggiornare senza verificare la compatibilità. Lo scenario tipico mette un gateway su una versione da cui non esiste percorso diretto, oppure aggiorna il gateway prima del management: entrambe le mosse sono sbagliate anche se l’installazione in sé riesce.
  • Il membro singolo del cluster. Central Deployment lavora sull’oggetto cluster. La richiesta di non toccare il membro attivo si soddisfa con l’opzione sui soli membri non attivi, non selezionando un membro nell’elenco.
  • Le esclusioni si ricordano insieme. ClusterXL in Load Sharing, VRRP, Security Group Maestro ed ElasticXL non sono destinazioni valide: se lo scenario le nomina, la risposta corretta non è «usa Central Deployment».
  • Ricadere nell’aggiornamento manuale. Installare gli hotfix a mano su ogni membro fa perdere la sequenza automatica, cioè standby per primi, Multi-Version Cluster e failover controllato, ed è l’errore che il vendore segnala più spesso su questo modulo.
  • Il grigio non parla solo di licenze. L’indicatore grigio ha quattro cause possibili, e la licenza assente è soltanto una di queste.