Outils du site

fr:xmpp_server

Serveur Xmpp

Article en brouillon, noté sur le pouce ; transfert de page, rien de neuf.

Se faire héberger par les copains

Il est possible de laisser quelqu'un d'autre gérer le serveur (pour nous, c'est jabberfr.org), tout en ayant des salons dans le genre khaganat@chat.khaganat.net, ce qui est quand même plus classe.

Dans les bonnes pratiques XMPP, il est plus élégant d'héberger les salons avec un sous-domaine, par exemple chat.mondomaine.com, que directement sur le domaine de base ; par contre la création de compte se fait sur le domaine (adresses en pseudo@mondomaine.com).

Pour cela, après un accord passé avec un hébergeur, il faut faire pointer le nom de domaine au bon endroit.

Exemple sur Gandi :

chat 	CNAME 	jabberfr.org.

Voir aussi https://prosody.im/doc/dns#srv_records et https://github.com/letsencrypt/boulder/issues/1309

Installation de base du serveur Prosody

Nous installons un serveur XMPP chez nous, ça va servir en jeu aussi à terme. Nous mettons Prosody, parce que c'est Link Mauve qui l'a dit :D (et que ça a l'air de faire son job, c'est ce qui compte).

Les paquets sous Debian Jessie/stretch sont un peu vieux ; il faut donc aller chercher à la source.

La doc de Prosody est très bien ; je traduis le principal pour Debian. Tout en root .

Ajouter les sources :

  echo deb http://packages.prosody.im/debian $(lsb_release -sc) main | tee -a /etc/apt/sources.list.d/prosody.list

Ajouter la clé :

wget https://prosody.im/files/prosody-debian-packages.key -O- | apt-key add -

apt-get update

Télécharger la bonne version :

apt-get install prosody

Ajouter des dépendances optionnelles qui devraient être pratiques :

apt-get install lua-sec lua-event lua-zlib

Ensuite on configure Prosody. Comme le dit la doc sur Jabberfr, faut surtout lire tranquillement /etc/prosody/prosody.cfg.lua.

Une fois que le serveur sera lancé et un utilisateur créé, ajouter son nom à la valeur admins = { }.

J'ai décommenté le module “blocklist”; parce que ça me parait essentiel ; je verrais si ça prend des ressources…

Le reste je verrais quand ça tournera.

Je donne le nom du serveur à VirtualHost

Ensuite… la partie amusante : les certificats. J'utilise let's encrypt, il faut donc pointer vers le bon certificat. Sauf que prosody ne peux pas lire les fichiers dans /etc/letsencrypt/live/* donc on utilise leur outil .

prosodyctl --root cert import /etc/letsencrypt/live

Il faudrait refaire ça à chaque renouvellement de let's encrypt ? Oui.

Et voilà à quoi ça ressemble dans /etc/prosody/prosody.cfg.lua (sans les commentaires) :

VirtualHost "khaganat.net"

Ensuite on redémarre prosody pour prendre en compte les modifications et on vérifie que ça marche :

prosodyctl restart
prosodyctl status

On regarde aussi dans /var/log/prosody/prosody.* si tout va bien.

On crée ensuite un utilisateur directement en ligne de commande (vu que je n'ai pas encore ouvert les inscriptions !) :

prosodyctl adduser me@example.com

Ensuite il faut ouvrir les bons ports.

iptables -t filter -A INPUT -p tcp --dport 5222 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 5269 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5222 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5269 -j ACCEPT

iptables -t filter -A INPUT -p tcp --dport 5000 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5000 -j ACCEPT

iptables -t filter -A INPUT -p tcp --dport 5280 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 5281 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5280 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 5281 -j ACCEPT

<WRAP center round help 60%> Ce n'est pas sensé sauter au redémarrage si je fais juste ça ?

Edit : Oui, il faut faire une sauvegarde des règles iptables avec iptables-save dans /etc/sysconfig/iptables

Pour vérifier que les ports sont bien ouverts :

nmap serveur.com

</WRAP >

Nous utilisons des VM XEN en NAT, donc dans l'hyperviseur :

iptables -t nat -I POSTROUTING -o eno1 -j MASQUERADE
 
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port 5222 -j DNAT --to 192.168.*.*:5222
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port 5269 -j DNAT --to 192.168.*.*:5269
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port 5222 -j DNAT --to 192.168.*.*:5000
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port 5269 -j DNAT --to 192.168.*.*:5280
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port 5222 -j DNAT --to 192.168.*.*:5281

Ajouter des modules

Voir aussi https://prosody.im/doc/components.

Le serveur de base est très bien, mais la grande force d'XMPP c'est qu'on peut lui ajouter des fonctionnalités via des modules, ou “components”. Les composants sont des services à par entière, qui seront lancés sur un serveur (pas forcément celui où prosody est installé) ; prosody va ensuite aller interroger les services qu'on lui demande, en se connectant à une adresse ip et un port et en échangeant un secret (ou mot de passe) avec le composant. Dans le cas des composants en interne, le mot de passe n'est pas nécessaire.

Si le composant est déjà intégré dans Prosody, il suffit de l'activer dans sa configuration, par exemple en ajoutant ceci dans le fichier de configuration, qui ajoutera la possibilité de créer des salons de discussion :

Component "conference.example.org" "muc"

Si le composant n'existe pas déjà dans Prosody, il faut qu'il utilise le protocole XEP-0114 (classique pour les extensions XMPP). Pour ajouter un composant externe, Prosody doit connaître l'adresse, le port (par défaut 5347, utilisé par la plupart des applications) et le mot de passe (ou “secret”) que le composant utilise.

Si le composant a besoin d'un sous-domaine pour fonctionner, comme conference.example.org, il faut paramétrer ce sous-domaine du côté du DNS et s'assurer qu'il est couvert par un certificat ssl.

proxy

Component “proxy.myserver.org” “proxy65”

upload

Component “dump.myserver.org” “http_upload”

Modules utiles

Voici une liste non-exhaustive des modules intéressants, conseillés par Link Mauve sur cette dépêche de Linuxfr :

  • https://candy-chat.github.io/candy/ : interface web pour se connecter à un salon (comme le webchat irc !) ;
  • https://xmpp.org/extensions/xep-0175.html et https://modules.prosody.im/mod_muc_ban_ip.html pour gérer les connexions anonymes et virer les troubles-fêtes au besoin ;
  • https://biboumi.louiz.org/ pour faire une passerelle avec IRC ;
  • Stream Management (XEP-0198), qui permet de savoir si l’on a bien reçu tous les messages du serveur et vice versa, ainsi que de restaurer une session qui s’est terminée de façon impromptue (pour des problèmes de réseau, par exemple) ;
  • Message Carbons (XEP-0280), qui fait que le serveur duplique les messages émis ou reçus aux différents clients connectés qui prennent en charge l’extension, garantissant une transition totalement transparente d’un appareil à un autre ;
  • Message Archive Management (XEP-0313), qui est la spécification de référence pour les archives de messages XMPP côté serveur, permettant d'avoir les logs de ce qui s'est dit ;
  • Client State Indication (XEP-0352), qui permet à un client de signaler son état d’inactivité au serveur, auquel cas le serveur aura l’autorisation de filtrer un certain nombre d’éléments non essentiels quand le client est inactif, diminuant ainsi la bande passante utilisée et améliorant l’autonomie d’autant ;
  • XMPP Subprotocol for WebSocket (RFC 7395), qui vient rejoindre XMPP over BOSH (XEP-0206) pour fournir aux clients Web un moyen de se connecter directement au serveur, cette fois‐ci en collant mieux au fonctionnement par TCP classique, tout en permettant de contourner le blocage mis en place sur certains réseaux ;
  • Blocking Command (XEP-0191) pour le filtrage des communications indésirables, d’une façon simple à implémenter pour les clients et efficace côté serveur ;
  • HTTP Upload (XEP-0363), pour permettre aux utilisateurs d’envoyer de petits fichiers sur le serveur, certains clients comme Conversations ou Gajim l’utilisent pour envoyer des images à l’intérieur des messages ;
  • Push Notifications (XEP-0357), pour les clients mobiles tournant sur un système d’exploitation restrictif quant aux connexions restant ouvertes (iOS, Windows Phone, Android 6+), permet de notifier au serveur du fabricant que le client a reçu un message, qui le transférera à ce dernier pour le réveiller. Il est à noter qu’à aucun moment les serveurs du développeur de l’application, ni ceux d’Apple, Google ou Microsoft n’ont accès au contenu ni à l’expéditeur du message : uniquement « tel téléphone a reçu un message ».
fr/xmpp_server.txt · Dernière modification: 2019/01/14 09:22 par Deed