Journal Réseau social et chat libre (Openfire + Jappix)

Posté par  (site web personnel) . Licence CC By‑SA.
7
3
avr.
2012

Après de nombreuses recherches pour un outil libre de chat avec des fonctionnalités avancées, j'ai opté pour une solution très complète, libre et gratuite.

Protocole :

Le protocole XMPP plus connu sous le nom de Jabber est LE protocole ouvert du chat. Il existe depuis très longtemps, et sa réputation n'est plus à faire. Apple, Google, Facebook, AOL, Yahoo sont tous passés à XMPP un jour ou l'autre pour leurs systèmes de chat. Cisco a même racheté Jabber.

Les fonctionnalités que j'attendais sont :

  • Les groupes de discussions
  • Transferts de fichiers
  • Inscriptions à la volée (sans passer par une demande formelle à un administrateur)

XMPP permet aussi à travers son extension Jingle de faire de la voix sur IP. Je n'en suis pas là pour le moment mais l'idée me plaît bien.

J'avais regardé aussi du côté de l'IRC - le bon vieux protocole de barbus - mais le choix des architectures serveurs et les documentations m'ont fait pensé que ce protocole n'est pas voué à une très grande évolution.

Logiciels :

D'abord un serveur libre et documenté :

J'ai commencé mes recherches sur wikipedia, et j'ai particulièrement exploré ces deux là :

  • eJabberd : Serveur XMPP sous Linux développé en Erlang (véridique !)
  • OpenFire : Serveur XMPP sous Linux ou Windows (Java oblige)

J'ai essayé les deux, les deux ont fonctionné, les deux présentent toutes les fonctionnalités dont j'ai besoin.

À mon sens, OpenFire propose une interface de configuration HTTP plus simple et, surtout, il est fait en java et peut se poser sur n'importe quel OS. Migration plus simple, bidouillages plus simples.

J'ai trouvé une documentation sur l'installation sous Debian, mais c'est très simple : télécharger le .deb et l'installer.

Ensuite un client libre et léger :

Les clients lourds sont nombreux et pas toujours à la hauteur.

J'ai trouvé que Pidgin faisait bien l'affaire, car il est très complet, par contre, un peu lourd à déployer sur de nombreuses machines.

Je me suis donc penché sur les clients légers HTTP.

J'en ai essayé de nombreux mauvais et un très bon : Jappix est excellent, très complet, beau, que demander de plus.
Il s'intègre totalement à OpenFire grâce à un greffon.

  • # Autres logiciels

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

    Bonsoir,

    la dernière fois que j'ai eu eJabberd sur mon serveur, je devais régulièrement le relancer parce qu'il avait des fuites de mémoires. C'était il y a un an.

    Il existe aussi Prosody, tu pourrais essayer.

    Quand au client, regarde Gajim, c'est le meilleur. Il ne gère QUE XMPP, mais le fait très bien.
    Il y a aussi Psi+ (psi-plus) qui est très sympa et gère plusieurs protocoles.

    Quand à Jappix, j'ai entendu dire que rien n'était chiffré, du coups les login/pass transitaient en clair sur Internet, et qu'ils étaient visible dans la source HTML. A vérifier.

    Bonne journée
    G

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Autres logiciels

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

      Quand à Jappix, j'ai entendu dire que rien n'était chiffré, du coups les login/pass transitaient en clair sur Internet, et qu'ils étaient visible dans la source HTML

      c'est peut-être pour ça que https existe ?

    • [^] # Re: Autres logiciels

      Posté par  . Évalué à 4.

      Je confirme pour Prosody. C'est un excellent serveur XMPP écrit en Lua, très léger, et extrêmement configurable. En gros, presque tout est possible dessus.

      Perso c'était avec jabberd que j'avais des fuites mémoires. Avec prosody tout roule nickel, et je ne le redémarre jamais. Un inconvénient commun à OpenFire et ejabberd c'est qu'il faut installer toute une usine à gaz machine virtuelle derrière. Si c'est juste pour XMPP c'est limite à mon sens. La communauté Prosody est aussi super réactive et efficace sur leur chan. Ils m'ont bien aidé à trouver un bug dans OpenSSL qui m'empêchait d'utiliser TLS (en passant par pcap).

      OpenFire propose une interface de configuration HTTP

      Ça c'est ridicule. Ça rajoute des failles de sécurité, des serveurs, et ça ouvre des ports. À quand une interface graphique pour gérer tout une serveur ? (Ça existe déjà en fait :-p.)

      Sur mes machines j'ai besoin de Kerberos, et la configuration avec prosody a été super facile. Pour ce qui est des clients, j'en ai testé plusieurs, et je n'ai réussi à faire marcher mes tickets Kerberos qu'avec Pidgin.

      • [^] # Re: Autres logiciels

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

        Ça rajoute des failles de sécurité

        En quoi ?

        ça ouvre des ports

        Tu sais, t'es pas obligé de les ouvrir sur l'extérieur…

        À quand une interface graphique pour gérer tout une serveur ? (Ça existe déjà (alternc) en fait :-p.)

        Sauf que : AlternC c'est une solution pour gérer un hébergement mutualisé. Tu propose quoi à la place ? Un accès shell à tout le monde ? Comment fait tuxfamily par exemple, ils n'ont pas genre une interface pour configurer ?
        A la rigueur, si tu voulais proposer un exemple pertinent, tu aurais pu parler de webmin. Il y a un moment c'était une interface de config très utilisée.

        • [^] # Re: Autres logiciels

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 12 avril 2012 à 08:37.

          Comment fait tuxfamily par exemple, ils n'ont pas genre une interface pour configurer ?

          il y a VHFFS oui cf. http://vhffs.org qui est instancié sur le panel https://panel.tuxfamily.org

          Après, ce n'est que pour la conf' utilisateur ; pour toutes les configurations de serveur, c'est paquets debian + fichiers de conf' bien sûr.

    • [^] # Re: Autres logiciels

      Posté par  . Évalué à 3.

      Quand à Jappix, j'ai entendu dire que rien n'était chiffré, du coups les login/pass transitaient en clair sur Internet, et qu'ils étaient visible dans la source HTML. A vérifier.

      Jappix s'appuie sur BOSH (Binary Over Streamed HTTP, de mémoire), c'est à dire du XMPP-over-HTTP "propre". Donc effectivement, si ton mode d'authentification utilise des mots de passe en clair ET que ta connexion HTTP est en clair, ton mot de passe sera visible. Comme dit plus haut, c'est exactement pour ça que HTTPS existe (ainsi que certains mécanismes SASL plus chiadés que le "PLAIN", mais je ne garantis pas leur intégration avec Jappix).

      Par contre, le fait qu'il soit visible dans le source HTML, je te suis moins. Jappix ne fournit aucun traitement côté serveur : il donne à ton navigateur une application HTML+Javascript, dans laquelle tu saisis ton mot de passe et qui va faire elle-même la connexion à ton XMPPd.

      (Note: je viens de voir la fonction "se souvenir de moi" sur la page de connexion, est-ce à cela que tu fais référence?)

    • [^] # Re: Autres logiciels

      Posté par  . Évalué à 4.

      Prosody est excellent, vraiment simple à configurer, léger (une dizaine de Mo de ram occupés) et disponible sur une large palette de systèmes (il y a même un port de la dernière version sur OpenBSD, c'est pour dire…). Il faut signaler également qu'ils ont un salon xmpp pour le support et qu'il y a un dev particulièrement sympathique et toujours prêt à aider (je ne me rappelle plus de son pseudo par contre). Le seul problème que je vois est qu'il n'existe pas de version pour CentOS, et je n'ai pas non plus réussi à le compiler, il faut donc faire gaffe.

      Openfire est incontestablement le plus simple avec son interface web, mais il est très lourd vu que c'est du Java, il faut prévoir plus de 200 Mo de ram rien que pour ça, et encore je ne compte pas la montée en charge. Il y a aussi le fait que le développement semble ralenti.

      Bref côté serveur mon choix c'est Prosody : ça évolue, ça ne bug pas, c'est simple à configurer, simple à transférer de serveur.

      Côté client j'en utilise beaucoup : Xabber (android), Pidgin (Windows), Kopete (Linux), Empathy (Linux), et même parfois le client web de jwchat.

      • [^] # Re: Autres logiciels

        Posté par  (site web personnel, Mastodon) . Évalué à 7.

        Le serveur est un choix à bien étudier selon les cas.

        • Openfire a mauvaise réputation principalement à cause de la guerre de religion contre Java. Mais c'est un serveur pas mal du tout, avec un bon support des XEPs, un des supports PubSub les plus complets. Malheureusement leur équipe est très (trop) petite, et les bugs mettent du temps à être corrigés. Par exemple, il y a eu un bug majeur qui bloquait les communication serveur à serveur il y a quelques mois, et la correction a mis beaucoup de temps (plusieurs mois) avant d'arriver dans une version distribuée (le patch était dispo sur le bugtracker quelques jours ou semaine après l'ouverture du rapport).
          Dire qu'il est impossible de faire quelque chose avec comme on peut le lire dans un autre commentaire n'a pas de sens puisqu'il est libre, et qu'il est donc toujours possible de le patcher (et il y a plus de gens qui connaissent Java que Erlang par exemple), maintenant ça peut prendre du temps. De ce que j'en ai vu, les sources sont bien lisibles.

        • Ejabberd est le plus connu, très réputé et Erlang lui permet de bien gérer les montée en charge. C'est le serveur utilisé notamment par Facebook. Son avantage est aussi un inconvénient, puisque peu de personnent connaissent Erlang, et que les logs/la config sont assez difficiles à lire. Il est réputé aussi pour avoir le support des XEP et de PubSub le plus complet. Il a un support communautaire et commercial au besoin.

        • Prosody est le plus jeune, et le plus en vogue à l'heure actuelle. Écrit en lua, il a un fort support communautaire, et son architecture modulaire permet de facilement implémenter des XEP. Facile à configurer, léger, c'est un très bon serveur qui a vraiment le vent en poupe. Il a un support moins complet des XEP que les 2 précédents (notamment PubSub qui est en train d'être implémenté, et disponible dans le tronc), mais ça avance vite, et les communauté est très disponible.

        Après il y en a d'autres que je n'ai pas essayé comme Tigase (écrit en Java), j'ai vu récemment un billet dessus dans le planet jabber, preuve d'une activité.

  • # Multiplatforme

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

    il est fait en java et peut se poser sur n'importe quel OS.

    Il me semble qu'Erlang est lui aussi multiplateforme, la doc précise Unix et Windows (mais je n'ai fait moi même le test que sur GNU/Linux et Windows…)

  • # OpenFire

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

    OpenFire, c'est bien ce vieux serveur Jabber, codé en Java, qui ne prend pas en charge l'hébergement virtuel (c'est à dire les noms de domaines multiples avec services séparés) ? Je ne recommanderais pas ça, comme serveur, sans compter que si un jour tu as besoin d'aide, sur les salons de discussion liés à Jabber, en expliquant que tu utilises OpenFire, tout le monde tournera le dos en disant qu'il ne connaît pas ce serveur, désolé…

  • # Yahoo!, AOL, Facebook, Microsoft

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

    Yahoo!, AOL, Facebook et Microsoft proposent bien un accès client XMPP à leurs services, mais ce sont des îlots XMPP autistes, non raccordés au réseau global. Attention à bien faire la distinction avec les vrais services Jabber comme celui de Google par exemple.

  • # Retour d'expérience diverse

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

    Bonjour,

    J'ai utilisé OpenFire il y a environ 2 ou 3 ans, j'avais été séduit en particulier pour sa configuration par interface graphique vraiment pratique. Malheureusement, les mises à jours se font rares, j'avais de petits bugs non critiques mais non corrigés pendant des mois, les comptes utilisateurs devaient être sur le ldap ou sur un compte interne mais pas les 2 à la fois, ou un truc du genre. Il me semble que le bochs n'était pas tout à fait compatible avec les clients web que je voulais utiliser. Je ne sais plus exactement ce qui m'a décidé mais finalement j'ai laissé tomber pour ejabberd.

    Ejabberd consomme moins de mémoire et de ressource cpu, il plante moins, et il est ultra configurable. On peut facilement étendre l'identification en utilisant pam ou autre ce qui m'a permis quelques bidouilles fort utiles.

    Sur le site dont je m'occupe, nous avons une contrainte forte : interdiction de sauvegarder un mot de passe et aucun mot de passe ne doit passer en clair. Afin d'éviter de redemander aux utilisateurs déjà identifiés sur le site (via ldap) de se relogguer pour accéder au chat, nous générons un mot de passe à usage temporaire (le temps de la session) qui sert de mot de passe pour jabber. Ainsi les clients web utilisent ce mot de passe pour s'authentifier. Ceci était plutôt simple à mettre en place avec ejabberd et tout simplement impossible avec OpenFire.

    Dans les clients, nous utilisons principalement gajim en client lourd et jappix + muckl en client web. Pour faire marcher Jappix, il a juste fallu configurer ejabberd pour activer bochs, je ne vois pas ce qu'une intégration pourrait apporter de plus, surtout que notre jappix est intégré au portail web (et comme expliqué, se connecte sans demande de mot de passe si l'utilisateur est déjà connecté au portail).

    • [^] # Re: Retour d'expérience diverse

      Posté par  . Évalué à 2.

      Sur le site dont je m'occupe, nous avons une contrainte forte : interdiction de sauvegarder un mot de passe et aucun mot de passe ne doit passer en clair. Afin d'éviter de redemander aux utilisateurs déjà identifiés sur le site (via ldap) de se relogguer pour accéder au chat, nous générons un mot de passe à usage temporaire (le temps de la session) qui sert de mot de passe pour jabber. Ainsi les clients web utilisent ce mot de passe pour s'authentifier. Ceci était plutôt simple à mettre en place avec ejabberd et tout simplement impossible avec OpenFire.

      Intéressant. Tu as des billes, là-dessus? Genre module d'eJabberd utilisé? Comment eJabbard vérifie-t-il que le mot de passe est valide?

      Est-ce que ça peut fonctionner combiné avec une authentification plus classique (genre mot de passe "normal" depuis un client Jabber natif, mais one-time-password depuis une connexion BOSH?

      • [^] # Re: Retour d'expérience diverse

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

        Dans la conf, j'utilise "internal" pour les comptes locaux comme "admin" et "pam" pour le ldap, les comptes locaux autorisés et l'authentification internet (celui avec un mot de passe différent).

        {auth_method, [internal, pam]}.
        {pam_service, "ejabberd"}.

        Je ne vais pas expliquer le fichier /etc/pam.d/ejabberd pour 2 raisons : j'ai fait ça il y a longtemps et je n'ai pas le temps :). Mais en gros, il faut utiliser pam_mysql.

        account sufficient pam_mysql.so user=monlogin passwd=monmdp host=localhost db=site_etud table=sessions usercolumn=login passwdcolumn=sid crypt=0
        auth sufficient pam_mysql.so user=monlogin passwd=monmdp host=localhost db=site_etud table=sessions usercolumn=login passwdcolumn=sid crypt=0

        @include common-account
        @include common-session
        @include common-auth

        auth required pam_shells.so
        auth required pam_listfile.so item=user sense=allow file=/etc/jabberusers onerr=fail

        • [^] # Re: Retour d'expérience diverse

          Posté par  . Évalué à 2.

          Merci pour ta réponse. Là où je coince un peu, c'est dans le schéma général de ton truc. Dis-moi si j'ai bien compris.

          • Lors de la connexion à ton appli/portail/truc d'un utilisateur, un mot de passe temporaire est généré et stocké en base.
          • Lors du clic sur un lien "le chat est par là" (en substance), tu passes ce mot de passe à Jappix via GET (je ne me souvenais pas que Jappix savait faire ça, mais je vois ça comme une bonne nouvelle).
          • Et donc Jappix utilise ce mot de passe "contre" la base pré-renseignée, et ça roule.

          C'est ça, l'idée?

          • [^] # Re: Retour d'expérience diverse

            Posté par  (site web personnel) . Évalué à 2. Dernière modification le 05 avril 2012 à 15:22.

            C'est plus ou moins l'idée. En gros Jappix utilise Bochs pour communiquer avec le serveur distant et donc à un moment où à un autre, il va envoyer, via un script JS, le login et le mot de passe. Il ne passe pas de mot de passe en GET à proprement parler puisque Jappix tourne côté client, c'est le serveur PHP qui va altérer le code de Jappix pour renseigner login et mot de passe (le login et le mot de passe sont enregistrés dans une session).

            Ici on utilise Jappix Mini, voici la doc : http://codingteam.net/project/jappix/doc/JappixMini

            Tu y vois notamment : launchMini(autoconnect, show_pane, domain, username, password); Et c'est donc dans le script JS qu'on rajoute un brin de PHP pour modifier le login/password pour que le client utilise le mot de passe temporaire.

            Le principe doit aussi marcher avec du Jappix classique puisque c'est le client qui communique avec le serveur Jabber, donc il suffit de remplacer le formulaire pour le compléter automatiquement en PHP.

  • # Pour ma part, ejabberd fonctionne très très bien

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

    Pour ma part, ejabberd fonctionne très très bien… je l'utilise depuis 3 ans, aucun problème, il est super stable.

    Pour information, Erlang est super adapté pour ce type de projet.

  • # 3 petits chats

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

    Il y a aussi d'autres protocoles intéressants pour chatter en liberté:

    • IRC qui a pris un sacré coup de vieux mais qui reste très pratique et très utilisé pour le chat de groupe sans authentification. Le manque d'authentification est un problème pour retrouver les gens, il faut souvent s'envoyer un mail "on se retrouve sur tel serveur, tel chan".
    • les tribunes qui grâce aux norloges sont la meilleure technologie pour le chat de groupe. L'absence de chat privé les empêche de dominer le monde.
    • Mumble spécialisé dans le chat par voix durant les jeux.
    • Retroshare qui fonctionne sans serveur et proposent une messagerie de type mail, des forums et du partage de fichiers.
    • psyced, un serveur qui permet de servir IRC, XMPP, web, telnet.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: 3 petits chats

      Posté par  . Évalué à 3.

      IRC qui a pris un sacré coup de vieux mais qui reste très pratique et très utilisé pour le chat de groupe sans authentification. Le manque d'authentification est un problème pour retrouver les gens, il faut souvent s'envoyer un mail "on se retrouve sur tel serveur, tel chan".

      Moué, à tel point que de plus en plus de projets libres passent désormais par des "MUC" Jabber pour ce genre d'usage. Avec un client comme poezio, la différence avec irssi est tout juste discernable. Et il y a des clients web très corrects (i.e. sans Flash, ni proxy Websocket sur le serveur, ni latences de malade) pour les accès anonymes.

      les tribunes qui grâce aux norloges sont la meilleure technologie pour le chat de groupe. L'absence de chat privé les empêche de dominer le monde.

      Hem ;)

      Mumble spécialisé dans le chat par voix durant les jeux.

      Son problème majeur, en termes de protocole, étant d'être la seule et unique implémentation. Libre, certes, mais néanmoins.

      Retroshare qui fonctionne sans serveur et proposent une messagerie de type mail, des forums et du partage de fichiers.

      Et qui ne marche pas très bien dans les réseaux où l'on n'est pas admin (i.e. au boulot). Sinon, même souci que Mumble.

      psyced, un serveur qui permet de servir IRC, XMPP, web, telnet.

      Pas vraiment un protocole non plus ;)

      • [^] # Re: 3 petits chats

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

        Moué, à tel point que de plus en plus de projets libres passent désormais par des "MUC" Jabber pour ce genre d'usage.

        On voit quand même une écrasante majorité de chan IRC dans le libre…

        Pas vraiment un protocole non plus ;)

        En fait, il y a le protocole psyc et pysced le serveur qui lui est capable de parler d'autres protocoles.

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: 3 petits chats

          Posté par  . Évalué à 2.

          Je ne sais pas, je n'ai pas de stats précises. Il y a quelques années, j'aurais été aussi convaincu que toi. Aujourd'hui, ça me semble moins écrasant - même s'il reste du chemin.

          • [^] # Re: 3 petits chats

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

            Les salons de chat sont généralement enfouis sous 36 menus et difficiles à utiliser avec beaucoup de clients XMPP, ceci explique peut être cela.

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: 3 petits chats

              Posté par  . Évalué à 2.

              Sauf quand le site du projet te file un lien en xmpp:. Un peu comme IRC quoi :)

              • [^] # Re: 3 petits chats

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

                Et il faut un compte pour que ça marche…

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                • [^] # Re: 3 petits chats

                  Posté par  . Évalué à 2.

                  Pas forcément. Des webclients Jabber gèrent ça très bien (genre https://jappix.com/?r=support@muc.jappix.org).

                  Après, je ne connais pas de client "lourd" qui gère ce genre de choses, mais à mon avis c'est surtout un manque d'usage : quand tu as pris la peine de télécharger un client, c'est que tu envisages d'avoir un compte Jabber quelque-part.

                  • [^] # Re: 3 petits chats

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

                    quand tu as pris la peine de télécharger un client, c'est que tu envisages d'avoir un compte Jabber quelque-part

                    J'ai un compte au boulot, mais le serveur n'est pas connecté vers l'extérieur, ça m'ennuie d'utiliser mon compte perso ou d'en créer un juste pour faire poser une question sur projet. Du coup, la paresse me fait préférer IRC.

                    J'ai un serveur Jabber et je créerais bien un salon de support pour mes réalisations, mais je sais qu'à cause du manque de mise en avant par les clients, personne n'y viendra jamais…

                    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: 3 petits chats

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

      Le manque d'authentification [d'IRC]

      Et le manque de fédération comme Jabber. IRC a une conception à la USENET ou PGP, destinée à former un anneau unique de serveurs synchronisés, seulement ce réseau a explosé et il y a aujourd'hui de multiples réseaux IRC disjoints.

Suivre le flux des commentaires

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