Jean Gabes a écrit 458 commentaires

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 :)

Je n'ai pas encore réussi à le reproduire, donc j'imagine que oui. En même temps de mémoire on ne me l'a remonté que sur une seule installation. Je suis beaucoup de grosses installations et aucune ne m'a remontée le problème encore :)

Je confirme que tu as mal compris :)

Il stocke les tar.gz des packs et modules directement :)

Ah ça fait plaisir de voir son nom cité tiens :p

Bon petite news en passant pour pas faire un commentaire un peu vide: nouvelle version de Shinken la semaine prochaine a priori :)

Sinon pour revenir au sujet, je pense que c'est une très bonne chose de mettre en avant les développeurs, et montrer ce qu'ils peuvent créer comme valeur. Le jour où on aura en France un bon dev payé bien plus cher que son petit chef on aura fait un grand pas en avant, et on arrêtera peu être l’hémorragie vers les US (faut dire que quand ils arrivent et proposent salaire_fr*5 ça calme) …

Je suis plutôt d'accord avec ça. Il se doit d'être clean sur sa sortie et de ne mettre personne dans la me%#e en supprimant par exemple sans les céder les sources du site communautaire par exemple. Mais de là à se devoir de rester alors qu'il n'en a plus envie non, là aucunement.

Il ne faut pas oublier que les autres ont aidées pour leur propre intérêt comme le dirait si bien notre Linus nation^{Winternational.} Ils y ont pris du plaisir et encore heureux, mais de là à ce que leur aide ait en contre-partie sa servitude je ne suis pas d'accord (car c'est bien de ça dont on parle s'il doit rester dans un projet dont il n'a pas envie, c'est comme si on demandait à un codeur de faire du PLSQL d'oracle, personne n'en a envie).

Je veux dire que même d'un point de vue éthique ce qui compte c'est la manière où il gère sa sortie, mais le fait de pouvoir sortir ne devrait pas être optionnel. Certains projets on très très mal gérés cela dans le passé genre en le faisant mais sans vraiment le dire. Là c'est assez clean je trouve même si le délai est un peu short. Si une personne motivée a les moyens avec ce qu'il laisse de reprendre le flambeau sans repartir de 0 (il y a toujours le nom qui est source soucis, car sa propriété) il n'y a pas de soucis. Si par contre il fait exprès de cramer ce que tout le monde a participé à bâtir (genre il drop les différents sites, forum and co avant de partir) là non ce n'est pas clean par contre :)

Donc fork. Il pars de son côté, c'est son droit je pense. La limite de 10jours est elle carrément limite quant à elle.

Si la communauté est si bien organisée que tu le dis, aucun soucis, un nouveau lead prends le pas, on change de nom et c'est reparti. C'est impactant j'en conviens, mais bon c'est aussi sa liberté de le faire non? Il me semble que l'on a pas le droit de lui enlever.

Il me semble que github aspire une grande majorité des projets. Si quelqu'un a des chiffres ça serait intéressant d'ailleurs.

Plus sérieusement que l'armée de troll qui ne va pas tarder à se lancer à l’assaut, est-ce que certains ont des stats sur justement le nombres de projets lancés par rapports aux types de licences, et à projet "équivalents" (pas de gros car la licence joue moins) quel type a le plus de contributions.

Par exemple avec toute l’effervescence nodejs et javascript, je pense que les types BSD poussent forts. Est-ce que d'autres domaines restent fortement typés GPL?

J'ai ma petite idée en tant que mainteneur de projet GPL sur les résultats, mais j'aimerai bien des statistiques réelle que mon ressenti :)

Ne t'inquiète pas, on va s'arranger héhéhé :)

Pénalisant pour l'image et la dilution des forces, mais ça permet également d'abaisser la barrière d'entrée de nouveaux projets (plus dur de faire face à un "gros" que X plus petits). Donc au final l'écosystème n'est pas si mal en point. De plus ils s'éloignent de plus en plus les uns des autres, donc on va avoir des situations plus claires pour choisir LE bon outil à sa situation. Ca donne plus de travail aux consultants ;)

C'est pas faux, mais on s'amuse bien dans le milieu justement, c'est une sorte d'animation de la communauté comme une autre :p

Ce n'est pas complètement faux non plus. La raison est historique, le site a été monté par ses auteurs précédents, mais la société a réclamé la propriété de l'enregistrement DNS car il y avait nagios dans le nom, ce que les auteurs ont fait (pour ne pas se froisser avec l'auteur de nagios). Donc on était dans une situation "anormale" en effet après tout, là c'est un mal pour un bien, ça clarifie les choses et on va avoir un équivalent nagios-exchange.org/monitoring-exchange.org (oui c'est pas la première fois que cette histoire se passé :) ).

Oui en effet, je l'ai déjà dis dans le passé et ça se vérifie: il est mon premier "commercial" :). Mais il bat un nouveau record en terme d'image. Ce qui est ironique c'est que c'est justement pour protéger son image qu'il fait tout ça…

Le plus fort c'est que commercialement il n'y a aucun intérêt à faire ça. Le pire qu'il peut être "reprocher" aux mainteneur des sondes était de dire clairement qu'elles étaient également pour les autres outils du monde nagios (centreon-engine, icinga, naemon et shinken). Enfin bon ce n'était pas non plus un crime si grave, pas de quoi flinguer le site sans aucun avertissements…

J'ai beau chercher là j'ai du mal à comprendre ce qu'il a fait. D'habitude il y a une raison commerciale assez claire, mais là ce sont juste les sondes, et je vois mal comment les modifier pour les monétiser.

Oh mais je ne disais pas du tout que c'était débile d'aller vers là, bien au contraire :)

Le truc c'est qu'à chaque fois que l'on parle d'économie & open source/libre on arrive au modèle des services genre intégration. Mais voila, ce modèle fait vivre les intégrateurs, pas les dev/éditeurs justement. Il ne faut donc pas s'étonner que de plus en plus d'outils s'orientent vers de l'open core ou cherchent à rendre l'utilisation sur certains OS payantes (en gros pour 99% des personnes devoir recompiler sous Windows est de l'ordre de l'impossible, donc on a bien créé une barrière virtuelle ici), ou la pub (on utilise la popularité de l'outil, mais ça demande donc une audience monstrueuse, qui par définition ne sera atteinte que par quelques outils seulement).

Pour le Big Daddy c'est bien ce que je disais. Le modèle est valide car justement de gros acteurs ont tout intérêt à ce que l'outil se développe fortement pour booster leur propre business. Donc là aucun soucis à ce que ça reste open source.

Mais dans le monde "normal", avec un outil "normal" on a pas la visibilité de Firefox, ni de gros acteurs qui veulent payer les dev (car on fait un outil qui concurrence les offres des gros par exemple). Or les intégrateurs sont ravis de pouvoir faire du chiffre avec la version open source, mais ne participent que très très peu au dev (quand ils participent tout cours…). Pouvoir payer un salaire avec du dev à la demande ça se fait, mais si on veux pouvoir embaucher pour faire plus de dev par exemple là ce n'est plus tenable comme modèle.

Le modèle open source n'est donc pas viable comme tel dans le système économique actuel. Or en effet il faut être réaliste et l'adapter (genre open core). Ce qui m'étonne c'est que beaucoup semblent encore penser que ce modèle est viable pour tous les outils. Or non, il ne l'est pas. On a quelques exceptions bien sûr, mais soyons sérieux dans la majorité des cas ça ne marche pas.

Il ne faut donc pas s'étonner que de plus en plus d'outil (surtout d'infrastructure) s'orientent vers de l'open core. On avait déjà Nagios et Centreon, on a aussi Puppet, Cfengine, Nginx et prochainement Shinken. C'est dommage mais bon réalité fait loi :)