Archives de l’auteur : admin

Module auto-discovery

Présentation

Centreon autodiscovery est un module centreon permettant la détection des disques, FS et interfaces réseau.

Fonctionnement

Installation

Pré-requis

Sur le serveur central

git doit être installé

yum install -y git

On télécharge les plugins

cd /usr/src
git clone https://github.com/centreon/centreon-plugins.git
Initialized empty Git repository in /usr/src/centreon-plugins/.git/
remote: Counting objects: 28756, done.
remote: Compressing objects: 100% (144/144), done.
remote: Total 28756 (delta 103), reused 162 (delta 51), pack-reused 28527
Receiving objects: 100% (28756/28756), 7.83 MiB | 3.80 MiB/s, done.
Resolving deltas: 100% (15920/15920), done.
cd centreon-plugins
chmod 755 centreon_plugins.pl
cp -rp ./* /usr/lib/nagios/plugins/

Déploiement des plugins sur les pollers

Vous pouvez le faire manuellement via un scp ou utiliser un outil de déploiement type RUDDER

Sur le serveur database

Création d’un user clapi pour la création automatique

CREATE USER 'clapi'@'%' IDENTIFIED BY "Un Mot De Passe";
GRANT ALL PRIVILEGES ON centreon.* TO 'clapi'@'%' IDENTIFIED BY "Un Mot De Passe" with grant option;
FLUSH PRIVILEGES;
  1. Le « % » est important pour permettre aux pollers et au central de pouvoir se connecter sur le serveur database.
  2. On donne les droits au user clapi sur la database centreon
  3. On active les droits

Sur le serveur central et database

Installation des modules perl

yum install perl net-snmp-perl -y
yum install perl-XML-LibXML perl-JSON perl-libwww-perl perl-XML-XPath perl-Net-Telnet perl-Net-DNS perl-DBI perl-DBD-MySQL perl-DBD-Pg

Configuration de snmp

On sauvegarde le fichier d’origine

mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.ori

On créé un nouveau fichier

vi /etc/snmp/snmpd.conf 

et on ajoute dans le fichier vide la ligne suivante

  • rocommunity C3ntr30n

et on redémarre le service

service snmpd restart
Arrêt de snmpd : [ OK ]
Démarrage de snmpd : [ OK ]

Contrôle du bon fonctionnement de snmp

snmpwalk localhost -c C3ntr30n -v 2c SNMPv2-MIB::sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux centreon-central-master 2.6.32-642.6.2.el6.x86_64 #1 SMP Wed Oct 26 06:52:09 UTC 2016 x86_64

Utilisation du plugin auto discovery de centreon

Préambule

Afin de pouvoir faire de l’auto discovery dans centreon nous devons besoin :

  1. De connaitre la liste des champs qui seront remontés par la découverte
  2. De récupérer un métrique nous permettant de « grapher » et d’afficher un status dans l’interface.

Sur les interfaces

Les 4 commandes ci-dessous devront être implémentées dans centreon afin de pouvoir faire de l’auto-discovery.

Découverte des interfaces

/usr/lib/nagios/plugins/centreon_plugins.pl --plugin=os::linux::snmp::plugin --mode=list-interfaces --hostname=localhost --snmp-version=2 --snmp-community=C3ntr30n --disco-show
<?xml version="1.0" encoding="utf-8"?>
<data>
<label status="up" name="lo" total="10" interfaceid="1"/>
<label status="up" name="eth0" total="1000" interfaceid="2"/>
<label status="up" name="eth1" total="1000" interfaceid="3"/>
</data>

Explications :

  • –plugin=os::linux::snmp::plugin –> Nous utilisons le plugin os::linux::snmp::plugin
  • –mode=list-interfaces –> Affiche les interfaces réseau
  • –disco-show –> Affiche toutes les interfaces découvertes

Lister les champs retournés par la découverte

/usr/lib/nagios/plugins/centreon_plugins.pl --plugin=os::linux::snmp::plugin --mode=list-interfaces --hostname=localhost --disco-format
<?xml version="1.0" encoding="utf-8"?>
<data>
<element>name</element>
<element>total</element>
<element>status</element>
<element>interfaceid</element>
</data>

Explications :

  • La commande de découverte remontera 4 champs
    • name
    • total
    • status
    • interfaceid

Sur les FS

Découverte des unités de stockage

/usr/lib/nagios/plugins/centreon_plugins.pl --plugin=os::linux::snmp::plugin --mode=list-storages --hostname=localhost --snmp-version=2 --snmp-community=C3ntr30n --disco-show
<?xml version="1.0" encoding="utf-8"?>
<data>
<label name="/" total="20516302848" storageid="31"/>
<label name="/dev/shm" total="522235904" storageid="35"/>
<label name="/boot" total="499355648" storageid="36"/>
<label name="/var/log" total="10434699264" storageid="37"/>
</data>

Lister les champs retournés par la découverte

/usr/lib/nagios/plugins/centreon_plugins.pl --plugin=os::linux::snmp::plugin --mode=list-storages --hostname=localhost --disco-format
<?xml version="1.0" encoding="utf-8"?>
<data>
<element>name</element>
<element>total</element>
<element>storageid</element>
</data>

explications :

  • La découverte des unités de stockage remontera :
    • name
    • total
    • storageid

 Implémentation dans centreon

Découverte des interfaces

Durant ce chapitre nous respecterons le modèle de conception de centreon

Création de la commande

La création d’une commande de découverte se fait via le menu Configuration > Commands > Discovery

Pour créer une nouvelle commande

Cliquer sur le bouton add comme le montre la capture ci-dessous

Commande pour récupérer les champs de la découverte

Liste des champs à renseigner :

  • Command Name
    • OS-Linux-SNMP-Traffic-Discovery-Arguments
  • Commande line
    • $USER1$/centreon_plugins.pl –plugin=os::linux::snmp::plugin –mode=list-interfaces –hostname=localhost –disco-format
Commande pour récupérer les interfaces

Liste des champs à renseigner :

  • Command Name
    • OS-Linux-SNMP-Traffic-Discovery
  • Commande line
    • $USER1$/centreon_plugins.pl –plugin=os::linux::snmp::plugin –mode=list-interfaces –hostname=$HOSTADDRESS$ –snmp-version=$_HOSTSNMPVERSION$–snmp-community=$_HOSTSNMPCOMMUNITY$ –disco-show

Explications :

  • Nous utilisons la variable $HOSTADDRESS$ pour récupérer l’adresse IP du serveur que nous voulons superviser
  • Nous utilisons la macro $_HOSTSNMPVERSION$ pour récupérer la version SNMP définie par défaut du serveur
  • Nous utilisons la macro $_HOSTSNMPCOMMUNITY$ pour récupérer la communauté SNMP définie par défaut du serveur

Création du template de service

Commande pour récupérer les champs de la découverte

Liste des champs à renseigner :

  • Command Name
    • OS-Linux-SNMP-Storage-Dicovery-Arguments
  • Commande line
    • $USER1$/centreon_plugins.pl –plugin=os::linux::snmp::plugin –mode=list-interfaces –hostname=localhost –disco-format
Commande pour récupérer les interfaces

Liste des champs à renseigner :

  • Command Name
    • OS-Linux-SNMP-Storage-Dicovery
  • Commande line
    • $USER1$/centreon_plugins.pl –plugin=os::linux::snmp::plugin –mode=list-storages –hostname=$HOSTADDRESS$ –snmp-version=$_HOSTSNMPVERSION$–snmp-community=$_HOSTSNMPCOMMUNITY$ –disco-show

Explications :

  • Nous utilisons la variable $HOSTADDRESS$ pour récupérer l’adresse IP du serveur que nous voulons superviser
  • Nous utilisons la macro $_HOSTSNMPVERSION$ pour récupérer la version SNMP définie par défaut du serveur
  • Nous utilisons la macro $_HOSTSNMPCOMMUNITY$ pour récupérer la communauté SNMP définie par défaut du serveur

Création de la règle de découverte

Les règles de découvertes se font via le menu Configuration > Services > Rules

Comme d’hab on créer une nouvelle règle en cliquant sur add

Onglet général

Liste des champs à renseigner :

  • Rule name : OS-Linux-SNMP-Network-Interfaces
  • Command Macro : OS-Linux-SNMP-Traffic-Discovery-Argument
  • Command Discover : OS-Linux-SNMP-Traffic-Discovery
  • Service Template: OS-Linux-Traffic-Generic-Id-SNMP-Custom
  • Service display name : Trafic-$name$
  • Host templates : OS–Linux-SNMP-Custom

onglet Inclusions/Exclusion  Macro

Une fois dans l’onglet les attribut de découverte doivent apparaître comme le montre la capture ci-dessous

Exclusion

Comme nous l’avons vu ci-dessus lors des tests du plugin de découverte, il découvre toutes les interface. Cependant il n’est pas nécessaire de superviser l’interface pour la boucle locale. Nous allons donc l’exclure des remontées de la découverte des interfaces.

Dans la partie exclusion nous allons ajouter une nouvelle entrée en cliquant sur Add a new entry

  • Dans le champs string nous allons indiqué la variable qui contient le nom de l’interace : $name$
  • dans le champs regex nous allons exclure l’interface lo

Dans la partie macro nous voyons que les macros assignées au template OS-Linux-Traffic-Generic-Id-SNMP-Custom sont bien là.

Nous allons donc renseigné la macro INTERFACEID avec la variable remontée par la commande de découverte. C’est à dire : $interfaceid$

Nous laisserons les autres Macros a vide afin d’hériter des valeurs par défaut des différents template de service.

Onglet Avancé

Les champs à renseigner :

  • String : @SERVICENAME@
  • Regexp : Traffic-eth(\d+)
  • Replace : Traffic-eth-$1

Explications :

L’idée et de mettre un « – » entre le nom de l’interface et son index

  • String : c’est le nom qui sera créé par le champ Service display name de l’onglet général
  • Regexp : nous récupérons le numéro de l’interface (\d+). Le « d » remonte la valeur numérique.
  • Replace : le regexp stocke le résultat dans la variable $1. Le résultat obtenu étant la concaténation de la chaine « Traffic-eth- » et la valeur de $1

Une fois toute ces opérations effectuées nous pouvons sauvegarder notre règle.

Découverte des unité de stockage

Création de la commande

Création du template de service

Création de la régle de découverte

Onglet général

onglet Inclusions/Exclusion  Macro

Onglet Avancé

Règle de nommage des services Linux

Préambule

Pour moi la supervision des serveurs linux est des plus intéressantes :

  • C’est un système ouvert
  • L’Os est suffisamment robuste pour permettre de prendre la main sur le serveur même si un service est défaillant
  • Il n’y a pas ou très peu de boite noires
  • Les fichiers de logs sont suffisamment parlant pour connaitre le hic 😀
  • Avec une gestion par fichier, la gestion du serveur est relativement simple

La supervision d’un serveur Linux peut paraître simple.

Pour paraphraser la première phrase de « Linux pour les nuls » : Tout est fichier 😀

Une fois que l’on a dit cela, on a tout dit et rien dit non plus 😛

Essayons de comprendre le fonctionnement d’un serveur Linux.

Plusieurs aspects sont à prendre en compte :

  • Le noyau de linux (je ne parlerais que des Os rencontrés en entreprise) :
    • Façon Debian
    • Façon RedHat
    • Façon SuSe (même si c’est assez proche de RedHat)
  • Gestion du démarrage du serveur en fonction de la version de l’OS
    • Debian
      • Depuis Debian 9 : systemD
      • Avant Debian 8 : initD ou systemD
      • Avant debian 8 : initD
    • RedHat
      • Depuis RedHat7 : SystemD
      • Avant RedHat7 : initD

Il faut prendre en compte également ces différents.

Par exemple :

  • iptables est devenu firewalld
  • Le nom des interfaces à changer
  • Les outils de gestion des paquets diffèrent
    • Debian : apt-get
    • RedHat : yum
    • SuSe : zipper ou yast2
  • Et ce ne sont pas les seuls différences et ce n’est pas le sujet de l’article 😀

La supervision doit être capable de prendre en compte ces différents aspect, sans rendre la maintenance de la supervision plus complexe.

Dans la suite de l’article nous allons donc mettre en place les templates nécessaires pour la supervision d’un serveur linux en fonction du noyaux et de la version.

NB : Je ne parlerais donc pas des distributions « Exotiques » dans cet article 😀

Continuer la lecture

Règle de nommage des services Windows

Préambule

Nous pouvons dire merci à Mr Bill 😀 de nous avoir pondu un Os ayant des services dépendants de la langue choisie lors de l’installation ( et ça me donne du travail 😀 ).

Les conséquences un service SNMP s’appelera :

  • Service SNMP en Français
  • SNMP service en Anglais
  • Je vous laisse imaginer dans les autres langues 😀

Cela à un impacte non négligeable dans la mise en supervision d’un serveur Windows.

Il va falloir créer un template Windows en fonction de la langue d’installation de l’Os. Et là on se dit WhouAAAAAA, il va falloir créer un template pour chaque langue ?

Et là, on se dit que cela va être galère si il faut gérer toutes les langues que Windows parle, mais c’est que la partie émergée de l’iceberg.

En effet ce n’est pas tout. En fonction de la version de ce super Os, certains services ont disparu, d’autres sont apparus.

L’expérience m’a monté que la supervision d’un serveur ZINDOWS (pour ceux qui auraient leur clavier en QWERTY 😀 ) nécessite de prendre en compte non seulement la version de l’Os mais aussi la langue dans laquelle il a été installé.

Merci de ne pas habité en Serbie ou en république Tchèque (gérer une langue en mode latin avec des caractères que je n’ai pas sur mon clavier et en cyrillique en plus 😀 ), j’ai que l’anglais et le français à gérer 🙂

Arrêtons les digressions et attaquons nous au vif du sujet.

Nous allons donc faire en sorte de prendre en compte les OS de la version 2000 à 2012 en français et en anglais ( j’ai eu des clients en NT4 même au 21ème siècle 😀 mais c’est pas le sujet).

Comment allons nous créer des Templates simple a maintenir et suffisamment flexibles pour ne pas avoir a faire des modifications dans tous les Templates afin d’avoir le résultat voulu.

 

Continuer la lecture

Règle de nommage des services

Préambule

Nous allons voir dans cet article comment oraginiser ses templates de service et les indicateurs présentés dans la vue monitoring.

Règles de nommage des indicateurs

Comprendre les indicateurs

Règles de Nommage pour les services :

Les indicateurs sont organisés de la façon suivante de manière générale :

  • Brique
  • Famille
  • Type
  • Domaine
  • Nom Indicateur

ci-dessous nous aurons :

  • Le nom du template de service utilisé
  • Le nom du service présenté dans la supervision

Un exemple lié à l’OS

TS_OS-Linux-SYS-FS-/var –> OS-Linux-SYS-FS-/var

  • Brique : OS
  • Famille : Linux
  • Type : SYS(tème)
  • Domaine : FS
  • Nom Indicateur : /var

Un exemple applicatif

TS_App-DB-Oracle-Process-ora_pmon –> App-DB-Oracle-Process-ora_pmon

  • Brique : APP(aplicatif)
  • Famille : DB ( Database )
  • Type : Oracle
  • Domaine : Process(us)
  • Nom Indicateur : ora_pmon

Continuer la lecture

Règles de nommage des objets

Liste des forces en présence

Préambule

Il n’est pas rare d’avoir des pages Centreon avec une liste interminable d’indicateur.

Quand nous utilisons l’ascenseur de notre indicateur et que nous sommes en bas de la page le menu disparaît et c’est la cata 😀

Je vais donc vous présenter un méthode perfectible mais simple d’identifier l’objet que vous êtes en train de manipuler.

Le chois de préfixer les objets est simple.

Cela permet :

  • De ne pas modifier les templates fournis par centreon ( facilitant les mise à jours de Centreon)
  • De faire dépendre nos templates préfixés des templates Centreon en les surchargeant selon nos besoins et en prenant en compte les correctifs que les mises à jours pourraient apporter.
  • De faciliter la maintenance des objets structurant permettant de déploiement des indicateurs

Continuer la lecture

Organiser ses indicateurs dans la vue monitoring

But de cet article

Le but de cet article est de vous présenter comment vos indicateurs seront :

  • Plus compréhensibles
  • Regroupés par périmètre de supervision
  • Plus visibles pour vos équipements que vous superviser

Dans mon travail de tous les jours, j’avoue que les règles que je vais vous présenter m’aident grandement.

Elles permettent :

  • Pour novice en supervision, de comprendre l’objet de configuration qu’il est en train de manipuler sans ambiguïté.
  • Faciliter la gestion des ACLs
  • dans l’exploitation de la supervision :
    • D’optimiser la compréhension des indicateurs qui sont présentés
    • De comprendre le domaine d’application de l’indicateur

Continuer la lecture

Sécuriser son serveur dédié proxmox avec iptables

Préambule

But de cet article

Dans cette article nous allons mettre en place une solution basée sur iptables-persistent et fail2ban afin de sécuriser notre serveur.

A la fin de l’article :

  • Notre serveur hôte :
    • Bloquera les différentes attaques du grand internet. Il faut le reconnaître qu’elles viennent souvent de Chine, de Russie ou d’Inde.
    • Fera du NAT pour permettre de se connecter aux VM via internet.
    • Permettra aux VM de se connecter à internet pour les mises à jour.
    • Permettra aux VM de communiquer entre elles.
  • Les VM :
    • Auront accès à internet.
    • Accepteront les connexion SSH sur un pour dédié pour l’administration

Continuer la lecture

Installation et configuration de fail2ban

Présentation de fail2ban

A quoi ça sert ?

Fail2ban sert a analyser des fichiers de logs et créé des règles iptables en fonction des actions que nous aurons définies.

Par exemple fail2ban va analyser le fichier /var/log/auth.log pour rechercher les connexions ayant échouées sur notre serveur.

Les actions sont définies dans un fichier prison (jail.conf)

 

Continuer la lecture

LVM

La gestion des disques avec LVM

Présentation

Linux permet de  gérer les disques via LVM qui est l’acronyme de Logical Volume Manager.

Cet outil fut développé par IBM pour l’AIX3 et fut porté par la firme sous linux.

Il n’y a pas de standard pour la structure des différents éléments qu’utilise LVM et donc chaque constructeur a développé ses propres spécifications.

Ce qui rend le portage et la compatibilité entre constructeurs difficile voir impossible.

Le schéma ci-dessous représente un exemple simple, pour un seveur mysql, sur le mode de fonctionnement de LVM

 

Continuer la lecture