Ce qu'il dit, c'est que si justement c'est résolu par XMPP car le protocole XMPP inclus déjà le fait qu'on check qu'une compte (une machine ici donc) est connecté ou pas.
En gros, si une machine = un user connecté, alors les autres users (le moniteur) savent si il est connecté ou pas.
Oui mais ça revient à faire un _contrôle régulier_, soit en pull, soit en push. Il me semble que XMPP ping[1] est d'ailleurs là pour ça.
Mais je restes persuadé qu'un ping ICMP est plus léger qu'un ping XMPP pour savoir si la communication entre le serveur de surveillance et la machine surveillée est toujours vivante.
En gros ce qu'il dit c'est qu'on pourrait utiliser XMPP et son modèle décentralisé comme couche transport pour se concentrer sur le contenu des messages sans qu'on ait à mélanger la gestion de la messagerie (push/pull, contenu structuré, etc) et l'utilisation qu'on en fait.
Non le journal propose d'utiliser XMPP pour ne plus avoir besoin faire des contrôles réguliers sur les machines. XMPP ne résoud pas se problème particulièrement :
- notamment le fait que celui-ci soit susceptible d'effectuer un nombre conséquent de vérifications à interval régulier sur des machines.
- On a du publish/subscribe, on peut faire du push, bref pas besoin de perdre sont temps à checker à interval régulier un service...
Le reste parle d'utiliser XMPP pour lancer des commandes sur les machines et, là encore, pourquoi rajouter un service supplémentaire alors qu'ssh est généralement installé sur les serveurs.
Ensuite utiliser XMPP pour communiquer, c'est un autre sujet, mais pas abordé dans le journal.
NAGIOS lui-même le fait, sauf qu'ils ont tout réinventé pour le faire tandis que XMPP se concentre QUE sur ça !
Hormis le fait que Nagios (1999) existait avant XMPP (2000 et 2004 pour le standard), donc ils n'ont pas réinventé en fait.
Maintenant les notifications via XMPP sont déjà disponibles dans Nagios[2]
le champs de mine qui a rendu plusieurs stagiaires infirmes
Je mets les mines après avoir enterré la machine, je ne laisses pas quelqu'un le faire à ma place, il risquerait de tenter de pirater la machine en creusant le trou (en fait je fais creuser le trou par quelqu'un que j'élimine ensuite (donc il creuse deux trous)) ... On est jamais trop prudent.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Bon ça c'est un choix de distribution, c'est délicat de se prononcer sur "c'est bien, c'est mal". Par exemple dans l'installation de base, Debian n'installe pas sudo, Ubuntu installe sudo configuré pour fonctionner sans mot de passe.
En même temps, et pour être honnête, je penses que la plus part des utilisateurs veulent pouvoir installé n'importe quoi et amener réparer si c'est cassé. Il faut les fouetter avec un barbelé rouillé, mais je m'emporte, je m'emporte.
C'est comme si un revendeur installait Windows avec l'UAC désactiver par défaut (never notify). Pour certaines personnes je le fais (pas l'UAC, le sudo sans mot de passe) et pour d'autre j'installe openSSH, no-ip ou dyndns et je gère moi. C'est la seule solution.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Le problème de la surveillance n'est pas vraiment la communication. Comme présenté dans le journal, XMPP est la solution idéal pour résoudre le cas du nombre de vérifications régulières faites par Nagios :
Dans un précédent journal, on parlait de Nagios, notamment le fait que celui-ci soit susceptible d'effectuer un nombre conséquent de vérifications à interval régulier sur des machines.
Si on prend uniquement le cas de la supervision de serveurs et non pas les équipements réseaux via SNMP avec les switchs/routeurs. Pourquoi alors ne pas utiliser XMPP ?
L'idée proposée est d'envoyer un message quand ça va mal. Bien je soulignais que le problème venait lorsqu'on a une coupure de réseau on se retrouvait dans le cas suivant : pas de message donc pas de problème.
La solution pour ça a été de faire comme les navigateurs quand ils téléchargent un fichier et que l'on interrompt le téléchargement. Je réplique que l'on ne peut pas garder une communication ouverte sans rien dire indéfiniment (les serveurs peuvent fonctionner des mois sans problèmes).
C'est là où est le problème. Qu'on utilise XMPP ou n'importe quoi d'autres, on aura toujours besoin d'avoir le serveur qui va demander aux client "ça va ?" ou alors le client devra toujours dire "je vais bien ?".
Donc ce point n'est pas automagiquement résolu par XMPP.
Il y a aussi SSH over XMPP. C'est vrai pourquoi utiliser SSH alors qu'on pourrait encapsuler ça dans du XMPP. C'est clairement un abus de l'utilisation de XMPP.
Ensuite quand je vois ça : Alors, pensez-vous que XMPP peut être intéressant pour superviser un parc de machine, plutôt qu'une usine a gaz gérée de manière centralisée qui va passer son temps à faire du polling ?
Je me dis que c'est vachement agressif, je suis pas certain qu'un serveur jabber soit moins gourmand qu'un Nagios. C'est un appel au troll.
Ils me semblent que tu vois la surveillance comme suit :
- Il y a une erreur, un message est envoyé à l'administrateur.
Le fait est qu'il y a d'autres choses à gérer (j'ai cité plus haut, je vais éviter de me répéter). Et XMPP tout seul ne le fait pas. Donc on doit intégrer le protocole XMPP dans le serveur de supervision ou alors avoir deux services pour la supervision, dont un uniquement pour l'échange de message.
Finalement la solution RedHat me semble ne pas être un système de surveillance, mais une outil pour lancer des tâches récurrentes, une sorte de cron centralisé, utilisant XMPP comme protocole de communication. Donc pas vraiment prévu pour faire de la surveillance.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Je crois qu'il ne faut pas dire du mal d'XMPP par ici, ça moinsse sec sinon. (en plus d'être nouveau c'est avec du XML, donc forcément c'est bien).
Moi je penses qu'Intel devrai implémenter XMPP sur les bus processeurs ... Ce serait vraiment une évolution.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Le serveur le sait parce que le client ferme le port, c'est prévu par TCP. Si il n'y a pas cette fermeture on se dit que si on a pas reçu de données sur ce port après X temps ben on considère que le port est mort. Donc ... si ton serveur plante, il va pas faire de fermeture correcte (déjà que maintenir un port ouvert pour rien dire c'est un peu con et surtout que chaque machine surveillée bouffe un port, ... bref) et donc on ne sait toujours pas.
De plus XMPP est prévu pour ne pas fonctionner sur TCP uniquement, donc dans les autres cas tu n'as pas ce mécanisme d'ouverture/fermeture de port (UDP) ...
Donc le client envoies, dans le cas d'un système de surveillance, un "je suis en vie" toutes les 2 minutes ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Je veux pas que les machines me parlent à moi directement, c'est juste infaisable, tu vois le chaos que ça donne ?
Non il doit y a avoir un endroit où tous les états sont centralisés et les actions entreprises avec. Une micro-interruption et hop tout le monde est réveillé ...
C'est pas possible, on veut être réveillé quand la panne est sérieuse.
Il peut arriver qu'un machine fonctionnel ait un contrôle qui fonctionne pas une fois (parce qu'une mouche est passée dans le ventilo du processeur et ça a produit une petite variation de tension qui a fait que la valeur de retour du contrôle est 255 au lieu de 0). Un incident comme ça ne doit pas faire gueuler tous les comptes XMPP des admins qui font leur sieste habituelle (celle de 8h à 18h).
Ensuite quand le problème est sérieux, il faut qu'on ait un rappelle de temps à autre (au cas où on a pas réussi à se réveiller, ça arrive).
Ensuite si un d'entre nous intervient, il doit pouvoir stopper les alarmes uniquement pour ce service.
Ensuite si on a une intervention planifiée, il faut que l'on indique au système de surveillance qu'on va la faire de 12h à 13h, donc de pas crier si le serveur est en panne durant ce temps.
Et encore plein d'autres choses. XMPP ne résout rien. Il faut faire un logiciel de surveillance qui introduit certainement un nouveau dialecte XML dans XMPP, un serveur Jabber XMPP qui s'interface avec notre logiciel de surveillance, et finalement notre logiciel de surveillance enverra les alarmes à qui de droit. Donc le serveur XMPP est juste un service qui fait passer les messages entre le serveur de surveillance et les machines puis entre le serveur de surveillance et les administrateurs.
Donc soit on réimplante XMPP dans un système de surveillance, soit on ajoute un service dans le système d'alarme avec tous les risques de pannes qu'un processus ajoute ...
Finalement tu m'expliquera comment le serveur XMPP fait pour savoir si un client est connecté ou pas ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Bah tu envois un message que quand il y a un problème (plus précisément quand tu change d'état), si tout va bien à l'instant N pas besoin de le répéter à l'instant N+1, le serveur garde en mémoire l'état de chaque client.
Une coupure réseau et un fonctionnement normal ont le même état dans ton histoire. Comment les distinguer ? Le serveur de surveillance "ping" régulièrement le client, ou alors le client envoie son état régulièrement. Mais se dire que rien == ok, c'est pas possible.
Bah si justement, le serveur n'intervient absolument pas dans le contenue échangé entre les clients, il se fout que ça soit pour de la supervision ou pour du chat tout ce qu'il fait c'est router ces messages.
??? Et comment il récupère les données de performances, comment il fait les statistiques de disponibilité ? Comment on peut dire confirmer un problème pour travailler dessus ? Comment on prévoit les temps d'interruptions d'un service/serveur ? La gestion des états (soft/hard) ?
C'est le plus gros du travail ça, la communication est la pointe de l'iceberg ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Heu ... tu as déjà bossé avec XMPP ? Les chiffres que je donne sont certes imprécis mais du même ordre de grandeur que ce j'ai constaté en utilisant ce protocole, bien sûr tu peux faire des paquets énormes mais en pratique ça se voit très rarement.
Références, références ... Si XMPP va aussi vite que ça et prend aussi peu de place, on devrait trouver plein de document expliquant ceci.
Pour les requêtes de présence tu interprète mal, j'ai précisé que 'la plupart' était inutiles notamment les plus verbeuses, et non pas la peine d'envoyer un 'hello je suis vivant' régulièrement, t'as juste à le faire si tu change d'état et si la connexion se coupe le serveur prévient les autres clients.
Il faut que tu m'expliques. L'idée de base présentée ici c'est que les serveurs surveillées envoient eux même un message quand il y a un problème. Si tu appliques cette solution, tu dois envoyer régulièrement un message pour dire que "je suis vivant". Sinon tu reviens à l'idée d'un serveur qui "poll" les clients et ça élimine une partie des raisons d'utiliser XMPP.
Donc soit tu fais les présences, soit tu fais du poll commen actuellement (à noter que le "push" existe aussi sur nagios).
XMPP n'est pas que 'hype', 'in' et 'cool' (c'est tout à son honneur) ... mais aussi standard[1], techniquement mature et complet[2] et disposent de nombreuses implémentations[3].
[1] Il y a pleins de protocoles standards aujourd'hui, XMPP est un parmi tant d'autres.
[2] Complet et mature ? Bon 5 ans d'âge, c'est mature, mais juste. Complet, ça veut dire que plus il y a de trucs différents c'est complet ... Perso j'aime bien la citation suivante : "La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer" - Antoine de Saint-Exupéry
[3] Des implémentations pour des messages, pas de la surveillance ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
et la taille d'une requête XMPP est 99% du temps inférieur à celle d'un paquet TCP.
Non mais la taille standard d'un paquet XMPP compressé est de 34ko (chiffre aussi sorti de mon chapeau, alors pas besoin de références).
les plus courantes sont les requêtes de présence qui sont pour la plupart inutile pour la supervision (genre indiqué quel musique l'utilisateur écoute, ou si il est en train de taper au clavier).
Non, pas besoin de savoir si un service est fonctionnel ou pas. C'est justement ça qui est important, il me semble, dans la supervision. Alors oui on peut imaginer que ce soit la machine qui envoie un message quand il y a un problème. Cool, je coupe tous les câbles réseau et il n'y a plus de problèmes ... pas de message, pas de problème.
Non, il faut que régulièrement on ait un "hello, je suis vivant", sinon comment peut-on savoir que le système fonctionne ou pas. Donc indication de présences
(et décodent 20k de messages XML en une fraction de secondes)
Dans mon chapeau j'ai tiré 10h de décodage ... C'est beaucoup ça, je retire. Ah 36.34s pour 20k messages sur une machine bi-Xeon octo-core et 64G de Ram dédiée au décodage uniquement.
Et bien sur que si l'utilisation d'un protocole peut améliorer la vitesse, XMPP sera beaucoup beaucoup plus lent que HTTP pour le transfert de gros fichiers binaires, mais sera plus rapide pour l'envoie de petites requêtes espacées dans le temps (sans parlé du push).
Bien entendu qu'un protocole peut apporter des améliorations de vitesses, mais de l'ordre du détail dans beaucoup de cas et plus important dans certain cas. Mais dans ce cas là, je penses pas que ce soit pertinent de vouloir mettre du XMPP là.
XMPP arrive ici parce qu'actuellement c'est un protocole "hype", "in", "cool", ... C'est juste la mode de mettre XMPP partout dès que possible, mais c'est pas un protocole qui solutionne tous les maux de la planète. Actuellement la supervision fonctionne sans XMPP, il n'y a pas besoin de le mettre.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
C'est pas parce qu'on utilise le protocole X au lieu de protocole X que le système va devenir automagiquement performant.
Pourquoi alors ne pas utiliser XMPP ?
Pour de la supervision le XML me semble déjà très lourd (entendre verbeux, ici).
Grâce à toutes les XEP disponibles ont peut facilement faire un système de supervision "temps réel".
XEP va automagiquement supprimer toutes les latences des tests, augmenter les bandes passantes des réseaux et utiliser la téléportation ?
on peut faire du push
Oui je vois assez 20k services envoyer leur état en temps réel à une machine avec du XML ... C'est claire que ça va alléger la charge de décoder 20k messages XML en temps réel. Le push peut-être intéressant en supervision dans certains cas et est disponible sur nagios, mais ce n'est pas _la_ solution pour alléger le tout.
Alors, pensez-vous que XMPP peut être intéressant pour superviser un parc de machine, plutôt qu'une usine a gaz gérée de manière centralisée qui va passer son temps à faire du polling ?
XMPP est un protocole de communication. On pourrait faire la même chose avec du HTTP, du FTP, ... peu importe. C'est pas un protocole qui va changer amener de la vitesse (bien qu'il peut changer). XMPP va rencontrer le même problème que n'importe quel autre protocole.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Ca c'est la realite dans le monde reel, ou on voit que Windows a eu un support utilisable par un non-informaticien avant Linux, sortir que c'est nickel sous Linux quand 99% de la population est incapable de l'utiliser en l'etat c'est de la mauvaise foi et rien d'autre.
Non ça c'est pas la réalité, ça c'est _un_ exemple d'un truc _spécifique_ parmi les nouveautés de l'informatique. Linux est des fois premier, des fois seconds, des fois derniers.
Mais puisque t'aime ça, on peut jouer à ce jeu. Top départ :
"Linux a sorti l'USB 3 avant Windows 7."
Non je rigole, j'ai pas le temps ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Non j'ai juste dit qu'il fallait une copie des fichiers de configuration avant de réinstaller ... Un des deux a pris une clé USB et a copié dessus, l'autre à pris du papier et commencé à copier les fichiers à la main ... Quand j'ai vu ça j'ai agrandi aussi sec la liste des fichiers nécessaires (comme je regrette de ne pas avoir mis /etc/services et /etc/mime.types).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Oui mais le sujet était le système de Mme Michu, donc dans ce cas là c'est la liste que j'ai donnée. Donc Mme Michu a la séparation des privilèges depuis XP ... C'est tout nouveau pour elle. Le grand publique découvre avec XP la séparation des privilèges, il faut attendre 5 à 10 ans qu'il s'habitue ...
Le problème des logiciels malveillants sont rares sur les ordinateurs des professionnels de l'informatique (enfin je supposes que ceux qui bossent là-dedans font attention).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
On parlait de Mme Michu là. Mme Michu c'est Win 3.1, Win95, Win98, Win Me et Win XP ... Pour le reste on en discutera lors d'un débat sur les serveurs.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
L'idée du LDAP est plus séduisante mais par exemple, mes fichiers nagios sont versionnés via svn et mis sur le serveur via cfengine. Donc on pourrait avoir un backend ldap qui génère les fichiers nagios en asynchrone.
C'est ce que je souhaites faire dès que j'ai le temps.
Le problème est de vouloir avoir des fichiers de conf "synchrone" qui deviennent donc des données et qu'ils ne deviennent vite modifiable que par des IHM graphique.
Il y a ldapvi. Tu vois ton arbres ldap comme un grand fichier ldif et tu l'édites avec vi.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Les prémices c'étaient NT/2k avec le multi-utilisateur, mais pas de possibilité d'effectuer une opération avec des droits élevés par l'utilisateur, XP c'est devenu fonctionnel mais sans plus, Vista c'est le début d'un truc utilisable mais trop bavard, 7, je sais pas.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
La logique de séparation des droits qui est récentes dans Windows mais éprouvée dans l'univers Unix.
Maintenant il est vrai que Windows devient de plus en plus "unix" parce que justement, c'est dur de faire mieux et grand public à la fois. Mais Windows souffre beaucoup de cet absence de séparation des droits et Microsoft doit recourir à la "virtualisation" des applications pour que les applications pré-"Windows avec séparation des droits" puissent continuer à fonctionner normalement (ou alors couper avec ça, mais ça fait beaucoup trop d'applications qui risquent de ne plus fonctionner et Microsoft a déjà assez souffert de la cassure dans le domaine des drivers sur Vista).
Ensuite durant longtemps Microsoft a refusé de travailler avec les standards et a tenté de réinventer la roue, on se souvient particulièrement du hachage des mots de passe LanMan et NTLM. Maintenant Microsoft est passé à Kerberos et ça va mieux (mais doit toujours supporté ces trucs d'antan).
La preuve du temps. Maintenant que Microsoft implémente des sécurités comme la séparation des privilèges et tout ça, il faut que ces sécurités soient prouvées sur la durée, donc encore bien 5 ou 10 ans à traîner cette réputation de gruyère ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas le choix !
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Je ne veux pas passer a KDE4!. Évalué à 2.
Mais fait attention aux malwares ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 2.
En gros, si une machine = un user connecté, alors les autres users (le moniteur) savent si il est connecté ou pas.
Oui mais ça revient à faire un _contrôle régulier_, soit en pull, soit en push. Il me semble que XMPP ping[1] est d'ailleurs là pour ça.
Mais je restes persuadé qu'un ping ICMP est plus léger qu'un ping XMPP pour savoir si la communication entre le serveur de surveillance et la machine surveillée est toujours vivante.
En gros ce qu'il dit c'est qu'on pourrait utiliser XMPP et son modèle décentralisé comme couche transport pour se concentrer sur le contenu des messages sans qu'on ait à mélanger la gestion de la messagerie (push/pull, contenu structuré, etc) et l'utilisation qu'on en fait.
Non le journal propose d'utiliser XMPP pour ne plus avoir besoin faire des contrôles réguliers sur les machines. XMPP ne résoud pas se problème particulièrement :
- notamment le fait que celui-ci soit susceptible d'effectuer un nombre conséquent de vérifications à interval régulier sur des machines.
- On a du publish/subscribe, on peut faire du push, bref pas besoin de perdre sont temps à checker à interval régulier un service...
Le reste parle d'utiliser XMPP pour lancer des commandes sur les machines et, là encore, pourquoi rajouter un service supplémentaire alors qu'ssh est généralement installé sur les serveurs.
Ensuite utiliser XMPP pour communiquer, c'est un autre sujet, mais pas abordé dans le journal.
NAGIOS lui-même le fait, sauf qu'ils ont tout réinventé pour le faire tandis que XMPP se concentre QUE sur ça !
Hormis le fait que Nagios (1999) existait avant XMPP (2000 et 2004 pour le standard), donc ils n'ont pas réinventé en fait.
Maintenant les notifications via XMPP sont déjà disponibles dans Nagios[2]
[1] http://xmpp.org/extensions/xep-0199.html
[2] http://www.gridpp.ac.uk/wiki/Nagios_jabber_notification
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: En même temps…
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal faille de sécurité dans GRUB. Évalué à 5.
Je mets les mines après avoir enterré la machine, je ne laisses pas quelqu'un le faire à ma place, il risquerait de tenter de pirater la machine en creusant le trou (en fait je fais creuser le trou par quelqu'un que j'élimine ensuite (donc il creuse deux trous)) ... On est jamais trop prudent.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: En même temps…
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal faille de sécurité dans GRUB. Évalué à 6.
Coulé dans du béton armé et enterré à 12 mètres de profondeurs ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mais oui ...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal MALWARE LINUX. Évalué à 2.
En même temps, et pour être honnête, je penses que la plus part des utilisateurs veulent pouvoir installé n'importe quoi et amener réparer si c'est cassé. Il faut les fouetter avec un barbelé rouillé, mais je m'emporte, je m'emporte.
C'est comme si un revendeur installait Windows avec l'UAC désactiver par défaut (never notify). Pour certaines personnes je le fais (pas l'UAC, le sudo sans mot de passe) et pour d'autre j'installe openSSH, no-ip ou dyndns et je gère moi. C'est la seule solution.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 2.
Dans un précédent journal, on parlait de Nagios, notamment le fait que celui-ci soit susceptible d'effectuer un nombre conséquent de vérifications à interval régulier sur des machines.
Si on prend uniquement le cas de la supervision de serveurs et non pas les équipements réseaux via SNMP avec les switchs/routeurs. Pourquoi alors ne pas utiliser XMPP ?
L'idée proposée est d'envoyer un message quand ça va mal. Bien je soulignais que le problème venait lorsqu'on a une coupure de réseau on se retrouvait dans le cas suivant : pas de message donc pas de problème.
La solution pour ça a été de faire comme les navigateurs quand ils téléchargent un fichier et que l'on interrompt le téléchargement. Je réplique que l'on ne peut pas garder une communication ouverte sans rien dire indéfiniment (les serveurs peuvent fonctionner des mois sans problèmes).
C'est là où est le problème. Qu'on utilise XMPP ou n'importe quoi d'autres, on aura toujours besoin d'avoir le serveur qui va demander aux client "ça va ?" ou alors le client devra toujours dire "je vais bien ?".
Donc ce point n'est pas automagiquement résolu par XMPP.
Il y a aussi SSH over XMPP. C'est vrai pourquoi utiliser SSH alors qu'on pourrait encapsuler ça dans du XMPP. C'est clairement un abus de l'utilisation de XMPP.
Ensuite quand je vois ça :
Alors, pensez-vous que XMPP peut être intéressant pour superviser un parc de machine, plutôt qu'une usine a gaz gérée de manière centralisée qui va passer son temps à faire du polling ?
Je me dis que c'est vachement agressif, je suis pas certain qu'un serveur jabber soit moins gourmand qu'un Nagios. C'est un appel au troll.
Ils me semblent que tu vois la surveillance comme suit :
- Il y a une erreur, un message est envoyé à l'administrateur.
Le fait est qu'il y a d'autres choses à gérer (j'ai cité plus haut, je vais éviter de me répéter). Et XMPP tout seul ne le fait pas. Donc on doit intégrer le protocole XMPP dans le serveur de supervision ou alors avoir deux services pour la supervision, dont un uniquement pour l'échange de message.
Finalement la solution RedHat me semble ne pas être un système de surveillance, mais une outil pour lancer des tâches récurrentes, une sorte de cron centralisé, utilisant XMPP comme protocole de communication. Donc pas vraiment prévu pour faire de la surveillance.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 3.
Moi je penses qu'Intel devrai implémenter XMPP sur les bus processeurs ... Ce serait vraiment une évolution.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 0.
XMPP c'est le protocole utilisé par le Dieu Google, c'est hype, c'est beau, c'est nouveau : c'est le Bien.
Il faut donc le mettre partout ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 2.
De plus XMPP est prévu pour ne pas fonctionner sur TCP uniquement, donc dans les autres cas tu n'as pas ce mécanisme d'ouverture/fermeture de port (UDP) ...
Donc le client envoies, dans le cas d'un système de surveillance, un "je suis en vie" toutes les 2 minutes ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 3.
Non il doit y a avoir un endroit où tous les états sont centralisés et les actions entreprises avec. Une micro-interruption et hop tout le monde est réveillé ...
C'est pas possible, on veut être réveillé quand la panne est sérieuse.
Il peut arriver qu'un machine fonctionnel ait un contrôle qui fonctionne pas une fois (parce qu'une mouche est passée dans le ventilo du processeur et ça a produit une petite variation de tension qui a fait que la valeur de retour du contrôle est 255 au lieu de 0). Un incident comme ça ne doit pas faire gueuler tous les comptes XMPP des admins qui font leur sieste habituelle (celle de 8h à 18h).
Ensuite quand le problème est sérieux, il faut qu'on ait un rappelle de temps à autre (au cas où on a pas réussi à se réveiller, ça arrive).
Ensuite si un d'entre nous intervient, il doit pouvoir stopper les alarmes uniquement pour ce service.
Ensuite si on a une intervention planifiée, il faut que l'on indique au système de surveillance qu'on va la faire de 12h à 13h, donc de pas crier si le serveur est en panne durant ce temps.
Et encore plein d'autres choses. XMPP ne résout rien. Il faut faire un logiciel de surveillance qui introduit certainement un nouveau dialecte XML dans XMPP, un serveur Jabber XMPP qui s'interface avec notre logiciel de surveillance, et finalement notre logiciel de surveillance enverra les alarmes à qui de droit. Donc le serveur XMPP est juste un service qui fait passer les messages entre le serveur de surveillance et les machines puis entre le serveur de surveillance et les administrateurs.
Donc soit on réimplante XMPP dans un système de surveillance, soit on ajoute un service dans le système d'alarme avec tous les risques de pannes qu'un processus ajoute ...
Finalement tu m'expliquera comment le serveur XMPP fait pour savoir si un client est connecté ou pas ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 1.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 2.
Une coupure réseau et un fonctionnement normal ont le même état dans ton histoire. Comment les distinguer ? Le serveur de surveillance "ping" régulièrement le client, ou alors le client envoie son état régulièrement. Mais se dire que rien == ok, c'est pas possible.
Bah si justement, le serveur n'intervient absolument pas dans le contenue échangé entre les clients, il se fout que ça soit pour de la supervision ou pour du chat tout ce qu'il fait c'est router ces messages.
??? Et comment il récupère les données de performances, comment il fait les statistiques de disponibilité ? Comment on peut dire confirmer un problème pour travailler dessus ? Comment on prévoit les temps d'interruptions d'un service/serveur ? La gestion des états (soft/hard) ?
C'est le plus gros du travail ça, la communication est la pointe de l'iceberg ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 4.
Références, références ... Si XMPP va aussi vite que ça et prend aussi peu de place, on devrait trouver plein de document expliquant ceci.
Pour les requêtes de présence tu interprète mal, j'ai précisé que 'la plupart' était inutiles notamment les plus verbeuses, et non pas la peine d'envoyer un 'hello je suis vivant' régulièrement, t'as juste à le faire si tu change d'état et si la connexion se coupe le serveur prévient les autres clients.
Il faut que tu m'expliques. L'idée de base présentée ici c'est que les serveurs surveillées envoient eux même un message quand il y a un problème. Si tu appliques cette solution, tu dois envoyer régulièrement un message pour dire que "je suis vivant". Sinon tu reviens à l'idée d'un serveur qui "poll" les clients et ça élimine une partie des raisons d'utiliser XMPP.
Donc soit tu fais les présences, soit tu fais du poll commen actuellement (à noter que le "push" existe aussi sur nagios).
XMPP n'est pas que 'hype', 'in' et 'cool' (c'est tout à son honneur) ... mais aussi standard[1], techniquement mature et complet[2] et disposent de nombreuses implémentations[3].
[1] Il y a pleins de protocoles standards aujourd'hui, XMPP est un parmi tant d'autres.
[2] Complet et mature ? Bon 5 ans d'âge, c'est mature, mais juste. Complet, ça veut dire que plus il y a de trucs différents c'est complet ... Perso j'aime bien la citation suivante : "La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer" - Antoine de Saint-Exupéry
[3] Des implémentations pour des messages, pas de la surveillance ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à -1.
Non mais la taille standard d'un paquet XMPP compressé est de 34ko (chiffre aussi sorti de mon chapeau, alors pas besoin de références).
les plus courantes sont les requêtes de présence qui sont pour la plupart inutile pour la supervision (genre indiqué quel musique l'utilisateur écoute, ou si il est en train de taper au clavier).
Non, pas besoin de savoir si un service est fonctionnel ou pas. C'est justement ça qui est important, il me semble, dans la supervision. Alors oui on peut imaginer que ce soit la machine qui envoie un message quand il y a un problème. Cool, je coupe tous les câbles réseau et il n'y a plus de problèmes ... pas de message, pas de problème.
Non, il faut que régulièrement on ait un "hello, je suis vivant", sinon comment peut-on savoir que le système fonctionne ou pas. Donc indication de présences
(et décodent 20k de messages XML en une fraction de secondes)
Dans mon chapeau j'ai tiré 10h de décodage ... C'est beaucoup ça, je retire. Ah 36.34s pour 20k messages sur une machine bi-Xeon octo-core et 64G de Ram dédiée au décodage uniquement.
Et bien sur que si l'utilisation d'un protocole peut améliorer la vitesse, XMPP sera beaucoup beaucoup plus lent que HTTP pour le transfert de gros fichiers binaires, mais sera plus rapide pour l'envoie de petites requêtes espacées dans le temps (sans parlé du push).
Bien entendu qu'un protocole peut apporter des améliorations de vitesses, mais de l'ordre du détail dans beaucoup de cas et plus important dans certain cas. Mais dans ce cas là, je penses pas que ce soit pertinent de vouloir mettre du XMPP là.
XMPP arrive ici parce qu'actuellement c'est un protocole "hype", "in", "cool", ... C'est juste la mode de mettre XMPP partout dès que possible, mais c'est pas un protocole qui solutionne tous les maux de la planète. Actuellement la supervision fonctionne sans XMPP, il n'y a pas besoin de le mettre.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Peu importe le protocole
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Supervision et XMPP, why not ?. Évalué à 1.
Pourquoi alors ne pas utiliser XMPP ?
Pour de la supervision le XML me semble déjà très lourd (entendre verbeux, ici).
Grâce à toutes les XEP disponibles ont peut facilement faire un système de supervision "temps réel".
XEP va automagiquement supprimer toutes les latences des tests, augmenter les bandes passantes des réseaux et utiliser la téléportation ?
on peut faire du push
Oui je vois assez 20k services envoyer leur état en temps réel à une machine avec du XML ... C'est claire que ça va alléger la charge de décoder 20k messages XML en temps réel. Le push peut-être intéressant en supervision dans certains cas et est disponible sur nagios, mais ce n'est pas _la_ solution pour alléger le tout.
Alors, pensez-vous que XMPP peut être intéressant pour superviser un parc de machine, plutôt qu'une usine a gaz gérée de manière centralisée qui va passer son temps à faire du polling ?
XMPP est un protocole de communication. On pourrait faire la même chose avec du HTTP, du FTP, ... peu importe. C'est pas un protocole qui va changer amener de la vitesse (bien qu'il peut changer). XMPP va rencontrer le même problème que n'importe quel autre protocole.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas d'alternative assez implémentée
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Le système de fichiers exFAT, dans la lignée des autres FAT, une menace pour la compatibilité des appareils mobiles avec les systèmes libres. Évalué à 1.
Ça veut dire que tu joues plus ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas d'alternative assez implémentée
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Le système de fichiers exFAT, dans la lignée des autres FAT, une menace pour la compatibilité des appareils mobiles avec les systèmes libres. Évalué à 2.
Non ça c'est pas la réalité, ça c'est _un_ exemple d'un truc _spécifique_ parmi les nouveautés de l'informatique. Linux est des fois premier, des fois seconds, des fois derniers.
Mais puisque t'aime ça, on peut jouer à ce jeu. Top départ :
"Linux a sorti l'USB 3 avant Windows 7."
Non je rigole, j'ai pas le temps ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mais oui ...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal MALWARE LINUX. Évalué à 5.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mais oui ...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal MALWARE LINUX. Évalué à 2.
Le problème des logiciels malveillants sont rares sur les ordinateurs des professionnels de l'informatique (enfin je supposes que ceux qui bossent là-dedans font attention).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mais oui ...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal MALWARE LINUX. Évalué à 3.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Vachement gore
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 2.
C'est ce que je souhaites faire dès que j'ai le temps.
Le problème est de vouloir avoir des fichiers de conf "synchrone" qui deviennent donc des données et qu'ils ne deviennent vite modifiable que par des IHM graphique.
Il y a ldapvi. Tu vois ton arbres ldap comme un grand fichier ldif et tu l'édites avec vi.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mais oui ...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal MALWARE LINUX. Évalué à 3.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Vachement gore
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Nagios va-t-il quitter le C pour le Python?. Évalué à 0.
Aïe.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: la stabilité et la communauté pour Debian
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Une féroce critique de Mandriva. Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Mais oui ...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal MALWARE LINUX. Évalué à 3.
Maintenant il est vrai que Windows devient de plus en plus "unix" parce que justement, c'est dur de faire mieux et grand public à la fois. Mais Windows souffre beaucoup de cet absence de séparation des droits et Microsoft doit recourir à la "virtualisation" des applications pour que les applications pré-"Windows avec séparation des droits" puissent continuer à fonctionner normalement (ou alors couper avec ça, mais ça fait beaucoup trop d'applications qui risquent de ne plus fonctionner et Microsoft a déjà assez souffert de la cassure dans le domaine des drivers sur Vista).
Ensuite durant longtemps Microsoft a refusé de travailler avec les standards et a tenté de réinventer la roue, on se souvient particulièrement du hachage des mots de passe LanMan et NTLM. Maintenant Microsoft est passé à Kerberos et ça va mieux (mais doit toujours supporté ces trucs d'antan).
La preuve du temps. Maintenant que Microsoft implémente des sécurités comme la séparation des privilèges et tout ça, il faut que ces sécurités soient prouvées sur la durée, donc encore bien 5 ou 10 ans à traîner cette réputation de gruyère ...
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell