Le but de ce tutoriel est l’installation et la mise en fonction d’un serveur XMPP/Jabber (ici Ignite Realtime Openfire 3.6.4). Une partie sera consacrée au DNS et une autre à l’installation d’un certificat signé par une autorité.

Ce tutoriel est basé sur une expérience d’installation de Openfire 3.6.4 sur une Centos-5.3 et une Debian-Squeeze avec une base de données PostgreSQL.

De plus, un service XMPP/Jabber n’est pas un service anodin, il impose une certaine responsabilité quant à son administration et à sa modération : en effet, il permet aux gens de s’exprimer, de mettre en relation des gens qui n’ont pas forcément les mêmes opinions… De ce fait, le niveau de ce tutoriel demande une certaine maîtrise du système et de son administration. Cela permet également au tutoriel de ne pas entrer dans trop de détails et de rester clair.

Pour mener à bien ce tutoriel vous avez besoin de :

• un système GNU/Linux, avec accès au root, et un système de distribution des mails locaux (postfix ou exim ou autre)
• l’archive d’installation adaptée à votre système (.deb, .rpm, .tar.gz) de openfire-3.6.4 avec ou sans machine virtuelle java intégrée : disponible sur le site officiel : http://www.igniterealtime.org/projects/openfire/index.jsp
• avoir de quoi installer la machine virtuelle java-1.6 de Sun (ou 1.5) (inutile si l’archive d’installation intègre déjà la machine virtuelle java)
• avoir de quoi installer une base de donnée PostgreSQL ou MySQL (facultatif : Openfire dispose aussi de sa propre base de donnée embarquée)
• pour la partie concernant le DNS :
  • avoir accès en écriture à la configuration du DNS de votre nom de domaine (une sauvegarde de votre configuration DNS actuelle ne sera pas de trop)
  • avoir de la patience lors de la mise à jour des DNS (propagation des changements)
• pour la partie concernant le certificat signé d’autorité :
  • avoir accès à la boîte mail principale de votre nom de domaine (webmaster ou root ou autre @domaine.tld)
  • avoir votre dernier certificat personnel d’accès au site de l’autorité de certification (ex. : startssl.com) (si vous êtes déjà inscrit sur un tel site)
  • avoir accès à la boîte mail utilisée pour ouvrir le compte d’accès au site d’autorité de certification (si vous êtes déjà inscrit sur un tel site)

Si nécessaire, installer le JRE de java Sun 1.6 (ou 1.5).

Note : Le paquet réclame la machine virtuelle java de Sun à l’installation. Il semblerait openfire puisse fonctionner avec OpenJDK, mais il faut bricoler pour outrepasser les dépendances du paquet.

Si nécessaire, installer MySQL ou PostgreSQL écoutant sur l’interface 127.0.0.1.

Note : il est possible d’utiliser une connexion via socket…

Comme un autre paquet du système (en respectant les dépendances requises) : installer le paquet openfire-3.6.4 sur le système.

Note : sur Centos, openfire s’installe dans /opt/openfire/ ; sur debian, il s’installe dans /usr/share/openfire/ et /etc/openfire/.

En ce qui concerne java, il n’y a rien à faire de plus pour l’instant.

On considère ici que la distribution des mails est locale et fonctionne. En root :

1. On crée un alias openfire@localhost de root@localhost pour distribuer le courrier venant du service openfire ; ajouter la ligne suivante dans le fichier /etc/aliases :

   openfire: root

2. On informe le service de distribution qu’il y a un nouvel alias avec la commande :

   newaliases

Le tutoriel se concentre sur PostgreSQL. Pour MySQL, il faut adapter, mais les étapes resteront les mêmes.

1. Autoriser la connexion de l’utilisateur système openfire à la base de données : éditer le fichier pg_hba.conf

   # "local" is for Unix domain socket connections only
   local   all         all                               password
   # IPv4 local connections:
   host    all         all         127.0.0.1/32          password
   # IPv6 local connections:
   host    all         all         ::1/128               md5

   
   Redémarrer le service postgresql

2. Se connecter en administrateur de la base de données (utilisateur système postgres par défaut), créer l’utilisateur openfire au niveau du serveur de base de données et se déconnecter :

   su - postgres
   createuser openfire -P
   exit

   
   Pour les questions posées : — choisir un mot de passe pour openfire ; — que l’utilisateur n’est pas superutilisateur ; — qu’il peut créer une base de données ; — mais qu’il ne peut pas créer de rôle.

3. Chercher le script d’initialisation de la base de données (dans répertoire openfire/resources/database, créer la base de données et lancer le script :

   cd /usr/share/openfire/resources/database
   createdb -W -U openfire -E UNICODE openfire
   psql -U openfire -W -d openfire -f openfire_postgresql.sql

Cette partie se déroule à partir d’un navigateur. Largement inspiré du tutoriel http://www.classhelper.org/articles/debian-openfire-chat-server/openfire-server-install-p1.shtml

1. Se rendre à l’adresse http://localhost:9090/, l’assistant de configuration vous y attends
   1. Choisissez la langue : le français est un bon choix dans nos contrées.
   2. Choisissez le nom de domaine que le service prendra en charge : domaine.tld (par exemple et pour la suite du tutoriel)) tel que les JID seront de la forme pseudo@domaine.tld ;
      ainsi que les ports d’accès à la console d’administration : laisser 9090 et 9191 est une bonne idée ; veillez (c’est un conseil) à garder la console non sécurisée (9090) en local (pas d’accès depuis internet à cette console).
   3. Choisissez d’utiliser une connexion à une base de données standard (PostgreSQL ou MySQL) ou à une base de données embarquée.
   4. Si une base de données standard est choisie :
      • choisir la pré-sélection PostgreSQL ou MySQL comme nécessaire.
      • laisser le pilote java JDBC Class comme suggéré : org.postgresql.Driver.
      • compléter les parties entre crochets ([]) : jdbc:postgresql://localhost:5432/openfire.
      • saisir le nom d’utilisateur openfire et son mot de passe associé, ceux de la partie 2. de la Configuration de PostgreSQL (ci-dessus)
      • laisser les valeurs par défaut des nombres et temps de connexion à la base de données : 5, 25, 1.0.
   5. Choisir une méthode de stockage des comptes : en ce qui nous concerne, la configuration par défaut est tout à fait indiquée.
   6. Pour le dernier écran, indiquer l’adresse email vers laquelle seront redirigés les mails envoyés par le serveur openfire : openfire@localhost est tout à fait indiqué ; ainsi que le mot de passe (2×) de l’administrateur admin ayant accès à la console d’administration. Cliquer sur continue.
2. Redémarrer le service openfire et attendre environ 30 sec à 1 min avant de se connecter à la console d’administration avec les identifiants de l’administrateur admin ci-dessus.
3. Se connecter à la console d’administration
4. Aller sur la page Serveur/Paramètres du Serveur/Serveur à serveur et Activer la connexion Serveur à serveur avec le port 5269
5. Aller sur la page Salon de discussion/Paramètre de Salon de discussion/Service summary et récupérer ou modifier le nom du sous-domaine pour le service de salon discussion (devrait être conference) ; ce qui veut dire que le domaine de l’adresse XMPP des salons de discussion sur ce serveur sera salon@conference.domaine.tld.

En général, votre modem ADSL est configuré en mode routeur (le serveur est connecté au réseau local derrière le routeur ADSL), de plus le modem routeur filtre les ports ouverts depuis Internet vers le réseau local. Accéder à l’interface de configuration des ports et, selon le modem, il s’agira d’ouvrir les ports ou d’effectuer la translation (NAT) des ports vers l’IP locale du serveur et les mêmes numéros de ports :

• 5222 : le service principal XMPP client à serveur (C2S), il permet la connexion non chiffrée, connexion chiffrée TLS, et discussion…
• 5223 : le service principal XMPP client à serveur (C2S) chiffré SSL (protocole ancien encore nécessaire pour certains vieux clients XMPP)…
• 5269 : la connexion serveur à serveur (S2S), permet la connexion entre les différents réseaux XMPP gérés par d’autres serveur (jabber.fr, talk.google.com, etc.) ; sans ce port, seuls les utilisateurs inscrits sur ce serveur auront accès aux services de ce serveur.

Ce sont les ports principaux nécessaire pour le service minimum ; sur la page principale de la console d’administration, une liste des services disponibles pour ce serveur avec leurs ports est affichée.

À noter que les services proposés sur les ports 9090 et 9191 sont les consoles d’administration et qu’il est plutôt judicieux d’en limiter l’accès depuis internet. Bannir le 9090 sur Internet est même une très bonne idée.

À ce moment-là, le service est utilisable et accessible depuis l’extérieur, à l’exception que les autres réseaux XMPP ne peuvent probablement pas se connecter à ce service puisque le nom de domaine de ce service (et des JID de comptes inscrits sur ce serveur) n’est pas configuré ; c’est l’objet des sections Configuration du DNS et Certificat non auto-signé.

Pour cette partie, il faut évidemment avoir accès à la configuration du DNS ou au moins à la configuration de la zone (domaine) dans laquelle le service XMPP sera servi. Avec un service DNS bind9, pour le domaine XMPP domaine.tld et conference.domaine.tld avec les ports 5222 et 5269 et l’adresse publique du serveur (l’adresse du routeur) 123.123.123.123 :

_xmpp-client._tcp 3600 IN SRV 5 0 5222 domaine.tld.
_xmpp-server._tcp.conference 3600 IN SRV 5 0 5269 domaine.tld.
_xmpp-server._tcp 3600 IN SRV 5 0 5269 domaine.tld.
@ 10800 IN A 123.123.123.123

2012-06-21 : En cours de rédaction… — Mickey86

Il certifie que le serveur est bien celui qu'il prétend être !

En fait, avec chaque communication (lorsqu'elle est chiffrée), le serveur va envoyer une signature unique sur Internet qui permettra d'être sûr de toujours avoir à faire au même serveur (un autre serveur ne peut pas se faire passer pour lui) et que les conversations sont authentiques (personne ne peut modifier les conversations entre le serveur et le client sans que ça se sache).

Il subsiste un problème : même si c'est toujours le même serveur et que les messages sont authentiques, rien ne prouve qu'il s'agit bien du serveur que l'on souhaite !

C'est pour pallier à ce problème qu'un certificat signé par une autorité de certification reconnue est nécessaire.

L'autorité de certification approuve (en signant de son propre certificat) qu'elle a vérifié l'identité du détenteur du certificat qu'elle signe.

L'autorité de certification startssl.com délivre des certificats signés par elle-même gratuitement. startssl.com permet de bénéficier de certificats ne nécessitant pas une vérification d'identité au niveau individuel (nom, prénom, adresse), mais au niveau d'une structure gérant son nom de domaine (demande la preuve que vous avez accès à l'administration du nom de domaine), ce certificat est valable pendant 1 an et ne dépasse pas 2048 bits ; ce qui est amplement suffisant pour beaucoup de services Internet ne partageant pas de données sensibles ou à caractère confidentiel ; notamment notre messagerie instantanée XMPP app3l.org.