rigacci.org

User Tools

Site Tools

Trace:
doc:appunti:linux:sa:cacti_122

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
doc:appunti:linux:sa:cacti_122 [2019/07/26 11:33] – [Notifiche] niccolodoc:appunti:linux:sa:cacti_122 [2022/10/10 16:27] (current) – [Monitoraggio servizio CLAMD] niccolo
Line 17: Line 17:
 Spine accede direttamente al database, controllare i parametri di accesso in **/etc/cacti/spine.conf**. Spine accede direttamente al database, controllare i parametri di accesso in **/etc/cacti/spine.conf**.
  
-FIXME: L'installazione predefinita genera una errore perché il poller eseguito da **/etc/cron.d/cacti** non ha i permessi per scrivere su **/var/log/cacti/poller-error.log**. È normale che venga eseguito **/usr/share/cacti/site/poller.php** anche se si è selezionato Spine? Come mai il proprietario del file era //root:root//?+**ATTENZIONE**: L'installazione predefinita genera un errore perché il poller eseguito da **/etc/cron.d/cacti** non ha i permessi per scrivere su **/var/log/cacti/poller-error.log**. Il proprietario del file era //root:root//, impostando **www-data:www-data** con **mode 640** pare risolvere. Sembra normale che venga eseguito **/usr/share/cacti/site/poller.php** anche se si è selezionato **Spine**. 
 ==== SNMP timeout detected [500 ms], ignoring host ==== ==== SNMP timeout detected [500 ms], ignoring host ====
  
Line 23: Line 24:
  
 Pare che la soluzione sia quella di allungare il **SNMP Timeout** nella configurazione di ciascun host. Per dispositivi raggiungibili tramite connessione DSL, che possono essere interessati da congestioni di traffico e picchi di carico elevati (utilizzo della CPU prossimo al 100%) può essere necessario portare il timeout anche intorno ai **15000 ms** (15 secondi). Pare che la soluzione sia quella di allungare il **SNMP Timeout** nella configurazione di ciascun host. Per dispositivi raggiungibili tramite connessione DSL, che possono essere interessati da congestioni di traffico e picchi di carico elevati (utilizzo della CPU prossimo al 100%) può essere necessario portare il timeout anche intorno ai **15000 ms** (15 secondi).
 +
 +FIXME Non è chiaro come mai con il **poller Spine** gli errori **SNMP Timeout** sono frequentissimi; un host con linea ADSL congestionata produce un grafico di oggetti SNMP pieno di lacune pressoché illeggibile, anche avendo impostato un SNMP Timeout di 60000 ms: (in /var/log/cacti/cacti.log si legge
 +
 +<code>
 +SPINE: Poller[1] ... WARNING: SNMP timeout detected [60000 ms], ignoring host ...
 +</code>
 +
 +Impostando invece il **poller cmd.php** tali errori scompaiono.
 ===== Icinga 2 ===== ===== Icinga 2 =====
  
Line 33: Line 42:
   * **Database per Icinga Web 2**. Utilizzato dall'interfaccia web come database di servizio. Non contiene i dati del monitoraggio, ma contiene ad esempio l'elenco degli utenti autorizzati all'accesso. Deve essere creato manualmente e viene popolato dalla procedura di configurazione web. Si consiglia di utilizzare il nome **icingaweb**.   * **Database per Icinga Web 2**. Utilizzato dall'interfaccia web come database di servizio. Non contiene i dati del monitoraggio, ma contiene ad esempio l'elenco degli utenti autorizzati all'accesso. Deve essere creato manualmente e viene popolato dalla procedura di configurazione web. Si consiglia di utilizzare il nome **icingaweb**.
  
-Si devono installare i seguenti pacchetti:+Si devono installare i seguenti pacchetti (si è scelto PostgreSQL come database di supporto):
  
 +  * **postgresql**
   * **icinga2**   * **icinga2**
   * **icingaweb2**   * **icingaweb2**
Line 129: Line 139:
  
 === Monitoring e database IDO === === Monitoring e database IDO ===
 +
 +Il modulo //Monitoring// ha bisogno di un database di supporto, che non è lo stesso usato da Icingaweb 2. Durante l'installazione del pacchetto **icinga2-ido-pgsql** viene infatti creato un **database** di nome **icinga2** a cui si accede tramite le credenziali salvate in **/etc/icinga2/features-available/ido-pgsql.conf**. La procedura di installazione crea l'utente e il database, inoltre popola quest'ultimo con le tabelle necessarie.
 +
 +Se la procedura di installazione fallisce (ad esempio perché durante l'esecuzione non è ancora installato il pacchetto **postgresql**), la soluzione più comoda è rimuovere e reinstallare il pacchetto **icinga2-ido-pgsql** (il ''%%--reconfigure%%'' purtroppo non è sufficiente).
  
 Quando la procedura web configura il **modulo Monitoring** si devono indicare le coordinate del backend IDO creato durante l'installazione del pacchetto Debian **icinga2-ido-pgsql**. Aprire il file **/etc/icinga2/features-available/ido-pgsql.conf** per vedere username, password, ecc. Quando la procedura web configura il **modulo Monitoring** si devono indicare le coordinate del backend IDO creato durante l'installazione del pacchetto Debian **icinga2-ido-pgsql**. Aprire il file **/etc/icinga2/features-available/ido-pgsql.conf** per vedere username, password, ecc.
Line 190: Line 204:
 </code> </code>
  
 +==== Monitoraggio di un servizio TCP/IP standard ====
 +
 +In questo esempio aggiungiamo il monitoraggio di un servizio standard **POP3** sulla porta 110 TCP.
 +
 +Per prima cosa si definisce un **CheckCommand** nel file **/etc/icinga2/conf.d/commands.conf** (o analogo):
 +
 +<file>
 +object CheckCommand "mail_check_pop" {
 +    command = [ PluginDir + "/check_pop" ]
 +    arguments = {
 +        "-H" = "$pop_server$"
 +    }
 +}
 +</file>
 +
 +Il comando si basa su uno dei plugin standard forniti dal pacchetto **monitoring-plugins-basic**, per la precisione si tratta di **/usr/lib/nagios/plugins/check_pop**. L'unico argomento che viene passato con l'opzione **%%-H%%** è l'indirizzo dell'host, che dovrà essere definito nella variabile **%%$pop_server$%%**.
 +
 +Quindi si definisce un servizio di nome **POP3 Service** basato sul comando appena definito; nel file **/etc/icinga2/conf.d/services.conf** (o analogo) si aggiunge:
 +
 +<file>
 +apply Service "POP3 Service" {
 +    import "generic-service"
 +    check_command = "mail_check_pop"
 +    check_interval = 5m
 +    assign where host.vars.pop_server
 +}
 +</file>
 +
 +Da notare che il nome del servizio verrà usato nella visualizzazione di IcingaWeb, pertanto si usa qualcosa di descrittivo e comprensibile. Considerato che il template **generic-service** ha un **check_interval** di un solo minuto, si è preferito rilassare il controllo ad un intervallo di **cinque minuti**.
 +
 +Infine si deve attivare il servizio per l'host desiderato: è sufficiente definire la variabile **pop_server** che sarà anche usata dal plugin come indirizzo remoto da testare. La definizione degli host è generalmente contenuta nel file **/etc/icinga2/conf.d/hosts.conf**:
 +
 +<file>
 +object Host "MyHost" {
 +  import "generic-host"
 +  ...
 +  vars.pop_server = "mail.rigacci.org"
 +</file>
 ==== Monitoraggio client remoto via NRPE ==== ==== Monitoraggio client remoto via NRPE ====
  
Line 242: Line 294:
 </file> </file>
  
 +==== CheckCommand con parametri opzionali ====
 +
 +Si è avuto un caso particolare in cui il **server NRPE versione 2.15** (in esecuzione sull'host da monitorare) non poteva essere interrogato da Icinga 2 a causa di problemi SSL (probabilmente a causa della versione troppo vecchia della libreria SSL). Nei log del server si legge:
 +
 +<code>
 +nrpe[9169]: Error: Could not complete SSL handshake.
 +</code>
 +
 +È stato necessario avviare il server NRPE con l'opzione **-n** per disabilitare SSL. Su Icinga 2 si è modificato il comando che invoca il **plugin check_nrpe**, in modo che disabiliti SSL (con l'analoga opzione **-n**), ma **solo per gli host che hanno questa limitazione**.
 +
 +<file>
 +object CheckCommand "disk_check_nrpe_swraid" {
 +    command = [ PluginDir + "/check_nrpe", "--timeout=60:UNKNOWN" ]
 +    arguments = {
 +        "-H" = "$address$"
 +        "-c" = "$nrpe_swraid$"
 +        "-n" = { set_if = "$nrpe_no_ssl$" }
 +    }
 +}
 +</file>
 +
 +È sufficiente definire la variabile opportuna nella sezione host:
 +
 +<file>
 +object Host "Server" {
 +  import "generic-host"
 +  address = "server.rigacci.org"
 +  vars.nrpe_swraid = "check_swraid"
 +  vars.nrpe_no_ssl = true
 +}
 +</file>
 ===== Check passivo ===== ===== Check passivo =====
  
 Normalmente Icinga 2 effettua **check attivi**, cioè interroga l'host remoto per conoscere lo stato di una specifica grandezza ed agire di consegunza. Se l'host remoto è dietro a un firewall o comunque non è possibile conoscerne lo stato con un check diretto, è possibile utilizzare i **check passivi**, cioè è l'host remoto che informa il server Icinga 2 sul proprio stato. Normalmente Icinga 2 effettua **check attivi**, cioè interroga l'host remoto per conoscere lo stato di una specifica grandezza ed agire di consegunza. Se l'host remoto è dietro a un firewall o comunque non è possibile conoscerne lo stato con un check diretto, è possibile utilizzare i **check passivi**, cioè è l'host remoto che informa il server Icinga 2 sul proprio stato.
  
-Utilizzeremo una configurazione **[[https://icinga.com/docs/icingaweb2/latest/modules/monitoring/doc/05-Command-Transports/#use-a-local-command-pipe|external command sent via command pipe]]**, che è direttamente derivata dai **[[nagios_passivo|check passivi con Nagios3]]**, FIXME probabilmente si tratta di una configurazione deprecabile, soprattutto per l'utilizzo di **NSCA** (Nagios Service Check Acceptor).+Nel nostro caso si vuole monitorare l'**esecuzione di un backup** su un host remoto. Il monitoraggio deve accorgersi non solo di un eventuale errore, ma anche della mancata esecuzione, per questo si utilizza una combinazione di **check passivi** e **attivi**.
  
-Anzitutto si deve abilitare l'opzione **external command file**. In pratica Icinga 2 inizierà a ricevere input dal //named pipe// **/var/run/icinga2/cmd/icinga2.cmd**: ogni eventuale check passivo deve solo **aggiungere una riga** sulla //pipe// per informare Icinga dello stato del check.+  * In condizioni normali l'host remoto esegue il backup e notifica Icinga 2 con un **check passivo**. 
 +  * Se l'host Icinga 2 non riceve il check passivo, esegue un **check attivo** //dummy// che restituisce lo stato 3 UNKNOWN. 
 + 
 +Il check passivo utilizza il meccanismo **[[https://icinga.com/docs/icingaweb2/latest/modules/monitoring/doc/05-Command-Transports/#use-a-local-command-pipe|external command sent via command pipe]]**, che è direttamente derivata dai **[[nagios_passivo|check passivi con Nagios3]]**. Probabilmente si tratta di una configurazione deprecabile, soprattutto per l'utilizzo di **NSCA** (Nagios Service Check Acceptor). 
 + 
 +Per qusto si deve abilitare l'opzione **external command file**; in pratica Icinga 2 inizierà a ricevere input dal //named pipe// **/var/run/icinga2/cmd/icinga2.cmd**: ogni eventuale check passivo deve solo **aggiungere una riga** sulla //pipe// per informare Icinga dello stato del check.
  
 Si verifica le //feature// abilitate, si abilita la //command// e si ricarica il servizio: Si verifica le //feature// abilitate, si abilita la //command// e si ricarica il servizio:
Line 262: Line 350:
 <file> <file>
 template Service "passive-backup-service" { template Service "passive-backup-service" {
-  import "generic-service" +    import "generic-service" 
-  check_command = "passive" +    check_command = "passive" 
-  enable_active_checks = false +    /* Do active checks to detect missing passive updates. */ 
-  enable_passive_checks = true +    enable_active_checks = true 
-  check_interval = 1d +    enable_passive_checks = true 
-  retry_interval = 4h +    /* Use a runtime function to retrieve the last check time and more details. */ 
-  max_check_attempts = 1+    vars.dummy_text = {{ 
 +        var service = get_service(macro("$host.name$"), macro("$service.name$")) 
 +        var lastCheck = DateTime(service.last_check).to_string() 
 +        return "No check results received. Last result time: " + lastCheck 
 +    }} 
 +    check_interval = 1d +1h  /* This determines the freshness of the check. */ 
 +    retry_interval = 1h      /* Execute the active check if freshness is due. */ 
 +    max_check_attempts = 3   /* Retry the active check some times, before notification. */ 
 +    vars.notification_interval = 1d  
 } }
 </file> </file>
  
-Da notare che lo stato viene controllato una sola volta al giorno (**check_interval = 1d**), in caso di problemi //SOFT// viene riprovato dopo 4 ore (**retry_interval = 4h**). Lo stato del servizio viene considerato valido alla prima verifica (**max_check_attempts = 1**).+Il //check_command// **passive** è definito in ''/usr/share/icinga2/include/command-icinga.conf'', si tratta in effetti del comando built-in **[[https://icinga.com/docs/icinga2/latest/doc/10-icinga-template-library/#itl-dummy|dummy]]** con il valore di //dummy_state// impostato a 3 (stato UNKNOWN). Il valore di //dummy_text// invece utlizza una funziona per recuperare il timestamp dell'ultimo esito positivo del check. 
 + 
 +In condizioni normali viene ricevuto un **check passivo** ogni 24 ore, quindi il check attivo giornaliero (//check_interval = 1d + 1h//) non viene eseguito. Qualora il check passivo non venga ricevuto, viene eseguito il check attivo //dummy// e lo stato passa da **OK** ad **UNKNOWN soft**. Il check viene ripetuto ogni ora (//retry_interval =1h//) e al terzo tentativo (//max_check_attempts = 3//) lo stato passa a **UNKNOWN hard**.
  
-Quindi si definisce un servizio associato ad un host, ad esempio nel file **/etc/icinga2/conf.d/services.conf** o analogo:+Per definire il servizio associato ad un host si aggiunge ad esempio nel file **/etc/icinga2/conf.d/services.conf** o analogo:
  
 <file> <file>
Line 290: Line 388:
  
 Il timestamp in formato Unix si può ottenere da una shell Unix con il comando **%%date +%s%%**. Il timestamp in formato Unix si può ottenere da una shell Unix con il comando **%%date +%s%%**.
 +
 +La ricezione di un check passivo viene registrata nel log **/var/log/icinga2/icinga2.log**:
 +
 +<code>
 +[2022-02-22 02:49:04 +0100] information/ExternalCommandListener:
 +    Executing external command: [1645494544] PROCESS_SERVICE_CHECK_RESULT;Naxos;
 +    Backup Maildir;0;2022-02-22 02:49:03: santorini-naxos-rsync-maildir:
 +    rsync Maildir da Santorini a Naxos eseguito con successo.
 +</code>
 +
 +==== Ricezione check passivo via REST API ====
 +
 +Si verifica che la **[[#rest_api_interface|REST API interface]]** sia attiva (è la stessa che viene usata dal modulo **Icinga Web 2**). Dovrebbe essere in ascolto sulla porta **TCP/5665**.
 +
 +Nel file **/etc/icinga2/conf.d/api-users.conf** si definisce un utente con password che abbia l'autorizzazione ad inviare i risultati dei check. L'unico permesso richiesto è **actions/process-check-result**:
 +
 +<file>
 +// Used to submit passive checks results, e.g. from backup scripts.
 +object ApiUser "passive-check" {
 +  password = "MyUserSecret"
 +  permissions = [ "actions/process-check-result" ]
 +}
 +</file>
 +
 +Il client che deve inviare l'esito del check passivo può utilizzare ad esempio **curl**, con autenticazione su protocollo https:
 +
 +<code bash>
 +ICINGA2_SERVER='icinga2.rigacci.org'
 +ICINGA2_USER='passive-check'
 +ICINGA2_PASSWORD='MyUserSecret'
 +
 +SERVICE_HOST='Naxos'
 +SERVICE_NAME="Backup Remote Rsync"
 +EXIT_STATUS="0"
 +EXIT_MESSAGE="[OK] Rsync to remote storage"
 +
 +curl -k -s -u "${ICINGA2_USER}:${ICINGA2_PASSWORD}" \
 +    -H 'Accept: application/json' \
 +    -X POST "https://${ICINGA2_SERVER}:5665/v1/actions/process-check-result" \
 +    -d '{ "type": "Service",
 +          "filter": "host.name==\"'"$SERVICE_HOST"'\" && service.name==\"'"$SERVICE_NAME"'\"",
 +          "exit_status": '"$EXIT_STATUS"',
 +          "plugin_output": "'"$EXIT_MESSAGE"'" }' > /dev/null
 +</code>
 +
 +Un servizio Icinga può essere in uno dei seguenti stati:
 +
 +^  0 | OK        |
 +^  1 | WARNING   |
 +^  2 | CRITICAL  |
 +^  3 | UNKNOWN   |
  
 ==== Server NSCA ==== ==== Server NSCA ====
 +
 +:!: **ATTENZIONE**: L'utilizzo di NCSA è deprecato, Icinga2 ha la sua interfaccia **REST API** che può essere protetta con HTTPS e autenticazione. La ricezione dei check passivi va fatta via REST API come spiegato sopra.
  
 Nell'ottica di riutilizzare più possibile la configurazione di un vecchio server Nagios3, si utilizza il **Nagios Service Check Acceptor** per ricevere le notifiche dei check passivi. Si tratta di un demone che ascolta sulla **porta TCP/IP 5667** e riceve le notifiche dai vari client per inoltrarle sulla //named pipe// monitorata da Icinga 2. Pertanto sullo stesso host dove viene eseguito Icinga si installa il pacchetto **nsca**. Nell'ottica di riutilizzare più possibile la configurazione di un vecchio server Nagios3, si utilizza il **Nagios Service Check Acceptor** per ricevere le notifiche dei check passivi. Si tratta di un demone che ascolta sulla **porta TCP/IP 5667** e riceve le notifiche dai vari client per inoltrarle sulla //named pipe// monitorata da Icinga 2. Pertanto sullo stesso host dove viene eseguito Icinga si installa il pacchetto **nsca**.
Line 367: Line 518:
  
 Nel nostro caso la mail **%%root@localhost%%** viene inoltrata a chi di dovere tramite **/etc/aliases** e le opportune configurazioni di Postfix. Nel nostro caso la mail **%%root@localhost%%** viene inoltrata a chi di dovere tramite **/etc/aliases** e le opportune configurazioni di Postfix.
 +
 +Nel file **/etc/icinga2/conf.d/notifications.conf** viene abilitata la notifica **per ogni host** che abbia definito la **host.vars.notification.mail** (clausola //assign where//):
 +
 +<file>
 +apply Notification "mail-icingaadmin" to Host {
 +  import "mail-host-notification"
 +  user_groups = host.vars.notification.mail.groups
 +  users = host.vars.notification.mail.users
 +  ...
 +  assign where host.vars.notification.mail
 +}
 +</file>
 +
 +Nello stesso file - con una sintassi praticamente identica - viene abilitata la notifica anche **per ogni servizio** che abbia definito la **host.vars.notification.mail**:
 +
 +<file>
 +apply Notification "mail-icingaadmin" to Service {
 +  import "mail-service-notification"
 +  user_groups = host.vars.notification.mail.groups
 +  users = host.vars.notification.mail.users
 +  ...
 +  assign where host.vars.notification.mail
 +}
 +</file>
 +
 +Quindi - definendo tale variabile per un host - si ottiene come risultato di ricevere notifiche per tutti gli eventi associati a tale **host** e per tutti gli eventi legati ai **servizi** che dipendono dallo stesso. Questa è la sintassi:
 +
 +<file>
 +object Host "Webserver" {
 +  import "generic-host"
 +  address = "www.rigacci.org"
 +  ...
 +  vars.notification.mail = {
 +      users = [ "icingaadmin" ]
 +  }
 +}
 +</file>
 +
 +==== Frequenza delle notifiche ====
 +
 +L'impostazione predefinita Debian è di inviare una notifica **ogni 30 minuti**, con periodo **24x7**. È possibile impostare un valore diverso per le notifiche che riguardano gli host e quelle dei servizi nel file **/etc/icinga2/conf.d/notifications.conf**:
 +
 +<file>
 +apply Notification "mail-icingaadmin" to Host {
 +  ...
 +  interval = 4h
 +}
 +
 +apply Notification "mail-icingaadmin" to Service {
 +  ...
 +  interval = 8h
 +}
 +</file>
 +
 +Si può personalizzare l'intervallo di notifica in base al servizio, ecco come modificare la **Notification "mail-icingaadmin"**:
 +
 +<file>
 +apply Notification "mail-icingaadmin" to Service {
 +  import "mail-service-notification"
 +  user_groups = host.vars.notification.mail.groups
 +  users = host.vars.notification.mail.users
 +  if (service.vars.notification_interval) {
 +    interval = service.vars.notification_interval
 +  } else {
 +    interval = 12h
 +  }
 +  assign where host.vars.notification.mail
 +}
 +</file>
 +
 +Come si vede l'intervallo di notifica predefinito è impostato a **12h** (due volte al giorno) a meno che non sia stata definita nel servizio la **vars.notification_interval**. Vediamo quindi la definizione di un servizio che imposta un //interval// personalizzato:
 +
 +<file>
 +apply Service "Software RAID" {
 +    import "generic-service"
 +    check_command = "disk_check_nrpe_swraid"
 +    check_interval = 15m
 +    vars.notification_interval = 1d
 +    assign where host.vars.nrpe_swraid
 +}
 +</file>
 +===== Notifica custom su Host =====
 +
 +Vediamo come predisporre le notifiche per un singolo host inviando una mail ad un determinato indirizzo. Si crea un file (ad esempio **/etc/icinga2/conf.d/notification_dsl.conf**) in cui si definisce il tipo di notifica e l'utente che deve ricevere la mail:
 +
 +<file>
 +apply Notification "mail-dsl-users" to Host {
 +  import "mail-host-notification"
 +  users = host.vars.notification.mailcustomer.users
 +  times.begin = 3h
 +  interval = 12h
 +  assign where host.vars.notification.mailcustomer
 +}
 +
 +object User "dsl_user_1" {
 +  import "generic-user"
 +  display_name = "Alert for ADSL 1"
 +  email = "name@domain.tld"
 +}
 +</file>
 +
 +Le notifiche inizieranno solo **dopo 3 ore** che l'host ha il problema, e verranno ripetute **ogni 12 ore**. Quindi è sufficiente aggiungere una riga alla definizione dell'host:
 +
 +<file>
 +object Host "ADSL_1"     {
 +    import "generic-host"
 +    address = "185.121.12.106"
 +    vars.notification.mailcustomer = { users = [ "dsl_user_1" ] }
 +}
 +</file>
 +
 +===== Modifica servizi predefiniti =====
 +
 +Potrebbe essere necessario fare delle modifiche ai servizi predefiniti. Ad esempio il servizio **ping4** viene applicato ad ogni host che abbia un **address**, ma i parametri sono un po' troppo stringenti; un host collegato ad una DSL di bassa qualità sarà molto spesso in stato di **WARNING** o **CRITICAL** a causa di //round-trip// o //packet loss// troppo alti.
 +
 +I file che definiscono i servizi sono in **/usr/share/icinga2/**, ma è sconsigliato modificarli perché un eventuale aggiornamento del pacchetto farebbe perdere le modifiche.
 +
 +Nel file **/usr/share/icinga2/include/command-plugins.conf** è definito l'**object CheckCommand "ping4"** che importa la sua configurazione dal **template CheckCommand "ping-common"**. Il comando ping4 viene applicato a tutti gli host nel file **/etc/icinga2/conf.d/services.conf**, quando asserisce un **apply Service "ping4"** con la semplice clausola **assign where host.address**.
 +
 +Nel file **/etc/icinga2/conf.d/commands.conf** si possono definire un template e due comandi nuovi:
 +
 +<file>
 +template CheckCommand "ping-common-slow" {
 +    vars.ping_wrta = 160
 +    vars.ping_wpl = 18
 +    vars.ping_crta = 320
 +    vars.ping_cpl = 36
 +}
 +
 +object CheckCommand "ping4slow" {
 +    import "ping-common"
 +    import "ping-common-slow"
 +    command += [ "-4" ]
 +    vars.ping_address = "$address$"
 +}
 +
 +object CheckCommand "ping6slow" {
 +    import "ping-common"
 +    import "ping-common-slow"
 +    command += [ "-6" ]
 +    vars.ping_address = "$address6$"
 +}
 +</file>
 +
 +poi si modifica il **Service "ping4"** nel file **/etc/icinga2/conf.d/services.conf** (ovviamente si dovrà modificare in maniera analoga anche il **ping6**):
 +
 +<file>
 +apply Service "ping4" {
 +  import "generic-service"
 +
 +  if (host.vars.ping_slow) {
 +    check_command = "ping4slow"
 +  } else {
 +    check_command = "ping4"
 +  }
 +  
 +  assign where host.address
 +}
 +</file>
 +
 +Per applicare il ping modificato sarà sufficiente definire la variabile **ping_slow** nella definizione di host:
 +
 +<file>
 +object Host "Naxos" {
 +  ...
 +  vars.ping_slow = true
 +}
 +</file>
 +===== Controllo hostalive e IPv6 =====
 +
 +Per ogni host viene effettuato un controllo **check_command = hostalive**, poiché così è impostato il template **generic-host** definito in **/etc/icinga2/conf.d/templates.conf**. Inoltre vengono effettuati anche i check per i servizi **ping4** e **ping6** se sono definiti  **host.address** e **host.address6** rispettivamente.
 +
 +Si tratta di due controlli indipendenti per cui può accadere che il **ping6** sia disabilitato (basta non definire l'//address6// nella configurazione dell'host), ma **hostalive** tenta comunque un ping6 se risolve il nome con un indirzzo IPv6. Se la connettività IPv6 non è attiva, si ottiene come risultato che l'host risulta **DOWN** nonostante che risponda al **ping4**.
 +
 +Per evitare questa situazione si deve sostituire **hostalive** con **hostalive4** nel template //generic-host//.
 +
 +===== Porta TCP alternativa per servizio standard =====
 +
 +Il servizio predefinito **ssh** viene applicato a tutti gli host che anno **vars.os = Linux** e si basa ovviamente sulla **porta 22 TCP**. Per fare il test su una porta alternativa si deve definire un servizio personalizzato:
 +
 +<file>
 +apply Service "ssh_alt" {
 +  import "generic-service"
 +  check_command = "ssh"
 +  vars.ssh_port = 2222
 +  assign where (host.address || host.address6) && host.vars.os == "LinuxAlt"
 +}
 +</file>
 +
 +===== VirtualHost con SSL =====
 +
 +Per monitorare il funzionamento basico di un server web è sufficiente definire una variabile **vars.http_vhosts** in una sezione **object Host**:
 +
 +<file>
 +object Host "ServerName" {
 +  import "generic-host"
 +  address = "servername.rigacci.org"
 +  vars.http_vhosts["www.rigacci.org"] = { }
 +}
 +</file>
 +
 +Il nome tra parentesi quadre è solo una label utilizzata per identificare il servizio nell'interfaccia web, non viene utilizzata né per ottenere l'indirizzo IP del server (a quello serve la variabile **address**) né tantomeno per identificare un //NamedVirtualHost//.
 +
 +Per un moderno server web tuttavia è necessario verificare la scadenza del certificato SSL ed eventualmente verificare diversi **VirtualHost** che condividono lo stesso indirizzo IP, ma hanno **ServerName** e **certificati SSL** diversi.
 +
 +In teoria non sarebbe possibile **verificare il certificato SSL di un VirtualHost basato su nome**, perché nella fase iniziale della negoziazione SSL il nome dell'host richiesto non è ancora noto e quindi il server non può sapere quale certificato presentare al client. Tuttavia l'estensione SNI è stata sviluppata apposta per ovviare a questo problema. Vedere in proposito **[[https://cwiki.apache.org/confluence/display/httpd/NameBasedSSLVHostsWithSNI|Name Based SSL VHosts With SNI]]**.
 +
 +Ammettendo che il server web sia configurato opportunamente, ecco un modo per verificare due diversi VirtualHost ospitati sullo stesso server:
 +
 +<file>
 +object Host "ServerName" {
 +  import "generic-host"
 +  address = "servername.rigacci.org"
 +  vars.http_vhosts["www.first_domain.tld"] = {
 +    http_address = "$address$"
 +    http_vhost = "www.first_domain.tld"
 +    http_ssl = true
 +    http_sni = true
 +    http_certificate = "24,14"
 +  }
 +  vars.http_vhosts["www.second_domain.tld"] = {
 +    http_address = "$address$"
 +    http_vhost = "www.second_domain.tld"
 +    http_ssl = true
 +    http_sni = true
 +    http_certificate = "24,14"
 +  }
 +}
 +</file>
 +
 +Each **vars.http_vhosts** section correspond to one command invokation, of this type:
 +
 +<code>
 +check_http -H "www.first_domain.tld" -I "servername.rigacci.org" -S --sni -C "24,14"
 +</code>
 +
 +===== Monitoraggio servizio CLAMD =====
 +
 +Il programma antivirus **[[http://www.clamav.net/|ClamAV]]** generalmente viene configurato in Debian come servizio **clamav-daemon.service**, l'eseguibile **clamd** è in esecuzione con i parametri configurati in **/etc/clamav/clamd.conf**. Per attivare il monitoraggio del servizio (si vuole sapere se il demone è in esecuzione) conviene usare il plugin **/usr/lib/nagios/plugins/check_clamd** fornito dal pacchetto **monitoring-plugins-basic**, che fa una semplice interrogazione su TCP/IP.
 +
 +Per impostazione predefinita clamd **non** si mette in ascolto sulla porta **TCP 3310**, è necessario aggiungere queste righe alla configurazione:
 +
 +<file>
 +# Listen also on TCP localhost, to allow running status check.
 +TCPSocket 3310
 +TCPAddr 127.0.0.1
 +</file>
 +
 +Il binding viene fatto solo su //localhost// in modo da non esporre il servizio antivirus all'esterno; pertanto il plugin Icinga deve essere eseguito in locale e il check da parte di un host remoto avvien tramite NRPE. Per ottenere questo si aggiunge in **/etc/nagios/nrpe_local.cfg**:
 +
 +<file>
 +command[check_clamd]=/usr/lib/nagios/plugins/check_clamd -H localhost
 +</file>
 +
 +Sul server Icinga2 si deve definire il **servizio** aggiungendo in **/etc/icinga2/conf.d/local/services.conf** la seguente sezione:
 +
 +<file>
 +apply Service "CLAMD Service" {
 +    import "generic-service"
 +    check_command = "mail_check_nrpe_clamd"
 +    assign where host.vars.nrpe_clamd
 +}
 +</file>
 +
 +Quindi si aggiunge il comando aggiungendo in **/etc/icinga2/conf.d/local/commands.conf** la seguente sezione:
 +
 +<file>
 +object CheckCommand "mail_check_nrpe_clamd" {
 +    command = [ PluginDir + "/check_nrpe", "--timeout=60:UNKNOWN" ]
 +    arguments = {
 +        "-H" = "$address$"
 +        "-c" = "check_clamd"
 +        "-n" = { set_if = "$nrpe_no_ssl$" }
 +    }
 +}
 +</file>
 +
 +Infine nella sezione **host** relativa all'host da monitorare (potrebbe essere nel file **/etc/icinga2/conf.d/hosts.conf**), si aggiunge la riga:
 +
 +<file>
 +object Host "clamav-hostname" {
 +  ...
 +  vars.nrpe_clamd = true
 +  ...
 +}
 +</file>
 ===== Riferimenti Web ===== ===== Riferimenti Web =====
  
Line 372: Line 809:
   * **[[https://icinga.com/docs/icinga2/latest/doc/09-object-types/|Object Types Docs]]**   * **[[https://icinga.com/docs/icinga2/latest/doc/09-object-types/|Object Types Docs]]**
   * **[[https://somoit.net/icinga/icinga-passive-checks-2|Icinga – How to configure passive checks made easy]]**   * **[[https://somoit.net/icinga/icinga-passive-checks-2|Icinga – How to configure passive checks made easy]]**
 +  * **[[https://somoit.net/icinga/icinga2-understanding-checks-notification-types|Icinga2 – Understanding checks and notification types]]**
doc/appunti/linux/sa/cacti_122.1564133634.txt.gz · Last modified: by niccolo