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 GG (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 zerkman (site web personnel) . Évalué à 7.
c'est peut-être pour ça que https existe ?
[^] # Re: Autres logiciels
Posté par neil . É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 à gazmachine 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).Ç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 CrEv (site web personnel) . Évalué à 2.
En quoi ?
Tu sais, t'es pas obligé de les ouvrir sur l'extérieur…
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 BAud (site web personnel) . Évalué à 2. Dernière modification le 12 avril 2012 à 08:37.
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 Larry Cow . Évalué à 3.
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 MTux . É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 Goffi (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 Milridor (site web personnel) . Évalué à 3.
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 🚲 Tanguy Ortolo (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 🚲 Tanguy Ortolo (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 Maxime (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 Larry Cow . Évalué à 2.
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 Maxime (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.
[^] # Re: Retour d'expérience diverse
Posté par Larry Cow . É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.
C'est ça, l'idée?
[^] # Re: Retour d'expérience diverse
Posté par Maxime (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 Stéphane Klein (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 devnewton 🍺 (site web personnel) . Évalué à 5.
Il y a aussi d'autres protocoles intéressants pour chatter en liberté:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: 3 petits chats
Posté par Larry Cow . Évalué à 3.
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.
Hem ;)
Son problème majeur, en termes de protocole, étant d'être la seule et unique implémentation. Libre, certes, mais néanmoins.
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.
Pas vraiment un protocole non plus ;)
[^] # Re: 3 petits chats
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
On voit quand même une écrasante majorité de chan IRC dans le libre…
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 Larry Cow . É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 devnewton 🍺 (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 Larry Cow . É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 devnewton 🍺 (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 Larry Cow . É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 devnewton 🍺 (site web personnel) . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
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.