Jean Gabes a écrit 497 commentaires

Ca allège le soucis oui, mais c'est loin de régler correctement la maintenance. C'est ce qu'on fait dans les outils genre Nagios ou Shinken par exemple, la notion de groupes de contacts (aka ~profile). Mais ça reste très complexe quand tu as plusieurs milliers d'équipements sur X datacenters chacun avec ses équipes, et donc les éléments ont des métriques qui ne doivent être vue que par une partie des équipes (genre le infos systèmes par les sysadmin, les métriques oracle par les dba, etc etc).

Donc le mapping est vraiment d'un ordre de grandeur monstrueux si tu veux le maintenir à la main (infaisable dans les faits sur de grosses infras). Tu as donc aussi besoin de profile/groupe sur tous tes éléments (que ce soit les serveurs, c'est presque "facile", mais aussi sur tous les métriques qu'ils ont, et là c'est chaud).

Pour l'avoir géré dans Shinken (groupes, héritages de templates and co), je les comprends parfaitement de ne PAS s’embêter avec ça. Quand on voit que malgré ce manque énorme les outil sont quand même déployés chez de gros utilisateurs, tu relativise beaucoup l'importance de l'énormité du manque en fait :p

Tout à fait juste.

En gros la partie chiffrement et auth doit être gérée par un élément tiers, mais si l'appli reçoit comme information l’identité (vérifiée) alors elle doit l'appliquer comme un filtre supplémentaire.

Le vrai soucis c'est pas trop de ce côté de la connexion en fait, car ça se fait assez bien peu importe le backend http utilisé. Mais ce qui est vraiment problématique pour les concepteurs c'est que ceci signifie qu'il faut avoir un mapping user<->objets, et ça à définir/maintenir c'est déjà rude d'un point de vue conceptuel, mais en plus ça va demander sûrement la création d'une UI de configuration et gestion. Or c'est pas vendeur lors d'un test pour attirer l'utilisateur, donc ils préfèrent laisser ça à plus tard :)

J'avoue être du même avis. Toute les couches d'auth et de sécurisation devraient être factorisées plutôt que réimplémentées par chaque outil (avec ses failles potentielles). Quand on parle d'application web mettre un frontal pour gérer le https correctement est pas si mal par exemple, surtout que tu factorise tes connaissance et tes configurations entre les X outils, plutôt que voir comment on gère sur chacun.

On peut difficilement faire plus moche si c'est pour de la génération de graph, surtout que ça fait des images statiques, pas des graphiques dynamiques :p

Le meilleur que j'ai trouvé pour switcher depuis highchart c'est justement nvd3. De base son style est moche, mais bon doit y avoir moyen de backporter un thème potable.

Sinon il a même des features similaires à highstocks (avec la version réduite du graph sur le bas pour le "zoom"). Et là plus de soucis de licences :p

Ce projet a l'air très intéressant et déjà bien documenté, bravo :)

Mais (y a toujours un mais…) j'ai juste une question sur l'utilisation de la lib Highcharts pour les graphs. Si je ne m'abuse, cette lib n'est pas libre (cf www.highcharts.com/license) et gratuite que pour une utilisation non commerciale.

Les personnes non averties qu'elles ont besoin d'une licence Highcharts se retrouveraient donc dans l'illégalité s'ils présentent une UI facette à leur clients par exemple, même si Facette est en BSD.

Même si j'avoue que je suis aussi un grand fan de cette lib, est-ce que pour un outil libre, que l'on souhaite utilisable par tout le monde sans risque d'avocat and co, ne serait-il pas préférable de switcher vers un équivalent genre http://nvd3.org/ (avec un petit re-stylage car de base c'est moche…).

Bravo en tout cas pour le projet, ça donne envie d'aller creuser dans ses métriques :D

Si tu veux faire des requêtes de supervision le REST est tout à fait adapté, websocket certainement pas :)

Oui, quand ça impacte la compréhension, et donc le fond, je suis pour un rappel, hors de question d'arriver au langage SMS également (peu d'effort pour un qui écrit, mais beaucoup pour tous ceux qui lisent).

Mais comme tu dis la limite est pas facile à placer. Juste que là je crois que vu le nombre de commentaires autour de points de détails qui n'apportent rien au fond du sujet, un simple rappel des modérateurs sur le fait qu'aller trop loin dans ce sens est juste contre productif pour le bien de la communauté (on perds des membres, et le plus souvent les plus expérimentés qui ont autre chose à faire que passer leur temps sur un détail de forme).

J'ouvre un ticket dans le suivi donc :)

Remarque: les réponses à un commentaires en négatifs devaient peu être être mis en cachés eux aussi? Ca éviterait l'effet pavé et qu'on perde du temps sur un échange qui part sur du vent?

C'est juste. Mais j'ai la forte impression (peut être fausse) qu'on a de plus en plus le cas. Il est possible aussi que je fasse de plus en plus attention à ces posts qui ressemblent plus à des formules de rhétoriques qui pour son auteur est un moyen d'être visible et "avoir raison" sans trop avoir à réfléchir sur le fond.

Le système de notation aide, mais j'ai encore vu dernièrement des pavés énormes sur un point de détail sur un terme (je ne me souviens plus tellement ça ne m'intéressait pas).

J'encourage les modérateurs a être un peu lus ferme sur ce genre dérive ou au moins ouvrir le débat car mine de rien, et là encore c'est peu être juste une impression, on a de moins en moins de débat technique dans les commentaires. Or c'est bien pour ça qu'on vient sur le site, pas pour être sur un sous domaine de bescherelle.fr :)

Bon c'est la fin du passage vieux con qui couine, même si j'ai pas encore tout à fait l'age :)

Et vive les débats techniques et de fonds donc :)

Un ami m'a dit hier qu'il ne lisait plus les commentaires sur linuxfr à cause du temps perdu par beaucoup sur des détails d’orthographes ou de terme pas totalement adéquat en laissant de côté le fond.

Et là bravo, tu es en plein dedans. Dans le genre de perds mon temps sur un point de détail digne d'une dicté de Pivot tu places la barre bien haut.

De l'importance d'avoir deux UIs (web et "console pleine") pour plaire à un maximum? Le coût qu'un tel choix impose au projet et à sa maintenabilité? Ou alors plus simplement un choix de librairie améliorable pour une certaines partie d'une ou autre UI? Non, c'est beaucoup plus intéressant de parler forme et pinaillage de mot.

Je commence à comprendre mon ami pour le coup.

Juste une remarque sur le load average, ça n'a pas vraiment de sens à le mettre en pourcentage. Le comparer au nombres de CPUs (ici j'imagine qu'il y en a un seul?) est un résumé vraiment approximatif pas représentatif sur de vrais serveurs. Ca aurait beaucoup plus de sens de prendre la somme des CPU en %user+%sys par exemple :)

Dans le même genre d'outil il y a glances qui est très avancé également et là aussi présent en deux versions :)

Dommage que les gens qui n'ont pas de temps à perdre le fassent perdre aux autres.

C'est justement là que je ne suis pas d'accord. ils sont là pour faire gagner du temps à la majorité des leurs utilisateurs. Se prendre la tête sur une niche de ces derniers c'est impacter les autres, ni plus ni moins. Or ils ne te doivent rien, même si tu es un utilisateur (point que beaucoup d'utilisateurs du libre semblent oublier je pense…).

Ton avis n'a pas plus d'importance que celui de madame michu qui aimerait bien que ses vidéo youtube tournent plus vite sur son vieux pc. Or ça demande du temps mais ça aide 99% de leurs utilisateurs. Chercher à développer pour le dernier % des utilisateurs est une perte de temps abominable qui ne devrait pas être faite, et qui je pense pour ce genre de gros projet est heureusement non faite sinon ils n'avanceraient jamais sur leur "cœur de métier".

Tu veux que ça soit géré? Donne leur un code propre, facilement maintenable et même de l'aide pour le maintenir justement. Là tu as une chance que ça soit accepté. C'est l'unique intérêt du libre il me semble. Je suis d'accord que tu vas déjà plus loin qu la plupart des utilisateurs en ouvrant un ticket, mais ça ne change pas grand chose, ils ne te doivent toujours rien.

Tu n'es pas dans le cœur de cible du projet. Pour que ce soit le cas il faudrait que beaucoup d'acteurs s’allient pour pousser bien fort le desktop linux et ce sur tous ses aspects (le code ce n'est que 10% des efforts à produire). Mais bon là on s'écarte, et vu que ce lundi ressemble à un vendredi on va s’arrêter là sur ce sujet polémique :)

En fait, en France en tout cas, la supervision est ue uniquement d'un point de vue "technique", comme "juste" un outil pour les admins mais qui n'a pas d'influence sur les métiers de l'entreprise.

Or je ne vais pas vous apprendre que plus c'est "technique" et plus c'est mal vu en France. Or la supervision peut, et même doit, être orienté vers les applications métiers, afin de les aider à toujours être en état de marche. C'est un long travail et le fait d'avoir un nagios qui se focalise sur l'IT d'un point de vue bas niveau n'aide pas à faire comprendre que si, on peut être supervision et haut niveau (genre ce qu'on a avec les bp_rule et shinken).

Corollaire: si c'est technique et peu important on ne mets pas les moyens, donc on mets un stagiaire. cqfd.

C'est bizarre, mais j'ai rarement des questions de stagiaires des US par exemple, mais surtout en France. Or on a beaucoup de shinken aux us aussi, mais le plus souvent ce sont les admins expérimentés qui le mettent en place.

Bon au final ça fait de bon sujet de stage, et ça marche pas si mal avec un très bon stagiaire. Le soucis c'est que quand on en mets un pas très débrouillard, bah ça donne pas grand chose, normal après tout :p

Je prends :)

Ca ne doit être que sur le (ou les) schedulers car le poller ne sait même pas ce qu'est un commentaire :)

Question: est-ce que ce sont des commentaires liés à des downtimes? Si oui, des downtimes auto ou manuels?

Bon bah ça sent la chasse des comments dans le code alors :)

Lol, j'aime bien l'idée, surtout qu'on pourrait facilement le faire en demandant le changement d'un flag sur l'API http justement :p (jolie ironie non?)

c'est vrai que le message d'erreur de libcurl est vraiment cryptique en plus. Je me le note pour la prochaine version de le catcher et proposer une solution de contournent ou un simple lien vers la doc qui l'explique en fait :)

Là le moindre admin qui regarde les precos ou qui va se demander comment le stagiarie à fait sans lui demander un certificat va savoir directement qu'il y a un soucis.

Donc on a plus un soucis d'organisation, et si on mets en place le 1 par défaut, on va juste avoir le ssl de désactivé systématiquement ce qui n'est gère mieux. On n'aura pas le faux sentiment de sécurité c'est vrai, on en aura carrément pas :)

Bon après ça permets justement de lever un signal d'alarme.

Est-ce que ça va poser un soucis dans certains endroits? oui peu être, mais ça leur montrera aussi que la mise en place d'un tel outil doit être fait par une personne qualifiée, et pas par un stagiaire.

Dans les SI où les admins prennent ça au sérieux et savent lire le commentaire qui est une ligne en dessous du paramètre d'activation du HTTPS ça ne posera aucun soucis, et sincèrement c'est bien eux mes utilisateurs principaux.

Je comprends ton point de vue, et oui c'est tout à fait justifiable de forcer un paramètre sécurisé dès le début, mais vu qu'il va n'impacter que ceux qui n'en ont pas grand chose à faire et va pourri la vie des mainteneurs sans impacter ceux que ça intéresse, le jeu n'en vaut pas la chandelle.

Ensuite ça n’empêche pas que je vais rajouter une page dans la doc sur l'activation du SSL avec justement un petit focus là dessus et un petit warning dans les logs par exemple. Si le stagiaire pense que c'est vraiment sécurisé alors que la ligne juste en dessous a un gros warning sur la sécurité, qu'il se prends un log de warning et que la doc a un point spécial là dessus, c'est qu'il est cliniquement con :)

Pas trivial comme problématique je dois bien l'avouer, et je suis un peu biaiser vu que je suis l'un de ceux qui devraient gérer l'afflux de demandes sur les forums. On verra bien dans le futur si on change le paramètre ou pas. Mais bon on part sur cette version sur une responsabilisation des utilisateurs justement, avec l'arrêt du script d'install automatiques et le non paramétrage par défaut de pleins de trucs de manière un peu magique. Je préfère suivre cette logique et voir ce que ça donne :)

Ps: je n'ai rien contre les stagiaires, on a tous commencé comme ça dans la supervision, mais il faut bien reconnaître que la proportions de questions triviales ("j'ai pas les droits sur tel répertoire, je dois faire quoi?") explose dès le début des périodes de stages..

pip, et plus simplement le packaging python, a été une vraie galère à mettre en place. C'est fait pour des lib, pas pour des outils (genre les fichiers de conf par exemple) :(

Sinon en fait le paramètre à 0 est situé juste en dessous de use_ssl avec un texte très explicite, donc là sincèrement le mec qui active le ssl ne pourra pas dire qu'il ne l'a pas vu :)

Ce qu'il faut voir c'est que si je le passe à 1 par défaut, on va avoir une armée de stagiaires arriver en pleurant sur les forums qui ne vont pas comprendre pourquoi ça ne marche pas, et sincèrement j'ai autre chose à faire que gérer une armée de stagiaires en supervision :)
(oui je commence à les connaître ceux là au bout de quelques années dans le domaine :) )

Là le paramètre est très clair, commenté et juste ne dessous de l'activation du ssl, donc un admin "normal" n'aura aucun soucis à savoir qu'il doit le passer à 1 s'il a ses propres certificats.

Bon après sincèrement autant mettre un simple reverse apache/nginx en façade, car les admins ont déjà tout outillé pour ça (les règles puppet and co) et ça facilite un peu la mise en place sur de grosses infras un peu sensibles au point de vue réseau (genre là où on a mis la 2.0 en prod dernièrement en fait).

On verra bien comment ça sera utiliser au final, après tout vu que c'est du http, c'est très malléable :)

Et hop voici une 2.0.1 toute chaude avec le paramètre de géré sur tous les daemons. Pour info il faut donc rajouter le paramètre hard_ssl_name_check les configuration des daemons (en plus de use_ssl donc).

Pour mettre à jour un passage par la commande pip suffira :)

Finalement heureusement que l'update simplifiée est gérée dès à présent :p

C'est justement pour ça que je prépare la 2.0.1 :)

Cette version est surtout concentrée sur le http, le s était en plus, car les mise en prod que j'avais faite reposaient surtout sur des reverse proxy qui s'occupaient de ça en frontal (car il le faut de toute manière pour la partie web), d'où le manque sur ce paramètre là. faut dire qu'entre les nrpe t autre graphite en général en matière de supervision on a d'autres soucis que le chiffrement (ou plutôt authentification) mais bon ça n'excuse pas tout en effet :p

Sinon pour pre shared key je connais le principe, c'est juste que j'aimerai surtout savoir ce que ça donne en vrai dans openssl côté implémentation et si possible si c'est déjà géré par pyopenssl (mais ça ça ne doit pas poser un gros soucis).

Ah intéressant, elle permet quoi exactement? Si elle est pas trop impactante (car si beaucoup ont encore du mal à avoir une vrai PKI :) ) ça pourrait être pas mal :)

C'est tout à fait juste, je sais donc quoi rajouter pour la première release bug fix merci :)

Perso ce qui m’embête plus n'est pas le paramétrage à 0 par défaut qui restera ainsi, mais plus qu'il ne soit pas modifiable. Heureusement ça va se gérer plutôt bien surtout qu'on a déjà le paramètre géré côté conf, il suffit de le relier au bon endroit :)

Vu que tu as l'air efficace dans le domaine je t'invite à aller voir du côté de l'UI web de shinken vérifier qu'il n'y a pas de soucis (https://github.com/shinken-monitoring/mod-webui/blob/master/module/module.py). Bon on a pas de https qui est laissé à un frontal si besoin est, mais si tu peux prendre un peu de temps pour regarder ça nous aiderai bien :)

Pas con, j'en rajoute un pour voir :)