logo onlyoffice

Installation d’un serveur OnlyOffice Document Server pour l’associer à une instance Nextcloud

En effet, le projet Nextcloud distribue un package de la version communautaire du serveur OnlyOffice Document Server, installable en un clic, mais c’est une version orientée tests. En conséquence, il est déconseillé d’utiliser ce package pour de la production, même si c’est juste pour un petit cloud perso. Perso ne veut pas dire pas fiable ou de mauvaise qualité. De plus, dans certaines situations, il n’est pas possible d’utiliser ce package, par exemple quand la plateforme qui fait tourner l’instance Nextcloud n’est pas 64 bits. Dans ce cas, il faut en venir à réaliser sur une machine dédiée l’installation d’un serveur OnlyOffice Document Server pour l’associer à une instance Nextcloud qui tourne sur une autre machine.

Le but ici sera bien sûr de pouvoir utiliser l’éditeur en ligne de documents bureautique de OnlyOffice Document Server directement depuis l’interface web de Nextcloud.

L’installation va se faire sur un serveur motorisé par Debian Buster.

Navigation

Installation du serveur OnlyOffice Document Server

Comme d’habitude, il suffit de suivre la documentation d’installation.

Téléchargement de la clé publique du dépôt d’OnlyOffice :

apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys CB2DE8E5

Ajout d’un fichier apt de description du dépôt de paquets OnlyOffice:

echo "deb https://download.onlyoffice.com/repo/debian squeeze main" | sudo tee /etc/apt/sources.list.d/onlyoffice.list

Notons que le nom de la distribution « squeeze » ne correspond pas à la Debian utilisée ici, mais bon, ça fonctionne comme ça…

Rafraîchissement de la liste des paquets:

apt-update

Installation et configuration de la base de donnée postgresql:

apt-get install postgresql

sudo -i -u postgres psql -c "CREATE DATABASE onlyoffice;"

sudo -i -u postgres psql -c "CREATE USER onlyoffice WITH password 'onlyoffice';"

sudo -i -u postgres psql -c "GRANT ALL privileges ON DATABASE onlyoffice TO onlyoffice;"

Installation de l’agent de messages RabbitMQ:

apt-get install rabbitmq-server

Installation d’un gros pack de modules pour nginx, dont dépend le bon fonctionnement d’OnlyOffice:

apt-get install nginx-extras

Installation du package OnlyOffice: on renseignera bien « onlyoffice » comme utilisateur et mot de passe pour la base de données:

apt-get install onlyoffice-documentserver

L’installation de base est terminée, le serveur OnlyOffice est accessible sur le port 80.

accueil onlyoffice

Configuration du https pour le serveur OnlyOffice Document Server

Car c’est toujours mieux de chiffrer les flux. Les flux cités ici ne concernent que le trafic entre le serveur OnlyOffice et le paquage d’intégration dans Nexcloud. On ne va donc pas se casser la tête, et générer un certificat auto-signé qui dure bien longtemps pour être tranquille un moment.

mkdir /etc/ssl/onlyoffice

openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:4096 -keyout /etc/ssl/onlyoffice/onlyoffice.key -out /etc/ssl/onlyoffice/onlyoffice.crt

chown -R www-data:www-data /etc/ssl/onlyoffice

chmod 600 /etc/ssl/onlyoffice/onlyoffice.key

La suite se passe selon la documentation de configuration de OnlyOffice Document Server pour https. Et c’est tout simple, le package fourni un exemple de fichier de configuration pour nginx qu’il suffit de copier et de personnaliser.

service nginx stop

cp -f /etc/onlyoffice/documentserver/nginx/ds-ssl.conf.tmpl /etc/onlyoffice/documentserver/nginx/ds.conf

Les directives que j’ai personnalisées dans le fichier ds.conf sont les suivantes:

 listen 0.0.0.0:9443 ssl;
listen [::]:9443 ssl default_server;


 ssl_certificate /etc/ssl/onlyoffice/onlyoffice.crt;
ssl_certificate_key /etc/ssl/onlyoffice/onlyoffice.key;

Et c’est tout. J’ai configuré le virtual host nginx pour qu’il écoute le port 9443 car le 443 est réservé à l’instance Nextcloud (je n’ai qu’une IP publique).

On peut démarrer de nginx :

service nginx start

Et hop, le serveur OnlyOffice Document Server est joignable en https sur le port 9443. Cette instance devra également être accessible depuis internet (l’idée c’est qu’on puisse l’utiliser à travers Nextcloud depuis l’extérieur), il faudra alors soit faire une règle de port forwarding sur sa box ou son parefeu, soit paramétrer son reverse-proxy pour le rendre accessible de l’extérieur. Attention au NAT si le serveur OnlyOffice est dans le même réseau que le serveur Nextcloud, il est possible que ça ne fonctionne pas très bien.

La suite de l’article considère que l’instance de OnlyOffice Document Server est accessible depuis internet sur le port 9443.

Intégration à Nextcloud

Ben oui, on a fait tout ça pour pouvoir intégrer OnlyOffice à une instance Nextcloud, et ainsi pouvoir éditer des documents bureautique directement depuis celle-ci.

Comme on fait dans le crade depuis le début avec nos certificats auto-signés, on va s’assurer que OnlyOffice Document Server ne rejette pas le certificat de l’instance de Nextcloud en éditant le fichier  /etc/onlyoffice/documentserver/default.json pour y modifier la directive suivante:

rejectUnauthorized : false

On souhaite également configurer une clé d’authentification à notre instance OnlyOffice, de sorte que seule notre instance de Nextcloud (ou toute autre instance connaissant la clé) puisse utiliser le service de documents. Selon la documentation d’OnlyOffice, il faut éditer le fichier /etc/onlyoffice/documentserver/local.json pour qu’il ressemble à ceci (les lignes à éditer sont celles en couleur):

{
  "services": {
    "CoAuthoring": {
      "sql": {
        "type": "postgres",
        "dbHost": "localhost",
        "dbPort": "5432",
        "dbName": "onlyoffice",
        "dbUser": "onlyoffice",
        "dbPass": "onlyoffice"
      },
      "token": {
        "enable": {
          "request": {
            "inbox": true,
            "outbox": true
          },
          "browser": true
        },
        "inbox": {
          "header": "Authorization"
        },
        "outbox": {
          "header": "Authorization"
        }
      },
      "secret": {
        "inbox": {
          "string": "m0t2p433E+"
        },
        "outbox": {
          "string": "m0t2p433E+"
        },
        "session": {
          "string": "m0t2p433E+"
        }
      }
    }
  },
  "rabbitmq": {
    "url": "amqp://guest:guest@localhost"
  }
}

La chaîne m0t2p433E+ sera le secret partagé entre l’instance Nextcloud et l’instance OnlyOffice.

On redémarre toute la pile pour prendre en compte les modifications:

supervisorctl restart all

La suite se passe depuis l’interface web d’administration de Nextcloud, rubrique applications.

On ajoute d’abord l’application d’intégration d’OnlyOffice:

ajout application onlyoffice

Puis, depuis les paramètres de Nextcloud, à la rubrique ONLYOFFICE, renseigner les paramètres suivants:

Adresse du service d’édition de document : https://mon-adresse-ou-mon-nom-de-domaine:9443

Cocher la case « Désactiver la vérification du certificat (non sur) ». Ben oui, encore un coup :/

Insérer le secret partagé entre les deux instances dans la zone « Clé secrète »:

configuration nextcloud onlyoffice

Voilà, une instance de Nextcloud capable de proposer de l’édition de documents bureautique en ligne grâce à OnlyOffice Document Server community edition !

edition document office

Bien que ça fonctionne, je ne conseille pas la technique du port forwarding pour rendre accessible de l’extérieur l’instance du serveur OnlyOffice ainsi que l’instance Nextlcoud. En effet, déjà c’est une vraie galère à mettre en place car il faut NATer sur plusieurs interfaces (il y a probablement  aussi des utilisateurs internes) mais en plus le serveur OnlyOffice et le serveur Nextcloud doivent être dans des réseaux différents. De plus, les deux serveurs sont directement exposés sur internet. Enfin ça oblige à une gestion des certificats sur deux machines en même temps ce qui n’est pas très pratique.

La solution idéale serait évidemment d’utiliser un reverse  proxy qui aurait la charge de rejouer les requêtes vers les deux machines et de porter l’unique certificat à gérer. Dans les cas comme ici où les deux instances sont à la racine de leur serveur web, il faudrait utiliser deux sous domaines différents pour les deux applications. Enfin, ce serait plus sécurisé, car la seule machine exposée serait le reverse proxy, qui en plus apporterait une coupure protocolaire à l’accès aux applications.

o/

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *