====== Activité : Installation et test du serveur de mails Postfix ======
===== Installation de Postfix =====
Postfix sera installé dans un premier temps avec un paramétrage basique. Lors de l'installation, choisissez **site internet** dans la configuration du paquet.
root@debianWheezy:# apt-get install postfix
Réponses à l'assistant d'installation :
* Type de configuration : Site internet ;
* Nom de courrier : Shinken ;
Le nom de courrier est le nom de votre serveur.
Modifiez le fichier **/etc/postfix/main.cf** pour **inhiber** la résolution par **DNS** qui est active par défaut, et forcer la prise en compte du fichier **/etc/hosts**.
* ajouter en fin de fichier la ligne suivante :
smtp_host_lookup = native
Ce paramètre force **postfix** à passer par le fichier **/etc/nsswitch.conf**, qui va lui donner comme méthode de résolution de noms file soit **/etc/hosts**.
Le fichier **/etc/nsswitch.conf** doit contenir la ligne suivante avec le mot **file** en premier, **dns** en second :
hosts: files dns
**Modifiez** le contenu du fichier **/etc/mailname** pour avoir le contenu suivant :
Shinken
**Redémarrez** le service Postfix :
root@Shinken:~# service postfix restart
===== Création d'un utilisateur pour recevoir les notifications =====
Créez un utilisateur avec votre prénom ; dans la suite du document il s'agira de **roger**.
root@Shinken:~# adduser roger
===== Test du serveur mail postfix et de l’utilisateur =====
* Envoyez un message avec la commande mail pour vérifier que ça fonctionne :
root@Shinken:~# mail -s "bonjour" roger
hello
j'essaie de t'envoyer un message
Cc:
Ctrl+d //pour sortir
**Attention** : Si le fichier **resolv.conf** ne définit pas un domaine de recherche par défaut, il faut mettre le nom complet, par exemple roger@btssio.local
Il suffit ensuite de se connecter avec roger (su - roger) et de vérifier qu'il a reçu le message avec la commande mail (pour revenir à root tapez exit).
roger@Shinken:~$ mail
Mail version 8.1.2 01/15/2001. Type ? for help.
"/var/mail/roger": 1 message 1 new
>N 1 root@ctShinken Tue Nov 22 22:49 14/396 Bonjour
&
* Tapez le numéro du message pour visualiser son contenu :
& 1
Message 1:
From root@Shinken Tue Nov 22 22:49:52 2016
X-Original-To: roger
To: roger@ctShinken
Subject: Bonjour
Date: Tue, 22 Nov 2016 22:49:52 +0100 (CET)
From: root@ctShinken (root)
Hello
j'essaie de t'envoyer un message
& q // pour sortir
Cela fonctionne et Postfix est opérationnel pour ce que l'on veut faire. La suite consiste à configurer les notifications dans Shinken.
Revenez à root par la commande **exit**.
===== Commandes de notification par défaut =====
Pour envoyer des mails, Shinken dispose de commandes définies dans $ETC/notificationways :
root@Shinken:~# cat /etc/shinken/notificationways/email.cfg
# This is how emails are sent, 24x7 way.
define notificationway {
notificationway_name email
service_notification_period 24x7
host_notification_period 24x7
service_notification_options c,w,r
host_notification_options d,u,r,f,s
service_notification_commands notify-service-by-email ; send service notifications via email
host_notification_commands notify-host-by-email ; send host notifications via email
}
**Rappel :**
* w (warning),
* c (critical),
* r (recovery),
* d (down),
* u (unknown).
On peut observer qu’une période de temps (24x7) est respectée pour envoyer les notifications.
Cette période est définie dans **$ETC/timeperiods/24x7.cfg**
define timeperiod{
timeperiod_name 24x7
alias Always
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}
La période 24x7 définit une plage de 24h sur 24 et de 7 jours sur 7.
Les commandes utilisées par le service de notification sont définies dans le répertoire **$ETC/commands**.
Fichier **notify-host-by-email.cfg** :
## Notify Host by Email
define command {
command_name notify-host-by-email
command_line /usr/bin/printf "%b" "Shinken Notification\n\nType:$NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\nDate/Time: $DATE$\n" | /usr/bin/mail -s "Host $HOSTSTATE$ alert for $HOSTNAME$!" $CONTACTEMAIL$
}
Fichier **notify-service-by-email.cfg** :
## Notify Service by Email
define command {
command_name notify-service-by-email
command_line /usr/bin/printf "%b" "Shinken Notification\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $DATE$ Additional Info : $SERVICEOUTPUT$\n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}
L'envoi est réalisé en 2 étapes :
* il y a d'abord la **génération** du texte (par la commande **printf**),
* puis **l’envoi** par mail (par la commande **mail**).
Des macros (variables) sont utilisées, signalées par l'encadrement des $.
Par exemple, la macro **$HOSTNAME$** sera remplacée par **ctShinken** dans le cas d'une alerte sur cette machine.
===== Configuration du contact à alerter dans shinken =====
L’utilisateur **roger** créé précédemment existe pour Linux mais pas pour Shinken. Il faut **créer un contact** dans Shinken et **l’associer** à notre utilisateur.
Vous allez configurer ce contact dans le fichier **$ETC/contacts/roger.cfg** qui faut créer. Attention : on rajoute un contact aux 2 contacts existants (admin et guest).
define contact{
use generic-contact
contact_name roger
email roger@shinken
}
Ce contact est identifié par le nom **roger**, il hérite de **generic-contact** qui définit des valeurs par défaut pour les paramètres de notification, notamment le droit de recevoir des notifications et la commande de notification utilisée.
**Rappel :** les modèles génériques sont définis dans le fichier **$ETC/templates/generic-contacts.cfg**.
# Contact definition
# By default the contact will ask notification by mails
define contact{
name generic-contact
register 0
host_notifications_enabled 1
service_notifications_enabled 1
email shinken@localhost
can_submit_commands 1
notificationways email
}
===== Configuration du déclenchement des alertes =====
La périodicité du déclenchement des notifications est définie de façon générale dans les modèles **generic_host** et **generic-service**.
# Generic service definition template - This is NOT a real service, just a template!
define service {
name generic-service ; The 'name' of this service template
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
notifications_enabled 1 ; Service notifications are enabled
notification_interval 10
notification_period 24x7
event_handler_enabled 0 ; Service event handler is enabled
flap_detection_enabled 1 ; Flap detection is enabled
process_perf_data 1 ; Process performance data
is_volatile 0 ; The service is not volatile
check_period 24x7 ; The service can be checked at any time of the day
max_check_attempts 3 ; Re-check the service up to 3 times in order to determine its final (hard) state
check_interval 5 ; Check the service every 5 minutes under normal conditions
retry_interval 2 ; Re-check the service every two minutes until a hard state can be determined
notification_options w,u,c,r ; Send notifications about warning, unknown, critical, and recovery events
contact_groups admins,users
stalking_options o,w,u,c
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE
}
Ce fichier définit la façon dont Shinken vérifie l'état des objets supervisés :
* Quand un objet est à l'état **OK**, il est vérifié toutes les **check_interval** minutes.
* S'il passe à l'état **WARNING, CRITICAL ou UNKNOWN,** il sera alors vérifié **max_check_attempts** fois à un intervalle de **retry_interval** minutes avant de déclencher une notification. On considère alors que le service testé ou l’hôte est à l’état **hard**.
D’autres périodes sont définies dans le fichier **$ETC/templates/time_templates.cfg**.
Il y a notamment la période **1hour_long** qui est intéressant pour la suite car elle est utilisée par le service **Disks** ce qui va permettre de tester les notifications.
# Check every 1hour with hard state after 6hours
define service {
name 1hour_long
use generic-service
max_check_attempts 6
normal_check_interval 60
retry_interval 60
register 0
}
root@ctShinken:~# cat /etc/shinken/packs/linux-snmp/services/disks.cfg
define service {
service_description Disks
use 1hour_long,linux-service
register 0
host_name linux-snmp
check_command check_linux_disks
_DETAILLEDESC Overall disks usage
_IMPACT Depends on disks, cause system instability
_FIXACTIONS Clean the appropriate disks
}
Le service **Disks** redéfinit donc à son niveau quelques valeurs de **generic_service**.
3 paramètres sont particulièrement intéressants :
* max_check_attempts 6 -> Nombre de “check” renvoyant une erreur avant l’envoi d’une notification
* normal_check_interval 60 -> temps entre 2 “check” renvoyant une erreur
* retry_interval 60 -> temps entre 2 “check” ne renvoyant pas d’erreur
Les temps sont exprimés en minutes.
Si on applique cela, la première notification nous parviendra après un temps calculé avec la formule suivante :
*** normal_check_interval + (retry_interval * (max_check_attempts – 1))** moins 1 parce que le premier retour avec erreur compte.
Donc en appliquant les valeurs du modèle 1hour_long on obtient :
* 60 + (60 * (6 – 1) ) = 360 minutes soit 6 heures
Ce qui est beaucoup trop pour nos tests.
On va donc utiliser plutôt le modèle de période suivant :
define service {
name 5min_short
use generic-service
max_check_attempts 1
normal_check_interval 5
retry_interval 2
register 0
}
En modifiant ainsi le service **Disks** de notre modèle **linux_snmp**.
define service {
service_description Disks
use 5min_short,linux-service
register 0
host_name linux-snmp
check_command check_linux_disks
_DETAILLEDESC Overall disks usage
_IMPACT Depends on disks, cause system instability
_FIXACTIONS Clean the appropriate disks
}
A ce stade les alertes sont déclenchées dès la première erreur après un temps calculé avec la formule suivante :
* 5 + (2 * (1 – 1) ) = 5 minutes.
Puis ensuite toutes les 2 minutes.
===== Configuration du déclenchement des notifications =====
Une alerte déclenchée n’est pas pour autant notifiée.
L’autorisation de notification pour un service ou un hôte, la plage de notification et la fréquence de notification est définie de façon générale dans les modèles **generic_host** et **generic-service**. La directive **notification_interval** est modifiée ci-dessous pour envoyer des messages toutes les 10 minutes dans les tests (par défaut 1440 soit 24 heures).
Les contacts notifiés et le niveau d’erreur à partir duquel une notification est envoyée est aussi stipulé ici.
# Generic service definition template - This is NOT a real service, just a template!
define service{
name generic-service ; The 'name' of this service template
active_checks_enabled 1 ; Active service checks are enabled
passive_checks_enabled 1 ; Passive service checks are enabled/accepted
notifications_enabled 1 ; Service notifications are enabled
notification_interval 10
notification_period 24x7
…
notification_options w,u,c,r ; Send notifications about warning, unknown, critical, and recovery events
contact_groups admins,users
stalking_options o,w,u,c
register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE
}
Attention, il faut bien sûr préciser dans le fichier **$ETC/hosts/localhost.cfg** que l'on veut notifier notre contact en cas de problème.
define host {
use linux-snmp,generic-host
contact_groups admins
host_name localhost
address localhost
}
Dans notre cas, le groupe **admins** étant notifié, on va rajouter dans ce groupe l’utilisateur **roger** :
root@ctShinken:~# cat /etc/shinken/contactgroups/admins.cfg
define contactgroup{
contactgroup_name admins
alias admins
members admin,roger
}
Après toutes ces modifications dans les fichiers de configuration, Il faut faire un contrôle de ces fichiers (service shinken check) et relancer Shinken.
==== Je reviens au menu Shinken ====
* [[reseau:supervision:shinken_00|Supervision des services avec Shinken]]