Outils pour utilisateurs

Outils du site


admin:services:xmpp

Ceci est une ancienne révision du document !


XMPP

XMPP (ou eXtensible Messaging and Presence Protocol) est un ensemble de protocoles standards ouverts de l’Internet Engineering Task Force (IETF) pour la messagerie instantanée, et plus généralement une architecture décentralisée d’échange de données. XMPP est également un système de collaboration en quasi-temps-réel et d’échange multimédia (Wikipédia).

On utilise comme serveur le logiciel ejabberd, écrit en erlang et développé avec des réseaux d'entreprise en tête. La plus populaire alternative est prosody (lua). Par rapport à prosody, ejabberd bénéficie d'un rythme de développement plus rapide (judicieux pour le support des dernières extensions du protocole), et d'une plus grande cohérence/qualité dans les modules à disposition (ce qui facilite grandement l'administration).

Mise en place du serveur

Installation

ejabberd est packagé dans pour stretch.

sudo apt install ejabberd

Configuration

ejabberd utilise le format yaml pour son fichier de configuration.

Le yaml est sensible à l'indentation, qui doit être faite uniquement avec des espaces…

La Documentation officielle est très complète (peut-être trop).

Voici un résumé des modifications par rapport au fichier par défaut :

hosts

/etc/ejabberd/ejabberd.yml

hosts:
  - "federez.net"

Certificats

Depuis la version 17.10, ejabberd implémente ACME et devrait donc pouvoir gérer lui-même ses certificats et leur renouvellement automatique. Dans la pratique, ça n'est pas possible car on souhaite fournir aux usagers un ID de la forme joe@federez.net (au lieu de joe@xmpp.federez.net), il faut donc que dodecagon (vers qui pointe le NDD) signe le certificat pour utilisation par dragon.

On a donc au minimum besoin d'ajouter les lignes suivantes au script /root/scripts/renew_letsencrypt_certificates.sh sur dodecagon:

/usr/bin/letsencrypt certonly --cert-name dragon.federez.net --config /etc/letsencrypt/cli.ini --non-interactive --quiet \
  -d federez.net \
  --text

ejabberd supporte un format de certificats concaténés:

cat /etc/letsencrypt/live/dragon.federez.net/privkey.pem /etc/letsencrypt/live/dragon.federez.net/fullchain.pem > /tmp/ejabberd.pem
scp /tmp/ejabberd.pem ejabberd@dragon.federez.net:~/ejabberd.pem

On oubliera évidemment pas d'adapter en conséquence le code de vérification.

Du coté de dragon, il faut ensuite ajouter la clé publique de root@dodecagon au fichier ~ejabberd/.ssh/authorized_keys. On ajoute au début de la ligne les restrictions suivantes :

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -t ~/ejabberd.pem" ssh-ed25519 AAAAC3...

On peut ensuite remplacer toutes les apparition de certfile: dans /etc/ejabberd/ejabberd.yml par:

certfile: "<ejabberd home>/ejabberd.pem"

Côté dragon, certbot est également utilisé pour générer les certificats qui seront utilisés par 'mod_http_upload' pour l'envoi de fichiers.

Au final, ejabberd gère donc les certificats:

certfiles:
  - "/var/lib/ejabberd/ejabberd.pem" ← pour la connexion des utilisateurs
  - "/var/lib/ejabberd/ejabberd-http.pem" ← pour le reste (http-upload)
<code>

===Authentification LDAP===

On souhaite fournir ce service à tous les membres de FedeRez, on utilise donc l'authentification LDAP.
ejabberd ne supporte pas ldap avec STARTTLS, on utilise  donc ldaps sur le port 636.

On commente donc ''auth_method: internal'' et on remplit le bloc ldap:
<code>
auth_method: ldap
ldap_servers:
  - "ldap.federez.net"
ldap_encrypt: tls
ldap_port: 636
ldap_rootdn: "cn=xmpp,ou=service-users,dc=federez,dc=net"
ldap_password: "P455w02d"
ldap_base: "ou=users,dc=federez,dc=net"
ldap_uids:
  - "cn": "%u"

On n'oubliera bien-sûr pas de créer l'utilisateur ad-hoc sur le LDAP federez.

Access Control

On ne veut pas laisser le serveur grand ouvert, on va donc restreindre l'accès à certaines fonctionnalités:

  register:
    - deny

Bridge IRC

On utilise [admin:services:biboumi] pour relier le serveur XMPP à IRC.
Par défaut, [admin:services:biboumi] se connecte sur le port 5347, on modifie donc le bloc ejabberd_service en conséquence :

  -
    port: 5347
    module: ejabberd_service
    access: local
    shaper_rule: fast
    ip: "127.0.0.1"
    privilege_access:
       roster: "both"
       message: "outgoing"
       presence: "roster"
    hosts:
      "irc.xmpp.federez.net":
        password: "<gateway password>"

À noter : le mot de passe est le même que celui défini dans la conf de biboumi.

Biboumi n'est pas packagé pour debian, il faut donc le compiler depuis les sources:

  • un checkout du dépôt git officiel se trouve dans dragon:/home/lhark/build/biboumi.
  • depuis ce dossier, la compilation se fait avec cmake . && make -j5 && sudo make install
  • Biboumi fournit un fichier d'unit systemd, donc service biboumi start suffit pour lancer le service

À l'heure actuelle, Biboumi stocke les logs des utilisateurs dans une base de données sqlite: /var/lib/biboumi/biboumi.sqlite
Depuis la version 7, il est possible d'utiliser postgresql pour ça, et migrer sur un serveur pg backupé est un point d'amélioration intéressant pour la pérennité des logs IRC.

SSLH/Multiplexing

En l'état, ejabberd écoute sur une série de ports (5222, 5280, 5444) pour fournir certains services côté client (XMPP-server, bosh+websockets, http upload) qui, du coup, peuvent se retrouver indisponibles derrière des connexions censurées (hôtel, aéroport, public hostpot, café, …) ne laissant généralement que le 80/443 ouverts. L'idée est de multiplexer ces services via le port 443 en utilisant sslh.

sslh est désormais déployé, est sa configuration se trouve dans /etc/sslh.cfg

DNS/SRV Records

XMPP supporte désormais un mode de connexion qui autorise l'envoi de SSL direct (ce qui évite un round-trip comparé à starttls), et sslh permet de multiplexer ce type de streams. Afin que les clients (surtout mobiles) en bénéficient, il faut le renseigner dans les DNS

_xmpp-client._tcp.federez.net. 18000 IN SRV 4 0 5222 xmpp.federez.net.
_xmpp-client._tcp.federez.net. 18000 IN SRV 3 0 443 xmpp.federez.net.
_xmpps-client._tcp.federez.net. 18000 IN SRV 4 0 5223 xmpp.federez.net.
_xmpps-client._tcp.federez.net. 18000 IN SRV 3 0 443 xmpp.federez.net.
_xmpp-server._tcp.federez.net. 18000 IN SRV 0 5 5269 xmpp.federez.net.
_xmpps-server._tcp.federez.net. 18000 IN SRV 0 5 5270 xmpp.federez.net.

Pour tester l'enregistrement DNS:

dig srv _xmpp-client._tcp.federez.net
dig srv _xmpps-client._tcp.federez.net
...

Pour tester le multiplexing (et autres):

# XMPP client classique
openssl s_client -connect xmpp.federez.net:5222 -starttls xmpp -xmpphost federez.net
# XMPP client multiplexé over 443
openssl s_client -connect xmpp.federez.net:443 -starttls xmpp -xmpphost federez.net
# XMPP client direct (multiplexé)
openssl s_client -connect xmpp.federez.net:5223 -alpn xmpp-client -xmpphost federez.net
# XMPP client multiplexé over 443
openssl s_client -connect xmpp.federez.net:443 -alpn xmpp-client -xmpphost federez.net
# XMPP server classique
openssl s_client -connect xmpp.federez.net:5269 -starttls xmpp-server -xmpphost federez.net
# XMPP server direct
openssl s_client -connect xmpp.federez.net:5270 -alpn xmpp-server -xmpphost federez.net

Todo / futures améliorationss

  • MAM archives: En l'état les logs des utilisateurs sont stockés dans mnesia, dont la taille limite est de 2GB. Comme biboumi, ejabberd supporte PostgreSQL, il serait judicieux de migrer l'archivage des messages hors mnesia, et utiliser ejabberdctl delete_old_mam_messages périodiquement en attendant.
admin/services/xmpp.1521589906.txt.gz · Dernière modification : 2018/03/21 00:51 de Tamytro

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki