Category Archives: Centreon

Les ACLs de Centreon (2) : contrôle d’accès aux ressources

Deuxième vidéo sur les ACLs de Centreon : les contrôles d’accès aux ressources. Ces contrôles d’accès permettent de spécifier « qui voit quelles ressources supervisées ».

 

Tout d’abord, il est important de partir d’une excellente organisation. Pour cela, je vous recommande d’utiliser les groupes d’hôtes. Dans cette vidéo, j’ai paramétré les groupes d’hôtes suivants:

  • Windows : groupe d’hôte Centreon contenant tous les hôtes Windows
  • Linux : groupe d’hôte Centreon contenant tous les hôtes Linux
  • Network : groupe d’hôte Centreon contenant tous les hôtes réseau (switch, routeurs, parefeu, …)

Les serveurs Windows doivent être visibles par les administrateurs Windows. Il en est de même pour les autres groupes : ils ne doivent être visibles que pour les administrateurs qui en ont la responsabilité. On en déduit la deuxième partie de la configuration : on crée des groupes de contacts par compétence.

  • Windows : groupe de contacts Centreon contenant tous les utilisateurs administrant des équipements Windows
  • Linux : groupe de contacts Centreon contenant tous les utilisateurs administrant des équipements Linux
  • Network : groupe de contacts Centreon contenant tous les utilisateurs administrant des équipements réseau (switch, routeurs, parefeu, …)

Ensuite, il suffit de relier les groupes de contact au groupe d’hôtes correspondant. Voici la démonstration en vidéo. Je vous invite grandement à cliquer sur l’icône en bas à droite de la vidéo afin de la voir en plein écran. Celle-ci a été prise en haute définition (1280×720) pour qu’elle soit la plus lisible possible. Vous pourrez alors voir plus précisément les actions réalisées afin d’obtenir la même configuration que moi. L’inconvénient est que cette vidéo est relativement lourde : la lecture peut se couper à intervalle régulier. N’hésitez pas à mettre la vidéo sur pause afin que le téléchargement se fasse en tâche de fond. Une fois la moitié du fichier téléchargée, vous pouvez reprendre la lecture.

 

Les ACLs de Centreon (1) : contrôles d’accès aux menus

On continue la série « fonctions mal connues de Centreon » en voyant les ACLs (ou Access Control List / Liste de contrôles d’accès). Les ACLs de Centreon font aussi l’objet d’une série d’articles qui nous permettront de mieux comprendre leur fonctionnement. On commence par les contrôles d’accès aux menus.

 

Principe des contrôles d’accès aux menus de Centreon

L’idée des contrôles d’accès aux menus de Centreon est de limiter la vue des utilisateurs aux fonctionnalités de l’interface web de Centreon. Le but est simple : pour éviter que mes utilisateurs soient pollués par des informations non nécessaires, on ne leur donne pas accès aux fonctionnalités dont ils n’ont pas besoin. En général, il existe plusieurs types d’utilisateur:

  • l’administrateur : il ne doit avoir aucune limite à ces accès
  • le pilote/le service desk/le 24×7/… : accès à l’interface de supervision uniquement pour analyser et traiter une alerte
  • l’administrateur système ou réseau ou d’une application : accès à l’interface de supervision sur les ressources supervisées sous sa responsabilité
  • le responsable d’application : accès à l’interface de supervision et l’interface de reporting sur les ressources supervisées (applications) sous sa responsabilité

Bien entendu, il est possible de décliner encore plus ces profils utilisateurs, de leur donner plus ou moins de droits selon l’organisation des équipes et du Système d’Information.

 

Exemple en vidéo de configuration des contrôles d’accès aux menus de Centreon

Un exemple de configuration des contrôles d’accès aux menus de l’interface de Centreon est présenté dans la vidéo ci-dessous. Je vous invite grandement à cliquer sur l’icône en bas à droite de la vidéo afin de la voir en plein écran. Celle-ci a été prise en haute définition (1280×720) pour qu’elle soit la plus lisible possible. Vous pourrez alors voir plus précisément les actions réalisées afin d’obtenir la même configuration que moi. L’inconvénient est que cette vidéo est relativement lourde (55Mo) : la lecture peut se couper à intervalle régulier. N’hésitez pas à mettre la vidéo sur pause afin que le téléchargement se fasse en tâche de fond. Une fois la moitié du fichier téléchargée, vous pouvez reprendre la lecture.

 

Quelques retours sur Centreon-Syslog

Suite à mes articles sur Centreon-Syslog (1, 2 et 3), le développeur de ce module et Community Leader de Centreon (AkHeNaToN) m’a fait quelques retours.

Tout d’abord, il me précise que la syntaxe que j’ai donnée envoie les messages syslog au travers du protocole TCP (grâce au double ‘@’):

*.* @@192.168.0.11:514

Il m’indique qu’une autre syntaxe permet d’envoyer les messages au travers du protocole UDP (avec un seul ‘@’):

*.* @192.168.0.11:514

 

Il m’indique aussi que le protocole syslog défini que le protocole par défaut est le protocole UDP, le protocole TCP ne devant être utilisé que pour des évènements prioritaires ou demandant un accusé de réception. Par exemple, les évènement « >=kernel.warning » pourront être envoyés par TCP et le reste en UDP.

La configuration des règles de filtrage que j’ai présentées est un peu… datée selon lui. Il existe des règles plus avancées ( à base de if, elsif, and, or, msg::contain::, …) permettant d’ajouter des conditions sur tout type de champ de l’évènement. Certes, mais une configuration simple est tout aussi efficace lorsque le besoin… est simple!

Merci Laurent pour ces retours.

Centreon méta service

J’ai décidé de faire une série d’articles sur les fonctions mal connues de Centreon. Le premier de cette série est les méta services de Centreon.

Définition d’un méta service Centreon

Un méta service Centreon agrège les données de performance de plusieurs services Centreon pour effectuer sur celles-ci des calculs mathématiques et fournir un nouvel objet (appelé méta service Centreon), équivalent à un service.

Cette définition n’étant pas simple à comprendre, nous allons l’illustrer par des cas d’utilisation. Les cas d’utilisation permettent de mieux exprimer la fonctionnalité apportée par les méta services.

Continue reading Centreon méta service

Faire parvenir à un serveur Centreon-Syslog les messages d’un serveur Linux

On continue notre série d’articles sur Centreon-Syslog. Après avoir découvert Centreon-Syslog et comment supprimer les messages d’erreur générés au démarrage de RSyslog, nous allons voir comment faire parvenir les messages syslog d’un serveur Linux au serveur Centreon-Syslog. Cependant, pour éviter de saturer le réseau ou le serveur Centreon-Syslog, nous filtrerons les messages envoyés. Seuls ceux considérés comme intéressants seront envoyés. Les autres seront uniquement stockés en local. Dans cet article, je ne parle que de RSyslog et je pars du principe que Centreon-Syslog est installé et configuré par défaut sur un serveur Centreon Enterprise Server (CES) dont l’adresse IP est 192.168.0.11. Je nomme sender le serveur qui doit envoyer les messages syslog sur le serveur Centreon-Syslog.

Continue reading Faire parvenir à un serveur Centreon-Syslog les messages d’un serveur Linux