Introduction

Les hôtes générés ne sont pas visibles dans l'interface de Configuration

Lorsque l'addon "nagvis-shinken-architecture" génère la visualisation de l'architecture, des hôtes sont également créés ou modifiés dans l'interface de Configuration.

Ces hôtes sont donc visibles en tant que Nouveaux ou en tant que Différences sur des hôtes Shinken existants. Les données de ces hôtes sont importées par la source listener-shinken.

Si dans cette source, les données des hôtes sont effacées (grâce au balai), les éléments en Nouveau et Différence ne sont plus présents dans l'interface de Configuration. On peut obtenir le même problème si les hôtes n'ont pas pu être envoyés à l'interface de Configuration à cause d'une erreur réseau par exemple.

Il faut alors déclencher un nouvel export de l'architecture pour que les informations des hôtes utilisés soient à nouveau disponibles dans l'interface de Configuration. Pour cela, il faut s'assurer que l'addon "nagvis-shinken-architecture" soit activé (avec les commandes d'Activation/désactivation des addons), puis redémarrer l'Arbiter.

/etc/init.d/shinken arbiter restart

Restrictions sur le nom de l'architecture

Lors de la configuration du module 'architecture-export', il est possible de modifier le nom de l'architecture.

Puisque le nom de l'architecture est également présent dans le nom des hôtes générés dans l'interface de Configuration, tous les caractères ne sont pas autorisés dans le nom de l'architecture.

Les restrictions de caractères sont les mêmes que pour les noms d'hôtes, à savoir:

• Les caractères 

  ~!$%^&"'|<>?,()=/+

  sont interdits dans un nom d'architecture.

Si ces caractères sont présents dans le nom de l'architecture, l'addon "nagvis-shinken-architecture" ne sera pas capable de générer les hôtes nécessaires et le statut des démons ne pourra jamais être affiché dans les cartes représentatives de l'architecture.

Impossible de se connecter à NagVis

Depuis l'interface de Visualisation, lorsqu'on veut accéder à la visualisation de l'architecture Shinken, on est redirigé vers NagVis, qui va ensuite nous afficher la carte correspondante.

Dans l'instance de NagVis installée par l'installeur Shinken Entreprise, l'authentification est liée avec Shinken, ce qui la rend automatique et ne requiert pas une authentification supplémentaire de la part de l'utilisateur.

Une impossibilité de se connecter à NagVis peut donc avoir plusieurs causes:

Le Broker et l'interface de Visualisation à utiliser pour l'authentification sont mal configurés

Pour autoriser l'authentification avec un utilisateur Shinken, NagVis communique avec l'interface de Visualisation. Si la liaison avec l'interface de Visualisation n'est pas correcte, il n'est pas possible de se connecter dans NagVis.

L'interface de Visualisation utilisée pour l'authentification est par défaut le backend Livestatus configuré dans NagVis, initialement défini comme le Broker présent sur la machine de l'Arbiter (127.0.0.1). Le port utilisé ainsi que le protocole sont également ceux par défaut (respectivement 7767 et http).

Si les paramètres de l'interface de Visualisation ont été modifiés, il faut indiquer à NagVis les paramètres à utiliser pour la contacter.

Les paramètres à modifier sont les suivants:

; Protocol to use when authenticating with Shinken (http or https) when using the CoreAuthModShinken authentication module
shinken_auth_protocol="https"
; Port of broker webui
shinken_auth_port=1234
; Address of broker webui. If not specified, address of default backend is used instead
shinken_auth_address="10.1.2.3"

Ces paramètres sont modifiables graphiquement dans l'interface de NagVis ou bien dans le fichier de configuration de NagVis (/etc/shinken/external/nagvis/etc/nagvis.ini.php).

Le Broker et/ou l'interface de Visualisation ne sont pas joignables

Si les paramètres de connexion à l'interface de Visualisation sont corrects, il est alors possible que cette interface ne soit pas joignable. Il peut s'agit d'un problème réseau (routage, firewall), ou bien simplement que le Broker n'est pas opérationnel.

Le statut du Broker et de l'interface de Visualisation peuvent être vérifiés avec le Shinken-healthcheck.

L'utilisateur qui demande la connexion n'est pas un administrateur Shinken 

Par défaut, la connexion des utilisateur non administrateurs Shinken est refusée. Pour autoriser les utilisateurs autres que les administrateurs Shinken à se connecter à NagVis, il faut modifier le paramètre "shinken_auth_restrict_to_shinken_admin":

; Authorize authentication into NagVis to Shinken administrators only
shinken_auth_restrict_to_shinken_admin=0

Dans le cas de l'authentification par en-tête HTTP, la configuration de l'authentification SSO ne correspond pas entre NagVis et Shinken.

Lorsque l'Authentification unique (SSO) est utilisée dans Shinken, il est possible de tirer avantage de cette fonctionnalité afin de l'appliquer également à NagVis. Si cette authentification par en-tête HTTP ne fonctionne pas dans NagVis pour connecter l'utilisateur automatiquement, il faut d'abord vérifier que ce mécanisme est bien configuré dans NagVis ET dans Shinken. Les points suivants sont à contrôler pour assurer l'authentification par SSO dans NagVis en liaision avec Shinken:

• Lorsque NagVis reçoit une requête avec en-tête HTTP, il vérifie auprès de Shinken si l'utilisateur fournit dans cet en-tête est un utilisateur existant. Il est donc nécessaire que l'interface de Visualisation à contacter soit joignable et correctement configurée dans NagVis (voir sections précédentes)
• Dans Shinken, il faut que l'authentification SSO soit activée dans le Broker (voir la documentation associée: Authentification unique (SSO))

• Dans NagVis, il faut que l'en-tête utilisé soit le même que celui définit dans Shinken pour le Broker.
  Pour utiliser l'authentification par en-tête HTTP dans NagVis, il faut définir le nom de l'en-tête à utiliser:

  ; This value must be the same as the one configured in Shinken. An empty value means authentication by http header is disabled. shinken_auth_remote_user_variable="X-Forwarded-User"

  Il faut que le paramètre "shinken_auth_remote_user_variable" de NagVis soit le même que le paramètre "remote_user_variable" du module webui dans Shinken.

L'authentification automatique entre Shinken et NagVis ne fonctionne pas

Avec la configuration effectuée par l'installeur Shinken Entreprise, on est automatiquement connecté dans NagVis lorsqu'on est connecté sur l'interface de Visualisation.

Pour authentifier automatiquement l'utilisateur, NagVis vérifie auprès de l'interface de Visualisation si il est connecté. Si c'est le cas, l'utilisateur sera automatiquement connecté dans NagVis.

Il se peut que cette authentification automatique ne fonctionne pas si NagVis n'arrive pas à obtenir les informations de connexion à l'interface de Visualisation. C'est le cas lorsque NagVis et l'interface de visualisation ne sont pas sur le même domaine.

Par exemple, l'adresse de l'Arbiter est une adresse IP, alors que l'interface de Visualisation est accédée via le nom DNS de cette adresse (exemple 127.0.0.1 et localhost).

Pour que l'authentification à l'interface de Visualisation soit partagée entre NagVis et Shinken, il faut que l'adresse d'accès soit identique entre l'interface de Visualisation et NagVis.

Dates incorrectes sur Nagvis

Si vous avez un décalage de temps entre votre serveur Shinken et les dates affichées dans Nagvis, éditez votre fichier php.ini  pour configurer votre Timezone :

date.timezone = Europe/Paris

Puis redémarrez le serveur Web :

service httpd restart

Supprimer des architectures générées

Il peut arriver que certaines architectures générées par l'addon doivent être supprimées. C'est par exemple le cas lorsqu'une architecture de test à été générée, ou alors l'architecture d'une installation Shinken qui n'existe plus.

Il faut alors supprimer ces entrées pour qu'elles n'apparaissent plus dans NagVis ainsi que dans la liste des architectures dans l'interface de Visualisation.

Cette suppression se fait en 2 étapes:

• Suppression des liens dans l'interface de Visualisation
• Suppression des cartes NagVis

Suppression des liens dans l'interface de Visualisation

Etape 1: Eteindre l'Arbiter

Etape 2: Supprimer les entrées voulues dans /var/lib/shinken/architecture_export_received.json

Ce fichier contient la liste des liens présentés dans l'interface de Visualisation au format JSON. Si vous désirez supprimer toutes les architecture générées, supprimez le fichier et passez à l'étape suivante.

Sinon, il faut éditer le fichier pour supprimer les liens non voulus. Ce fichier se présente sous la forme suivante:

{
    "a30addd4-a940-4313-81f0-60c15db9a56f": {
        "arch_map": {
            "name": "architecture_export.global_map_name",
            "url": "http://localhost/shinken-core-map/frontend/nagvis-js/index.php?mod=Map&show=shinken_architecture-a30addd4-a940-4313-81f0-60c15db9a56f"
        },
        "name": "Shinken-local_02_06",
        "tree_map": {
            "name": "architecture_export.tree_map_name",
            "url": "http://localhost/shinken-core-map/frontend/nagvis-js/index.php?mod=Map&show=shinken_global-a30addd4-a940-4313-81f0-60c15db9a56f"
        }
    },
    "id_2": {
        "arch_map": {
            "name": "architecture_export.global_map_name",
            "url": "http://localhost/shinken-core-map/frontend/nagvis-js/index.php?mod=Map&show=shinken_architecture-id_2"
        },
        "name": "Architecture 2 à supprimer",
        "tree_map": {
            "name": "architecture_export.tree_map_name",
            "url": "http://localhost/shinken-core-map/frontend/nagvis-js/index.php?mod=Map&show=shinken_global-id_2"
        }
    }
}

On a d'après la configuration précédente 2 architectures, nommées respectivement "Shinken-local_02_06" et "Architecture 2 à supprimer".

Supposons qu'on veuille supprimer l'architecture nommée "Architecture 2 à supprimer":

• Il faut retenir l'identifiant de l'architecture à supprimer. Dans ce cas l'identifiant est "id_2"
• On supprime ensuite la section correspondante à l'architecture à supprimer.

Le fichier après suppression de la section correspondante à l'architecture "Architecture 2 à supprimer" est de la forme suivante:

{
    "a30addd4-a940-4313-81f0-60c15db9a56f": {
        "arch_map": {
            "name": "architecture_export.global_map_name",
            "url": "http://localhost/shinken-core-map/frontend/nagvis-js/index.php?mod=Map&show=shinken_architecture-a30addd4-a940-4313-81f0-60c15db9a56f"
        },
        "name": "Shinken-local_02_06",
        "tree_map": {
            "name": "architecture_export.tree_map_name",
            "url": "http://localhost/shinken-core-map/frontend/nagvis-js/index.php?mod=Map&show=shinken_global-a30addd4-a940-4313-81f0-60c15db9a56f"
        }
    }
}

Etape 3: Redémarrer l'Arbiter

Suppression des cartes NagVis

L'interface des cartes NagVis est en lecture seule pour empêcher la suppression de cartes générées automatiquement qui nécessitent un redémarrage complet de l'Arbiter pour être recréées.

Lorsqu'on veut supprimer une architecture, il faut supprimer les cartes NagVis en plus du lien présent dans l'interface de Visualisation. La suppression de ces cartes est optionnelle.

Pour supprimer les cartes, il faut d'abord retenir l'identifiant de l'architecture trouvé dans le fichier /var/lib/shinken/architecture_export_received.json. Une fois cet identifiant en main,

on peut supprimer les fichiers suivants:

• /etc/shinken/external/nagvis/etc/maps/*<identifiant>.cfg

• /etc/shinken/external/nagvis/etc/conf.d/rotation_shinken_<identifiant>.cfg