mise en place architecture
Cet article traite de l’installation et de la configuration de Collabora, son lien avec Nextcoud. Il ne traite pas de l’installation de l’instance de Nextcloud qui est supposée fonctionnelle, certificat compris.
Architecture
L’architecture comprend :
- un serveur nextcloud sur un container (CT),
- un serveur collabora sur un container (CT),
- un reverse proxy nginx,
- le tout hébergé par un serveur proxmox.
Le serveur proxmox est sur un serveur dédié, avec une seule IP publique. Pour plus de détail sur cette configuration, voir cet article
Environnement détaillé
Serveur proxmox
- proxmox 5.X, basé sur debian stretch, kernel 4.15,
- une VM héberge un parefeu ipfire derrière lequel sont situés tous les serveurs d’application,
- matériel : CPU(s) 8 x Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz (1 Socket), 62 Go RAM, 1,5To SATA disk
CT nextcloud
- créé à partir du template debian-9-turnkey-nextcloud_15.0-1_amd64
- debian 9 stretch,
- nextcloud 13.0.5
- ressources : 2 coeurs CPU, 8 Go RAM
CT collabora
- créé à partir du template debian-9.0-standard-9.3.1
- debian 9 stretch,
- Collabora 3.3.1 (sur base depot),
- apache 2.4,
- ressources : 2 coeurs, 4 Go RAM
CT nginx
- créé à partir d’un template turnkey Nginx PHP FastCGI Server
- debian 8 jessie,
- nginx 1.6,
- ressources : 1 coeur, 1 Go RAM
Config réseau
Les 3 containers sont sur un sous-réseau 192.168.X.0, avec une passerelle commune dans une VM ipfire.
Tous les ports utiles sont nattés dans la configuration réseau du proxmox vers le parefeu, dans le détail.
- CT nginx : 192.168.X.6,
- CT nextcloud : 192.168.X.114,
- CT collabora : 192.168.X.115.
2 sous-domaines sont utilisés :
- ncloud.mondomaine.xxx pour nextcloud
- office.mondomaine.xxx pour collabora
Installation collabora
Vu le contexte de virtualisation, il était plus pertinent de ne pas utiliser docker mais directement des packages. L’installation se fait en suivant la documentation officielle
Dans notre cas pour debian 9 :
# import the signing key
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0C54D189F4BA284D
# add the repository URL to /etc/apt/sources.list
echo 'deb https://www.collaboraoffice.com/repos/CollaboraOnline/CODE-debian9 ./' >> /etc/apt/sources.list
# perform the installation
apt-get update && apt-get install loolwsd code-brandAttention !
En cas d’erreur au moment de l’ajout de la clé, comme ce fut mon cas, il s’agit d’un soucis de DNS. Il faut au moins temporairement ajouter un serveur de DNS en tête de liste dans le fichier /etc/resolv.conf. Pour ma part j’ai chois les DNS de cloudflare, mais vous pouvez aussi prendre le "8.8.8.8" de google.
nameserver 1.1.1.1
# --- BEGIN PVE ---
nameserver 127.0.0.1
nameserver ZZ.210.16.6
nameserver ZZ.210.16.7
# --- END PVE ---
A ce niveau tout se passe tranquillement.
Paramétrage certificats
Nextcloud et collabora vont fonctionner en flux sécurisé. Si les deux n’arrivent pas à communiquer ensemble, c’est soit à cause d’un problème de DNS, soit à cause des certificats, il est donc extrêmement important qu’ils soient bien mis en place.
Nous utilisons uniquement des certificats Letsencrypt. Il est fortement conseillé de générer les certificats sous-domaine après sous-domaine, et non groupé.
Vu notre architecture, on génère tous les certificats depuis notre container Nginx. Le reverse proxy sera le premier maillon de l’identification des certificats.
Voici la création du certificat pour office.mondomaine.xxx
service nginx stop
/opt/certbot/certbot-auto certonly --standalone --email monmail@mondomaine.xxx -d office.mondomaine.xxx
service nginx start
cd /etc/letsencrypt/live
scp -r office.mondoamine.xxx user@192.168.X.115:/etc/letsencrypt/liveNotez qu’une fois le certificat créé, on le copie aussi sur le container de collabora car on en aura besoin avec apache et le service libreoffice (loolwsd).
Paramétrage DNS
Vu que les deux serveurs sont sur un réseau local et que les noms de domaines renvoient des IP publiques, pour que les deux serveurs puissent communiquer, il va falloir déclarer les IP locales avec les fichiers /etc/hosts
- sur CT collabora, ajouter la ligne :
192.168.X.114 ncloud.mondomaine.xxx - sur CT nextcloud ajouter la ligne :
192.168.X.115 office.mondomaine.xxx
Vérification certificats et DNS
Pour être sur que votre configuration de certificats et de DNS fonctionne bien, voici les test à faire.
- certificat : sur le container collabora, il faut vérifier la bonne reconnaissance du certificat de nextcloud, et inversement. On peut utiliser pour cele :
root@ct-nextcloud:~# openssl s_client -connect office.mondomaine.xxx:443 root@ct-collabora:~# openssl s_client -connect ncloud.mondoamine.xxx:443Ce qui renvoie pour le second :
CONNECTED(00000003) depth=0 CN = ct-nextcloud verify error:num=18:self signed certificate verify return:1 depth=0 CN = ct-nextcloud verify return:1 --- Certificate chain 0 s:/CN=ct-nextcloud i:/CN=ct-nextcloud --- Server certificate -----BEGIN CERTIFICATE----- MIIC9jCCAd6gAwIBAgIJALwGJjeTnVg2MA0GCSqGSIb3DQEBCwUAMBcxFTATBgNV ...je tronque... Qa13SWw6xPA0ICgmBIHQEqipGwqT0tQNqlIiRAdSS19WL6gqNOqwLkGhH2wneM+c jm/bEWAAZjzmI0nNPTqBARaHyP0jUb4NXt/kYJ5rBWhc6yNeU7m+uSID -----END CERTIFICATE----- subject=/CN=ct-nextcloud issuer=/CN=ct-nextcloud --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1448 bytes and written 302 bytes Verification error: self signed certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 47E336522CF9AC43CCB62439E3F62079E2B32C77594E7201CD3AB751E63E3AE9 Session-ID-ctx: Master-Key: 2F4DB1913CD33A3D2175717E0B77A7B518FA57EA29130AC46C80CAEFA8417601D775B92ED9F45FB133A6D8497EB1D5A0 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 2b 89 87 c3 04 b5 25 95-0d 48 8c 90 d2 66 c4 24 +.....%..H...f.$ 0010 - 22 ad 9b 7e a8 2d 38 81-6e 9e 2e 42 6a c3 69 21 "..~.-8.n..Bj.i! 0020 - 54 e7 ac c4 c5 c4 8b db-e7 c1 2a fc 18 a8 19 16 T.........*..... 0030 - a4 4e 13 d4 c4 cf 6e 20-12 f7 6e 7a e4 e6 ce 40 .N....n ..nz...@ 0040 - cb 30 f3 5e dc f1 f2 e4-ca d0 bb f6 79 8c 56 e4 .0.^........y.V. 0050 - b0 4c 2d 5e 4e 53 01 c8-d4 9e a9 13 9e 4e 4a 54 .L-^NS.......NJT 0060 - 55 2c c4 cd 5d 46 3a 47-82 1f 47 24 4e 68 ef 5b U,..]F:G..G$Nh.[ 0070 - 0b d8 c7 d9 f6 84 e4 5d-69 3e 52 83 9b 7d b9 bf .......]i>R..}.. 0080 - 95 62 26 c0 e4 cf 28 95-ee 12 98 72 17 5e 48 4e .b&...(....r.^HN 0090 - 24 09 61 58 9e b5 40 0b-85 12 30 a5 52 ef 9a 5e $.aX..@...0.R..^ 00a0 - 03 04 1e 7f ca 88 c8 ca-28 34 cc 69 1d e7 76 de ........(4.i..v. 00b0 - 47 a5 31 25 14 e3 5a c8-50 1f d0 ab 38 f4 cc c5 G.1%..Z.P...8... Start Time: 1534150346 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) Extended master secret: no --- closed
- DNS : respectivement sur chacun des containers, tester la reconnaissance du domaine en IP locale avec un simple ping, ici depuis le container collabora vers le domaine "ncloud" :
root@ct-collabora : # ping ncloud.mondomaine.xxx
PING ncloud.mondomaine.xxx (192.168.X.114) 56(84) bytes of data.
64 bytes from ncloud.mondomaine.xxx (192.168.X.114) : icmp_seq=1 ttl=64 time=0.052 ms
64 bytes from ncloud.mondomaine.xxx (192.168.X.114) : icmp_seq=2 ttl=64 time=0.075 ms
Paramétrage container Collabora
Au niveau du serveur web sur ce container, il est théoriquement possible d’utiliser indifféremment Nginx ou Apache. Néanmoins pour ma part, c’est uniquement la configuration avec Apache qui a marché, ce fut un échec avec Nginx.
Apache
Tout est bien décrit et il suffit de reporter la configuration proposée sur le doc officielle pour Apache "Setting up Apache 2 reverse proxy"
- chargez bien les modules complémentaire :
a2enmod nom_modules service apache2 restart - Pensez à remplacer collabora.example.com par mondomaine.xxx,
- remplacer le chemin des certificats, dans notre cas ca donne :
SSLCertificateFile /etc/letsencrypt/live/office.mondomaine.xxx/cert.pem SSLCertificateChainFile /etc/letsencrypt/live/office.mondomaine.xxx/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/office.mondomaine.xxx/privkey.pem
Loolwsd
Le fichier /etc/loolwsd/loolwsd.xml permet de configurer l’instance de libreoffice.
Les éléments importants à modifier sont :
- définir le fichier de log, toujours utile pour déplomber :
<logging> <file enable="true"> <property name="path" desc="Log file path.">/var/log/loolwsd.log</property>
- indication de nos fichiers de certificat pour le SSL :
<ssl desc="SSL settings"> <enable type="bool" default="true">true</enable> <termination desc="Connection via proxy where loolwsd acts as working via https, but actually uses http." type="bool" default="true">true</termination> <cert_file_path desc="Path to the cert file" relative="false">/etc/letsencrypt/live/office.mondomaine.xxx/cert.pem</cert_file_path> <key_file_path desc="Path to the key file" relative="false">/etc/letsencrypt/live/office.mondomaine.xxxe.org/privkey.pem</key_file_path> <ca_file_path desc="Path to the ca file" relative="false">/etc/letsencrypt/live/office.cen-centrevaldeloire.org/fullchain.pem</ca_file_path>
- autorisation des hôtes qui vont se connecter au service loolwsd :
<storage desc="Backend storage"> <filesystem allow="false" /> <wopi desc="Allow/deny wopi storage. Mutually exclusive with webdav." allow="true"> <host desc="Regex pattern of hostname to allow or deny." allow="true">localhost</host> <host desc="Regex pattern of hostname to allow or deny." allow="true">office\.mondomaine\.xxx</host> <host desc="Regex pattern of hostname to allow or deny." allow="true">ncloud\.mondomaine\.xxx</host> <host desc="Regex pattern of hostname to allow or deny." allow="true">192\.168\.X\.114</host> <host desc="Regex pattern of hostname to allow or deny." allow="true">192\.168\.X\.6</host>En théorie, seules les lignes avec les deux sous-domaine "ncloud" et "office" devrait suffire. Comme j’ai pas mal tatonné sur la configuration, Pour ma part, j’ai ajouté l’IP locale de nextcloud et celle du reverse proxy. Pas sur que tout cela soit indispensable.
- pour accéder à la console d’administration de collabora, définition d’un compte utilisateur (monuser) et son mot de passe (le_mdp) :
<admin_console desc="Web admin console settigs."> <enable desc="Enable the admin console functionality" type="bool" default="true">true</enable> <enable_pam desc="Enable admin user authentication with PAM" type="bool" default="false">false</enable_pam> <username desc="The username of the admin console. Ignored if PAM is enabled.">monuser</username> <password desc="The password of the admin console. Deprecated on most platforms. Instead, use PAM or loolconfig to set up a secure password.">le_mdp</password>
Pour appliquer ces paramètre, il faut redémarrer le service :
systemctl restart loolwsd.service
Il peut être intéressant de vérifier que le service tourne bien :
root@ct-collabora:~# ss -tunlp
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 50688 0 192.168.X.115:123 *:* users:(("ntpd",pid=143,fd=19))
udp UNCONN 0 0 127.0.0.1:123 *:* users:(("ntpd",pid=143,fd=18))
udp UNCONN 0 0 *:123 *:* users:(("ntpd",pid=143,fd=17))
udp UNCONN 0 0 fe80::60da:75ff:fe73:aedd%eth0:123 :::* users:(("ntpd",pid=143,fd=24))
udp UNCONN 0 0 ::1:123 :::* users:(("ntpd",pid=143,fd=20))
udp UNCONN 0 0 :::123 :::* users:(("ntpd",pid=143,fd=16))
tcp LISTEN 0 128 *:22 *:* users:(("sshd",pid=133,fd=3))
tcp LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=353,fd=13))
tcp LISTEN 0 64 *:9981 *:* users:(("loolwsd",pid=793,fd=15))
tcp LISTEN 0 128 :::80 :::* users:(("apache2",pid=2078,fd=4),("apache2",pid=2077,fd=4),("apache2",pid=701,fd=4))
tcp LISTEN 0 128 :::22 :::* users:(("sshd",pid=133,fd=4))
tcp LISTEN 0 100 ::1:25 :::* users:(("master",pid=353,fd=14))
tcp LISTEN 0 128 :::443 :::* users:(("apache2",pid=2078,fd=6),("apache2",pid=2077,fd=6),("apache2",pid=701,fd=6))
tcp LISTEN 0 64 :::9980 :::* users:(("loolwsd",pid=793,fd=18))Ou l’on voit bien le serveur apache qui tourne sur 80 et 443 et loolwsd qui tourne sur le port 9980 et 9981.
Paramétrage nginx reverse proxy
Je rappelle le contexte, comme nous partageons une seule IP publique pour servir un ensemble d’applications, nous utilisons Nginx en reverse proxy en frontal pour aiguiller les différents flux sur base du nom de domaine. La configuration pour Nextcloud est en place, on va faire de même pour Collabora.
Dans un premier temps, j’avais configuré Nginx pour renvoyer grossièrement tout le flux vers le serveur collabora, et çà ne passait pas. Du coup, j’ai appliqué la configuration Nginx proposé sur la doc, comme si Nginx était sur le serveur collabora à la place d’apache. Ce qui donne :
server {
listen 443 ssl;
server_name office.mondomaine.xxx;
access_log /var/log/nginx/office_access.log;
error_log /var/log/nginx/office_error.log debug;
#SSL Certificates
ssl_certificate "/etc/letsencrypt/live/office.mondomaine.xxx/cert.pem";
ssl_certificate_key "/etc/letsencrypt/live/office.mondomaine.xxx/privkey.pem";
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_timeout 10m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
# static files
location ^~ /loleaflet {
proxy_pass https://192.168.X.115;
proxy_set_header Host $http_host;
}
# WOPI discovery URL
location ^~ /hosting/discovery {
proxy_pass https://192.168.X.115;
proxy_set_header Host $http_host;
}
# main websocket
location ~ ^/lool/(.*)/ws$ {
proxy_pass https://192.168.X.115;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
# download, presentation and image upload
location ~ ^/lool {
proxy_pass https://192.168.X.115;
proxy_set_header Host $http_host;
}
# Admin Console websocket
location ^~ /lool/adminws {
proxy_pass https://192.168.X.115;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
}Paramétrage container Nextcloud
La seule chose à paramétrer sur le système hébergeant nextcloud, c’est le DNS local avec l’ajout de la ligne dans le /etc/hosts. Le reste se passe dans l’interface de Nextcloud.
Paramétrage nextcloud
Aucune mauvaise surprise ici, il suffit de suivre la démarche officielle.
- se connecter en tant qu’administrateur de Nextcloud,
- installer l’application Collabora online,
- une fois installée, aller dans paramètres et choisir sur la gauche "Collabora en ligne",
- définir alors l’adresse du serveur comme dans l’image ci-dessous
Définir serveur collabora dans NextcloudLudovic Lestrat - on clique sur "appliquer" et un message "sauvegardé" doit apparaître si tout va bien.
A partir de là, vous devriez être en mesure de créer des fichiers au format compatible libreoffice, et surtout, les éditer en ligne !