ejabberd 1.0.0 : le serveur Jabber qui monte (...en charge)

Posté par  (site web personnel) . Modéré par rootix.
Étiquettes :
0
15
déc.
2005
XMPP
L'équipe d'ejabberd est heureuse d'annoncer la publication de la version 1.0.0 d'ejabberd. Ejabberd est développé depuis 2002 et le projet a fêté ses 3 ans en novembre dernier. Ce qui fait de cette étape un événement encore plus important.

Cette version est compatible avec le standard XMPP. Cela fait d'ejabberd le premier serveur Jabber Open Source à revendiquer la compatibilité complète avec le standard XMPP défini par l'IETF (XMPP Core and XMPP IM).

Vous pouvez passer le mot !

Les fonctionnalités uniques d'ejabberd sont :
  • Le clustering
  • Le support intégré des connexions HTTP (HTTP Polling)
  • La compatibilité XMPP
  • L'architecture modulaire
  • La localisation dans 11 langues
  • L'intégration d'un composant de publication / abonnement (Publish-Subscribe)
  • La gestion des statistiques (JEP-0039: Statistics Gathering).

Il est maintenant temps de faire la fête pour cette version majeure ! ejabberd 1.0.0 est compatible avec le protocole standard XMPP (eXtensible Messaging and Presence Protocol). ejabberd est le premier serveur Open Source revendiquant une conformité totale au protocole XMPP.

Les changements récents concernent :

Chiffrement des connexions de serveur à serveur pour améliorer la sécurité
* Support de STARTTLS et SASL EXTERNAL pour les connexions de serveur à serveur (s2s).
* STARTTLS+Dialback a été implémenté pour connexions de serveur à serveur (s2s). Des options ont été ajoutées dans le fichier de configuration : s2s_use_starttls and s2s_certfile. Voir le fichier ejabberd.cfg.example pour des exemples d'utilisation.
* La gestion des certificats est simplifiée par l'utilisation des fonctionnalités DNS "commonName" et de correspondance des champs dNSName.
* Des certificats pour chaque serveur virtuel peuvent être définis.

Support d'ODBC
* Le support d'ODBC a été amélioré pour permettre l'utilisation d'ejabberd en production avec des bases de données relationnelles.
* Le support du stockage des vCard dans une base relationnelle a été ajouté.
* ejd2odbc.erl est un outil permettant de migrer une installation de la base Mnesia vers une base de données relationnelle.

Support natif de PostgreSQL
* Le support natif de PostgreSQL a été ajouté : vous pouvez maintenant utiliser une base de données PostgreSQL sans passer par le driver ODBC.

Liste de contacts partagée
* Le support des listes de contact partagées a été amélioré : vous pouvez demander que tous les utilisateurs d'un serveur virtuel soient ajoutés dans un groupe. Plus d'information sur cette fonctionnalité sur http://ejabberd.jabber.ru/shared-roster-all

Interface Web
* Le code de l'interface Web a été modifié pour une meilleure intégration et une meilleure compatibilité avec J-EAI.
* La compatibilité de l'interface Web avec le standard « XHTML 1.0 Transitional » a été améliorée.

Transports
Un contournement pour les transports peut être activé avec une option lors de la compilation. Vous pouvez passer l'option "--enable-roster-gateway-workaround" au script "configure". Par exemple :

./configure --enable-roster-gateway-workaround

Cette option permet d'ajouter des abonnements de type 'to' dans la liste de contact en envoyant la balise depuis le transport vers l'utlisateur. Cette option est nécessaire pour le transport ICQ JIT.x.
Attention : en utilisant cette option, ejabberd n'est pas totalement compatible avec le standard XMPP.

Documentation et Internationalisation
* La documentation a été étendue pour couvrir plus de sujets.
* La traduction d'ejabberd a été mise à jour pour supporter les nouvelles fonctionnalités.

Correction de bugs
* Cette version contient plusieurs corrections de bugs.
* Parmi les corrections, on peut noter une amélioration de module de gestion des connexions entre le client et le serveur (c2s).
* Vous trouverez dans le fichier Changelog fourni avec cette version la liste complète des changements et améliorations apportées à ejabberd.

Installation
Des installeurs sont fournis pour Microsoft Windows et Linux/x86. L'installeur Linux inclut une version allégée d'Erlang. Les installeurs sont téléchargeables depuis la page de téléchargement.

Aller plus loin

  • # Licence

    Posté par  (site web personnel) . Évalué à 4.

    Pour ceux qui se posent la question, vu que ce n'est pas indiqué dans la news, la licence est la GPL

  • # Cluster?

    Posté par  . Évalué à 3.

    Est-ce que l'on peut participer à un cluster ejabberd sans être connecté en permanence?

    (Un peu à la manière des projets de type SETI)

    • [^] # Re: Cluster?

      Posté par  (site web personnel) . Évalué à 2.

      non, ce n'est pas possible.

      Mickaël

      • [^] # Re: Cluster?

        Posté par  . Évalué à 4.

        L'aspect cluster via la réplication de base en temps réel est très intéressante, mais ne serait-il pas possible de simplifier cela pour que chaque serveur ejabberd sur Internet puisse se synchroniser ?
        Ainsi quel que soit le serveur utilisé par l'utilisateur, il retrouverait ses contacts.

        • [^] # Re: Cluster?

          Posté par  (site web personnel) . Évalué à 2.

          Le problème que cela pose est important : le stockage du mot de passe en clair :)

          en effet, afin de pouvoir authentifier l'utilisateur à travers Internet via des modes complexes comme CRAM-MD5, il est nécessaire de disposer dans le serveur du mot de passe de l'utilisateur en clair.

          donc si l'on réplique sur N serveurs (dont certains potentiellement pas de confiance) on a donc N copies de ton mot de passe en clair :)

          • [^] # Re: Cluster?

            Posté par  . Évalué à 2.

            Et en utilisant le SSO ?
            http://linuxfr.org/2005/12/10/20037.html

          • [^] # Re: Cluster?

            Posté par  . Évalué à 2.

            Je ne vois pas le rapport avec le CRAM-MD5 ( en même temps, je ne connais pas le CRAM-MD5, je peux donc dire des bétises).
            Je ne connais pas le CRAM-MD5 mais pourquoi le serveur ne pourrait t'il pas stocker le MD5 (ou autre) dans la base plutôt que de le stocker en clair; l'applicatif peut très bien stocker sa correspondance MD5 plutôt que sa valeur et tester la valeur MD5 du mot de passe envoyé. J'avoue avoir du mal à saisir.

            • [^] # Re: Cluster?

              Posté par  (site web personnel) . Évalué à 2.

              Sauf erreur le principe c'est d'envoyer une chaine aléatoire et de dire "mixe ton mot de passe avec cette chaine et envoie moi le md5".
              Pour vérifier le mot de passe il te faut :
              - soit les md5 possibles pour toutes les chaines aléatoires que tu es succeptible d'envoyer (impossible si tu ne fais pas du réel aléatoire, et si tu n'as qu'un jeu réduit de chaines soit-disant aléatoire alors tu met en défaite tout le principe) pour vérifier si ça correspond
              - soit le mot de passe initial (en clair) et la chaine aléatoire (tu l'as parce que c'est toi qui la fourni) pour refaire le même calcul que le client et vérifier le résultat

              Vu que la première solution est impossible, il te faut bien le mot de passe en clair.



              > l'applicatif peut très bien stocker sa correspondance MD5 plutôt que
              > sa valeur et tester la valeur MD5 du mot de passe envoyé

              Si l'applicatif envoie du md5, si toi tu n'as que du md5 pour vérifier, ça sert à quoi d'avoir crypter le mot de passe ? celui qui lit ta base (donc relit le md5) pourra te le réenvoyer pour se faire authentifier. Dans ce cas là conceptuellement le md5 devient ton mot de passe réel (en clair) et le mot de passe que l'utilisateur tape n'est qu'un raccourci facilement retenable qu'il utilise en interne de son coté. Tu ne gagnes aucune sécurité.

              Le cryptage dans la base n'a aucun intérêt si ce que tu demandes au client est aussi la version cryptée. Ca ne peut avoir un intérêt que si l'un a le mot de passe en clair et l'autre le mot de passe crypté (si c'est le client qui transmet du crypté c'est pour protéger la connexion, si c'est le serveur qui stocke du crypté c'est pour protéger le stockage).

  • # Comparatif ?

    Posté par  (site web personnel) . Évalué à 4.

    Le serveur jabber de l'APINC avait un choix difficile à faire entre la stabilité et les fonctionalités - notamment les passerelles vers les autres réseaux d'IM.
    Pouvez-vous partager votre expérience concernant ejabberd ou d'autre serveurs ?

    • [^] # Re: Comparatif ?

      Posté par  (site web personnel) . Évalué à 4.

      Tu peux utiliser toutes les passerelles que tu veux avec ejabberd.
      Les passerelles traditionnelles fonctionnent très bien avec.

      Mickaël

      • [^] # Re: Comparatif ?

        Posté par  (site web personnel) . Évalué à 2.

        Je confirme, marche très bien sur mailfr.com depuis quelques semaines.

        ejabberd étant, je trouve, plus simple à configurer que jabberd2.

        Je n'ai, cependant, pas encore testé en mode cluster (mais cela ne saurait tarder ...)

  • # A quand le support de l'authentification LDAPS ?

    Posté par  . Évalué à 5.

    Le problème c'est que la lib ldap en erlang, c'est pas le pérou :-)

    Tant que cette feature n'est pas supporté, je ne peux pas remplacer jabberd2 par ejabberd (qui a l'air pourtant beaucoup plus sympa et robuste...) dans ma boite.


  • # Site communautaire francophone de Jabber.

    Posté par  . Évalué à 7.

    Je rajouterai à la liste de liens utiles pour cette dépêche le site communautaire francophone de Jabber/XMPP :
    http://www.jabberfr.org

    Je suis d'ailleurs en train de préparer un tutoriel d'installation de ejabberd pour le wiki. Je n'aurais certainement pas le temps de m'en occuper d'ici la fin de l'année mais il devrait être disponible courant janvier 2006. Si vous avez prévu de monter un serveur jabber l'an prochain pensez-y :-)

  • # Commentaire supprimé

    Posté par  . Évalué à 7.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.