sondes

[manu]

Bonjour,

dans Options/Sondes, j'ai bien la liste de toutes mes sondes. Par contre lorsque j'essaie de configurer un service, je ne retrouve pas ces sondes ....

Savez-vous d'où ça peut provenir ?

merci pour votre aide !

[surcouf]

Re: sondes

Bonjour,

dans Options/Sondes, j'ai bien la liste de toutes mes sondes. Par contre lorsque j'essaie de configurer un service, je ne retrouve pas ces sondes ....

Savez-vous d'où ça peut provenir ?

Oui: il faut d'abord définir une commande utilisant la dite sonde.
C'est cette commande qu'on associe ensuite au service.

[manu]

merci pour l'info

et command définit-on cette commande ?

[surcouf]

merci pour l'info

et command définit-on cette commande ?

Il faut bien avouer qu'Oreon n'est pas d'une grande aide par rapport à cela.
Je te rapproche donc de la documentation officielle de Nagios pour ce faire :
http://nagios.sourceforge.net/docs/1...e.html#command

En effet, sous Oreon, il faut définir la ligne de commande à utiliser avec les macros nécessaires comme on le ferait dans le fichier checkcommands.cfg.
Ainsi, il te faudra remplir dans le formulaire, la ligne correspondant à la directive "command_line" d'une définition "command" de Nagios.
Quant aux macros utilisables, en voici la liste exhaustive en fonction du contexte : http://nagios.sourceforge.net/docs/1_0/macros.html
Les plus importantes et utiles étant :

- $HOSTADDRESS$, qui permet de rappeller l'adresse IP de l'hôte auquel le service est associé ;
- $USERn$, avec n compris entre 1 et 32, qui permet d'utiliser des variables utilisateurs pré-définies (dans l'onglet "Options" d'Oreon, partie ressource.cfg). Par défaut et convention, $USER1$ sert notamment à définir le répertoire des sondes ;
- $ARGn$, avec n compris entre 1 et 32, qui permet d'utiliser des arguments librement modifiables. Ces arguments sont à modifier depuis les définitions de services. Évidemment, on peut penser qu'il s'agit des arguments mais on peut s'en servir pour remplacer n'importe quelle chaîne de caractères (sauf ceux qui sont explicitement interdits par le fichier nagios.cfg, voir aussi l'onglet "Options" d'Oreon, tout en bas).

J'avais déjà dit dans un autre fil qu'il faudrait sans doute améliorer cette partie d'Oreon car elle est rebutante pour le débutant. Le tout est encore d'arriver à formuler les besoins exacts. ;-)

[manu]

ok !

merci beaucoup pour l'info et la rapidité de réponse

[julio]

oauis oauis mais bon oreon ne va pas tout faire non plus. Il faut se former... le top serait deja d'avoir une belle doc. une fois qu'on a compris c quand meme relativement simple.

Tous les produits doivent etre maitrisés et cela me parait franchement tres dur d'utiliser oreon sans connaitre la moindre chose a propos de nagios. tous les softs ont leurs spécificités...

Apres si vous avez des idées pour améliorer pourkoi pas....

[surcouf]

oauis oauis mais bon oreon ne va pas tout faire non plus. Il faut se former... le top serait deja d'avoir une belle doc. une fois qu'on a compris c quand meme relativement simple.

Tous les produits doivent etre maitrisés et cela me parait franchement tres dur d'utiliser oreon sans connaitre la moindre chose a propos de nagios. tous les softs ont leurs spécificités...

Oui mais si c'est pour n'avoir aucune valeur ajoutée par rapport à l'édition en ligne de commande, ça ne sert à rien...
Pire, pour l'heure (parce que je n'ai pas encore vu les toutes dernières versions), on y perd même en flexibilité, par rapport à la ligne de commande...
Cela étant, il y a quand même des fonctionnalités très intéressantes, comme la duplication des hôtes, qui mériterait d'ailleurs d'être étendue aux autres objets, ou l'activation/désactivation d'un objet.

Apres si vous avez des idées pour améliorer pourkoi pas....

L'idée générale serait de parser la sortie des plugins en les exécutant avec l'option --help et de récupérer la liste des options disponibles avec leurs définitions, un peu comme l'utilitaire help2man génère des manuels.
Ainsi, il serait possible de proposer les options lors de l'édition d'une commande au lieu de devoir la taper entièrement soi-même.
Tout comme il serait possible de détecter les répertoires fournissant des plugins parmi les variables utilisateurs ($USERn$) afin de proposer directement leurs plugins sans se préoccuper de savoir où ils sont.

Mes 0,02¤

[julio]

Oui mais si c'est pour n'avoir aucune valeur ajoutée par rapport à l'édition en ligne de commande, ça ne sert à rien...
Pire, pour l'heure (parce que je n'ai pas encore vu les toutes dernières versions), on y perd même en flexibilité, par rapport à la ligne de commande...

desinstalle oreon alors... on est desolé pour toi... enfin pour une fois c bien tu le fais sur le forum oreon et non sur linuxFR

Cela étant, il y a quand même des fonctionnalités très intéressantes, comme la duplication des hôtes, qui mériterait d'ailleurs d'être étendue aux autres objets, ou l'activation/désactivation d'un objet.

Je vais le repeter mais je pense que cela sera la derniere fois, tu pourra desactiver tout ce que tu voudra dans la 1.3, tu pourra meme faire n fichiers nagios.cfg et activer celui que tu voudra (un seul a la fois).

L'idée générale serait de parser la sortie des plugins en les exécutant avec l'option --help et de récupérer la liste des options disponibles avec leurs définitions, un peu comme l'utilitaire help2man génère des manuels.

oauis a voir ca.... il faut que tout le monde soit sur une meme charte... sinon c le bordel.

Ainsi, il serait possible de proposer les options lors de l'édition d'une commande au lieu de devoir la taper entièrement soi-même.
Tout comme il serait possible de détecter les répertoires fournissant des plugins parmi les variables utilisateurs ($USERn$) afin de proposer directement leurs plugins sans se préoccuper de savoir où ils sont.

nous examinons cela.. mais normalement ca sera ok pour la 1.3.

Le pb est que nous n'avons pas autant de mains que nous le voudrions. Nous essayons de faire du mieux que l'on peut. Mais a l'avenir, si vous avez encore de bonnes idées, donnez les nous. ne gardez rien pour vous et surtout ne pas attendre que des modifications importantes soient realisées... vous etes au courant qu'on est dans une grosse phase de chantier et que c surement plus simple de rajouter des idees now que une fois que cela sera fait

Je rapelle, par la meme occasion, que ce projet est open et open source, tout le monde peut participer.

A bon entendeur...

[surcouf]

Cela étant, il y a quand même des fonctionnalités très intéressantes, comme la duplication des hôtes, qui mériterait d'ailleurs d'être étendue aux autres objets, ou l'activation/désactivation d'un objet.

Je vais le repeter mais je pense que cela sera la derniere fois, tu pourra desactiver tout ce que tu voudra dans la 1.3, tu pourra meme faire n fichiers nagios.cfg et activer celui que tu voudra (un seul a la fois).

Je n'ai pas mis en doute ces fonctionnalités, je les énumère comme étant justement de la valeur ajoutée par Oreon.

L'idée générale serait de parser la sortie des plugins en les exécutant avec l'option --help et de récupérer la liste des options disponibles avec leurs définitions, un peu comme l'utilitaire help2man génère des manuels.

oauis a voir ca.... il faut que tout le monde soit sur une meme charte... sinon c le bordel.

En effet, mais on n'a pas besoin d'une "charte" pour une seule option obligatoire. Cette même option est la seule définie par les NPDG (Nagios Plug-in Developement Guideline) qui devrait être toujours présente, à minima. Le but est justement de découvrir les autres options.

Ainsi, il serait possible de proposer les options lors de l'édition d'une commande au lieu de devoir la taper entièrement soi-même.
Tout comme il serait possible de détecter les répertoires fournissant des plugins parmi les variables utilisateurs ($USERn$) afin de proposer directement leurs plugins sans se préoccuper de savoir où ils sont.

nous examinons cela.. mais normalement ca sera ok pour la 1.3.

Le pb est que nous n'avons pas autant de mains que nous le voudrions. Nous essayons de faire du mieux que l'on peut. Mais a l'avenir, si vous avez encore de bonnes idées, donnez les nous. ne gardez rien pour vous et je rapelle que ce projet est open et open source, tout le monde peut participer.

J'entends bien mais je n'ai toujours pas vu les modifications des bogues clôturés dans le CVS. Un problème de synchro ?

[julio]

c'est déja dit et redit... si je commit, tu ne pourra rien en faire... arbo compeletement #, DB aussi, et le code est diferent... ca sera pas un simple remplacement de fichiers. Si ca avait été possible nous l'aurions fait.

Et crois moi, on a pas fermé les posts pour rigoler. attend encore un peu.