Quando un amministratore dice che «SmartConsole non funziona» sta descrivendo dove ha visto il sintomo, non dove sta il guasto. A livello CCTE la differenza è tutta qui: SmartConsole è un client, parla con il Management Server, e quasi nessuno dei suoi malfunzionamenti si risolve mettendo le mani su un Security Gateway.

Separare client, rete e server prima di aprire una shell

Conviene tagliare il problema in tre strati e decidere subito in quale ci si trova.

Il primo è la postazione: versione di SmartConsole rispetto a quella del server, risoluzione del nome, credenziali dell’amministratore. Un client più vecchio del server si comporta in modi che sembrano guasti del server.

Il secondo è la rete fra il client e il Management Server. Qui il controllo più informativo è il fingerprint: fwm fingerprint mostra il Check Point fingerprint sul server, ed è il valore da confrontare con quello che SmartConsole propone alla prima connessione. Se i due non coincidono non è «un problema di login»: o il certificato del server è cambiato, o qualcuno sta in mezzo.

Il terzo strato è il server, ed è l’unico in cui i comandi che seguono hanno senso.

Determinare lo stato del management con il WatchDog

Check Point WatchDog è il processo che «invokes and monitors critical processes such as Check Point daemons on the local computer, and attempts to restart them if they fail». L’elenco esatto dipende dai prodotti e dalle Software Blade installate; su un Management Server si incontrano tipicamente fwm, fwd, cpd e DAService.

cpwd_admin list «prints the status of all WatchDog monitored processes on the screen». Le colonne sono APP, PID, STAT, #START, START_TIME, MON e COMMAND. I valori di STAT sono due: E per executing e T per terminated.

La lettura ingenua si ferma a STAT, ed è quella che l’esame punisce. La lettura utile incrocia tre colonne. Un processo con STAT a E sta girando in questo istante; se però #START è a quattordici e START_TIME risale a due minuti fa, quel processo sta morendo e il WatchDog lo sta rialzando in ciclo. Una fotografia scattata nel momento giusto racconterebbe che è tutto a posto.

La colonna MON dice come il processo viene sorvegliato. In modo passivo il WatchDog «restarts the process only when the process terminates abnormally»; in modo attivo «checks the process status every predefined interval». Un processo vivo ma bloccato, sorvegliato in modo passivo, non viene rialzato da nessuno: resta E per sempre e non serve a niente.

La storia dei riavvii, che cpwd_admin list riassume in un contatore, sta per esteso in $CPDIR/log/cpwd.elg.

Accanto ai processi va guardata la macchina. cpview è «a text based built-in utility on a Check Point computer» e mostra CPU, Memory e Disk space. Una partizione piena su un Management Server non ferma alcun processo, ma fa fallire le scritture e si presenta all’utente finale come un errore di SmartConsole. fwm ver chiude il quadro indicando la versione del server.

L’API Server, il componente che si dimentica

Molte operazioni che l’utente compie in SmartConsole passano dall’API Server, che gira sul Management Server. Il suo stato si legge con api status: quando è in ordine riporta «Overall API Status: Started» e conferma che «API readiness test SUCCESSFUL. The server is up and ready to receive connections». Si governa con api start e api restart, e si configura da SmartConsole in Manage & Settings > Blades > Management API > Advanced Settings.

Qui sta la distinzione che il modulo chiede davvero. cpwd_admin list dice che un processo esiste; api status dice che un servizio è pronto a ricevere connessioni. Un API Server avviato che non supera il readiness test risulta vivo alla prima verifica e inerte alla seconda: fermo e degradato non sono lo stesso guasto e non hanno la stessa cura.

mgmt_cli fornisce la lente indipendente dalla GUI, perché «works directly with the management database on your Management Server». Se mgmt_cli risponde e SmartConsole no, il guasto è a valle del server; se non risponde nessuno dei due, è sul server.

Una nota documentata che sembra un guasto e non lo è: sui server standalone «the API Documentation web portal stops working when you open SmartView Web Application».

Trappole tipiche d’esame

  • Spostarsi sul gateway per un sintomo del management. Lo scenario mostra SmartConsole che si comporta male e fra le risposte compare un comando da eseguire sul Security Gateway. Il gateway non partecipa alla connessione fra client e Management Server: se il sintomo vive lì, la prova va cercata lì.
  • Dimenticare l’API Server. La domanda descrive un’azione di SmartConsole che fallisce mentre «tutti i processi sono in esecuzione». Proprio quella premessa è l’indizio: cpwd_admin list è già stato fatto, manca api status.
  • Leggere STAT e fermarsi. Se lo scenario fornisce #START e START_TIME, li fornisce perché servono. Un contatore di avvii alto con un orario recente descrive un ciclo di crash, non un servizio sano.
  • Trattare un servizio degradato come un servizio fermo. Riavviare un processo che risponde male può far sparire il sintomo senza spiegare nulla; la risposta corretta di solito chiede una verifica in più, non un riavvio in più.