Publication sur internet de notre cloud perso
Ben oui, il est là l’intérêt. Que tous les membres de la famille puissent utiliser les services fournis par notre petit cloud perso, et ce depuis n’importe où.
Configuration des règles de NAT entrant pour les ports 80 et 443
Ici, nous allons considérer que l’application est publiée grâce à un transfert de port (et non à travers un reverse proxy) depuis la box familiale, et on admettra donc que les ports 80 et 443 sont transférés depuis la box vers le minicloud. A chacun la charge de trouver une documentation ou un tuto pour configurer du NAT entrant sur sa box ou son pare-feu.
Obtention d’un certificat de sécurité valide
Jusqu’à maintenant, notre minicloud assure le chiffrement de la connexion https à l’aide d’un certificat autosigné, que nous avons créé précédemment. On peut s’en contenter pour la configuration initiale, mais en aucun cas pour la mise en production et la publication de l’application. En effet, outre le fait qu’il faille éviter de s’habituer à utiliser des certificats auto-signés pour des raisons de sécurité, il est probable que certains logiciels de synchronisation que vont utiliser les outils des membres de la famille (ordinateurs, smartphone etc…) refusent tout simplement le certificat auto-signé sans possibilité de passer outre.
Nous allons ainsi générer un certificat qui sera signé par une autorité de certification reconnue par la plupart des clients : let’s encrypt. Evidemment, la condition nécessaire à l’obtention d’un tel certificat est de posséder un nom de domaine dédié à notre application Nextcloud, avec un enregistrement DNS pointant l’IP publique de notre box ou parefeu faisant le NAT entrant vers notre Nextcloud. L’obtention d’un tel nom de domaine sort du cadre de l’article, et on va donc considérer pour la suite que nous avons à disposition un nom de domaine qui pointe notre Nextcloud.
Les certificats émis par let’s encrypt ont une durée de vie de 90 jours (par opposition à 1 an, voir jusqu’à 3 couramment), principalement pour inciter les gens à automatiser le renouvellement de leurs certificats.
L’EFF propose un programme très pratique nous permettant d’automatiser l’obtention et le renouvellement d’un certificat let’s encrypt, le certbot. Et ça tombe bien, certbot est disponible dans les paquets Debian, donc paf:
apt install certbot
Il n’y a pour ainsi dire pas de configuration particulière à faire pour l’instant. On va utiliser le certbot avec http, donc il va falloir qu’on libère le port 80 sur notre minicloud, qui est actuellement occupé par notre virtual host nginx.
vi /etc/nginx/sites-enabled/nextcloud.conf
Et on change le port 80 utilisé pour l’instance http pour disons, le port 81; puis on redémarre nginx comme on a l’habitude.
upstream php-handler {
server unix:/run/php/php7.3-fpm.sock;
}
server {
listen 81;
listen [::]:81;
server_name minicloud;
# Enforce HTTPS
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name minicloud;
(...)
C’est aussi en prévision de cette manipulation qu’on a pris soin précédemment de NATer le port 80 en même temps que le 443 vers notre minicloud. Ensuite hop, on invoque certbot avec les options qui vont bien:
certbot certonly --standalone --preferred-challenges http -d mon.nom-de-domaine.tld
On remplace bien sûr mon.nom-de-domaine.tld par son propre nom de domaine avec lequel l’instance Nextcloud sera joignable.
Et paf magie, arrivent dans le dossier /etc/letsencrypt/live/mon.nom-de-domaine.tld/ la clé privée, le certificat, et la chaine de certification dont on a besoin. Notez que le clé privée est générée localement par certbot et n’a jamais quitté notre machine; on est bien le seul en possession de celle-ci.
Il ne reste qu’à configurer nginx pour utiliser ces éléments et on sera bon là-dessus, toujours en modifiant notre virtual host /etc/nginx/sites-enabled/nextcloud.conf cette fois-ci bien sûr dans le server https:
(...)
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name minicloud;
# Use Mozilla's guidelines for SSL/TLS settings
# https://mozilla.github.io/server-side-tls/ssl-config-generator/
ssl_certificate /etc/letsencrypt/live/mon.nom-de-domaine.tld/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mon.nom-de-domaine.tld/privkey.pem;
(...)
Notez que pour le certificat on utilise ici le fichier fullchain.pem car il contient le certificat et toute sa chaine de certification. Le fichier qui contient la clé privée est le fichier privkey.pem.
On rend les fichiers accessibles à l’utilisateur www-data qui exécute nginx:
chown www-data:www-data /etc/letsencrypt/archive/lab.cinquantehuit.org/*
Encore un reload de nginx et ça y est, notre https est protégé par un vrai certificat valide partout. A partir de là, notre instance nextcloud est censée être accessible depuis le nom de domaine dédié, https://mon.nom-de-domaine.tld/. Cependant, il faut configurer l’application pour qu’elle approuve ce domaine. Ca se fait en éditant de nouveau le fichier /var/www/nextcloud/config/config.php pour y ajouter notre nom de domaine dans le tableau des domaines approuvés:
Il reste une dernière chose à faire sur ce sujet, qui est de s’assurer que le certificat sera renouvelé automatiquement et que ce renouvellement sera bien pris en compte. Le package certbot configure automatiquement une tâche cron dans /etc/cron.d/certbot. Celle-ci exécute toutes les 12 heures certbot en mode renouvellement. Le fichier de configuration /etc/letsencrypt/renewal/mon.nom-de-domaine.tld.conf pour ce renouvellement a automatiquement été créé à la première exécution du certbot avec tout ce qu’il faut dedans pour que ça se passe bien. Il faut juste ajouter dedans la directive renew_hook = systemctl reload nginx pour dire au certbot de recharger nginx à chaque renouvellement de certificat pour qu’il soit bien pris en compte.
Quelques mots pour finir
Voilà, si vous lisez ça je pense que vous avez bien mérité une bonne bière (et moi aussi). On pourrait continuer à en écrire des tartines mais il faut savoir s’arrêter, d’autant que cet article n’est pas une documentation de Nextcloud. A ce stade, on dispose d’une plateforme de cloud auto-hébergé, performante si on se limite au nombre d’utilisateurs pour lequel elle est adaptée, totalement silencieuse et minuscule, de sorte qu’elle peut loger n’importe où dans la maison. Elle est accessible de n’importe où, avec n’importe quel périphérique connaissant les protocoles standards webdav, caldav et carddav (et https bien sûr). Bref, un vrai petit bijou pas cher permettant de se désintoxiquer des GAFAM, tout en faisant à mon sens un petit geste écolo en retirant ses données d’un ou plusieurs datacentres. Mais à propos de ça…
Et la consommation électrique alors ?
Pendant l’installation de la plateforme, mon watt-mètre a enregistré un pic de consommation à 13,1 W, ce qui est à peu près ce que je m’attendais à avoir en pic de charge.
En utilisation réelle, j’ai relevé une puissance consommée stable autour des 10 W pendant qu’un client uploadait un peu plus de 26000 fichiers. Cette consommation est venue à osciller entre 13,5 W et 15,1 W lorsqu’en plus de cette synchronisation de fichiers, deux clients supplémentaires sont venus synchroniser à partir de zéro de gros calendriers et un gros carnet d’adresses.
En ce qui concerne l’utilisation de l’interface web (qui est fluide et agréable même sur cette plateforme), j’ai noté le record de consommation tout de suite après le login, à l’affichage du dashboard avec une pointe à 18,1 W. Il est probable qu’en même temps d’autres clients étaient en train de faire des synchronisations en même temps, car j’en ai laissé plusieurs avec des fréquences de synchro hyper agressives toutes les minutes, ce qui n’est pas vraiment un cas réaliste. Le chargement des pages des différentes applications installées faisait osciller la consommation entre 10 W et 15 W.
En idle, ce qui représente certainement ce que fera la plateforme la grande majorité du temps, la consommation est entre 4,2 W et 5,5 W, ce qui est ce à quoi je m’attendais (que j’espérais 🙂 ) grosso modo.
o/