Raphaël SurcouF a écrit 2609 commentaires

Aurais-tu un lien précis concernant ce projet ?

En effet, ce serait effectivement plus simple ;-)
Si tu es le Julio auquel je pense, j'ai bien vu que Romain avait résolu normalement plusieurs de mes bogues déjà ouverts mais je n'ai pas trouvé les modifications dans le cvs...
Vivement la 1.3-RC1 que je vois tout ça ! ;-)

La version actuellement en developpement revient sur bon nombre de limitations et s'en affranchi. Ainsi, les templates de templates deviennent possible, il en est de même du rattachement de services à des hostgroups.

Comme je le disais, j'ai vu les confirmations de mes bogues mais pas encore dans le cvs. J'attends donc ces modifications avec impatience pour pouvoir confirmer les corrections apportées.

Concernant tes idées d'améliorations, je t'invite à les partager avec eux par le biais de leur forum. Il sont effectivement très ouverts.

Je ne manque jamais une occasion de partager mes idées avec eux, juste le temps de formuler mes requêtes. ;-)

En tout cas, merci pour toutes tes précisions.

- gestion de "MetaServices" (services aggrégeant les données d'autres services)

Peux-tu être plus précis ?

Ce qui me gêne davantage dans Oreon, pour l'avoir déployé chez de nombreux clients, ce n'est certainement pas le support de Nagios 2.
Encore qu'on peut se demander s'il le supporte car il pose la question de la version de Nagios dès l'installation.
Bien que de récentes réponses à des bogues que j'ai ouvert sur leur flyspray semblent avoir trouvé une issue, je n'ai pas encore vu leur application dans le cvs actuel. Et c'est ce manque de support presque complet de Nagios 1.x que je trouve gênant. Bien sûr, Oreon remplit très bien son rôle d'interface de configuration, évitant à des profanes d'éditer les fichiers de configuration de Nagios. Je regrette surtout que le développement soit trop proche de ces fichiers de configuration.
Sans doute aurait-il été plus pertinent d'en faire abstraction et de penser à faciliter la saisie des divers objets de la configuration, comme par exemple, ne pas dissocier les hôtes et les extensions d'hôtes (de même pour les services).
Et sur ce plan-là, Oreon ne facilite guère cette saisie. Il y a bien la duplication des hôtes, fonctionnalité qu'on avait demandé et merci beaucoup d'ailleurs. Mais je regrette certaines fonctionnalités qu'offre Nagios 1.x et que ne permette plus Oreon ! Surtout quand il s'agit de fonctionnalités qui ne sont pas insignifiantes, comme associer un service à un groupe d'hôtes ou créer un modèle à partir d'un autre modèle (quand on peut créer un modèle pour un objet, car tous les objets ne peuvent pas avoir de modèles alors que Nagios offre ces fonctionnalités...). Il s'agit là pourtant de fonctionnalités qui permettent justement de réduire, de simplifier la saisie... En fait, pour être honnête, je me suis souvent demandé si les développeurs d'Oreon connaissaient bien Nagios.
Et j'ai bien d'autres idées à développer à ce sujet, comme l'intégration de SNMPtt pour gérer les traps ou un meilleur support des options des plugins pour éviter que les profanes ne soient rebutés par cette phase de configuration.
Maintenant, je dois avouer que leur produit s'améliore et que l'équipe est ouverte aux suggestions et j'admet que ce n'est pas facile de développer une telle application. Les critiques sont faciles, l'art est difficile, comme on dit.

Donc, le support de Nagios 2.0 n'est pas la priorité pour moi, d'autant que pas mal de fonctionnalités changent, de nouvelles apparaissent et qu'il faudrait déjà valider cette version avant de pouvoir la déployer. Non, ce qui compte, c'est qu'Oreon supporte davantage et correctement Nagios 1.x, déjà, car ça profitera tout naturellement à Nagios 2.x.

Le lien vers le Changelog est intéressant mais n'est pas capital pour savoir ce qui a *vraiment* changé entre les versions 1.x et cette nouvelle mouture. Le lien suivant donne un meilleur état des lieux :

http://nagios.sourceforge.net/docs/2_0/whatsnew.html

dont l'url est :
http://www.oreon-project.org/

Le support SQL original a été enlevé mais il existe déjà un autre support pour Nagios 2.x. grâce au projet Nagios-DB[1].

[1]: http://sourceforge.net/projects/nagios-db/

Oui mais on ne peut pas parler exactement de concurrence puisqu'ils sont complémentaires.

Je travail actuellement sur un projet hébergé sur 16 instances weblogic. Parfois, lors de la création d'un compte, on a une page d'erreur. Ca arrive TRES rarement, et les utilisateurs ne nous ont jamais donné les informations necessaires pour identifier le serveur. Grace à ce genre d'outil, on va pouvoir faire tourner la création de compte toute la nuit, et on aura plus qu'à regarder l'heure de plantage. apres, sur chacun des serveur, regarder dans le log à l'heure indiquée.

Sans doute conviendra-t-il alors, si le test n'est toujours pas concluant, de le rejouer aux heures normalement ouvrées parce que la nuit, l'utilisation des ressources peut-être sensiblement différente (sauvegardes, moins d'utilisateurs, etc.).

Je vois. En fait, je suis à la recherche d'un outil me permettant d'enregistrer des "scénarios" comme le permet Seleniume IDE mais aussi LiveHTTPHeaders (bien que ça n'enregistre que les entêtes) et à même de rédiger les fichiers de configuration (en XML) pour WebInject (ou, à la rigueur, tout autre outil du même genre permettant de remonter une alerte à nagios).
Tout ce qu'il me manque jusqu'à présent, c'est l'outil qui saura convertir les requêtes HTTP en fichiers de configuration XML (et du temps aussi).
Etant donné que Selenium IDE permettait manifestement d'enregistrer au format HTML, je me demandais si c'était possible d'en faire autant en XML, les langages de descriptions étant sensiblement assez proches, àmha.

Une sauvegarde en XML serait intéressante pour le ré-injecter dans webinject[1] et réaliser ainsi des tests applicatifs. En effet, dans mon cadre (supervision avec nagios), la dépendance forte sur un navigateur n'est pas souhaitable...
Visiblement, on peut écrire de nouvelles fonctions pour la sauvegarde, ce serait donc possible.

[1]: http://www.webinject.org/
--
Raphaël 'SurcouF' Bordet

Et le jour où tu as besoin du paquet XYZ, tu te prends la mise à jour de toute la distribution dans la gueule parce que ce dernier dépend de la bibliothèque ABC qui n'est pas à jour sur ton installation...
De toutes façons, c'est une gestion quotidienne bien plus complexe qu'avec une version stable.

D'autant plus que la version stable d'Ubuntu propose justement les fameuses versions des logiciels sus-cités.
Maintenant, Firefox, OOo ou Xorg sont sans doute plus discutable dans le choix d'un serveur...

Rien que le besoin de nouveaux paquets est un dilemme en soi.
Dans un cycle normal de production, il y a toujours une phase d'intégration et une phase de validation. Debian correspond très bien à ce type de critère. Il y a donc de fortes chances que le besoin de PHP5 ne corresponde pas non plus vraiment à des architectures vraiment critiques. Après, la plupart des applications Java tournent encore avec des jvm 1.4 pour les plus à jour. Et pourtant, l'arrivée de JMX dans la 1.5 facilite grandement la supervision de telles applications...

Sans doute serait-il pertinent que les grands noms des Logiciels Libres suivent tous l'exemple de Gnome, avec une sortie assez régulière pour qu'une distribution puisse se caler sur le calendrier d'un ou deux logiciels qui occupent une place importante dans ses choix. L'exemple d'Ubuntu est assez éloquent.

Il s'agit en effet du second cas et j'ai bien vu que la recherche sur ces sites pouvait poser problème... Au temps pour moi ;-)

- La casse dans la recherche de noms de films :
La première recherche que j'ai fais, "Le Grand Bleu" n'a pas trouvé d'échos sur les premiers sur lesquels j'avais recherché. En fait, il fallait chercher "Le Grand bleu"...

- Les accents et autres caractères bien français :
Je ne sais pas si c'est l'UTF-8 qui lui a joué des tours mais "La rançon", il n'a pas trouvé, il pédalait plutôt dans la semoule. Par contre, avec "La rancon", il a retrouvé le bon film.

Irssi supporte, via des plugins, ce protocole ainsi qu'ICQ.
http://irssi.org/?page=plugins

Oui, c'est d'autant plus dommage qu'il y a déjà eu deux essais pour faire une interface GTK+, irssi-gtk et xirssi.
C'est vrai qu'il aurait été sans doute plus profitable d'ajouter d'autres plugins pour ajouter des fonctionnalités à cette base mais sans doute que la première motivation de l'auteur était avant tout d'apprendre à écrire son client IRC de A à Z. On peut le déplorer mais c'est son choix.

Dire qu'irssi peut se voir ajouter ce genre de listes à l'aide d'un simple script:
http://wouter.coekaerts.be/site/irssi/nicklist

Beaucoup de fonctionnalités de ce genre sont gérées de façon externe. C'est voulu par l'auteur même d'irssi.

Et les sources du Mandriva Club, elles sont où ?
Launchpad n'est pas un logiciel destiné à être distribué, que je sache.
Cela n'enlève en aucune manière la qualité d'Ubuntu comme distribution Linux libre.

Et aussi, Mandriva ose tester des nouvelles technos avant les autres donc forcément elle essuie les platres. Et forcément parfois ça marche pas comme il faut dès le départ.

Heu, quelles "nouvelles technologies" ?
Faudrait pas se foutre de la gueule du monde là, quand même.
Les utilisateurs sont en droit d'attendre une distribution relativement stable quand elle sort. Pour tester les nouveautés pas toujours stables, j'aurais pensé que Cooker servait justement de garde-fou...

Sauf que Canonical sponsorise Ubuntu en employant des développeurs de Debian et de Gnome.
Si par malheur, Canonical venait à disparaître, la Fondation Ubuntu a plus de chances de rester encore debout.

Pour des applis grand public faudra qu'on m'explique quel service on peut vendre, etant donne que le soft est gratuit (et meme si l'auteur ne fait que vendre le binaire yaura toujours un connard pour redistribuer le binaire/sources gratos) et que pour du grand public on est cense faire un produit qui marche out of the box sans aide.
Donc a moins de faire des produits inutilisables sans l'aide des dev (et donc enfermer les utilisateurs dans un support), je vois pas comment faire du pognon avec.

Note que la question se pose autant pour les logiciels propriétaires et que la plupart d'entre-eux sont devenus aussi relativement gratuits.
Bien sûr, il y aurait "l'exception" Windows mais le Grand Public, le vrai, n'a aucune idée du coût réel de Windows puisqu'il est toujours fourni en complément d'un autre produit bien connu: l'ordinateur.
Il y a longtemps que pour cette cible marketing, le logiciel est devenu un complément plus qu'un produit en lui-même.

Ce cybercafé d’un genre nouveau vous permet de surfer sur l'Internet, imprimer , scanner, discuter, jouer, et bien entendu découvrir le monde du libre grâce à des formations et des forfaits "découvertes".

Pour rassembler un plus grand nombre, le responsable annonce que les étudiants et les chômeurs se verront offrir 15 minutes de connexion gratuite.

Neptune Internet Services proposait déjà ce genre de choses à Grenoble, et ce, dès 1995... Le concept n'a donc RIEN de nouveau !
Je rejoins donc les précédents commentaires sur le sujet et j'ajouterais aussi qu'on aimerait bien voir les sources du logiciel de décompte du temps (pas forcément sous GPL mais qu'il soit libre comme c'est écrit sur la brochure).
En outre, je précise que monter un tel commerce de nos jours n'a plus rien d'un exploit, avec Ubuntu ou Mandriva... Il y a 10 ans, c'était une toute autre paire de manche : pour ceux qui n'en étaient pas, à l'époque on n'avait pas encore KDE, Gnome, etc.. Il fallait présenter Afterstep puis Windows Maker aux clients (clients soit-disant lambda qui n'y trouvaient rien à redire et ne réclamaient pas un sempiternel Windows).

Oui mais tous les RPMs sont loin d'être sous le coup de la GPL...
La GPL t'oblige (et oblige aussi RedHat) à fournir les sources des logiciels placés sous cette licence que tu fournis à ton client, sous forme binaire.
En aucun cas, elle ne précise de les publier plus largement.
Toutefois, RedHat fournit librement les sources de ses RPMs, ce qui a permis à des distributions dérivées proches de RedHat d'exister.
Maintenant, le principal argument de vente d'une RedHat est son support. Si vous supprimez l'avantage lié au support, je ne vois plus l'intérêt de prendre RedHat. Autant prendre une Debian ou une Fedora. Les coûts liés au support RedHat sont dérisoires en comparaison d'autres logiciels, certes, propriétaires. On pourrait comparer avec Oracle : le logiciel en lui-même est librement accessible via le Réseau des réseaux mais il faut souscrire un contrat de support mirobolant si jamais on souhaite déployer une base de données dans un environnement de production. Et je ne parle même pas des formations pour apprendre à l'installer correctement...

Normalement, pour avoir droit de faire des mises à jour, il faut souscrire un abonnement à RHN par machine. Chaque machine nécessitant une mise à jour (comprenant le support de RedHat) doit être enregistrée à l'aide de la commande up2date.
Je ne pense pas que, d'un point de vue légal, tu puisses librement re-distribuer les paquets binaires ainsi installés sur d'autres machines à moins qu'elles ne soient elles-même dûment enregistrées sur RHN.
Sans doute vaudrait-il mieux de poser la question directement à RedHat, non ?