go right here xhamster
look at this web-sitebrowap.info

Résoudre les problèmes liés au premier démarrage

Introduction

La mise en place initiale de la solution Overmon peut s’avérer ardue. 

Non pas que le produit en lui-même soit déficient. Simplement, il repose sur des pré-requis nombreux, en terme de configuration systèmes et réseaux.

Cet article a pour but de vous amener à réussir cette mise en place.

Schéma d’installation type



Prenez le temps de bien comprendre ce petit schéma.

Il représente un Système d’Information classique, et va nous servir d’exemple et de référence pour le reste de l’article

Sur cette installation :

  • Ce Système d’Information se compose de 3 lans (ou wans) au sein desquels sont répartis différents équipements (Serveurs, PC, Imprimantes, …)
  • L’OVS est installé en lan3, et son hostname est overmon-server
  • L’OAT est installé en lan1, et son hostname est overmon-laptop

Quelques rappels fondamentaux

Comprenez bien qu’on parle ici d’une solution de gestion de parc. Il s’agit là d’un type de logiciel particulier, ou la notion de communication inter-machines est particulièrement important. A ce titre, la plupart des problèmes que vous allez être amené à rencontrer lors de son utilisation, seront liés à des problèmes de paramétrage réseau.

Pour que la solution fonctionne, les pré-requis fondamentaux suivants devront être respectés :

  • L’OAT devra pouvoir se connecter en ssh sur l’OVS. C’est le minimum !
  • Dans le même ordre d’idée, l’OAT devra pouvoir se connecter sur chacun des équipements avec lesquels il devra interagir. Ce point est crucial, notamment pour la phase de déploiement des agents. Un accès ssh sera donc nécessaire pour les machines linux. Quant aux machines Windows, elle devront permettre les accès en rpc. S’il devait s’avérer que certains lans de votre entreprise soient étanches à d’autres, vous devrez envisager un scénario adéquat pour résoudre ce problème (ouvrir certains ports, poser un OAT par lan, …)
  • L’OVS, lui aussi, devra pouvoir contacter les machines distantes, afin de pouvoir récupérer les inventaires générés, les éventuelles alarmes nagios, etc …

Heureusement pour vous, l’OAT est concu pour vous accompagner sur un certain nombre de diagnostics en regard de ces pré-requis.

Par exemple, lors de l’import de nouvelles machines, l’OAT controle automatiquement que cette machine distante est bien capable de communiquer, que ce soit avec l’OAT ou l’OVS.

Premier niveau de vérification

Vérifiez que la connectivité est OK entre tous les composants

Entre votre PC d’admin et l’OVS

Commencez par un simple ping …

ping <OVS_HOSTNAME>


Si c’est OK, alors lancez une session SSH (via putty ou autre) vers l’OVS.

Entre votre PC d’admin et l’équipement à superviser

Ici, tout dépend de la nature de l’équipement à atteindre. Actif ou passif, pingable ou pas … up to you … ;o)

Entre l’équipement à superviser et l’OVS

Idem.

Si votre équipement ne sait pas joindre l’OVS, il est possible/probable que l’OVS ne soit pas enregistré au niveau de votre DNS. Dans ce cas, vous devrez permettre à cet équipement de résoudre son nom (via fichier .hosts)

Entre l’OVS et l’équipement à superviser

Idem

Contrôlez l’état de l’OVS

Depuis la console de l’OVS, tapez la commande :

overmon status


Lorsque tout se passe bien, vous obtenez l’écran suivant :

Les informations retournées sont multiples :

  • Hostname
  • IP
  • Etat des processus
  • Etat des satellites (OVP)

A partir du moment ou l’un de ces composants est en KO, il est inutile d’aller plus loin : vous devez traiter l’erreur.

Traiter certains messages d’erreurs particuliers

Il arrive que la commande 

overmon status

retourne des messages d’erreurs spécifiques :

  • You have to register <OVS HOSTNAME> in your DNS : Ce message vous indique que vous n’avez pas déclarer votre OVS au niveau de votre serveur DNS. Vous devez prendre en compte cette remarque. Autant sur une plateforme de test, il est possible de s’en dispenser en passant par des inscriptions en dur dans les fichiers hosts de vos machines, autant, en environnement de production, avec des centaines de machines, cela n’est pas envisageable. 
  • <OVS HOSTNAME> in your DNS is not a real OVS : Ce message vous indique qu’une machine dont le nom correspond à l’OVS est bien présente. Par contre il semble que cette machine ne soit pas un OVS.
  • <OVS HOSTNAME> miss web access : Ce message vous indique que votre OVS ne peut pas accéder à Internet. Cela n’est pas bloquant en soi. Simplement, vous ne pourrez envisager d’upgrade via git, ou d’update système (apt-get update)

Erreurs communes

Lorsque je génère les fichiers de conf à partir de Centreon, ils ne sont pas copiés automatiquement vers les satellites

Connectez vous sur l’OVS, en tant que user centreon. Puis tentez de vous connecter en ssh vers chacun de vos satellites. A chaque fois qu’on vous demande « The authenticity of host … », tapez yes

Au lancement de l’OAT, j’obtiens un message d’erreur : « Votre installation actuelle dispose de plusieurs satellites Nagios. Et vous ne disposez pas d’une licence de type ‘Overmon Unlimited' »

Ce message apparait lorsque votre installation actuelle de Overmon n’est pas confirme à la clé de licence dont vous disposez. Lorsque ce message apparait, l’OAT se ferme. A ce moment là, allez dans le sous-répertoire de l’OAT nommé « Logs », et ouvrez le fichier de log de l’OAT, nommé OvermonAdminTools.log.

La première ligne de ce fichier contient votre UUID.

Récupérez cet UUID, puis renseignez le formulaire disponible à l’adresse : http://www.overmon.fr/demande-de-cle/

Vous recevrez votre clé sous 24H, et sous réserve que vous ayez acquis la licence correspondante au préalable.