The commercial editions can update their agents on Linux, Windows and Solaris automatically.
This feature enables easy updating of the agents in the case of new Checkmk versions, and even a changed configuration of the agents can be applied automatically.
In this way you can take advantage of the Agent Bakery to apply individual configurations to hosts.
 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
Le edizioni commerciali possono aggiornare automaticamente i propri agenti su Linux, Windows e Solaris.
Questa funzione consente di aggiornare facilmente gli agenti in caso di nuove versioni di Checkmk e permette persino di applicare automaticamente una configurazione modificata degli agenti.
In questo modo puoi sfruttare l'agent bakery per applicare configurazioni personalizzate agli host.
1. Configurazione degli aggiornamenti automatici
Per configurare gli aggiornamenti, segui questi passaggi: Per prima cosa apri Setup > Agents > Windows, Linux, Solaris, AIX e seleziona "Agents > Automatic updates":
Consulta Prerequisites per un elenco dei prerequisiti necessari affinché gli aggiornamenti automatici funzionino correttamente.
Puoi semplicemente spuntarli in ordine.
Non dimenticare che puoi ottenere maggiori informazioni su ciascuno di questi elementi tramite Help > Show inline help.
Cliccando su 
verrai indirizzato direttamente all'impostazione che devi configurare.
Nello specifico, le impostazioni descritte nelle seguenti cinque sezioni devono essere configurate e poi attivate tramite l'Master switch.
1.1. Creazione di una chiave di firma
Il sistema è progettato in modo tale che gli agenti possano effettuare lo scaricamento degli aggiornamenti tramite HTTP o HTTPS dal loro server di monitoraggio centrale. Poiché gli agenti contengono codice eseguibile, è particolarmente importante proteggersi dalla possibilità che agenti falsificati provengano da un malintenzionato. A questo scopo vengono utilizzate le chiavi di firma. Queste chiavi consistono in una coppia di chiavi pubblica e privata (il metodo a chiave pubblica).
Puoi creare tutte le chiavi di firma che vuoi. Ognuna di queste è protetta da una passphrase, che dovrai inserire ogni volta che effettui una firma. Questo impedisce, ad esempio, che un malintenzionato che abbia accesso al backup di un server di monitoraggio possa firmare gli agenti di monitoraggio.
Crea qui una chiave di firma e prendi nota della passphrase.
|
Questa chiave di firma non potrà essere né modificata né eseguita un ripristino in seguito. Se la chiave viene persa, potrebbe essere necessario aggiornare nuovamente tutti gli agenti manualmente. |
1.2. Configurazione del plug-in di aggiornamento
L'aggiornamento vero e proprio viene eseguito da un plug-in dell'agente chiamato cmk-update-agent.
Questo viene richiamato dall'agente con una frequenza definibile (ad es. una volta all'ora).
In quel momento chiede al server di deployment (il tuo sistema di monitoraggio centrale) se c'è un nuovo pacchetto disponibile per questo host e, in caso affermativo, esegue l'aggiornamento.
Il plug-in deve ovviamente essere presente e configurato correttamente nell'agente. Per farlo, estendi gli agenti con questo plug-in utilizzando il set di regole "Agent updater (Linux, Windows, Solaris)". Puoi trovare questo set di regole cliccando sulla voce "Configuration of update plug-in" nella pagina "Automatic agent updates".
Tieni presente che il set di regole qui segue il principio "La prima regola per parametro prevale". Questo ti permette di definire le impostazioni di base in generale, in modo che non debbano essere impostate più volte nelle regole più specifiche. Inoltre, l'aiuto in linea fornisce ulteriori informazioni su ogni elemento non appena lo attivi.
Di seguito trovi alcune spiegazioni sui singoli punti.
Attivazione
Questa impostazione deve essere abilitata (Deploy plugin …) per consentire l'aggiunta del plug-in dell'agente alla cartella dell'agente. Qui, ad esempio, l'ereditarietà delle regole può essere utilizzata per impostare un valore predefinito in una cartella di livello superiore e sovrascriverlo per singoli host/cartelle secondo necessità.
Informazioni sul server di aggiornamento
Qui puoi inserire i dati di configurazione opzionali per la connessione dell'aggiornamento dell'agente al server Checkmk. Se questa voce non è configurata, le informazioni devono essere inserite in un secondo momento durante la registrazione dell'aggiornamento dell'agente.
Utilizzo
Nel caso di monitoraggio distribuito con configurazione centrale, l'aggiornamento dell'agente riceve di default il server di aggiornamento pertinente dall'istanza Checkmk a cui si connette. Questa opzione può essere utilizzata per configurare l'utilizzo permanente del server di aggiornamento inserito qui e l'ignoranza del server di aggiornamento automatico.
Nome DNS o indirizzo IP del server di aggiornamento
Qui inserisci — con poche eccezioni — il nome del server su cui stai configurando questa regola. Pertanto, puoi copiare l'URL dalla finestra del browser corrente.
Un'eccezione a questo approccio si avrebbe se gli host interessati dovessero essere "spostati" su un altro server Checkmk. In questa situazione, inserisci qui un server diverso una sola volta. Vedi anche sotto alla voce Scenari applicativi. Inserisci il nome DNS con cui è possibile accedere al server Checkmk. È importante che l’host da monitorare sia in grado di risolvere questo nome DNS e che sia stato configurato come host in Checkmk. Se usi HTTPS, assicurati che il nome del certificato corrisponda al nome del server Checkmk conosciuto dall’host.
Nome dell'istanza Checkmk del server di aggiornamento
Qui inserisci — con poche eccezioni — il nome dell'istanza su cui stai configurando questa regola. Un'eccezione a questo approccio sarebbe se gli host interessati dovessero essere "spostati" su un'altra istanza Checkmk. In tal caso, solo per questa volta, inserisci qui un'altra istanza. Vedi anche sotto alla voce Scenari di applicazione. In un monitoraggio distribuito con Setup centrale, l'istanza in cui desideri registrarti potrebbe anche essere diversa dall'istanza centrale in cui è configurata questa regola.
Protocollo da utilizzare per il recupero degli aggiornamenti
Se, come raccomandiamo, utilizzi HTTPS, devi assicurarti che anche l'aggiornamento dell'agente disponga di un certificato CA (CA = Certification Authority) per verificare la connessione.
|
A seconda della configurazione del server, l'uso di HTTPS (incluso il reindirizzamento da HTTP a HTTPS) potrebbe essere obbligatorio. In tal caso, configurare questa regola su HTTP non ha alcun effetto. |
Certificati per la verifica HTTPS
I certificati CA o self-signed configurati qui sono disponibili per l’aggiornamento dell’agente per la verifica delle connessioni HTTPS. In alternativa, nel caso di un monitoraggio distribuito con configurazione centrale, i certificati possono anche essere resi disponibili per l’aggiornamento dell’agente dal sito Checkmk, oppure possono essere importati direttamente durante la connessione tramite parametri della riga di comando.
|
Se la catena di certificati del server è firmata da una CA pubblica, la connessione può normalmente essere verificata senza certificati importati. Tuttavia, non appena i certificati importati da una delle fonti menzionate sono disponibili per l'aggiornamento dell'agente, tutte le altre autorità di certificazione CA vengono ignorate! In caso di problemi con la configurazione di HTTPS, consulta le seguenti FAQ qui sotto. |
Intervallo per il check degli aggiornamenti
Qui specifichi l'intervallo con cui l'aggiornamento dell'agente interroga il server di monitoraggio configurato per verificare se sono disponibili aggiornamenti. Finché l'intervallo specificato non è scaduto, viene restituita una chiamata memorizzata nella cache, in modo da gravare il meno possibile sul carico di rete. Di solito è consigliabile utilizzare un intervallo non inferiore a 10 minuti, altrimenti c'è il rischio molto elevato che la tua rete venga gravata pesantemente se hai un gran numero di agenti Checkmk. Se non imposti un valore qui, verrà applicato un valore predefinito di 1 ora.
Impostazioni proxy
Anche questo set di regole è facoltativo. L'aggiornamento dell'agente parte inizialmente dal presupposto che ci sia una connessione diretta al server Checkmk sull'host di destinazione, anche se sono state configurate impostazioni proxy, e ignora tutte le impostazioni proxy locali. Se questo è il comportamento desiderato, questa impostazione può quindi essere omessa. Altrimenti, inserisci manualmente le impostazioni proxy oppure usa le variabili d'ambiente esistenti dell'host.
Formato eseguibile (Linux)
Puoi specificare facoltativamente come il plug-in viene aggiunto al pacchetto di installazione dell'agente. Il comportamento predefinito della regola dipende dal sistema di destinazione:
Linux (deb, rpm, tgz): Non devi modificare nulla manualmente per questi sistemi; l'aggiornamento dell'agente viene fornito come binary a 64 bit. Puoi anche selezionare facoltativamente un binary a 32 bit per i sistemi legacy, oppure il vecchio script Python. Nota: per il binary avrai bisogno del pacchetto glibc (versione minima 2.5). Le distribuzioni Linux soddisfano generalmente questi requisiti dal 2006.
Windows: Per gli host Windows, Checkmk distribuirà sempre un eseguibile a 32 bit. Questa regola viene quindi ignorata per impostazione predefinita. Nota: se dovessi trovare un binary a 64 bit dell’aggiornamento dell’agente su uno dei tuoi host Windows, questa versione risale a una versione precedente di Checkmk e non è aggiornata.
Solaris: Non devi modificare nulla neanche qui. Checkmk utilizzerà lo script Python anche se lasci il valore predefinito sul binario a 64 bit.
Altre architetture: Se disponi di pacchetti per altre architetture come arm o ppc, imposta manualmente questa opzione su Python , poiché Checkmk non la rileva automaticamente e non sono disponibili binari per queste piattaforme.
Se devi ancora affidarti al vecchio script Python, al sistema si applicano i seguenti requisiti:
Python3 nella versione 3.4 o più recente
I moduli Python requests, PySocks e pyOpenSSL
Chiavi di firma che l'agente accetterà
Seleziona almeno una chiave di firma la cui firma debba essere accettata dall’aggiornamento dell’agente. Puoi anche specificare più chiavi, se lo desideri. Questo può essere il caso, ad esempio, se vuoi disabilitare una vecchia chiave. A tal fine, l’aggiornamento dell’agente dell’host deve accettare entrambe le chiavi nel frattempo.
Dopo quest'ultima impostazione, la tua regola potrebbe apparire come nella schermata seguente:
Salva tutte le tue impostazioni cliccando su "
" (Salva configurazione) Save.
1.3. Creazione e firma degli agenti
Successivamente, puoi immediatamente compilare e firmare gli agenti configurati in questo modo con un'unica azione. Questo perché le regole appena create e personalizzate non saranno presenti nei pacchetti di installazione finché non le avrai create/compilate nuovamente.
Per farlo, clicca sulla voce "Baked agents" nella pagina "Automatic agent updates", quindi clicca su "Bake and sign agents". Ora devi inserire la passphrase per la chiave di firma. Dopo aver cliccato su "Bake and sign", la procedura di baking inizierà come processo in background. Una volta completato questo processo, riceverai una notifica:
A tutti gli agenti firmati in questo modo verrà assegnato un simbolo 
corrispondente.
Se hai creato più chiavi, firma separatamente con queste chiavi aggiuntive.
È sufficiente che l'aggiornamento dell'agente sull'host venga monitorato se il nuovo pacchetto è stato firmato con una delle chiavi note all'aggiornamento.
1.4. Registrazione dell'aggiornamento dell'agente
Nel passaggio successivo registra gli host da monitorare sul server Checkmk. Poiché un nuovo host non è ancora considerato attendibile dal server Checkmk e il server non sa ancora che l’host deve essere aggiornato automaticamente, l’agente deve essere installato manualmente — una sola volta — sull’host.
Per farlo, vai prima su Setup > Agents > Windows, Linux, Solaris, AIX e effettua lo scaricamento del pacchetto appropriato per l'host dall'agent bakery. Assicurati che il pacchetto contenga effettivamente il plug-in dell'aggiornamento dell'agente.
Selezione di un utente per la registrazione
La registrazione deve essere eseguita da un utente Checkmk che disponga dei permessi necessari.
 |
Tieni presente che l'utente automazione |
Puoi eseguire la registrazione come amministratore, ovvero con un utente a cui è stato assegnato il ruolo di amministratore, poiché un amministratore dispone di tutti i permessi. Tuttavia, se per motivi di sicurezza devi utilizzare un utente autorizzato solo a registrare l'aggiornamento dell'agente, puoi farlo. Devi creare manualmente tale utente, poiché Checkmk al momento non lo crea automaticamente. Per farlo, procedi come segue:
Per prima cosa, crea un nuovo ruolo nella pagina Setup > Users > Roles & permissions clonando il ruolo esistente no_permissions.
Modifica il nuovo ruolo assegnandogli nomi descrittivi nei campi Internal ID e Alias e assegnando al ruolo solo i seguenti permessi.
Il modo più veloce per trovarle è cercarle utilizzando Find on this page nell'elenco lungo della pagina delle autorizzazioni:
Register host & download monitoring agents of your hosts.
Register all hosts & download all monitoring agents.
Use the GUI at all
Quindi, nella pagina Setup > Users > Users, crea un nuovo utente con un nome descrittivo Username (ad es. agent_updater_registration) e assegna a questo utente solo il ruolo appena creato.
Clicca su Automation secret for machine accounts per creare il nuovo utente come utente automazione.
Durante la registrazione ti verrà richiesta la password di automazione corrispondente.
Le sezioni seguenti mostrano la registrazione con un utente automazione agent_updater_registration creato in questo modo.
Completamento della registrazione
- Linux
Ora copia il pacchetto dell'agente sull'host e installalo con
rpmodpkg(installazione del pacchetto Linux).Dopo l'installazione, troverai il plug-in di aggiornamento dell'agente nella directory
/usr/lib/check_mk_agent/plugins/3600/cmk-update-agent. Il valore della sottodirectory3600indica l'intervallo per il controllo degli aggiornamenti in secondi (qui per il valore predefinito di un'ora). Uno script con lo stesso nome è memorizzato anche in/usr/bin/, in modo checmk-update-agentsia disponibile anche come comando.Ora chiama l'aggiornamento dell'agente con l'argomento
register. Inserisci le informazioni richieste in sequenza.Con il seguente comando, ora registri l'aggiornamento dell'agente da un host Linux:
In alternativa, puoi eseguire la registrazione in modalità non interattiva inserendo i dati richiesti tramite le opzioni della riga di comando. Una chiamata a
cmk-update-agent register --helpmostra qui le opzioni impostabili.- Windows
Ora copia il pacchetto dell'agente sull'host e installalo con
msiexec(installazione del pacchetto Windows).Dopo l'installazione, l'aggiornamento dell'agente è integrato nell'
C:\Program Files (x86)\checkmk\service\check_mk_agent.exedell'agente Windows. L'aggiornamento stesso può essere controllato con il comandocheck_mk_agent.exe updater.Ora chiama l'aggiornamento dell'agente con l'argomento
register. Su Windows questo deve essere fatto in un prompt dei comandi con diritti di amministratore. Inserisci le informazioni richieste in sequenza.Poiché l'aggiornamento dell'agente per gli host Windows è integrato nell'agente stesso, il comando per registrarlo è il seguente:
In alternativa, puoi eseguire la registrazione in modalità non interattiva inserendo i dati richiesti tramite le opzioni della riga di comando. Il comando completo per la registrazione è il seguente:
L'opzione
-Sviene utilizzata per passare la password di automazione dell'utente automazione.
Informazioni generali sulla registrazione
Al momento della registrazione, il plug-in richiede anche il nome host così come è noto nel monitoraggio. Questo non è necessariamente identico al nome host del computer. Il nome host viene quindi memorizzato localmente insieme alla chiave.
Per utilizzare HTTPS, HTTPS deve essere configurato anche sul tuo server di monitoraggio. HTTP è molto più semplice in questo caso, ma non garantisce la crittografia della trasmissione. Poiché l'agente può teoricamente contenere password, HTTPS è il metodo consigliato. L'autenticità dell'agente è comunque garantita in modo indipendente dalla firma.
La registrazione è richiesta una sola volta. Al momento della registrazione, l'agente e il server concordano una chiave segreta (host secret) nota solo a questo host. La password che inserisci non viene memorizzata da nessuna parte.
Mentre la modalità interattiva interroga solo i campi che non sono ancora presenti in nessun file di configurazione, la modalità non interattiva consente di impostare tutti i campi visualizzati nella guida e ha la massima priorità per questa chiamata. Le opzioni salvate solo in
cmk-update-agent.stateverranno sovrascritte, mentre quelle dicmk-update-agent.cfgno. Maggiori dettagli su questo argomento sono disponibili più avanti alla voce Visualizzazione della configurazione locale.
A seguito di una registrazione riuscita, il segreto host viene memorizzato nell'agente nel file /etc/cmk-update-agent.state.
Sul server si trova in ~/var/check_mk/agent_deployment/myhost.
D'ora in poi il segreto host permette all'host di effettuare lo scaricamento del proprio agente dal server senza richiedere una password.
Non è possibile effettuare lo scaricamento di agenti da altri host, poiché questi potrebbero contenere dati riservati.
1.5. Switch principale
La distribuzione automatica degli agenti è disabilitata globalmente per impostazione predefinita.
Infine, attivalo cliccando su Master switch.
Questo modifica l'impostazione globale Activation of automatic agent updates in Setup > General > Global Settings > Automatic Agent Updates.
Ora tutte le condizioni dovrebbero essere soddisfatte. La tabella "Prerequisites" dovrebbe ora apparire così:
D'ora in poi, l'agente invierà una segnalazione alla fine di ogni intervallo di aggiornamento configurato e cercherà una nuova versione dell'agente. Se una nuova versione è pronta — e firmata — verrà eseguito lo scaricamento e l'installazione automatica.
Allo stesso tempo, l'Master switch è anche un modo per disattivare il processo di aggiornamento a livello globale.
Una guida passo passo è disponibile anche nel video girato alla Checkmk Conference #3 (2017), al link seguente. Non è l'ultima versione, ma la procedura di base non è cambiata: I nuovi aggiornamenti automatici degli agenti
1.6. Disabilitazione degli aggiornamenti automatici per un host
Se vuoi escludere un host dagli aggiornamenti automatici, usa il set di regole "Agent updater (Linux, Windows, Solaris)" per modificare le impostazioni in modo da disattivare il plug-in di aggiornamento. La prossima volta che verrà eseguito un aggiornamento regolare, l'agente rimuoverà il proprio programma di aggiornamento!
Va da sé che l'aggiornamento potrà essere riattivato solo tramite installazione manuale di un nuovo pacchetto dell'agente. Tuttavia, la registrazione rimane intatta e non è necessario effettuare il rinnovo.
2. Limitare gli aggiornamenti a host specifici
Prima di distribuire un nuovo agente su un gran numero di host, ti consigliamo vivamente di provarlo prima su un numero più ridotto di host. Questo passaggio importante previene possibili errori di gravi conseguenze.
Per questa funzione, usa il box centrale nella pagina Automatic agent updates:
Alle condizioni viene applicata una congiunzione logica (AND): solo gli host che corrispondono a tutti i criteri selezionati riceveranno l'aggiornamento. Dopo aver specificato qui le condizioni per la selezione degli host, puoi utilizzare il campo "Test hostname before activation" per inserire i nomi host e verificare se gli aggiornamenti per questi host sono stati abilitati o meno.
Importante: sugli host che non devono ancora ricevere gli aggiornamenti automatici, il pacchetto installato non deve contenere il plug-in di aggiornamento dell'agente; in caso contrario, il plug-in ti avviserà regolarmente che l'host non è ancora stato registrato.
3. Verifica
Ci sono diverse fonti di informazioni per verificare se tutti gli aggiornamenti funzionano come previsto.
3.1. Statistiche di distribuzione dell'agente
Questa panoramica mostra come si comportano i singoli host nell'aggiornamento dell'agente.
L'aiuto in linea fornisce ulteriori spiegazioni.
Cliccando su 
viene visualizzato un elenco dettagliato dei singoli host.
Puoi anche accedere all'elenco completo di tutti gli host registrati tramite la visualizzazione Monitor > System > Agent update status.
Lì puoi poi cercare i singoli host.
In questo elenco troverai anche la documentazione su come inizia l'hash di un agente, quale agente è destinato a un host (Target Agent), quale agente è stato sottoposto a scaricamento più di recente dall'host (Downloaded Agent) e quale agente è attualmente installato sull'host (Installed Agent). In questo modo puoi sempre vedere se le specifiche sono state soddisfatte o a che punto si trova attualmente il processo. Va notato che le informazioni sullo stato appaiono a sinistra direttamente nella comunicazione tra Agent Bakery e l'aggiornamento dell'agente, mentre i campi Update Check e Update Check Output provengono dal plug-in dell'aggiornamento dell'agente quando si interroga l'agente dell'host, e che a causa della cache (definita dall'intervallo di tempo) questi potrebbero essere aggiornati in un momento diverso.
3.2. Il servizio "Check_MK Agent "
Se hai installato il plug-in di aggiornamento dell'agente su un agente, questo invierà regolarmente lo stato attuale dell'aggiornamento sotto forma di dati di monitoraggio. Il servizio di scoperta del servizio genera un nuovo servizio con il nome Check_MK Agent sull'host. Anche questo riflette lo stato attuale dell'aggiornamento. In questo modo puoi ricevere una notifica in caso di problemi con gli aggiornamenti.
Tra le altre cose, lo stato del servizio indica come viene valutato lo stato della chiave di firma. Sono possibili i seguenti stati:
WARN: il certificato della chiave di firma è danneggiato, non è più valido o scadrà nei prossimi 90 giorni.
CRIT: Non esiste un certificato valido per la chiave di firma oppure il certificato perderà la sua validità entro i prossimi 30 giorni.
3.3. Visualizzazione della configurazione locale
Il comportamento dell'aggiornamento dell'agente è regolato dai due file cmk-update-agent.cfg e cmk-update-agent.state.
I valori definiti nel file .cfg hanno sempre la precedenza su quelli del file .state.
Se l'aggiornamento dell'agente mostra un comportamento inaspettato, a volte vale la pena dare un'occhiata alla configurazione.
C'è anche una funzione utile se chiami l'aggiornamento dell'agente direttamente dalla riga di comando:
3.4. Messaggi di log
In caso di problemi, troverai anche i dati di log relativi agli aggiornamenti sull'host da sottoporre a monitoraggio.
Su Linux, l'cmk-update-agenta informazioni importanti su syslog, come avvisi ed errori:
Jul 02 13:59:23 myhost [cmk-update-agent] WARNING: Missing config file at ./cmk-update-agent.cfg. Configuration may be incomplete.
Jul 02 13:59:23 myhost [cmk-update-agent] ERROR: Not yet registered at deployment server. Please run 'cmk-update-agent register' first.Un file di log più dettagliato di cmk-update-agent.log, che include l'output di debug e possibili traceback, è disponibile su Linux e su Windows:
2026-01-16 07:49:23,295 [288229] DEBUG: Starting Checkmk Agent Updater v2.4.0p19
2026-01-16 07:49:23,295 [288229] DEBUG: Updating the certificate store "/var/lib/check_mk_agent/cmk-update-agent/cas/all_certs.pem"...
2026-01-16 07:49:23,297 [288229] INFO: Updated the certificate store "/var/lib/check_mk_agent/cmk-update-agent/cas/all_certs.pem" with 1 certificate(s)
...
2026-01-16 07:49:23,326 [288229] DEBUG: Successfully read /var/lib/check_mk_agent/cmk-update-agent/cmk-update-agent.state.
2026-01-16 07:49:23,326 [288229] DEBUG: Successfully read /var/lib/check_mk_agent/cmk-update-agent/cmk-update-agent.state.
2026-01-16 07:49:23,327 [288229] DEBUG: Saved deployment status to /var/lib/check_mk_agent/cmk-update-agent/cmk-update-agent.state.
2026-01-16 07:49:23,327 [288229] INFO: Target state (from deployment server):
2026-01-16 07:49:23,327 [288229] INFO: Agent available: True
2026-01-16 07:49:23,327 [288229] INFO: Signatures: 1
2026-01-16 07:49:23,327 [288229] INFO: Target hash: 37221b87f5cb46a2
2026-01-16 07:49:23,327 [288229] INFO: Agent 37221b87f5cb46a2 already installed.
2026-01-16 07:49:23,340 [288229] DEBUG: Caught Exception:
Traceback (most recent call last):
File "cmk_update_agent.py", line 1733, in main
File "cmk_update_agent.py", line 714, in run
File "cmk_update_agent.py", line 1372, in _run_mode
File "cmk_update_agent.py", line 1071, in _do_update_as_command
File "cmk_update_agent.py", line 1150, in _do_update_agent
File "cmk_update_agent.py", line 1221, in _check_signatures
Exception: No valid signature found.Su entrambi i sistemi puoi anche usare l'opzione da riga di comando --logfile LOGFILE per specificare un percorso alternativo per il file di log.
4. Casi d'uso
4.1. Disattivazione degli aggiornamenti automatici dell'host
Se vuoi escludere un host dagli aggiornamenti automatici, modifica la sua impostazione nel set di regole "Agent updater (Linux, Windows, Solaris)" in modo da disattivare lì il plug-in di aggiornamento. Al prossimo aggiornamento regolare, l'agente rimuoverà automaticamente il proprio programma di aggiornamento!
Va da sé che l'aggiornamento potrà essere riattivato solo tramite l'installazione manuale di un nuovo pacchetto dell'agente! La registrazione viene mantenuta e non deve essere rinnovata.
4.2. Migrazione a una nuova istanza di monitoraggio
Se desideri passare a un nuovo sito Checkmk in una configurazione a sito singolo senza perdere gli host registrati sul server, tieni presente che, affinché il processo di aggiornamento dell'agente avvenga correttamente, le seguenti informazioni relative al server e all'host devono corrispondere:
Il nome con cui l'host viene sottoposto a monitoraggio e registrato.
Il segreto dell'host, che è stato assegnato automaticamente durante la registrazione.
La firma utilizzata per firmare gli agenti.
Per farlo, segui questi passaggi:
Per prima cosa aggiungi al monitoraggio tutti gli host le cui informazioni di registrazione devono essere migrate al nuovo sito. Assicurati che gli host nel nuovo sito siano monitorati con lo stesso nome. Quindi copia la cartella
~/var/check_mk/agent_deploymentdal vecchio al nuovo sito di monitoraggio.Esporta le chiavi di firma accettate dagli agenti installati sugli host. Le chiavi di firma possono essere esportate e importate utilizzando Setup > Agents > Windows, Linux, Solaris, AIX > Agents > Signature keys.
Importa queste chiavi di firma dal passaggio 2 nell'istanza di monitoraggio nuova.
Configura la regola di aggiornamento dell'agente sul nuovo sito di monitoraggio seguendo le istruzioni e firma gli agenti generati con le chiavi di firma importate.
Infine, nella regola di aggiornamento dell'agente sul vecchio sito, configura i campi relativi al server di aggiornamento e al nome del sito Checkmk in modo che corrispondano al tuo nuovo sito di monitoraggio, quindi ricompila gli agenti. Nota: a questo punto, verifica di aver specificato tutto correttamente prima di ricompilare gli agenti.
Non appena i prossimi aggiornamenti automatici saranno stati eseguiti sugli host, il vecchio sito di monitoraggio verrà bloccato. Da quel momento in poi, gli host da monitorare risponderanno solo al nuovo server Checkmk. Dopo il secondo aggiornamento automatico, l'agente verrà installato dal nuovo server Checkmk di conseguenza.
4.3. L'aggiornamento dell'agente come programma di installazione automatica
|
Questa non è una funzionalità ufficiale dell'aggiornamento dell'agente. Queste istruzioni sono quindi destinate principalmente agli utenti più esperti. Il modo ufficiale per installare un agente Checkmk su un host è effettuare lo scaricamento e l'esecuzione del pacchetto agente appropriato per il sistema. È tuttavia possibile consentire l'installazione iniziale dell'agente Checkmk tramite l'aggiornamento dell'agente, poiché questo funziona anche come programma autonomo. |
Procedi come segue:
Copia il file binario cmk-update-agent o lo script
cmk_update_agent.pysull'host da monitorare (entrambi sono disponibili all'indirizzo~/share/check_mk/agents/pluginssul server Checkmk).Registra l'host sul server Checkmk eseguendo
cmk-update-agent register. In questo caso è consigliabile passare le informazioni di registrazione richieste direttamente tramite la riga di comando – specialmente se vuoi usare uno script di installazione. Le opzioni corrispondenti possono essere visualizzate richiamandocmk-update-agent register --help.Quindi, con un'ultima chiamata al plug-in di aggiornamento dell'agente, installa l'agente con tutti i dettagli di configurazione per l'host sottoposto a monitoraggio. Tuttavia, poiché non esiste una configurazione locale (l'aggiornamento dell'agente visualizza anche un avviso corrispondente) e quindi nessuna firma per il pacchetto dell'agente da scaricare, chiama nuovamente l'aggiornamento con
cmk-update-agent --skip-signaturesper considerare esplicitamente attendibile il pacchetto scaricato. Il prerequisito per l'installazione tramite l'aggiornamento dell'agente è, ovviamente, che l'agent bakery abbia un pacchetto agente adatto pronto per l'host di destinazione sul server Checkmk.
5. Aggiornamenti degli agenti nel monitoraggio distribuito
A partire da Checkmk2.0.0 è possibile distribuire gli agenti precompilati anche tramite istanze remote. Il presupposto è un monitoraggio distribuito con Setup centrale e una connessione che permetta alle istanze remote di raggiungere l'istanza centrale tramite HTTP/HTTPS.
Un monitoraggio distribuito di questo tipo può — soprattutto temporaneamente — funzionare anche con versioni diverse di Checkmk. Questo permette di switchare gradualmente a una nuova versione di Checkmk anche nei sistemi più grandi. In questo caso, però, assicurati di seguire le note sugli ambienti di monitoraggio con versioni miste nel monitoraggio distribuito.
5.1. Funzionalità
Dal punto di vista tecnico, la funzionalità è implementata in modo tale che le richieste di aggiornamento sulle istanze remote vengano inoltrate all'istanza centrale, in modo che l'intera configurazione e il baking degli agenti avvengano esclusivamente sull'istanza centrale. I pacchetti degli agenti già richiesti in un'istanza remota vengono memorizzati nella cache dell'istanza remota (purché siano validi), in modo che non sia necessario effettuare lo scaricamento nuovamente dall'istanza centrale. Inoltre, i dati richiesti vengono checkati per la coerenza sull'istanza remota, in modo da evitare connessioni non necessarie all'istanza centrale.
A differenza di una configurazione a sito singolo, il server di aggiornamento appropriato per gli host non deriva esclusivamente dall’insieme di regole dell’aggiornamento degli agenti, ma viene comunicato all’aggiornamento dell’agente richiedente dal sito Checkmk contattato. In questo processo, a un host viene assegnato il proprio server dal sito da cui viene monitorato. La specifica di un server Checkmk è quindi necessaria solo per la registrazione iniziale, che in teoria può avvenire in qualsiasi istanza — accessibile dall’host — dell’intero sistema di monitoraggio distribuito. Se la connessione al server determinato automaticamente fallisce, viene utilizzato come ripiego il server salvato in precedenza (dalla configurazione delle regole o inserito manualmente durante la registrazione).
5.2. Configurazione
La distribuzione dei pacchetti degli agenti tramite istanze remote non deve essere attivata separatamente: l’istanza remota riconosce automaticamente la situazione e comunica di conseguenza con l’istanza centrale e con l’aggiornamento dell’agente richiedente. Se gli agenti devono effettuare la segnalazione esplicita solo all’istanza centrale per gli aggiornamenti, questo può essere fatto tramite un server di aggiornamento fisso nel set di regole per l’aggiornamento dell’agente.
Affinché gli aggiornamenti degli agenti funzionino effettivamente in un monitoraggio distribuito, tuttavia, è necessario effettuare alcune impostazioni sull'istanza centrale,
tutte disponibili all'indirizzo Setup > General > Global Settings > Automatic Agent Updates.
Se le impostazioni differiscono per ciascuna istanza remota, possono essere modificate anche separatamente.
Per farlo, vai su Setup > General > Distributed monitoring e seleziona il simbolo a forma di ingranaggio 
nella riga dell'istanza desiderata per accedere all'Site specific global settings di quell'istanza.
Connessione all'agente centrale bakery
A questo punto, devi specificare l'URL attraverso il quale è possibile accedere all'istanza centrale dall'istanza remota, includendo il protocollo e la stringa di caratteri /check_mk/, ad esempio https://myserver.org/mysite/check_mk/.
Sebbene il sito Checkmk cerchi di identificare autonomamente tutte le altre impostazioni mancanti, la specificazione di questo URL non è facoltativa, poiché altrimenti questa direzione di connessione non verrebbe stabilita nel caso di una configurazione centrale.
Se il protocollo è HTTPS, l'istanza remota utilizza automaticamente i certificati CA o self-signed disponibili nel Setup per la verifica della connessione Setup > General > Global Settings > Site management > Trusted certificate authorities for SSL.
Connessione all'agente remoto bakery
Dato che le istanze remote non sono necessariamente accessibili dai rispettivi host monitorati tramite lo stesso URL utilizzato dall’istanza centrale, qui puoi configurare un URL a questo scopo. Questo URL viene poi comunicato automaticamente all’host (o all’aggiornamento dell’agente richiedente) quando si stabilisce una connessione a un sito Checkmk. La configurazione come Site specific global settings è particolarmente utile in questo caso. Se non viene specificato alcun URL, si presume che le istanze remote siano accessibili sia dall'istanza centrale che dagli host monitorati con lo stesso URL. Se si tratta di una connessione HTTPS, è possibile rendere automaticamente disponibile all'host anche il certificato appropriato. Poiché l'archivio CA centrale non può essere utilizzato a questo scopo, è possibile specificare i certificati appropriati in questa fase. In alternativa, i certificati possono essere specificati anche nelle regole dell'aggiornamento dell'agente.
6. Lavorare con HTTPS
In vari punti di questo articolo si fa riferimento alla protezione delle rispettive connessioni tramite HTTPS. Qui forniremo ancora una volta una panoramica generale di ciò che occorre fare per proteggere completamente le connessioni tramite HTTPS. Sia la connessione da un sito remoto alla propria istanza centrale, sia quella da un host a un sito Checkmk possono e devono essere protette tramite TLS, ovvero utilizzando HTTPS. Questo vale indipendentemente dal fatto che si tratti di una configurazione a sito singolo o di un monitoraggio distribuito.
6.1. Configurazione di HTTPS
Per potersi connettere a un'istanza Checkmk tramite HTTPS, occorre innanzitutto configurare il server di monitoraggio per HTTPS. Ciò può essere ottenuto, ad esempio, tramite un'adeguata configurazione dell'Apache di sistema, o più semplicemente tramite le impostazioni HTTPS sull'Checkmk Appliance.
Il fatto che un server Checkmk venga poi raggiunto tramite HTTP o HTTPS dipende dall'URL configurato in ciascun caso.
Se questo inizia con https://, il server viene raggiunto tramite il protocollo HTTPS utilizzando la porta 443.
Questo vale anche per il protocollo che hai configurato con l'impostazione Update server information.
In linea di principio, puoi forzare il reindirizzamento da HTTP a HTTPS sul lato Apache ed escludere (inizialmente) singoli percorsi da questo.
Per i dettagli sulla configurazione, consulta la documentazione di Apache per i moduli mod_rewrite e mod_redirect.
6.2. Fornitura dei certificati
Affinché venga stabilita una connessione HTTPS, deve essere possibile verificare la catena di certificati del server contattato o il certificato self-signed (a seconda di come è configurato il server). La fornitura di certificati CA o self-signed adeguati rende possibile tutto ciò e può essere realizzata in vari modi.
Connessioni da un host a un server Checkmk
L'aggiornamento dell'agente cerca sempre di verificare le connessioni HTTPS e le interrompe se la verifica non è possibile. I certificati per la verifica sono disponibili per l'aggiornamento dell'agente dalle seguenti fonti:
L'aggiornamento dell'agente: Per impostazione predefinita, l'aggiornamento dell'agente include un ambiente di esecuzione Python con tutti i moduli necessari. È incluso anche il pacchetto di certificati del modulo Certifi, che a sua volta si basa sulla raccolta di certificati del progetto Mozilla. Questo garantisce che le CA pubbliche vengano rese note all'aggiornamento dell'agente in modo tempestivo, anche quando sono in sospeso aggiornamenti del sistema operativo.
Certificati tramite agent bakery: I certificati contenuti nel modulo Certifi vengono ignorati una volta che uno o più certificati sono stati importati tramite uno dei seguenti meccanismi. I certificati provenienti dalle seguenti fonti vengono memorizzati localmente sull'host e utilizzati solo dall'aggiornamento dell'agente:
Utilizzando l'impostazione Certificates for HTTPS verification, i certificati possono essere integrati in un pacchetto agente e saranno disponibili per l'aggiornamento dell'agente a partire dall'installazione (o da un aggiornamento).
Quando configuri la connessione all'istanza remota tramite Setup > General > Global settings > Automatic agent updates > Connection to remote agent bakery, puoi specificare i certificati da utilizzare per verificare la connessione HTTPS all'istanza remota. Ciò è particolarmente utile se al momento della configurazione non è ancora chiaro quale host verrà assegnato a quale istanza remota. Questa opzione di importazione può essere utilizzata anche per ridurre il numero di agenti da integrare, poiché non è necessario configurare i certificati corretti per le rispettive istanze di aggiornamento in modo specifico per ogni host.
Archivio certificati:
l'aggiornamento dell'agente può utilizzare l'archivio certificati del sistema operativo solo se è stato configurato per utilizzare System-Python invece dell'ambiente di esecuzione Python fornito e se nel System-Python non è configurato alcun modulo Certifi.
Poiché qui sono coinvolti molti fattori, come i parametri di installazione o la variabile d'ambiente _PIP_STANDALONE_CERT, non supportiamo ufficialmente tale configurazione.
Certificato tramite riga di comando - Importa certificato:
Puoi anche richiamare l'aggiornamento dell'agente con l'argomento della riga di comando --trust-cert.
Questo recupera e importa il certificato del server.
Ciò avviene senza tenere conto del tipo di certificato:
Il certificato viene considerato attendibile senza ulteriori verifiche di una possibile catena, indipendentemente dal fatto che si tratti di un certificato self-signed, di un certificato alla fine di una catena di certificati pubblici o di un certificato firmato con una CA interna.
|
|
Certificato tramite riga di comando - Ignora certificato:
Se non c'è alcun certificato valido a disposizione dell'aggiornamento dell'agente, la convalida del certificato può essere bypassata utilizzando l'argomento della riga di comando --insecure per una chiamata.
Questo può essere utile se il certificato valido è già in attesa di essere recuperato dal server alla prossima connessione,
ma l'aggiornamento dell'agente verrà "bloccato" da questo certificato mancante.
|
Questo di fatto disattiva completamente il check del certificato per questa chiamata. La comunicazione avviene comunque in forma crittografata, quindi l'uso di questo argomento è "meglio di niente". |
Connessione da un'istanza remota a un'istanza centrale
La distribuzione dei certificati è più semplice durante una connessione da un'istanza remota all'istanza centrale, poiché la procedura di Setup non viene affatto eseguita. L'istanza remota può utilizzare l'archivio certificati di Checkmk all'indirizzo Global settings > Site management > Trusted certificate authorities for SSL. È quindi sufficiente importare i certificati tramite l'istanza centrale, se necessario anche tramite Site specific global settings quando l'istanza centrale è accessibile tramite più URL.
Procedura per la sostituzione di un certificato
Se lavori con la tua infrastruttura di certificazione, l'ideale è utilizzare un certificato radice valido per un periodo molto lungo e la cui chiave associata venga utilizzata regolarmente per creare certificati intermedi. Questi vengono poi a loro volta utilizzati per firmare i certificati del server. In questo caso, distribuisci i certificati intermedi come catena di certificati sul server Checkmk. Gli host che ricevono gli aggiornamenti automatici dell'agente devono ora solo essere informati del certificato radice.
Se non sei sicuro che un nuovo certificato server richieda un nuovo certificato root, usa il seguente comando. Usalo per determinare l'identificatore della chiave root utilizzata per firmare un certificato server:
Se l'identificatore visualizzato è identico sia per il certificato vecchio che per quello nuovo, non è necessaria alcuna ulteriore azione. Gli host che si fidano di questo certificato radice possono continuare a ricevere gli aggiornamenti anche se la catena di certificati cambia, a condizione che la catena sia stata correttamente memorizzata nell'Apache di sistema.
Se finora è stato utilizzato un certificato self-signed o un certificato radice a breve durata proveniente da una CA interna, oppure se la precedente chiave radice di una delle tue CA interne è stata compromessa, procedi come segue quando sostituisci il certificato:
Aggiungi il nuovo certificato utilizzando il parametro Certificates for HTTPS verification (nella regola Agent updater (Linux, Windows, Solaris)).
Rigenera i pacchetti degli agenti e aggiorna tutti gli host nel monitoraggio. Assicurati che questo aggiornamento sia stato eseguito per tutti gli host prima di procedere.
Ora sostituisci il certificato del server.
Esegui un test su alcuni host in cui è facile reinstallare manualmente l'agente in caso di errore, per verificare se è possibile eseguire nuovamente l'aggiornamento utilizzando il nuovo certificato.
Se il passaggio precedente (4) è stato eseguito con successo — puoi (il certificato scadrà) o devi (la chiave è stata compromessa) — rimuovi il vecchio certificato ed esegui un altro aggiornamento dell'agente.
7. Risoluzione dei problemi
Questo capitolo tratta innanzitutto degli errori tipici e generali e delle loro cause:
L'aggiornamento dell'agente verrà eseguito solo una volta durante l'intervallo di aggiornamento, quindi un errore verrà visualizzato continuamente finché non chiami manualmente il plug-in dell'agente o non sia in arrivo il prossimo intervallo.
L'aggiornamento dell'agente crea autonomamente il proprio file di stato cmk-update-agent.state (su Linux/Unix in /etc e su Windows nella cartella config).
Questo file rimane sull'host dopo la disinstallazione, in modo che le informazioni di registro non vadano perse.
Una nuova installazione troverà il file e continuerà a utilizzarlo.
Se questa situazione non è desiderata, basta cancellare manualmente il file cmk-update-agent.state dopo la disinstallazione.
La pagina Monitor > System > Agent Update Status mostra tutti gli host che sono in monitoraggio e per i quali esiste un file di stato sul server Checkmk.
Non importa se l'host si collega effettivamente al server Checkmk per gli aggiornamenti automatici.
Se qui dovesse comparire un host inaspettato, vale la pena dare un'occhiata alla cartella /omd/sites/mysite/var/check_mk/agent_deployment — la causa sarà probabilmente un registro vecchio o creato per sbaglio.
L'aggiornamento dell'agente è progettato per considerare attendibili solo i certificati che di solito sono specificati in Agent updater (Linux, Windows, Solaris) nella configurazione HTTPS. In particolare, i certificati installati localmente vengono ignorati. Può anche succedere che il server Checkmk sia accessibile tramite il browser, mentre l'aggiornamento dell'agente non riesca a effettuare la connessione a causa di una configurazione errata.
Nella configurazione HTTPS della regola dell’aggiornamento dell’agente deve essere specificato un certificato radice con cui sia possibile verificare la connessione al server Checkmk. In altre parole: la catena di certificati inclusa nel certificato del server Checkmk deve essere verificabile tramite il certificato indicato qui. Spesso qui viene specificato invece il certificato del server — questo però non è adatto a questo scopo.
Dai un'occhiata alla catena di certificati del server Checkmk con lo strumento OpenSSL.
A causa della lunghezza della catena, per chiarezza qui viene mostrata solo una sezione rilevante e le sezioni omesse sono contrassegnate d[...]e:
Per l'ultima voce — nel nostro caso subject=/CN=mymonitoring.example.net — hai bisogno di un certificato root valido.
Questo non deve necessariamente essere — come in questo esempio — l'emittente del certificato.
Di solito si tratta di una catena di emittenti.
Quindi guarda il certificato utilizzato. Anche in questo caso, a causa della lunghezza, verrà abbreviato come nell'esempio sopra:
Il certificato principale — visibile nell'estratto sopra — non può dipendere da un altro certificato.
Puoi vedere che Issuer e Subject sono identici e che è inclusa l'opzione CA:TRUE.
Inoltre, la catena dell'emittente che autenticare un oggetto deve essere coerente fino alla voce finale.
Hai quindi bisogno anche di tutti i certificati intermedi se l'emittente dell'ultimo certificato non è una CA.
È capitato occasionalmente, specialmente sui sistemi Red Hat/CentOS, che la chiamata a rpm innescata dall'aggiornamento automatico fallisca ripetutamente,
mentre una chiamata manuale a cmk-update-agent venga elaborata con successo.
La causa in questi casi era una policy SELinux che impediva una chiamata senza errori se rpm veniva chiamato da un processo figlio di xinetd.
Puoi risolvere il problema, ovvero andare a fondo della questione, analizzando i log di SELinux e modificando la policy di conseguenza utilizzando lo strumento audit2allow.
La sezione seguente tratta i problemi indicati da specifici messaggi di errore:
Su alcuni sistemi Linux è installato il programma Prelink ed è attivato un cronjob
che esamina regolarmente tutti i file binari sul sistema e, se necessario, li adatta per velocizzare i programmi.
Tuttavia, il plug-in di aggiornamento dell'agente è impacchettato con il programma PyInstaller, che non è compatibile con tali azioni e quindi non funziona correttamente.
Checkmk dispone quindi di una voce nella blacklist per i pacchetti deb/rpm, memorizzata in /etc/prelink.conf.d,
e — se prelink è presente — imposta una voce nel file esistente /etc/prelink.conf.
Poiché questo problema è difficile da gestire, può comunque capitare che queste misure non abbiano effetto — specialmente in caso di una successiva configurazione di prelink.
Pertanto, se effettui l'installazione di prelink in un secondo momento, imposta tu stesso la voce e aggiungi la seguente riga al file con il comando seguente:
Questo messaggio di errore si verifica quando la directory /tmp è stata montata nel sistema con il flag noexec.
Per risolvere questo problema, puoi rimuovere il flag oppure, se lo hai impostato e lo richiedi deliberatamente, creare una regola su server Checkmk in Setup sotto Agents > Windows, Linux, Solaris, AIX > Agents > Agent rules > Installation paths for agent files (Linux, Unix).
Lì puoi definire tu stesso la directory tmp nell'opzione Directory for storage of temporary data (set TMPDIR environment variable).
Il plug-in di aggiornamento dell'agente scriverà quindi in futuro i file temporanei nella directory definita.
Questo funziona anche se chiami il plug-in manualmente con lo script helper in /usr/bin/cmk-update-agent.
Se il servizio Check_MK Agent visualizza l'avviso No valid signature found, significa che il pacchetto dell'agente destinato all'host nell'agent bakery non è stato firmato con una delle chiavi accettate.
Nel caso più semplice, basta firmare i tuoi agenti utilizzando la funzione "Sign agents" nell'agent bakery con una delle chiavi visualizzate sotto "Signature keys the agent will accept".
Non appena l'aggiornamento dell'agente invia il suo prossimo rapporto dall'host interessato al server Checkmk e l'intervallo di cache per il servizio è scaduto, l'avviso scomparirà.
Tuttavia, se l'host non possiede (o non possiede più) una singola chiave di firma che si trova sul server Checkmk, devi ripetere il bake e firmare con una chiave visualizzata sotto Signature keys the agent will accept, quindi copiare l'agente bake sull'host interessato e reinstallarlo lì.
Su un host interessato, puoi eseguire cmk-update-agent -v o check_mk_agent.exe updater -v per ottenere maggiori dettagli su questo errore.
Il messaggio di errore dettagliato elenca esplicitamente le firme dal file di configurazione del plug-in di aggiornamento dell'agente che non hanno una controparte accettata (cioè configurata) sul tuo server Checkmk.
Ignoring signature #1 for certificate: certificate is unknown.
No valid signature found.8. File e directory
8.1. Percorsi dei file sul server Checkmk
| Percorso del file | Descrizione |
|---|---|
|
Contiene gli agenti precompilati, ordinati prima nelle sottodirectory in base al sistema operativo (ad es. |
|
Contiene i file con i nomi degli host registrati. Uno di questi file contiene l'ora dell'ultima registrazione e il segreto dell'host. |
8.2. Percorsi dei file sull'host sottoposto a monitoraggio
- Linux
Percorso del file Descrizione /usr/lib/check_mk_agent/plugins/3600/cmk-update-agentIl plug-in di aggiornamento dell'agente come file binario o script, a seconda della configurazione in formato eseguibile. La sottodirectory
3600indica l'intervallo per il controllo degli aggiornamenti in secondi (qui per il valore predefinito di un'ora)./usr/bin/cmk-update-agentScript per richiamare il plug-in di aggiornamento dell'agente e registrare l'agente con il comando
cmk-update-agent register./etc/check_mk/cmk-update-agent.cfgFile di configurazione per il plug-in di aggiornamento dell'agente, che contiene le impostazioni della regola Agent updater (Linux, Windows, Solaris). Non modificare questo file, perché viene scritto durante le installazioni e gli aggiornamenti.
/etc/cmk-update-agent.stateFile con le informazioni del registro, incluso il segreto dell'host.
/var/lib/check_mk_agent/cmk-update-agent.logFile di log dettagliato con messaggi di debug.
- Windows
Percorso del file Descrizione C:\ProgramData\checkmk\agent\plugins\cmk_update_agent.checkmk.pyIl plug-in di aggiornamento dell'agente come file Python.
C:\Program Files (x86)\checkmk\service\check_mk_agent.exeProgramma agente per registrare l'agente con il comando
check_mk_agent.exe updater register.C:\ProgramData\checkmk\agent\config\cmk-update-agent.cfgFile di configurazione per il plug-in di aggiornamento dell'agente, che contiene le impostazioni della regola Agent updater (Linux, Windows, Solaris). Non modificare questo file, poiché viene scritto durante le installazioni e gli aggiornamenti.
C:\ProgramData\checkmk\agent\config\cmk-update-agent.stateFile con le informazioni del registro, incluso il segreto dell'host.
C:\ProgramData\checkmk\agent\log\cmk-update-agent.logFile di log dettagliato con messaggi di debug.
C:\ProgramData\checkmk\agent\bakery\check_mk.bakery.ymlFile di configurazione creato da agent bakery, che tra le altre cose definisce l'intervallo per il check degli aggiornamenti.