Installation de ownCloud
Installation des paquets officiels pour Debian
Avec les commandes suivantes, on installe ownCloud grâce aux paquets officiels pour notre distribution Debian 12 "bookworm" (à noter qu'il existe aussi des paquets d'installation pour les anciennes versions de Debian mais aussi pour d'autres distributions de Linux, les instructions sont données sur la page https://software.opensuse.org/download.html?project=isv:ownCloud:server:10&package=owncloud-complete-files ) :
# echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/server:/10/Debian_12/ /' | sudo tee /etc/apt/sources.list.d/isv:ownCloud:server:10.list # curl -fsSL https://download.opensuse.org/repositories/isv:ownCloud:server:10/Debian_12/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/isv_ownCloud_server_10.gpg > /dev/null # sudo apt update # sudo apt install -y owncloud-complete-files
Création de la base de données
On va créer une base de données et un utilisateur pour ownCloud avec les commandes suivantes (le mot de passe pour l'administrateur "root" de nos bases de données, que nous avons configuré lors du lancement du script d'installation de la solution iRedMail, nous sera demandé) :
# mysql -uroot -p # CREATE DATABASE owncloud; # CREATE USER 'owncloud'@'localhost' IDENTIFIED BY 'motDePasseOwncloud'; # GRANT ALL PRIVILEGES ON owncloud.* TO 'owncloud'@'localhost' WITH GRANT OPTION; # FLUSH PRIVILEGES; # exit
Création du fichier de configuration pour Apache
On crée un fichier de configuration pour Apache grâce à la commande ci-dessous, on va notamment forcer l'utilisation de la version 7.4 du langage PHP, sachant que le logiciel php7.4-fpm a été configuré par le script d'installation de la solution iRedMail de façon à écouter sur le port TCP 9999 :
# sudo bash -c 'cat << EOM > /etc/apache2/conf-available/owncloud.conf
Alias /owncloud "/var/www/owncloud/"
<Directory /var/www/owncloud/>
Options +FollowSymlinks
AllowOverride All
Require all granted
<IfModule mod_dav.c>
Dav off
</IfModule>
<IfModule mod_security2.c>
SecRuleRemoveById 911100 920340 920420 920440 921110 932110 932125 941100 949110 941130 960010 960015 960032 960034 960904 980170 981172 200004
</IfModule>
SetEnv HOME /var/www/owncloud
SetEnv HTTP_HOME /var/www/owncloud
<FilesMatch \.php$>
SetHandler "proxy:fcgi://localhost:9999"
</FilesMatch>
</Directory>
EOM'Et on ajoute cette configuration pour le site que l'on souhaite, par exemple pour le site par défaut (dans ce cas il faut modifier le fichier "/etc/apache2/sites-enabled/000-default.conf") :
<VirtualHost *:6666> ... IncludeOptional conf-available/owncloud.conf </VirtualHost>
Enfin, on redémarre Apache :
# sudo systemctl restart apache2
Cohabitation avec le module "modsecurity" de Apache (obsolète)
Dans le fichier de configuration précédent, les lignes "<IfModule mod_security2.c>...</IfModule>" servent à désactiver certaines règles du module "modsecurity" de Apache qui risquent d'empêcher le bon fonctionnement de ownCloud, ce sont les "false positives" dont nous avons brièvement parlé lors du chapitre sur l'installation des modules de protection du serveur Apache. Mais, dans ce même chapitre, nous avons aussi précisé que la description de l'installation de ce module "modsecurity" pour Apache était à titre purement informatif car nous avons décrit ensuite une méthode plus moderne avec l'installation de "modsecurity" sous sa forme de librairie généraliste et d'interfaçage avec Nginx, donc les lignes "<IfModule mod_security2.c>...</IfModule>" en question peuvent être supprimées du fichier "/etc/apache2/conf-available/owncloud.conf" et les explications qui vont suivre sont également à prendre à titre purement indicatif.
Lorsque nous aurons fini d'installer ownCloud et que nous l'utiliserons, il est possible que, même si l'on a précédemment désactivé certaines règles de "modsecurity" qui posent soucis pour l'utilisation de ownCloud avec les lignes "<IfModule mod_security2.c>...</IfModule>" , des "false positives" puissent survenir dans le fichier de logs d'erreur d'Apache "/var/log/apache2/error.log" comme celle ci-dessous :
[Mon Jun 13 13:03:26.990491 2022] [:error] [pid 3401117:tid 140442461001472] [client 10.11.12.13:0] [client 10.11.12.13] ModSecurity: Warning. Match of "within %{tx.allowed_methods}" against "REQUEST_METHOD" required. [file "/usr/share/modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line "44"] [id "911100"] [msg "Method is not allowed by policy"] [data "PROPFIND"] [severity "CRITICAL"] [ver "OWASP_CRS/4.0.0-rc1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272/220/274"] [tag "PCI/12.1"] [hostname "patate.spou.net"] [uri "/owncloud/remote.php/dav/files/utilisateur@p.spou.net/"] [unique_id "YqcZfhjn2f4flmP03Al6TQAAABA"]Dans l'exemple précédent, on voit que c'est la règle d'ID "911100" qui pose problème alors qu'on l'avait bien ajoutée dans la liste d'exceptions de notre fichier de configuration de ownCloud pour Apache.
En fait, si on lit en détail l'erreur dans les logs d'Apache, on se rend compte que c'est la méthode "PROPFIND", utilisée par ownCloud, qui n'est pas autorisée par le fichier "/usr/share/modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf" qui correspond à cette règle d'ID "911100".
Les méthodes autorisées sont dans une variable qu'il faut modifier dans le fichier "/usr/share/modsecurity-crs/crs-setup.conf", or ce fichier est appelé en premier donc notre exception pour la règle d'ID "911100" dans notre fichier de configuration de ownCloud pour Apache n'a aucun effet car nos exceptions sont appelées bien après et donc, pour cette règle spécifique, c'est déjà trop tard.
Soit on désactive complètement la règle en renommant le fichier de configuration correspondant :
# sudo mv /usr/share/modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf /usr/share/modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf.example
Soit on ajoute la ligne suivante dans le fichier "/usr/share/modsecurity-crs/crs-setup.conf" pour autoriser notamment les méthodes "PROPFIND", "PUT", "MOVE" et "DELETE", etc... qui sont utilisées par ownCloud :
... SecAction "id:900200,phase:1,nolog,pass,t:none,setvar:'tx.allowed_methods=PUT PATCH CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH UNLOCK REPORT TRACE jsonp'" ...
Ou alors, on modifie le fichier "/etc/apache2/mods-enabled/security2.conf" ainsi :
...
IncludeOptional /usr/share/modsecurity-crs/crs-setup.conf
SecAction "id:900200,phase:1,nolog,pass,t:none,setvar:'tx.allowed_methods=PUT PATCH CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH UNLOCK REPORT TRACE jsonp'"
IncludeOptional /usr/share/modsecurity-crs/rules/*.conf
...On n'oublie pas de relancer Apache dans tous les cas :
# sudo systemctl reload apache2
Cohabitation avec la librairie "modsecurity"
Avec "modsecurity" installé comme librairie et non comme module Apache, on va modifier le fichier "/usr/share/modsecurity-crs/crs-setup.conf" , comme ci-dessous, et on va créer une règle d'ID "99" (ou tout autre ID en dessous de "100" car on est sûr que ces numéros ne sont pas utilisés par d'autres règles).
On va notamment utiliser la variable "tx.crs_exclusions_nextcloud " qui permet d'appliquer une certain nombre d'exceptions prédéfinies pour ownCloud (et nextCloud qui est un fork de ownCloud, d'où le nom de la variable) :
...
SecRule REQUEST_URI "@beginsWith /owncloud/"\
"id:99,\
phase:2,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_nextcloud=1,\
ctl:ruleRemoveById=920170,\
ctl:ruleRemoveById=920230,\
ctl:ruleRemoveById=920270-920272,\
ctl:ruleRemoveById=920420,\
ctl:ruleRemoveById=921110,\
ctl:ruleRemoveById=921150,\
ctl:ruleRemoveById=921200,\
ctl:ruleRemoveById=930120,\
ctl:ruleRemoveById=931130,\
ctl:ruleRemoveById=932100-932190,\
ctl:ruleRemoveById=932200,\
ctl:ruleRemoveById=933100-933190,\
ctl:ruleRemoveById=933210,\
ctl:ruleRemoveById=941100-941190,\
ctl:ruleRemoveById=941310-941340,\
ctl:ruleRemoveById=942100-942190,\
ctl:ruleRemoveById=942200-942290,\
ctl:ruleRemoveById=942300-942390,\
ctl:ruleRemoveById=942400-942490,\
ctl:ruleRemoveById=942510-942511,\
ctl:ruleRemoveById=949110"
...Comme dans notre cas nous utilisons la librairie "modsecurity" via un connecteur à Nginx, nous devons redémarrer ce dernier :
# sudo systemctl reload nginx
Lorsque nous aurons fini d'installer ownCloud et que nous l'utiliserons, il est possible que malgré ces nombreuses exceptions mises en place précédemment, des "false positives" puissent tout de même survenir dans le fichier de logs d'erreur de Nginx "/var/log/nginx/error.log", ils se présenteront alors plus ou moins comme dans l'exemple ci-dessous :
2023/09/28 17:43:33 [error] 522272#522272: *18864 [client 10.11.12.13] ModSecurity: Warning. Match of "within %{tx.allowed_methods}" against "REQUEST_METHOD" required. [file "/usr/share/modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf"] [line "44"] [id "911100"] [msg "Method is not allowed by policy"] [data "PROPFIND"] [severity "CRITICAL"] [ver "OWASP_CRS/4.0.0-rc1"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272/220/274"] [tag "PCI/12.1"], client: 10.11.12.13, server: _, request: "GET /owncloud/remote.php/dav/files/utilisateur@p.spou.net/ HTTP/2.0", upstream: "http://127.0.0.1:6667/owncloud/remote.php/dav/files/utilisateur@p.spou.net/", host: "patate.spou.net", referrer: "https://patate.spou.net/owncloud"Il faudra alors modifier le fichier "/usr/share/modsecurity-crs/crs-setup.conf" en conséquence, en ajoutant une exception pour l'ID qui pose problème d'après les logs précédents, ici l'ID "911100" :
...
SecRule REQUEST_URI "@beginsWith /owncloud/"\
"id:99,\
...
ctl:ruleRemoveById=91100,\
...
ctl:ruleRemoveById=949110"
...Cependant, si mettre une exception pour l'ID de la règle en question qui pose problème, comme on vient de le faire, fonctionne dans la majorité des cas, parfois ce n'est pas suffisant comme pour ce cas précis. En lisant en détail l'erreur dans les logs de Nginx, on se rend compte que c'est la méthode "PROPFIND", utilisée par ownCloud, qui n'est pas autorisée par le fichier "/usr/share/modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf", lequel correspond à cette règle d'ID "911100".
Les méthodes autorisées doivent apparaitre dans la variable "tx.allowed_methods" qu'il va falloir modifier explicitement dans le fichier "/usr/share/modsecurity-crs/crs-setup.conf" :
...
SecRule REQUEST_URI "@beginsWith /owncloud/"\
"id:99,\
...
setvar:'tx.allowed_methods=PUT PATCH CHECKOUT COPY DELETE LOCK MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH UNLOCK REPORT TRACE jsonp',\
...
ctl:ruleRemoveById=949110"
...On n'oublie pas de relancer Nginx dans tous les cas :
# sudo systemctl reload nginx
Les étapes d'installation de ownCloud
On visite le site https://nom-du-serveur/owncloud pour lancer l'installation de base de ownCloud, on donnera comme nom d'utilisateur administrateur l'adresse mail de notre administrateur mail, à savoir "postmaster@p.spou.net" ; pour l'utilisateur et le nom de la base de données, on indiquera "owncloud" et le mot de passe de l'utilisateur est celui que l'on a donné précédemment lors de la création de cette base.
On configure les noms d'hôte à partir desquels on va accéder à ownCloud, ici patate.spou.net et p.spou.net, grâce à la commande suivante (la connexion sera alors refusée si on se connecte à partir d'autres noms d'hôte) :
# sudo -u www-data php7.4 /var/www/owncloud/occ config:system:set trusted_domains 1 --value patate.spou.net # sudo -u www-data php7.4 /var/www/owncloud/occ config:system:set trusted_domains 2 --value p.spou.net
On se connecte de nouveau à https://nom-du-serveur/owncloud en entrant les identifiants de notre administrateur postmaster@p.spou.net et on va sur la page https://nom-du-serveur/owncloud/index.php/settings/admin?sectionid=general afin de voir les différents points à régler pour un fonctionnement optimal d'ownCloud.
On nous indique d'abord qu'il faut configurer le "verrouillage transactionnel de fichiers basé sur la mémoire", pour cela on va utiliser un serveur de cache en mémoire Redis couplé avec le système de cache de PHP, APCu :
# sudo apt install -y redis-server php-redis php8.0-redis php7.4-redis # sudo -u www-data php7.4 /var/www/owncloud/occ config:system:set memcache.local --value \\OC\\Memcache\\APCu # sudo -u www-data php7.4 /var/www/owncloud/occ config:system:set memcache.locking --value \\OC\\Memcache\\Redis # sudo -u www-data php7.4 /var/www/owncloud/occ config:system:set redis host --value localhost # sudo -u www-data php7.4 /var/www/owncloud/occ config:system:set redis port --value 6379 # sudo systemctl restart php7.4-fpm
On ajoute ou modifie les deux valeurs suivantes dans le fichier "/etc/redis/redis.conf" :
maxmemory 2gb maxmemory-policy allkeys-lru
On redémarre le serveur Redis :
# sudo systemctl restart redis-server
On rafraichit la page https://nom-du-serveur/owncloud/index.php/settings/admin?sectionid=general où le message d'alerte concernant le verrouillage transactionnel de fichiers a du disparaitre.
On nous demande ensuite de créer une tâche planifiée, on le fait grâce aux commandes suivantes :
# sudo -u www-data php7.4 /var/www/owncloud/occ background:cron # sudo bash -c 'echo "*/15 * * * * php7.4 /var/www/owncloud/occ system:cron" > /var/spool/cron/crontabs/www-data chown www-data.crontab /var/spool/cron/crontabs/www-data chmod 0600 /var/spool/cron/crontabs/www-data'
On rafraichit la page https://nom-du-serveur/owncloud/index.php/settings/admin?sectionid=general où il ne reste plus normalement que des messages d'alerte concernant des headers manquants, il faut pour cela modifier le fichier "/etc/nginx/conf-enabled/headers.conf" ainsi :
#add_header X-Frame-Options sameorigin; #add_header X-Content-Type-Options nosniff; #add_header X-XSS-Protection '1; mode=block'; #add_header X-Download-Options noopen; #add_header X-Permitted-Cross-Domain-Policies none; add_header Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"; add_header Referrer-Policy strict-origin; add_header Strict-Transport-Security "max-age=15552001; includeSubDomains; preload";
A noter cependant que la ligne ci-dessous, que nous avons ajouté dans le fichier précédent, semble causer des soucis avec la suite Collabora Online dont nous allons décrire l'installation juste après. De toute façon, elle ne semble plus nécessaire au bon fonctionnement des versions les plus récentes d'ownCloud, on peut donc la supprimer ou la commenter en ajoutant le signe "#" au début de la ligne :
add_header Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'";
On redémarre Nginx :
# sudo systemctl restart nginx
On va maintenant faire en sorte que tous les utilisateurs qui ont une adresse ***@p.spou.net possèdent également un espace de stockage ownCloud. Pour cela, on va sur la page https://nom-du-serveur/owncloud/index.php/settings/admin?sectionid=apps&category=disabled afin d'activer l'application "External user support". On exécute ensuite la commande suivante :
# sudo -u www-data php7.4 /var/www/owncloud/occ config:system:set user_backends 0 class --value OC_User_IMAP
Puis on modifie le fichier "/var/www/owncloud/config/config.php" ainsi :
...
'user_backends' =>
array (
0 =>
array (
'class' => 'OC_User_IMAP',
'arguments' =>
array (
0 => '{patate.spou.net:993/imap/ssl/novalidate-cert}'
),
),
),
...Installation de la suite Collabora Online et interfaçage avec l'instance ownCloud
On va maintenant installer la suite Collabora Online afin de pouvoir modifier les documents de bureautique (Word, Excel, ...) directement depuis l'interface web de ownCloud. on commence par installer la clé nécessaire pour pouvoir télécharger la solution :
# cd /usr/share/keyrings # sudo wget https://collaboraoffice.com/downloads/gpg/collaboraonline-release-keyring.gpg
On crée ensuite un fichier "/etc/apt/sources.list.d/collaboraonline.sources" dans lequel on met le contenu suivant :
Types: deb URIs: https://www.collaboraoffice.com/repos/CollaboraOnline/CODE-deb Suites: ./ Signed-By: /usr/share/keyrings/collaboraonline-release-keyring.gpg
On peut alors installer les paquets nécessaires au fonctionnement de la suite Collabora Online :
# sudo apt update && sudo apt install -y coolwsd code-brand
Nous allons maintenant décrire deux façons de configurer cette suite Collabora Online.
Configuration de la suite Collabora Online, solution n°1 (obsolète)
La solution que nous allons décrire ici est donnée simplement à titre informatif et ne sera pas utilisée dans notre cas car il existe une méthode plus simple que nous verrons juste après.
On utilise notre certificat SSL (dans cet exemple un certificat SSL acheté auprès d'une autorité de certification officielle qui fonctionne avec n'importe quel nom d'hôte du domaine spou.net) pour la connexion au service Collabora Online installé localement sur notre serveur :
# sudo ln -sf /etc/ssl/STAR_spou_net.key /etc/coolwsd/key.pem # sudo ln -sf /etc/ssl/STAR_spou_net.crt /etc/coolwsd/cert.pem # sudo ln -sf /etc/ssl/STAR_spou_net.ca /etc/coolwsd/ca-chain.cert.pem
Dans certains cas, notamment pour l'utilisation de certificats générés par l'outil Certbot, il vaut mieux faire une copie des fichiers plutôt que de créer des liens symboliques :
# sudo cp /etc/letsencrypt/live/patate.spou.net/privkey.pem /etc/coolwsd/key.pem # sudo cp /etc/letsencrypt/live/patate.spou.net/cert.pem /etc/coolwsd/cert.pem # sudo cp /etc/letsencrypt/live/patate.spou.net/chain.pem /etc/coolwsd/ca-chain.cert.pem
ATTENTION à penser à refaire les commandes précédentes à chaque fois que les certificats SSL sont renouvelés avec Certbot (c'est à dire tous les 3 mois).
On modifie le fichier "/etc/coolwsd/coolwsd.xml" ainsi si ce n'est pas déjà le cas :
...
<ssl desc="SSL settings">
...
<enable type="bool" desc="Controls whether SSL encryption between coolwsd and the network is enabled (do not disable for production deployment). If default is false, must first be compiled with SSL support to enable." default="true">true</enable>
...
</ssl>
...On redémarre le service Collabora Online :
# sudo systemctl restart coolwsd
Si le serveur ne s'est pas lancé, on exécute la commande ci-dessous pour voir les erreurs :
# sudo -u cool coolwsd --version --o:sys_template_path=/opt/cool/systemplate --o:child_root_path=/opt/cool/child-roots --o:file_server_root_path=/usr/share/coolwsd
Dans notre cas il y avait par exemple un problème de lecture du fichier "/etc/coolwsd/key.pem" et la commande suivante a semble-t-il réglé la situation (mais à voir cependant s'il ne faut pas la refaire à chaque redémarrage du système) :
# sudo chmod +r /etc/coolwsd/key.pem
On va sur la page https://nom-du-serveur/owncloud/index.php/apps/market/#/app/richdocuments afin d'installer l'application Collabora Online pour ownCloud (ATTENTION, l'installation de cette application risque de déclencher sur chaque page de l'interface web de ownCloud une fenêtre nous disant que nous avons 24h pour saisir notre clé pour la version "Entreprise" de ownCloud mais normalement au bout de ces 24h le message disparait et la suite Collabora Online est toujours utilisable).
On va sur la page https://nom-du-serveur/owncloud/index.php/settings/admin?sectionid=additional où on indique "https://patate.spou.net:9980" dans le champs "Serveur Collabora en ligne".
ATTENTION, dans notre cas on a été obligé d'ouvrir le port TCP 9980 en entrée sur notre serveur au niveau du firewall pour que tout fonctionne mais notre installation de Collabora Online sera tout de même protégée car on va faire en sorte qu'elle n'accepte que des requêtes provenant des sites web appartenant au domaine "spou.net" et protégés en SSL. Pour cela, il faut éditer le fichier "/etc/coolwsd/coolwsd.xml" ainsi :
... <storage desc="Backend storage"> <filesystem allow="false" /> <wopi desc="Allow/deny wopi storage." allow="true"> ... <alias_groups desc="default mode is 'first' it allows only the first host when groups are not defined. set mode to 'groups' and define group to allow multiple host and its aliases" mode="groups"> ... <group> <host allow="true" desc="Regex pattern of hostname to allow or deny.">https://spou\.net:443</host> <alias desc="regex pattern of aliasname">https://(.+)\.spou\.net:443</alias> </group> ... </alias_groups> ... </wopi> ... </storage> ...
On n'oublie pas de redémarrer de nouveau le service Collabora Online :
# sudo systemctl restart coolwsd
Configuration de la suite Collabora Online, solution n°2
La seconde solution que l'on propose pour configurer la suite Collabora Online est un peu plus simple car :
- elle ne nécessite pas d'ouvrir le port TCP 9980 en entrée sur notre serveur au niveau du firewall ;
- elle fonctionne sans que l'on ait besoin de faire une copie des fichiers de notre certificat SSL ni de ce soucier du renouvèlement de ce dernier (et donc encore moins de se retrouver avec des erreurs au niveau des droits d'accès à ces fichiers) ;
- les modifications à faire sur le fichier de configuration "/etc/coolwsd/coolwsd.xml" sont minimes.
Nous allons en fait utiliser utiliser notre serveur Nginx comme reverse proxy du serveur Collabora Online. Normalement, lors de l'installation de Collabora Online, un fichier "/etc/nginx/snippets/coolwsd.conf" a été créé avec quelque chose comme le contenu suivant (créer ce fichier avec ce contenu si tel n'est pas le cas) :
location ^~ /browser {
proxy_pass http://localhost:9980;
proxy_set_header Host $http_host;
}
location ^~ /hosting/discovery {
proxy_pass http://localhost:9980;
proxy_set_header Host $http_host;
}
location ^~ /hosting/capabilities {
proxy_pass http://localhost:9980;
proxy_set_header Host $http_host;
}
location ~ ^/cool/(.*)/ws$ {
proxy_pass http://localhost:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
location ~ ^/(c|l)ool {
proxy_pass http://localhost:9980;
proxy_set_header Host $http_host;
}
location ^~ /cool/adminws {
proxy_pass http://localhost:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
Sachant que l'on a au préalable créé un nom d'hôte nommé "cool.spou.net" en créant une zone "CNAME" qui pointe vers notre serveur (voir le chapitre "Configurer les noms de domaine") et que l'on utilise notre certificat SSL unique qui marche pour n'importe quel nom d'hôte appartenant au domaine "spou.net" (voir le chapitre "Créer un ou des certificats SSL"), on édite alors le fichier "/etc/nginx/sites-enabled/00-default-ssl.conf" pour ajouter les lignes suivantes :
...
server {
listen 443 ssl;
server_name cool.spou.net;
ssl_certificate /etc/ssl/STAR_spou_net.fullchain;
ssl_certificate_key /etc/ssl/STAR_spou_net.key;
include /etc/nginx/snippets/coolwsd.conf;
}
Pour ce qui est du fichier "/etc/coolwsd/coolwsd.xml", il n'y a que deux lignes à modifier, comme ci-dessous, pour désactiver l'utilisation d'un certificat SSL, vu que c'est notre serveur Nginx qui sécurise la connexion, et pour préciser que le serveur Collabora Online est en mode proxy :
...
<ssl desc="SSL settings">
...
<enable type="bool" desc="Controls whether SSL encryption between coolwsd and the network is enabled (do not disable for production deployment). If default is false, must first be compiled with SSL support to enable." default="true">false</enable>
...
<termination desc="Connection via proxy where coolwsd acts as working via https, but actually uses http." type="bool" default="true">true</termination>
...
</ssl>
...On redémarre le service Collabora Online et le serveur Nginx :
# sudo systemctl restart coolwsd # sudo systemctl reload nginx
Si le serveur Collabora Online ne s'est pas lancé, on exécute la commande ci-dessous pour voir les erreurs :
# sudo -u cool coolwsd --version --o:sys_template_path=/opt/cool/systemplate --o:child_root_path=/opt/cool/child-roots --o:file_server_root_path=/usr/share/coolwsd
Si ce n'est pas déjà fait, on va sur la page https://nom-du-serveur/owncloud/index.php/apps/market/#/app/richdocuments afin d'installer l'application Collabora Online pour ownCloud (ATTENTION, l'installation de cette application risque de déclencher sur chaque page de l'interface web de ownCloud une fenêtre nous disant que nous avons 24h pour saisir notre clé pour la version "Entreprise" de ownCloud mais normalement au bout de ces 24h le message disparait et la suite Collabora Online est toujours utilisable).
Pour finir, on va sur la page https://nom-du-serveur/owncloud/index.php/settings/admin?sectionid=additional où on indique "https://cool.spou.net" dans le champs "Serveur Collabora en ligne".
Ajuster les paramètres du serveur Nginx
Il est possible que le genre de messages suivant apparaisse dans "/var/log/nginx/error.log", le fichier d'erreur du serveur Nginx :
2021/12/12 10:07:42 [error] 15967#15967: *3 upstream sent too big header while reading response header from upstream, client: 12.34.56.78, server: _, request: "POST /owncloud/index.php/login HTTP/2.0", upstream: "http://127.0.0.1:6666/owncloud/index.php/login", host: "patate.spou.net", referrer: "https://patate.spou.net/owncloud/" 2021/12/13 16:47:16 [error] 6855#6855: *73108 client intended to send too large body: 1675894 bytes, client: 12.34.56.78, server: _, request: "PUT /owncloud/remote.php/dav/files/utilisateur@p.spou.net/DOSSIER_PERSO/fichier_perso.pdf HTTP/1.1", host: "patate.spou.net"
Pour corriger cela, on peut ajouter les lignes suivantes dans le fichier "/etc/nginx/nginx.conf" à l'intérieur de la section "http {}" ou bien dans le fichier déjà existant "/etc/nginx/conf-enabled/client_max_body_size.conf" (on peut augmenter la valeur du paramètre "client_max_body_size" si le message précédent "client intended to send too large body" persiste malgré ces modifications) :
...
http {
...
proxy_buffering off;
proxy_buffer_size 16k;
proxy_busy_buffers_size 24k;
proxy_buffers 64 4k;
client_max_body_size 64M;
...
}
...
Il faut également modifier le fichier "/etc/nginx/templates/misc.tmpl" afin de remplacer la ligne suivante qui a été automatiquement ajoutée par le script d'installation de la solution iRedMail :
location ~ /\. { deny all; }Par celle ci-dessous afin de ne pas bloquer la fonctionnalité de renommage des fichiers par ownCloud et pour pouvoir potentiellement sauvegarder les fichiers cachés dont les noms commencent parfois par un point :
location ~ ^(?!/owncloud/remote\.php/(web|)dav/(files|uploads)/.+/).*/\. { deny all; }On va aussi faire en sorte de ne pas encombrer nos logs avec des accès à des fichiers sur ownCloud qui nous intéressent peu ou qui peuvent être sources d'erreurs 404, on commence d'ailleurs par modifier le fichier "/etc/nginx/templates/misc.tmpl" ouvert précédemment pour commenter les lignes suivantes qui ont été ajoutées automatiquement par le script d'installation de la solution iRedMail et que nous allons gérer autrement :
#location = /favicon.ico { access_log off; log_not_found off; }
#location = /robots.txt { access_log off; log_not_found off; }On ajoute les lignes suivantes à la fin du fichier "/etc/nginx/conf-enabled/0-general.conf" :
...
map $request $loggable {
~/favicon\.ico 0;
~/apple-touch-icon(.*)\.png 0;
~/robots\.txt 0;
~/(sitemap|rss)(.*)\.(xml|txt) 0;
~/owncloud/status\.php 0;
~/owncloud/ocs/v[0-9]\.php 0;
~/owncloud/remote\.php/(web|)dav/avatars 0;
~/owncloud/remote\.php/(web|)dav/files 0;
default 1;
}On modifie le fichier "/etc/nginx/conf-enabled/log.conf" ainsi pour ne pas afficher dans les logs l'accès aux fichiers listés précédemment :
... access_log /var/log/nginx/access.log combined if=$loggable; ...
On peut aussi vouloir ne pas enregistrer dans les logs l'accès à nos sites depuis les IP internes à notre réseau local, dans ce cas on peut modifier le fichier "/etc/nginx/conf-enabled/0-general.conf" ainsi (sachant que dans notre cas, les IP de notre réseau interne commencent par 192.168.15) :
map $request$remote_addr $loggable {
~/favicon\.ico 0;
~/apple-touch-icon(.*)\.png 0;
~/robots\.txt 0;
~/(sitemap|rss)(.*)\.(xml|txt) 0;
~/owncloud/status\.php 0;
~/owncloud/ocs/v[0-9]\.php 0;
~/owncloud/remote\.php/(web|)dav/avatars 0;
~/owncloud/remote\.php/(web|)dav/files 0;
~192\.168\.15\..+ 0;
~127\.0\.0\.1 0;
default 1;
}Enfin, on modifie le fichier "/etc/nginx/sites-enabled/00-default-ssl.conf" afin de ne pas limiter le nombre de requêtes par seconde pour une même IP pour ownCloud :
server {
...
location /owncloud {
proxy_pass http://127.0.0.1:6667;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
}
location / {
limit_req zone=limit_requests burst=50 nodelay;
proxy_pass http://127.0.0.1:6667;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
}
...
}
On n'oublie pas de redémarrer Nginx pour appliquer les modifications :
# sudo systemctl reload nginx
Encryption des documents stockés sur ownCloud côté serveur
Afin d'ajouter une couche de protection à notre instance ownCloud, nous allons encrypter l'ensemble des documents qui seront uploadés par nos utilisateurs.
Pour cela, on commence par activer l'application "Default encryption module" en allant sur la page https://nom-du-serveur/owncloud/index.php/settings/admin?sectionid=apps&category=disabled, après s'être connecté avec un compte administrateur (en l'occurrence avec les identifiants de notre administrateur mail, à savoir dans notre cas "postmaster@p.spou.net").
On va ensuite sur la page https://nom-du-serveur/owncloud/index.php/settings/admin?sectionid=encryption afin de cocher la case "Activer le chiffrement côté serveur" et on confirme que l'on veut bien activer cette option quand cela nous est demandé.
Il nous sera alors demandé également de nous déconnecter et nous reconnecter à ownCloud pour activer les clés de chiffrement.
Il nous reste une dernière chose à faire pour que le chiffrement fonctionne, en particulier sur les distributions récentes de Linux, il nous faut modifier le fichier "/etc/ssl/openssl.cnf" pour ajouter ces lignes :
...
[openssl_init] providers = provider_sect ... [provider_sect] default = default_sect legacy = legacy_sect
...
[default_sect]
activate = 1
[legacy_sect]
activate = 1
...
On redémarre le service php7.4-fpm pour appliquer ces modifications à notre instance ownCloud :
# sudo systemctl restart php7.4-fpm
Commentaires