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

Mise en place de la réplication des bases

Préparation du compte Mysql

Sur les 2 serveurs Mysql

Arrêter les bases de données
Modification du compte mysql
Génération des clés ssh
Echange des clés ssh entre les serveurs bases de données
Copier le contenu de la clé publique du serveur DB1 sur DB2 et inversement dans le fichier ~/.ssh/authorized_keys
Modifier les droits du fichier
Tester les connexions

Configuration de MariaDB

Ajouter les lignes suivantes dans le fichier /etc/my.cnf.d/centreon.cnf
Penser à mettre 1 pour le master et 2 pour le slave
Laisser le read_only commenté

Redémarrer le services sur les 2 serveurs

Continuer la lecture

Installation d’un cluster à 4 nœuds

Prérequis

Compréhension

Connaissances Indispensables :

Linux
- Shell
- Gestion des utilisateurs
- LVM
Fonctionnement de centreon

Avant de suivre cette procédure, il est recommandé d’avoir un niveau de connaissance satisfaisant du système d’exploitation Linux, de Centreon et des outils de clustering Pacemaker-Corosync pour bien comprendre ce qui va être fait et savoir résoudre un éventuel incident. En pointillé sur les schémas ci-dessous les flux en attente.

Fonctionnement initial de la plateforme ( Site A)

Bascule sur le site secondaire (Site B)

Continuer la lecture

Centreon Auto-discovery

Présentation

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

Fonctionnement

Un crontab sur le serveur central lance toutes les règles actives
Centreon lance une commande snmpget pour déterminer les éléments à superviser
Applique la règle de découverte :
Rattache le bon template (Host ou Service) en fonction des éléments découverts
Applique les différents filtres en fonction des paramétrages de la règle

Continuer la lecture

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

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 (Pour Linux)

TS_OS-Linux-Disk-/var-Usage –> Linux-Disk-/var-Usage

Brique : OS
Famille : Linux
Type : Disk
Domaine : <Nom du FS>
Type Indicateur : Utilisation

TS_OS-Linux-Process-sshd-Status –> OS-Linux-Process-sshd-Status

Brique : OS
Famille : Linux
Type : Process
Domaine : <Nom du Process>
Type Indicateur : Etat

TS_OS-Linux-SYS-Memory-Usage –> OS-Linux-SYS-Memory-Usage

Brique : OS
Famille : Linux
Type : System
Domaine : <Composant système>
Type Indicateur : Utilisation

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 ces 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 de « Sécuriser son serveur dédié proxmox avec iptables »

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