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 gli agenti su Linux, Windows e Solaris. Questa funzione consente di aggiornare facilmente gli agenti in caso di nuove versioni di Checkmk e di applicare automaticamente anche una configurazione modificata degli agenti. In questo modo puoi sfruttare l'Agent bakery per applicare configurazioni individuali agli host.
1. Impostazione degli aggiornamenti automatici
Il deployment automatico dell'agente è disabilitato a livello globale per impostazione predefinita. Pertanto, prima di occuparti della configurazione predefinita, attiva l'opzione Activation of automatic agent updates in Setup > General > Global Settings > Automatic Agent Updates:
Per implementare gli aggiornamenti, segui i seguenti passaggi: per prima cosa apri Setup > Agents > Windows, Linux, Solaris, AIX e seleziona Agents > Automatic updates:
Consulta Prerequisites per un elenco dei prerequisiti che devono essere soddisfatti per il corretto funzionamento degli aggiornamenti automatici. Puoi semplicemente spuntarli in ordine sparso. Non dimenticare che puoi ottenere maggiori informazioni per ogni elemento tramite Help > Show inline help. Cliccando su di esso verrai indirizzato direttamente all'impostazione che devi configurare. In particolare, le impostazioni descritte nei cinque capitoli seguenti devono essere effettuate e attivate tramite Master switch.
1.1. Creare una chiave di firma
Il sistema è progettato in modo che gli agenti possano scaricare gli aggiornamenti via 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 aggressore. A questo scopo vengono utilizzate le chiavi di firma, che consistono in una coppia di chiavi pubbliche e private (metodo della chiave pubblica).
Puoi creare tutte le chiavi di firma che vuoi. Ognuna di queste è protetta da una passphrase che dovrai inserire ogni volta che firmi. Questo impedisce, ad esempio, a un malintenzionato di accedere al backup di un server di monitoraggio per firmare gli agenti.
Crea qui una chiave di firma e registra la passphrase.
Importante: questa passphrase non può essere modificata o ripristinata in seguito. Se la chiave viene persa, può significare che tutti gli agenti devono essere nuovamente aggiornati 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 chiamato dall'agente in un ciclo definibile (es. una volta all'ora). In questo momento chiede al deployment dell'agente (il tuo sistema centrale di monitoraggio) se c'è un nuovo pacchetto disponibile per questo host e, in caso affermativo, esegue l'aggiornamento.
Naturalmente, il plug-in deve essere presente e correttamente configurato nell'agente. Per farlo, estendi gli agenti con questo plug-in utilizzando il set di regole Agent updater (Linux, Windows, Solaris). Il set di regole può essere trovato rapidamente, ad esempio, nella pagina Automatic agent updates nel menu Related > Agent updater ruleset.
Nota che il set di regole segue il principio "La prima regola per parametro vince": 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 inline fornisce maggiori informazioni su ogni elemento non appena lo attivi.
Di seguito sono riportate alcune spiegazioni sui singoli punti.
Attivazione
Questa impostazione deve essere attivata (Deploy plugin …) per consentire l'aggiunta del plug-in dell'agente. In questo caso, ad esempio, è possibile utilizzare l'ereditarietà delle regole per impostare un valore predefinito in una cartella di livello superiore e sovrascriverlo per i singoli host/cartelle, se necessario.
Aggiorna le informazioni sul server
Qui possono essere inseriti 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 centralizzata, l'agente Checkmk riceve il relativo server di aggiornamento per impostazione predefinita dall'istanza Checkmk a cui si connette. Questa opzione può essere utilizzata per configurare l'utilizzo permanente del server di aggiornamento qui inserito e per ignorare il server di aggiornamento automatico.
Nome DNS o indirizzo IP del server di aggiornamento
È importante che l'host da monitorare sia in grado di risolvere questo nome e che sia configurato come host in Checkmk. Se utilizzi HTTPS, fai attenzione che il nome del certificato corrisponda al nome del server Checkmk noto all'host.
Nome dell'istanza Checkmk del server di aggiornamento
In questa sezione, a parte alcune eccezioni, inserisci il nome del sito su cui stai configurando questa regola. Un'eccezione a questo approccio è rappresentata dal caso in cui gli host interessati debbano essere "spostati" in un'altra istanza Checkmk. In questo caso, per una sola volta, inserisci un sito diverso. Vedi anche sotto la voce Scenari di applicazione. In una configurazione distribuita con una configurazione centrale, il sito in cui vuoi registrarti può anche essere diverso dal sito centrale in cui è configurata questa regola.
Protocollo da utilizzare per il recupero degli aggiornamenti
Se, come ti consigliamo, utilizzi il protocollo HTTPS, devi assicurarti che anche l'aggiornamento dell'agente abbia a disposizione un certificato CA per verificare la connessione.
Importante: A seconda della configurazione del server, l'uso di HTTPS (compreso l'inoltro da HTTP a HTTPS) potrebbe essere forzato. In tal caso, la configurazione di 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'installazione distribuita con una configurazione centrale, i certificati possono essere messi a disposizione dell'aggiornamento dell'agente dall'istanza Checkmk, oppure possono essere importati direttamente durante la connessione tramite i parametri della riga di comando.
Importante: se la catena di certificati del server è firmata da una CA pubblica, la connessione può essere normalmente 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.
Intervallo per il controllo degli aggiornamenti
Qui puoi specificare l'intervallo in 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 in 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 che la rete sia molto appesantita se hai un gran numero di agenti Checkmk. Se non imposti un valore qui, verrà applicato il valore predefinito di 1 ora.
Impostazioni proxy
Anche questa regola è facoltativa. L'aggiornamento dell'agente Checkmk presuppone inizialmente una connessione diretta al server Checkmk sull'host di destinazione, anche con le impostazioni proxy configurate, e ignora tutte le impostazioni proxy locali. Se questo è il comportamento desiderato, questa regola può essere omessa. In caso contrario, inserisci manualmente le impostazioni proxy o utilizza le variabili d'ambiente esistenti nell'host.
Formato eseguibile (Linux)
Puoi specificare facoltativamente il modo in cui 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): per questi sistemi non devi modificare manualmente nulla; l'aggiornamento dell'agente viene passato come un binario a 64 bit. Puoi anche selezionare facoltativamente un binario a 32 bit per i sistemi legacy o il vecchio script Python.Importante: Per il binary è necessario il pacchetto glibc (almeno la versione 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 binario a 64 bit dell'aggiornamento dell'agente Checkmk su uno dei tuoi host Windows, questa versione risale a una versione precedente di Checkmk e non è aggiornata.
Solaris: anche in questo caso non dovrai modificare nulla: Checkmk utilizzerà lo script Python anche se lascerai il valore predefinito sul binary a 64 bit.
Altre architetture: se hai dei pacchetti per altre architetture come arm o ppc, imposta manualmente questa opzione su Python, poiché Checkmk non la intercetta automaticamente e non vengono offerti binari per queste piattaforme.
Se hai ancora bisogno di affidarti al vecchio script Python, il sistema deve soddisfare i seguenti requisiti:
Python3 nella versione 3.4 o più recente
Le richieste dei moduli Python, PySocks e pyOpenSSL
Chiavi di firma accettate dall'agente
Seleziona almeno una chiave di firma la cui firma deve essere accettata dall'aggiornamento dell'agente. Puoi anche specificare facoltativamente più chiavi. Questo può accadere se, ad esempio, vuoi disabilitare una vecchia chiave. A tal fine, l'aggiornamento dell'agente dell'host deve accettare entrambe le chiavi.
Dopo quest'ultima impostazione, la tua regola potrebbe assomigliare alla seguente schermata. Salva tutti i dati inseriti cliccando su Save.
1.3. Baked agent e firma degli agenti
In seguito, potrai immediatamente creare e firmare gli agenti così configurati in un'unica azione. Questo perché le regole appena create e personalizzate non si troveranno nei pacchetti di installazione fino a quando non le avrai create/fornite di nuovo. Naviga su Setup > Agents > Windows, Linux, Solaris AIX e clicca su Bake and sign agents. A questo punto dovrai inserire la passphrase per la chiave che vuoi utilizzare. Dopo aver cliccato su Bake and sign, il processo di creazione delle chiavi si avvierà in background. Al termine di questo processo, verrai informato:
Tutti gli agenti firmati in questo modo saranno assegnati a un simbolo corrispondente. Se hai creato più chiavi, firma con queste chiavi aggiuntive separatamente.
Importante: è sufficiente che l'aggiornamento dell'agente sull'host sia monitorato se il nuovo pacchetto è stato firmato con una delle chiavi note all'aggiornatore.
1.4. Registrazione dell'aggiornamento dell'agente
Il passo successivo consiste nel registrare gli host da monitorare sul server Checkmk. Poiché un nuovo host non è ancora attendibile per il server Checkmk e il server non sa ancora che l'host deve essere aggiornato automaticamente, l'agente dell'agente deve essere installato manualmente - una sola volta - sull'host.
Per farlo, vai su Setup > Agents > Windows, Linux, Solaris, AIX e scarica il pacchetto appropriato per l'host dall'Agent bakery. Assicurati che il pacchetto contenga davvero il plug-in dell'agente.
Registrazione dell'aggiornamento dell'agente in Linux
Ora copia il pacchetto dell'agente sull'host e installalo con rpm o dpkg (installazione del pacchetto Linux).
Dopo l'installazione, troverai il plug-in dell'agente nella directory /usr/lib/check_mk_agent/plugins/3600/cmk-update-agent. Il valore della sottodirectory 3600 indica l'intervallo per l'aggiornamento di controllo in secondi (qui il valore predefinito è di un'ora). Uno script con lo stesso nome è memorizzato anche in /usr/bin/, in modo che cmk-update-agent sia disponibile anche come comando.
Ora chiama l'aggiornamento dell'agente con l'argomento register. Inserisci le informazioni richieste in sequenza.
Con il comando seguente, puoi registrare l'aggiornamento dell'agente da un host Linux:
root@linux# cmk-update-agent register -v
-------------------------------------------------------------------
| |
| Check_MK Agent Updater v2.1.0 - Registration |
| |
| Activation of automatic agent updates. Your first step is to |
| register this host at your deployment server for agent updates. |
| For this step you need a user with the permission |
| "Register all hosts" on that Checkmk site. |
| |
-------------------------------------------------------------------
Our host name in the monitoring:
myhost
User with registration permissions:
cmkadmin
Password:
Going to register agent at deployment server
Successfully registered agent of host "myhost" for deployment.
You can now update your agent by running 'cmk-update-agent -v'
Saved your registration settings to /etc/cmk-update-agent.state.
Hint: you can do this in scripts with the command:
cmk-update-agent register -s myserver.example.com -i mysite -H myhost -p https -U cmkadmin -P * -vIn alternativa, puoi eseguire la registrazione in modalità non interattiva inserendo i dati richiesti tramite le opzioni della riga di comando. Su Linux, una chiamata a cmk-update-agent register --help mostra le opzioni impostabili.
Registrazione dell'aggiornamento dell'agente in 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'agente di Windows C:\Program Files (x86)\checkmk\service\check_mk_agent.exe. L'aggiornamento stesso può essere controllato con il comando check_mk_agent.exe updater.
Ora chiama l'aggiornamento dell'agente con l'argomento register. In 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:
C:\WINDOWS\system32> "C:\Program Files (x86)\checkmk\service\check_mk_agent.exe" updater register
Using previous settings from C:\ProgramData\checkmk\agent\config\cmk-update-agent.state.
Our host name in the monitoring:
mywindowshost
User with registration permissions:
cmkadmin
Password:
Successfully registered agent of host "mywindowshost" for deployment.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:
C:\WINDOWS\system32> "C:\Program Files (x86)\checkmk\service\check_mk_agent.exe" ^
updater register -s myserver.example.com -i mysite -H mywindowshost -p https -U cmkadmin -P mycmkadminpassword -vRegistrazione una tantum e informazioni generali
La registrazione one-time può essere effettuata anche tramite un utente automazione. A questo scopo, alla riga di comando viene passato l'utente automazione tramite -U/--user e la password automazione tramite -S/--secret.
Alcune note sulla registrazione:
Al momento della registrazione, il plug-in ha bisogno anche del nome dell'host conosciuto nel monitoraggio, che non è necessariamente identico al nome host del computer. Il nome dell'host viene quindi memorizzato localmente insieme alla chiave.
Per utilizzare HTTPS, è necessario impostare HTTPS anche sul server di monitoraggio. HTTP è molto più semplice, ma non fornisce la crittografia della trasmissione. Poiché l'agente di monitoraggio può teoricamente contenere password, HTTPS è il metodo consigliato. L'autenticazione dell'agente è comunque garantita in modo indipendente dalla firma.
Il login come amministratore Checkmk è richiesto solo una volta. Al momento della registrazione, l'agente e il server Checkmk concordano una chiave segreta(host secret) nota solo a questo host. La password dell'amministratore Checkmk non viene archiviata da nessuna parte.
Mentre la modalità interattiva controlla solo i campi che non sono ancora presenti in nessuna configurazione, la modalità non interattiva permette di impostare tutti i campi visualizzati nella guida e ha la massima priorità per questa chiamata. Le opzioni salvate solo in
cmk-update-agent.statesaranno sovrascritte, mentre le opzioni dicmk-update-agent.cfgnon lo saranno. Maggiori dettagli su questo aspetto sono disponibili in Visualizzazione della configurazione locale.
Dopo che la registrazione è andata a buon fine, il segreto dell'host viene archiviato nell'agente nel file /etc/cmk-update-agent.state. Sul server si trova in ~/var/check_mk/agent_deployment/myhost. Da questo momento in poi il segreto dell'host consente all'agente di scaricare il proprio agente dal server senza richiedere una password. Non è possibile scaricare agenti da altri host, poiché questi potrebbero contenere dati riservati.
1.5. Switch master
A questo punto tutte le condizioni dovrebbero essere soddisfatte. Se non è ancora successo, attivalo cliccando su Master switch. La tabella Prerequisites dovrebbe ora avere questo aspetto:
D'ora in poi, l'agente farà un report alla fine di ogni intervallo di aggiornamento configurato e cercherà una nuova versione dell'agente. Se una nuova versione è pronta -e firmata- verrà scaricata e installata automaticamente.
Allo stesso tempo, Master switch è anche un modo per disattivare il processo di aggiornamento a livello globale.
Una guida passo-passo è fornita anche dal video realizzato in occasione della Conferenza Checkmk #3 (2017), al seguente link. Questa non è l'ultima versione, ma la procedura di base non è cambiata:il nuovo aggiornamento automatico dell'agente
2. Limitare gli aggiornamenti a host specifici
Prima di distribuire un nuovo agente a un gran numero di host, sicuramente vorrai provarlo con un numero minore di host. Questo importante passo evita un possibile errore di gravi dimensioni.
Per questa funzione, utilizza il box centrale della 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 indicato le condizioni per la selezione degli host, puoi utilizzare il campo Test hostname before activation per inserire i singoli nomi host e verificare se gli aggiornamenti per questi host sono stati attivati o meno.
Importante: Per gli host per i quali non è ancora previsto l'aggiornamento automatico, il pacchetto installato non deve contenere il plug-in dell'agente - altrimenti il plug-in ti avviserà regolarmente che l'host non è ancora stato registrato.
3. Diagnosi
Esistono diverse fonti di informazione per diagnosticare se tutti gli aggiornamenti funzionano come previsto.
3.1. Statistiche sul deployment dell'agente
Questa panoramica mostra il comportamento dei singoli host nell'aggiornamento dell'agente. L'aiuto inline fornisce ulteriori spiegazioni. Facendo clic su di essa, si ottiene 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. Qui puoi cercare i singoli host.
In questo elenco troverai anche la documentazione su come si avvia l'hash di un agente, quale agente è destinato a un host (Target Agent), quale agente è stato scaricato più di recente dall'host (Downloaded Agent) e quale agente è attualmente installato sull'host (Installed Agent). In questo modo potrai sempre vedere se le specifiche sono state rispettate o dove si trova attualmente il processo. Va notato che le informazioni sullo stato appaiono a sinistra direttamente nella comunicazione tra l'agent bakery e l'agent updater, mentre i campi Update Check e Update Check Output provengono dal plug-in dell'aggiornamento dell'agente durante l'interrogazione dell'agente dell'host e, a causa della cache (definita dall'intervallo di tempo della query), potrebbero essere aggiornati in un momento diverso.
3.2. Il servizio dell'agente Check_MK
Se hai installato il plug-in dell'agente per l'aggiornamento dell'agente, questo emetterà regolarmente lo stato attuale dell'aggiornamento sotto forma di dati di monitoraggio. La scoperta del servizio genera un nuovo servizio con il nome Check_MK Agent sull'host, che riflette lo stato attuale dell'aggiornamento. In questo modo puoi essere avvisato di qualsiasi problema 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 è corrotto, non è più valido o non lo sarà nei prossimi 90 giorni.
CRIT: non esiste un certificato valido per la chiave di firma o il certificato perderà la sua validità nei 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 prevalgono sempre su quelli del file .state. Se l'aggiornamento dell'agente mostra un comportamento inaspettato, a volte vale la pena di dare un'occhiata alla configurazione. Esiste anche una funzione utile se chiami l'aggiornamento dell'agente direttamente dalla linea di comando:
root@linux# cmk-update-agent show-config
Showing current configuration...
Configuration from config file (/etc/check_mk/cmk-update-agent.cfg):
server: myserver
site: mysite
protocol: http
certificates: []
ignore_update_url: False
interval: 3600
proxy: None
signature_keys: ['-----BEGIN CERTIFICATE-----\n [...] \n-----END CERTIFICATE-----\n']
use_proxy_env: False
Configuration from state file (/etc/cmk-update-agent.state):
last_error: None
host_secret: zqscykkqfdkpwnwenqfibdksqvuamblstbtmpasbhnlbubmncgmrqxvakasittxw
host_name: myhost
user: cmkadmin
last_check: 1660750511.8183599
pending_hash: None
installed_aghash: 94b60c8ef40c4900
last_update: 1660750584.85276533.4. Messaggi di log
In caso di problemi, troverai anche i dati di log degli aggiornamenti sull'host da monitorare. Su Linux cmk-update-agent registra le informazioni importanti nel 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 cmk-update-agent.log che include l'output di debug e possibili traceback si trova su Linux e su Windows:
2021-07-02 17:58:18,321 DEBUG: Starting Check_MK Agent Updater v2.0.0p9
2021-07-02 17:58:18,322 DEBUG: Successfully read /etc/cmk-update-agent.state.
2021-07-02 17:58:18,322 DEBUG: Successfully read /etc/check_mk/cmk-update-agent.cfg.
pass:q[...]
2021-07-02 17:58:18,387 INFO: Target state (from deployment server):
2021-07-02 17:58:18,387 INFO: Agent Available: True
2021-07-02 17:58:18,387 INFO: Signatures: 1
2021-07-02 17:58:18,387 INFO: Target Hash: 081b6bcc6102d94a
2021-07-02 17:58:18,387 INFO: Ignoring signature #1 for certificate: certificate is unknown.
2021-07-02 17:58:18,388 DEBUG: Caught Exception:
Traceback (most recent call last):
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1733, in main
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 714, in run
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1372, in _run_mode
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1071, in _do_update_as_command
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1150, in _do_update_agent
File "/build/enterprise/agents/plugins/cmk_update_agent.py", line 1221, in _check_signatures
Exception: No valid signature found.In entrambi i sistemi puoi anche utilizzare l'opzione da linea di comando --logfile LOGFILE per specificare un percorso alternativo per il file di log.
4. Scenari di applicazione
4.1. Disattivare gli aggiornamenti automatici degli host
Se un host deve essere rimosso dagli aggiornamenti automatici, modifica le sue impostazioni con il set di regole Agent updater (Linux, Windows, Solaris) in modo che il plug-in di aggiornamento venga disattivato. Al prossimo aggiornamento regolare, l'agente stesso rimuoverà il proprio programma di aggiornamento!
Va da sé che l'aggiornamento può 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 un nuovo sito di monitoraggio
Se vuoi passare a un nuovo sito Checkmk in una configurazione a sito singolo senza perdere gli host registrati sul server, è bene notare che per un processo di aggiornamento dell'agente che vada a buon fine, le seguenti informazioni sul server e sull'host devono corrispondere:
Il nome host monitorato e registrato.
Il segreto dell'host, assegnato automaticamente durante la registrazione.
La firma utilizzata per firmare gli agenti.
Per ottenere questo risultato, segui i seguenti passaggi:
Per prima cosa aggiungi al monitoraggio tutti gli host le cui informazioni di registrazione devono essere migrate nel nuovo sito. Assicurati che gli host del nuovo sito siano monitorati con lo stesso nome. Poi 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 punto 2 nel nuovo sito di monitoraggio.
Configura la regola di aggiornamento dell'agente sul nuovo sito di monitoraggio seguendo le istruzioni e firma gli agenti Baked agents con le chiavi di firma importate.
Infine, nella regola di aggiornamento dell'agente sul vecchio sito, configura i campi per il server di aggiornamento e il nome del sito Checkmk conforme al tuo nuovo sito di monitoraggio e inforna nuovamente gli agenti. Nota: a questo punto, verifica di aver specificato tutto correttamente prima di cuocere nuovamente gli agenti.
Non appena i prossimi aggiornamenti automatici passeranno attraverso gli 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.
4.3. L'aggiornamento dell'agente come programma di installazione automatica
Attenzione: Questa non è una funzione ufficiale dell'aggiornamento dell'agente, pertanto le presenti istruzioni sono destinate principalmente agli utenti più esperti. Il modo ufficiale per installare un agente Checkmk su un host è quello di scaricare ed eseguire il pacchetto agente adatto al sistema. Tuttavia, è anche possibile consentire l'installazione iniziale dell'agente Checkmk Agent tramite l'aggiornamento dell'agente, che funziona anche come programma autonomo.
Procedi come segue:
Copia il binario cmk-update-agent o lo script
cmk_update_agent.pysull'host da monitorare (entrambi si trovano all'indirizzo~/share/check_mk/agents/pluginssul server Checkmk).Registra l'host sul server Checkmk invocando
cmk-update-agent register. In questo caso è opportuno passare le informazioni di registrazione richieste direttamente tramite la linea di comando, soprattutto se vuoi utilizzare uno script di installazione. Le opzioni corrispondenti possono essere visualizzate quando si chiamacmk-update-agent register --help.Quindi, con una chiamata finale al plug-in dell'agente, si installa l'agente con tutti i dettagli di configurazione per l'host da monitorare. Tuttavia, poiché non esiste una configurazione locale (l'aggiornamento dell'agente visualizza anche un avviso corrispondente) e quindi non esiste una firma per il pacchetto dell'agente da scaricare, chiama ancora una volta l'aggiornamento dell'agente con
cmk-update-agent --skip-signaturesper fidarsi esplicitamente del pacchetto scaricato. Il prerequisito per l'installazione tramite l'aggiornamento dell'agente è, ovviamente, che l'Agent bakery abbia pronto un pacchetto agente adatto all'host di destinazione sul server Checkmk.
5. Aggiornamento dell'agente nel monitoraggio distribuito
A partire dall'istanza Checkmk 2.0.0 è possibile distribuire gli agenti remoti in Checkmk. Il prerequisito è una configurazione centralee una connessione che permetta di raggiungere il sito centrale dai siti remoti tramite HTTP/HTTPS.
Un monitoraggio distribuito di questo tipo può essere operato - soprattutto in via temporanea - anche con versioni diverse di Checkmk. In questo modo è possibile switchare successivamente sistemi più grandi a una nuova versione di Checkmk. In questo caso, però, assicurati di seguire le note sugli ambienti di monitoraggio a versioni miste nel monitoraggio distribuito.
5.1. Funzionalità
Tecnicamente, la funzione è implementata in modo tale che le richieste di aggiornamento sui siti remoti vengano inoltrate al sito centrale, in modo che l'intera configurazione e l'infornata di agenti avvengano esclusivamente sul sito centrale. I pacchetti di agenti che sono già stati richiesti su un sito remoto vengono messi in cache sul sito remoto (finché sono validi), in modo che i pacchetti non debbano essere scaricati nuovamente dal sito centrale. Inoltre, i dati richiesti saranno controllati per verificarne la coerenza sul sito remoto, in modo da evitare connessioni inutili al sito centrale.
A differenza di una configurazione a sito singolo, il server di aggiornamento appropriato per gli host non proviene esclusivamente dal set di regole per l'agente Checkmk, ma viene comunicato all'agente richiedente l'aggiornamento dal sito Checkmk contattato. In questo processo, un host riceve il suo server dal sito da cui viene monitorato. La specifica di un server Checkmk è quindi necessaria solo per la registrazione una tantum, che può teoricamente avvenire in qualsiasi sito - accessibile dall'host - dell'intero sistema di monitoraggio distribuito. Se la connessione al server determinato automaticamente fallisce, il server precedentemente salvato (dalla configurazione delle regole o inserito manualmente durante la registrazione) viene utilizzato come ripiego.
5.2. Configurazione
La distribuzione di pacchetti di agenti tramite siti remoti non deve essere attivata separatamente: il rispettivo sito remoto riconosce automaticamente la situazione e comunica di conseguenza con il sito centrale e con l'aggiornamento dell'agente richiedente. Se gli agenti devono riferire esplicitamente solo al sito centrale per gli aggiornamenti, questo può essere fatto tramite un server di aggiornamento fisso nelset di regole dell'aggiornamento dell'agente.
Affinché gli aggiornamenti dell'agente funzionino effettivamente in un monitoraggio distribuito, tuttavia, è necessario effettuare alcune impostazioni sul sito centrale, che si trovano in Setup > General > Global Settings > Automatic Agent Updates. Se le impostazioni differiscono per ogni sito remoto, possono essere modificate in Setup > General > Distributed monitoring > (Site specific global settings).
Connessione all'agent bakery centrale
A questo punto, è necessario specificare l'URL attraverso il quale è possibile accedere al sito centrale dal sito remoto, includendo il suo protocollo e la stringa di carattericheck_mk, ad esempio https://myserver.org/mysite/check_mk. Anche se l'istanza Checkmk cercherà di identificare autonomamente tutte le altre impostazioni mancanti, l'indicazione di questo URL non è facoltativa, poiché altrimenti questa direzione di connessione non verrà stabilita nel caso di una configurazione centrale. Se il protocollo è HTTPS, il sito remoto utilizza automaticamente i certificati CA o self-signed disponibili nella configurazione per la verifica della connessione Setup > General > Global Settings > Site management > Trusted certificate authorities for SSL. Il sito remoto richiede anche un utente dell'istanza creato in precedenza per poter accedere al sito centrale. Anche questo può essere selezionato qui. Se non viene specificato nulla, il sito remoto cerca un utente dell'automazione con il nome "Automazione".
Connessione con l'agent bakery remoto
Poiché i siti remoti non sono necessariamente accessibili dai rispettivi host monitorati tramite lo stesso URL del sito centrale, è possibile configurare un URL a questo scopo. Questo URL viene poi comunicato automaticamente all'host (o all'aggiornamento dell'agente richiedente) quando viene effettuata una connessione a un sito Checkmk. La configurazione come impostazione globale specifica del sito ha particolarmente senso in questo caso. Se non viene specificato alcun URL, si presume che le istanze remote siano accessibili sia dal sito centrale che dagli host monitorati con lo stesso URL. Se si tratta di una connessione HTTPS, il certificato appropriato può essere messo automaticamente a disposizione dell'host. Poiché non è possibile utilizzare l'archivio CA centrale, i certificati appropriati possono essere specificati a questo punto. In alternativa, i certificati possono essere specificati anche nelle regole di aggiornamento dell'agente.
6. Lavorare con HTTPS
In vari punti di questo articolo si fa riferimento alla protezione delle rispettive connessioni tramite HTTPS. In questa sede, forniremo ancora una volta una panoramica generale di ciò che è necessario fare per proteggere completamente le connessioni tramite HTTPS. Sia la connessione da un sito remoto a quello centrale, sia quella da un host a un'istanza remota in Checkmk possono e devono essere protette tramite TLS, cioè utilizzando HTTPS. Questo indipendentemente dal fatto che si tratti di un'istallazione a sito singolo o distribuita.
6.1. Configurare HTTPS
Per potersi connettere a un sito Checkmk tramite HTTPS, prima di tutto il server di monitoraggio deve essere configurato per HTTPS. Questo può essere ottenuto, ad esempio, tramite un'adeguata configurazione di Apache di sistema o più semplicemente tramite le impostazioni HTTPS dell'appliance Checkmk.
Il fatto che il server Checkmk venga indirizzato tramite HTTP o HTTPS dipende dall'URL configurato in ogni caso. Se inizia con https://, il server viene indirizzato tramite il protocollo HTTPS utilizzando la porta 443. Questo vale anche per il protocollo configurato con l'impostazione Update server information In linea di principio, puoi forzare l'inoltro da HTTP a HTTPS sul lato Apache e (inizialmente) escludere singoli percorsi. Per i dettagli sulla configurazione, consulta la documentazione di Apache relativa ai moduli mod_rewrite e mod_redirect.
6.2. Provider di certificati
Affinché una connessione HTTPS possa essere stabilita, 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 lo rende possibile e può essere realizzata in vari modi.
Connessioni da un host a un server Checkmk
L'aggiornamento dell'agente tenta sempre di verificare le connessioni HTTPS e le termina se la verifica non è possibile. I certificati per la verifica sono disponibili per l'aggiornamento dell'agente dalle seguenti fonti:
L'Agent Updater:per impostazione predefinita, l'Agent Updater viene fornito con un ambiente di esecuzione Python che include tutti i moduli necessari. È incluso anche il bundle 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'Agent Updater in modo tempestivo, anche quando sono in corso 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 inseriti in un pacchetto agente e saranno disponibili per l'Agent Updater fin dall'installazione (o da un aggiornamento).
Quando configuri la connessione al sito remoto tramite Setup > General > Global settings > Automatic agent updates > Connection to remote agent bakery, puoi specificare i certificati che possono essere utilizzati per verificare la connessione HTTPS al rispettivo sito remoto. Questo è particolarmente utile se al momento della configurazione non è ancora chiaro quale host sarà assegnato a quale sito. Questa opzione di importazione può essere utilizzata anche per ridurre il numero di Bake agents da preparare, poiché i certificati corretti per i rispettivi server di aggiornamento non devono essere configurati in modo specifico per l'host.
Certificate Store:l'Agent Updater può utilizzare il Certificate Store del sistema operativo solo se l'Agent Updater è stato configurato per utilizzare System-Python invece dell'ambiente di esecuzione Python in dotazione e se non è stato configurato alcun modulo Certifi in System-Python. Poiché in questo caso sono coinvolti molti fattori come i parametri di installazione o la variabile d'ambiente _PIP_STANDALONE_CERT, non supportiamo ufficialmente tale configurazione.
Certificato tramite linea di comando - Importazione del certificato:puoi anche richiamare l'aggiornamento dell'agente con l'argomento della linea di comando --trust-cert. Questo recupera e importa il certificato del server, senza tenere conto del tipo di certificato: il certificato viene considerato attendibile senza ulteriori controlli 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 da una CA interna.
|
|
Certificato tramite linea di comando - Ignora certificato:se l'aggiornamento dell'agente non dispone di un certificato valido, la convalida del certificato può essere aggirata utilizzando l'argomento della linea 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 sarà "bloccato" da questo certificato mancante.
|
La comunicazione avviene comunque in modulo crittografato, quindi l'uso di questo argomento è "meglio di niente". |
Connessione da un sito remoto a un sito centrale
La distribuzione dei certificati è più semplice quando la connessione avviene da un sito remoto a un sito centrale, poiché la procedura di configurazione non viene eseguita. Il sito remoto può utilizzare l'archivio dei certificati di istanza remota in Checkmk all'indirizzo Global settings > Site management > Trusted certificate authorities for SSL. È quindi sufficiente importare il/i certificato/i tramite il sito centrale, se necessario anche tramite Site specific global settings quando il sito centrale è accessibile da più URL.
Procedura per la sostituzione di un certificato
Se lavori con una tua infrastruttura di certificazione, l'ideale è utilizzare un certificato radice valido per molto tempo e la cui chiave associata viene regolarmente utilizzata per creare certificati intermedi. In questo caso, i certificati intermedi vengono distribuiti come catena di certificati sul server Checkmk. Gli host che ricevono gli aggiornamenti automatici dell'agente devono ora essere informati solo del certificato principale.
Se non sei sicuro che un nuovo certificato server richieda un nuovo certificato root, usa il seguente comando per determinare l'identificatore della chiave root utilizzata per firmare un certificato server:
root@linux# openssl x509 -noout -text -in cert.pem | grep -A1 'X509v3 Authority Key'
X509v3 Authority Key Identifier:
14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6Se l'identificatore visualizzato è identico sia per il vecchio che per il nuovo certificato, non sono necessarie ulteriori azioni. Gli host che si fidano di questo certificato radice possono continuare a ottenere gli aggiornamenti anche se la catena del certificato cambia, a patto che la catena sia stata memorizzata correttamente nell'Apache di sistema.
Se finora è stato utilizzato un certificato self-signed o un certificato radice di breve durata di una CA interna o se la precedente chiave radice di una delle tue CA interne è stata compromessa, procedi come segue per la sostituzione del certificato:
Aggiungi il nuovo certificato utilizzando il parametro Certificates for HTTPS verification (nella regola Agent updater (Linux, Windows, Solaris) ).
Crea nuovamente i pacchetti dell'agente e aggiorna tutti gli host del monitoraggio. Assicurati che l'aggiornamento sia stato eseguito per tutti gli host prima di procedere.
Ora sostituisci il certificato del server.
Esegui un test con alcuni host in cui sia facile reinstallare manualmente l'agente in caso di errore, per verificare se è possibile eseguire nuovamente l'aggiornamento utilizzando il nuovo certificato.
Se il passo precedente (4) è stato eseguito con successo - puoi (il certificato scadrà) o devi (la chiave è stata compromessa) - rimuovere il vecchio certificato ed eseguire un altro aggiornamento dell'agente.
7. Risoluzione dei problemi
7.1. Errori tipici e relative soluzioni
Errori già risolti nel servizio agente Checkmk
L'aggiornamento dell'agente viene eseguito solo una volta durante l'intervallo di aggiornamento, quindi l'errore viene visualizzato continuamente fino a quando non richiami manualmente il plug-in o fino all'intervallo successivo.
La registrazione fallisce dopo una reinstallazione manuale dell'agente Checkmk
L'aggiornamento dell'agente crea il proprio file di stato cmk-update-agent.state in modo indipendente (in Linux/Unix in /etc e in Windows nella cartella config ). Questo file rimane sullo stato dell'host dopo la disinstallazione, in modo che le informazioni del registro non vadano perse. Una nuova installazione troverà il file e continuerà a usarlo. Se questa situazione non è desiderabile, è sufficiente eliminare manualmente il file cmk-update-agent.state dopo una disinstallazione.
Stato dell'aggiornamento per host che non hanno aggiornamenti automatici attivi
La pagina Monitor > System > Agent Update Status mostra tutti gli host che sono in fase di monitoraggio e per i quali esiste un file dell'host sul server Checkmk. Non importa se l'host fa effettivamente report al server Checkmk per gli aggiornamenti automatici. Se viene visualizzato un host inaspettato, vale la pena di dare un'occhiata alla cartella /omd/sites/mysite/var/check_mk/agent_deployment: la causa è probabilmente un registro vecchio o creato per sbaglio.
La connessione tramite SSL/TLS non funziona
L'aggiornamento dell'agente Checkmk è stato progettato per fidarsi esplicitamente solo dei certificati che di solito vengono specificati alla voce Agent updater (Linux, Windows, Solaris) nellaconfigurazione HTTPS. In particolare, i certificati installati localmente vengono ignorati. Può anche accadere che il server Checkmk sia accessibile attraverso il browser, mentre l'aggiornamento dell'agente non riesce a connettersi a causa di una configurazione errata.
Nella configurazione HTTPS della regola per l'aggiornamento dell'agente Checkmk è necessario specificare un certificato radicecon il quale è possibile verificare la connessione al server Checkmk. In altre parole: la catena di regole delcertificato del server Checkmk deve poter essere verificata dal certificato qui indicato. Spesso il certificato del server viene specificato qui, ma non è adatto a questo scopo.
Dai un'occhiata alla catena di certificati del server Checkmk con lo strumentoOpenSSL. A causa della lunghezza della catena, per chiarezza qui viene mostrata solo una sezione rilevante e le sezioni omesse sono contrassegnate da [...]:
root@linux# openssl s_client -connect mymonitoring.example.net:443
[...]
subject=/CN=mymonitoring.example.net
issuer=/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3832 bytes and written 302 bytes
Verification: OK
---
[...]Per l'ultima voce - nel nostro casosubject=/CN=mymonitoring.example.net- è necessario 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.
Poi guarda il certificato utilizzato. Anche in questo caso, a causa della lunghezza, sarà abbreviato come nell'esempio precedente:
root@linux# openssl x509 -text -noout -in myca.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 38 (0x26)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
Validity
Not Before: Jul 9 12:11:00 1999 GMT
Not After : Jul 9 23:59:00 2019 GMT
Subject: C = DE, O = Deutsche Telekom AG, OU = T-TeleSec Trust Center, CN = Deutsche Telekom Root CA 2
[...]
X509v3 extensions:
[...]
X509v3 Basic Constraints:
CA:TRUE, pathlen:5
[...]Il certificato superiore, come si vede nell'estratto qui sopra, non può dipendere da un altro certificato. Si può notare che l'emittente(Issuer) e l'elemento(Subject) sono identici e che l'opzione CA:TRUE è inclusa. Inoltre, la catena dell'emittente che autentica un oggetto deve essere coerente fino alla voce finale. Pertanto, sono necessari anche tutti i certificati intermedi se l'emittente dell'ultimo certificato non è una CA.
Messaggio di errore: Impossibile aprire il programma cmk-update-agent o l'archivio cmk-update-agent.pkg
Su alcuni sistemi Linux viene installato il programma Prelink e viene attivato un cronjob che esamina regolarmente tutti i file binary del sistema e li adatta se necessario per velocizzare i programmi. Tuttavia, il plug-in dell'agente è stato confezionato con il programma PyInstaller che non è compatibile con tali azioni e quindi non funziona. Checkmk ha quindi una voce nella lista nera dei pacchetti deb/rpm che viene memorizzata in/etc/prelink.conf.d e, se esiste un prelink, imposta una voce nel file /etc/prelink.conf esistente. Poiché questo problema è difficile da gestire, può succedere che queste misure non abbiano effetto, soprattutto nel caso di una successiva installazione di prelink.
Pertanto, se installi prelink in un secondo momento, imposta tu stesso la voce e aggiungi la seguente riga al file con il seguente comando:
root@linux# echo "-c /etc/prelink.conf.d/cmk-update-agent.conf" >> /etc/prelink.confMessaggio di errore cmk-update-agent: errore durante il caricamento delle librerie condivise: libz.so.1: fallita mappatura del segmento da un oggetto condiviso
Questo messaggio di errore si verifica quando la directory /tmp con il flagnoexec è stata montata nel sistema. Per risolvere il problema, puoi rimuovere il flag oppure - se lo hai deliberatamente impostato e richiesto - creare sul server Checkmk una regola in Setup sottoAgents > Windows, Linux, Solaris, AIX > Agents > Agent rules > Installation paths for agent files (Linux, UNIX). Lì puoi definire tu stesso la directory tmp nell'opzioneDirectory for storage of temporary data (set TMPDIR environment variable). Il plug-in 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.
L'installazione di RPM fallisce su Red Hat Enterprise Linux/CentOS
Occasionalmente, soprattutto su sistemi RedHat/CentOS, è capitato che la chiamata a rpm attivata dall'aggiornamento automatico fallisse ripetutamente, mentre una chiamata manuale a cmk-update-agent veniva processata con successo. In questi casi, la causa era una policy SELinux che impediva una chiamata priva di errori se rpm veniva chiamato da un processo figlio di xinetd. Puoi risolvere il problema, cioè risolverlo, analizzando i log di SELinux e regolando di conseguenza la policy utilizzando lo strumento audit2allow.
Messaggio di errore: Nessuna firma valida trovata
Se il servizio Check_MK Agent visualizza l'avviso No valid signature found, significa che il pacchetto agente destinato all'host nell'Agent bakery non è stato firmato con una delle chiavi accettate.
Nel caso più semplice, tutto ciò che devi fare è firmare i tuoi agenti utilizzando la funzione Sign agents nell'Agent bakery con una delle chiavi visualizzate in Signature keys the agent will accept.
Non appena l'aggiornamento dell'agente effettua il prossimo report dall'host interessato al server Checkmk e l 'intervallo di cache per il servizio è scaduto, l'avviso scomparirà.
Tuttavia, se l'host non ha (o non ha più) un'unica chiave di firma che si trova sul server Checkmk, dovrai ripetere il bake e firmare con una chiave visualizzata su Signature keys the agent will accept, quindi copiare il Baked agent sull'host interessato e reinstallarlo.
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 del file di configurazione del plug-in dell'agente che non hanno una controparte accettata (cioè configurata) sul 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 i Bake agents, ordinati prima in sottodirectory per sistema operativo (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 sugli host Linux/Unix monitorati
| Percorso del file | Descrizione |
|---|---|
|
Il plug-in dell'agente in formato binario o script, a seconda della configurazione in formato eseguibile. La sottodirectory |
|
Script per chiamare il plug-in dell'agente e registrare l'agente con il comando |
|
File di configurazione del plug-in dell'agente, che contiene i set di regole di Agent updater (Linux, Windows, Solaris). Non modificare questo file perché viene scritto durante le installazioni e gli aggiornamenti. |
|
File con le informazioni del registro di sistema, compreso il segreto dell'host. |
|
File di log completo con i messaggi di DEBUG. |
8.3. Percorsi dei file sull'host Windows monitorato
| Percorso del file | Descrizione |
|---|---|
|
Il plug-in dell'agente per l'aggiornamento dell'agente come file Python |
|
Programma agente per registrare l'agente con il comando |
|
File di configurazione del plug-in di aggiornamento dell'agente |
|
File con le informazioni del registro di sistema, compreso il segreto dell'host |
|
File di log dettagliato con messaggi di DEBUG |
|
File di configurazione creato dall'agent bakery, che tra le altre cose definisce l'intervallo per il controllo degli aggiornamenti. |