Migrazione al nuovo active check HTTP

Come utente del sito, esegui il comando cmk-migrate-http --help per avere una panoramica dei sottocomandi disponibili. Questi sono:

• migrate: Migra le regole v1 alle regole v2. Questo sottocomando esegue un'anteprima o crea regole da utilizzare in contemporanea (per ora inattive). La modalità eseguita è determinata da parametri aggiuntivi: --dry-run o --write.
• activate: Attiva le regole v2 inattive create in precedenza.
• deactivate: Disattiva le regole v2 attive, ma non finalizzate.
• delete: Cancella tutte le regole v2 che non sono ancora state finalizzate.
• finalize: Elimina le regole v1 migrate e rimuove i riferimenti dalle controparti v2. Questo passaggio è irreversibile!

Ogni sottocomando dispone della propria opzione di aiuto. In questo contesto, quelle relative a migrate sono le più importanti, poiché migrate prepara la migrazione. Tutte le azioni possono essere limitate a specifiche cartelle (opzionalmente in modo ricorsivo) e a determinati host. Quest’ultima opzione non si basa sui nomi degli host, ma sulle condizioni degli host.

Tieni inoltre presente che l’opzione relativa alle cartelle non funziona con i nomi così come appaiono nell’interfaccia grafica, ma con i nomi delle cartelle elaborati internamente (convertiti in minuscolo e con caratteri speciali e spazi sostituiti). Prova inizialmente a usare il nome della cartella che conosci. Se non viene trovato, ti verrà mostrato un elenco dei nomi interni disponibili:

cmk-migrate-http migrate --dry-run --folder 'a nested folder with spaces'
Starting dry run.
Importing...
Loading plugins...
Loading rule sets...
No folder found for the given argument. Use the 'script_folder_key' for the desired folder. Available folders:
Main > ''
badssl > 'badssl'
somefolder > 'somefolder'
somefolder/a nested folder with spaces > 'somefolder/a_nested_folder_with_spaces'

Come accennato in precedenza, lo script di migrazione consente di eseguire una simulazione, testando in parallelo l’effetto delle regole v1 e v2 sul monitoraggio, per poi finalizzare la configurazione oppure eseguire un rollback in qualsiasi momento. Inoltre, puoi modificare qualsiasi nuova regola prima della finalizzazione. Se commetti un errore, ti basta effettuare il rollback e ricominciare da capo. In questo capitolo ti mostriamo nel dettaglio come eseguire una migrazione.

Per prima cosa, esegui la simulazione:

cmk-migrate-http migrate --dry-run

Il check mostrerà quindi quante regole sono presenti, quante di queste possono essere convertite automaticamente e quante, invece, richiedono un intervento manuale. Nel caso di regole incompatibili, consigliamo di saltarne la migrazione. È possibile migrare solo le regole compatibili aggiungendo i flag appropriati, ad esempio

cmk-migrate-http migrate --dry-run --ssl-incompatible skip

per le regole trovate che tentano di forzare una versione obsoleta di TLS. Queste verranno ignorate e potrai gestirle in un secondo momento. Combina tutti i flag necessari per migrare solo le regole non ambigue in questa prima fase. Approfondirai la risoluzione dei conflitti più avanti. Quando sarai soddisfatto del risultato, esegui il comando con l'opzione --write per scrivere effettivamente le nuove regole (Es.):

cmk-migrate-http migrate --write --ssl-incompatible skip --v2-checks-certificate skip

Ora le regole migrate sono state scritte, ma sono inattive. Scorri tra di esse e verifica se ti sembrano ragionevoli.

Hai due opzioni per abilitare le regole: utilizzare il sottocomando activate dello script per abilitare tutte le regole appena migrate, oppure abilitarle una ad una tramite l’interfaccia grafica. In entrambi i casi, dovrai anche attivare le modifiche per renderle effettive.

Ricorda che abilitare tutte le regole in un’unica operazione potrebbe causare un alto numero di servizi in stato CRIT, a seconda di quanto accuratamente erano configurate le vecchie regole. Poiché il vecchio check non controllava il nome dell'host presente nel certificato, il controllo della durata del certificato veniva effettuato sull’indirizzo IP. Per questo motivo, abbiamo modificato il comportamento predefinito in caso di un campo​​​​​​​ Address vuoto o non specificato, passando dall’indirizzo IP al nome dell'host.

Nota: Nel caso in cui tu abbia specificato manualmente un indirizzo IP a cui connetterti, dovrai modificare le regole migrate. Sentiti libero di modificare qualsiasi cosa. Ricorda che, se commetti un errore, puoi sempre disattivare tutte le regole migrate o addirittura annullare tutto e ricominciare da capo.

Potrebbe capitare spesso che alcune regole migrate non siano del tutto soddisfacenti. In questo caso, puoi eseguire un rollback parziale o completo. I rollback parziali vengono eseguiti eliminando semplicemente le regole v2 che non dovrebbero essere convertite in questa migrazione. I rollback completi vengono eseguiti utilizzando i sottocomandi deactivate e poi delete.

Abbiamo già menzionato le difficoltà che potresti incontrare e consigliato di saltare le regole che non possono essere migrate senza l'interazione dell'utente. Adesso è però arrivato il momento di migrare queste regole. Per un totale di undici conflitti frequenti, forniamo la possibilità di risolvere il conflitto in modo automatico. Nella maggioranza dei casi, la risoluzione automatica porterà a regole v2 che funzionano come previsto, ma in alcuni casi potrebbe essere necessaria una configurazione aggiuntiva.

I problemi, la loro (parziale) risoluzione tramite la riga di comando e gli eventuali aggiustamenti necessari sono solo le sfide più importanti. Utilizza sempre il comando cmk-migrate-http migrate --help come riferimento: potremmo estendere le scelte per le opzioni di migrazione esistenti o aggiungere nuove opzioni in base alle necessità.

Quando si utilizzava check_http per i controlli URL con HTTPS abilitato, per impostazione predefinita non veniva verificata la validità del certificato. Il nuovo check v2, invece, verifica i certificati per impostazione predefinita. Sia che tu voglia adottare il nuovo comportamento, sia che preferisca restare più vicino al comportamento precedente, puoi specificarlo con --v2-checks-certificates insieme alle parole chiave skip, keep (per mantenere comportamento più rigoroso di v2) o disable (per ignorare completamente i controlli del certificato). Per poter successivamente combinare il controllo dei certificati e degli URL, consigliamo di usare keep.

Qualcosa di simile vale per i controlli esclusivi sui certificati: la versione 2 verifica sempre tutti gli aspetti di un certificato, mentre la versione 1 controlla solo la validità residua. Usa l’opzione --cant-ignore-certificate-validation per indicare se saltare la migrazione delle regole interessate oppure accettare il nuovo comportamento predefinito. Se hai già migrato i controlli URL con le impostazioni più rigorose, puoi facilmente aggiungere la verifica della validità residua al controllo URL stesso, risparmiando così un check attivo per host.

Un aspetto cruciale della gestione dei certificati è cambiato: il vecchio check utilizzava l'indirizzo dell'host come valore predefinito per i tentativi di connessione, anche nell'intestazione della richiesta HTTP, mentre il nuovo check utilizza il nome dell'host. Questo comportamento viene mappato anche durante la migrazione. Insieme al comportamento più rigoroso, ciò dovrebbe ridurre al minimo i problemi derivanti dalla migrazione. Tuttavia, nel caso in cui tu abbia specificato manualmente la macro $HOSTADDRESS$, essa non verrà sostituita e potresti ritrovarti con dei check falliti.

La versione 2 del check supporta solo TLS 1.2 e 1.3. Potresti aver specificato regole che forzano versioni più vecchie, non supportate dal nuovo check. In tal caso, puoi usare --ssl-incompatible e negotiate per modificare la regola migrata in una negoziazione della versione.

Nel caso tu abbia davvero bisogno di monitorare host con versioni TLS/SSL così obsolete, potrebbe esserti utile la guida che abbiamo pubblicato per la release di Checkmk 2.3.0, in cui l'aggiornamento di OpenSSL alla versione 3.x ha causato incompatibilità con TLS 1.0 e versioni precedenti.

Mentre il vecchio check_http permetteva una definizione libera sia dei request che dei response header, il nuovo check richiede un set specifico di coppie campo-valore. Le regole che non seguono lo schema “Header: value” richiedono una decisione da parte dell'utente. Usa --add-headers-incompatible e --expect-response-header con le parole chiave skip o ignore per saltare la migrazione della regola o forzare la migrazione con l'opzione rimossa. Puoi apportare correzioni in seguito, se necessario.

Con il vecchio check era possibile specificare status codes arbitrari. Non solo numeri a tre cifre come 320 (o 737…), ma anche stringhe (per maggiori dettagli vedi Werk 17738). In alcuni casi, quando la stringa specificata veniva trovata da qualche parte negli header della risposta, non veniva segnalato alcun errore. Per continuare a ignorare tali status codes errati, usa --only-status-codes-allowed insieme alla parola chiave ignore per migrare tali regole rimuovendo lo status code errato. Una volta fatto, verifica attentamente.

Il vecchio check non seguiva il reindirizzamento per verificare altri aspetti della risposta, come le stringhe nel body. Il nuovo check segue prima i reindirizzamenti e poi esegue i controlli. Usa --v1-skips-redirect-response acknowledge per confermare il nuovo comportamento predefinito. Successivamente, potrai affinare le impostazioni dei reindirizzamenti durante i test e la modifica delle regole.

Il nuovo check non supporta più OPTIONS, TRACE, CONNECT, CONNECT_POST, PROPFIND. Nel caso in cui li avessi configurati per il vecchio check, puoi usare --method-unavailable per ignorare questi metodi e passare a GET (quando non sono presenti dati POST) o a POST (nel caso siano presenti dati POST).

Inoltre, il vecchio check permetteva di configurare i dati POST per metodi non POST. Se viene trovata tale configurazione, puoi usare​​​​​​​ --cant-post-data​​​​ post per cambiare il metodo in POST oppure --cant-post-data prefermethod per migrare il metodo, ma ignorare i dati POST.