[MàJ] Nextcloud 12 à 15 sur un mutualisé OVH

nextcloud 29 sept. 2018

Chose promise, chose due, il paraît, et pour Nextcloud je l’ai promise plusieurs fois cette chose. Après un bon moment de silence, la faute à pas mal de taf, à un déménagement, à une nouvelle vie qui commence… je vais reprendre si tout va bien un rythme de publication plus régulier.

Et pour fêter ça, on va commencer par quelque chose de pas mal demandé par ici : une mise à jour du tutoriel d’installation de Nextcloud / ownCloud sur un hébergement mutualisé OVH. J’y fusionne les retours qui m’ont été faits dans les commentaires de l’ancien article, et d’autres infos plus ou moins liées (genre la synchro avec DAVdroid cassée, c’est pas un pré-requis pour que Nextcloud fonctionne, mais c’est quand même cool d’avoir la solution sous la main ! 😉 ). On ajoutera également une partie sur la synchro des tâches et notes. Allons-y !

Pré-requis

Pas de changements majeurs dans les pré-requis, PHP 5.6+ est toujours supporté, même si PHP version 7.0 ou plus récent est recommandé. Pour ma part, j’ai fait l’installation test avec PHP 7.0. Si un changement de version se fait sans souci avant une installation propre (en repartant de zéro — ça fait du bien de temps en temps !), gardez en tête que se borner à changer la version de PHP dans votre fichier .ovhconfig ou via le Manager OVH peut précipiter le recours à l’installation propre parce que ça aurait tout pété. Pas mal de logiciels digèrent mal la chose, j’en ai fait l’expérience ici même (ouais, j’suis comme ça, j’ai pété Open-Freax en testant, heureusement il a suffi de rebasculer en PHP 5.6 pour réparer).

Je vous conseille également d’utiliser MySQL et pas SQLite, si vous avez pas mal de fichiers et/ou de comptes, sinon, bonjour les dégâts et la base corrompue à mort (testé et désapprouvé). Au final, ma base ne prend pas énormément de place, pour un Nextcloud partagé avec madame, et avec pas mal d’applications.

Il vous faut donc simplement un client FTP(S de préférence) et l’archive d’installation officielle. Il existe aussi un script PHP justement fait pour ne pas se cogner des centaines de fichiers à téléverser via FileZilla (par exemple), mais je ne l’ai pas testé avec Nextcloud (je suis passé de la v11 à la v12, puis de la v12 à la V13, et là de la V13 à V14 sans installation fraîche –c’est mal, mais comme quoi).

On va commencer par l’essentiel, le (sous-)domaine. Dans mon cas, plutôt que d’utiliser une URL de la forme https://mon-domaine.fr/nextcloud/, je préfère un sous-domaine, type https://nextcloud.mon-domaine.fr. C’est affaire de goût, principalement.
Pour le créer, direction le manager OVH, ajoutez votre sous-domaine en prenant bien soin de cocher que vous voulez y accéder en https, pour qu’il ajoute ce sous-domaine à la liste de ceux couverts par votre certificat TLS gratuit Let’s Encrypt. Ensuite, cliquez simplement sur le bouton pour régénérer votre certificat. Patientez quelques minutes (allez prendre un café, ça peut être un poil long), le temps que tout ça se fasse. Pendant ce temps-là, passez à l’étape 1 (du moins le début).

Étape 1 : installation de Nextcloud

Simplissime : téléversez l’archive extraite via FileZilla (par exemple). Une fois que le sous-domaine est bien créé et le certificat mis à jour, pointez votre navigateur web vers la page d’installation, et suivez les instructions. C’est tout bon ! Vous pouvez vous y connecter et activer d’autres applications fournies (Agenda, Contacts), tout ça tout ça.

Mais si vous vous rendez dans la partie « Administration » de votre instance fraîchement installée, vous verrez une flopée d’erreurs. Notez que ça n’empêche pas Nextcloud de fonctionner, du moins pas totalement, mais ça peut vous poser souci dans certains cas d’usage, ou causer un risque d’un point de vue sécurité. On va y remédier.

admin panel

Étape 2 : se débarrasser des erreurs

Étape 2a : les headers

Pour cela, ouvrez le fichier .htaccess à la racine du répertoire contenant Nextcloud et repérez le pavé qui cause des headers.

Modifiez chaque ligne commençant par Header set en Header always set, et ajoutez ces lignes au bloc en question :

Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

Header always set Referrer-Policy "strict-origin"

Étape 2b : activer le cache

Modifiez le fichier config/config.php et ajoutez la ligne :

'memcache.local' => '\\OC\\Memcache\\ArrayCache',

Puis rechargez la page d’administration, et c’est tout bon. Une erreur de moins, qui peut également causer l’apparition d’un nouveau message comme quoi OPCache serait mal configuré. Je n’ai pas encore pris le temps de regarder ça.

Étape 2c : la vérification de code

Puisque nous avons modifié des fichiers propres à Nextcloud, et que depuis quelques temps maintenant un mécanisme vérifie que l’empreinte du fichier en place correspond bien à l’empreinte du fichier fourni par Nextcloud, il paraît logique que ce mécanisme puisse détecter nos modifications et nous en avertir (c’est le but, à la base). Deux options : vivre avec ce bandeau jaune (visible seulement par les administrateurs), ou désactiver la vérification (pas super recommandé, mais ça dépanne).

Dans ce 2e cas, il vous faut ouvrir le fichier config/config.php et ajouter : 'integrity.check.disabled' => true puis relancer la vérification d’intégrité. Le message va disparaître.

Étapes restantes…

Restent 2 « soucis » : une erreur concernant la configuration de php-fpm, côté serveur donc, pour laquelle je ne sais pas s’il est possible de faire quelque chose sans passer par OVH. Enfin, l’espace disponible n’est pas renvoyé, même avec ma manip’ « habituelle » : il faut creuser là-dessus ! Rien de bloquant pour le moment, sauf certaines extensions comme celle pour les « gros fichiers » de Thunderbird qui vérifient l’espace disponible… et illimité ne lui convient pas 😛

Étape 3 : installer le client sans péter sa synchro

Ça parait couillon dit comme ça, hein. Et pourtant…

Techniquement, l’équipe de développement de Nextcloud (un héritage d’ownCloud, techniquement) a décidé que les gros fichiers devaient être découpés en morceaux de 10Mo. Ça se défend, je ne le remet pas en cause. Simplement, sur nos connexion ADSL classiques, ça prend un peu de temps à envoyer, des bouts de 10Mo. Conséquence : le serveur MySQL d’OVH, qui attend les infos sur le fichier tout au long du process, finit par se lasser et fermer la connexion… entraînant l’arrêt de la synchronisation dudit fichier, et une erreur type « MySQL has gone away ». Encore une fois, « on y travaille »… ou pas ? Depuis le temps (genre été 2015), ce n’est pas résolu…

J’ai donc décidé, pour régler le problème côté client, de découper mes « gros » fichiers en morceaux de 1Mo. Plus petit, donc plus rapide à envoyer, donc de multiples connexions à MySQL mais d’une durée plus courte. Et ça passe.

Pour ça c’est simple, il faut modifier le fichier de configuration du client. Déjà, installez-le en suivant les instructions officielles, connectez-vous, puis fermez le client.

Il faut ensuite ajouter la ligne chunkSize=1000000 sous la section [General] du fichier de configuration ($HOME/.local/share/data/Nextcloud/nextcloud.cfg sous Linux).

Il existe aussi une autre façon de faire, qui permet d’étendre le changement à tout le système, utile si c’est l’ordinateur familial avec 5 utilisateurs. Pour ça, sous Linux, c’est simple, ajoutez à vos variables d’environnement la suivante : export OWNCLOUD_CHUNK_SIZE=1000000 . Concrètement, vous pouvez soit l’ajouter à votre propre fichier .profile (situé à la racine de votre dossier personnel, ce qui n’affectera que votre utilisateur), soit la propager à tout le système en l’ajoutant au fichier /etc/profile (il vous faudra les droits superutilisateur, dans ce cas).

Pour OS X: c’est la même commande que celle indiquée ci-dessus, puis vérifier dans le fichier de log situé dans: « /Applications/nextcloud.app/Contents/MacOS/nextcloud »

Sous Windows : Panneau de configuration > Système > Paramètres système avancés, puis créer une nouvelle variable soit pour l’utilisateur en cours, soit pour l’entièreté du système :

  • Nom de la variable: OWNCLOUD_CHUNK_SIZE
  • Valeur de la variable: 1000000

Étape 4 : installer/configurer les différentes synchronisations avec Nextcloud sous Android

On va traiter plusieurs choses ici : le client pour les fichiers (qui nous servira également à téléverser automagiquement nos photos, comme le fait Google avec son propre service, sauf que là ça reste chez nous), un client contacts/agenda qui nous permettra de stocker nos contacts et RDV ailleurs que sur un compte Google, un client de synchronisation des tâches et enfin un client pour les notes (façon Google Keep, si on veut et si ça existe encore).

Étape 4a : installer les clients

Plusieurs options s’offrent à vous : passer par le Google Play Store ou par le dépôt de logiciels libres F-Droid. Nextcloud a fait un choix différent d’ownCloud, et bienvenu : l’application officielle est gratuite sur le Play Store (ownCloud vous facture la sienne 0,79€, ce n’est pas excessif mais c’est un choix discutable). Si vous souhaitez passer par F-Droid, la procédure est simple : dans les paramètres de sécurité du téléphone, activez temporairement l’installation d’applications provenant de sources inconnues (au sens de Google, « inconnue » signifie hors Play Store… ce n’est pas forcément dangereux), rendez-vous via le téléphone sur f-droid.org fpour télécharger le fichier APK d’installation. Installez-le. C’est fait !

Petit récapitulatif des logiciels que je vais utiliser ici :

Synchro de…ClientLicencePlay StoreF-Droid
Fichiers/photosNextcloudGPL v2.0Télécharger (gratuit)Télécharger
Contacts/agendaDAVx⁵GPL v3.0Télécharger (3,99€)Télécharger
TâchesOpenTasksApache 2.0Télécharger (gratuit)Télécharger
NotesNextcloud NotesGPL v3.0+Télécharger (2,99€)Télécharger
FavorisNextcloud BookmarksMIT Télécharger (0,79€)Télécharger

Alors, je ne dis pas que ce sont les meilleurs, ou les seuls, simplement ils répondent à mes critères : simples à utiliser, savent se faire oublier (genre la sauvegarde automatique des photos prises, ou même DAVdroid qui une fois configurer ne demande plus rien et fait son job), gratuits (sur F-Droid du moins, et de toutes façons je n’ai pas les services Google Play sur mon smartphone), et surtout libres.

Mais libre à vous d’utiliser autre chose et, pourquoi pas, de me suggérer des outils dans les commentaires : je suis toujours preneur d’infos ! 😀

Certaines de ces applications sont à ajouter à la main côté serveur évidemment. Au pire, il vous suffit de vous rendre sur Nextcloud Apps, de prendre le fichier zip qui correspond à votre version de Nextcloud (a priori, la 12 😉 ) et de le décompresser dans le dossier apps/ de votre instance, toujours via votre client FTP(S), ou même via l’interface web (net2ftp) proposée par OVH. Ensuite, il suffit de les activer dans le menu « Applications » !

Étape 4b : activer l’authentification à 2 facteurs pour Nextcloud

C’est facultatif, bien évidemment, MAIS je le recommande très fortement. Concrètement, vous ajoutez une couche de protection à votre instance : lors de votre connexion, Nextcloud vous demandera un code en plus de votre mot de passe, et vous devrez utiliser votre smartphone pour l’obtenir (ou un des codes de secours sur papier, au pire).

C’est ce qu’on appelle l’authentification forte : vous cumulez 2 facteurs d’authentification (« ce que vous savez » : le mot de passe de votre compte, et « ce que vous possédez » : votre smartphone. En théorie, vous êtes le seul à pouvoir réunir ces deux éléments).

Vous avez pour cela besoin de deux éléments :

  • installer l’application « Two Factor TOTP Provider » côté serveur (la télécharger)et l’activer ;
  • installer et configurer une application permettant de générer les codes sur votre téléphone. Beaucoup de gens utilisent Google Authenticator, mais je vous recommande quelque chose de plus sérieux comme OneTimePad. Il stocke les secrets permettant de générer des codes de manière sécurisée, c’est un atout indéniable, et il est libre, sous licence MIT (le code de Google Authenticator a été refermé il y a quelques années, alors qu’il était initialement ouvert). Bref, choisissez un outil qiu vous convient, tant qu’il respecte la RFC 6238 qui décrit l’implémentation de TOTP.

Une fois que tout cela est fait, il vous suffit de vous rendre sur la page « Personnel » (via le menu en haut à droite), d’activer TOTP, et de générer des codes de secours. Vous aurez un QRCode à « scanner » dans l’application mobile, pour permettre la génération de codes. C’est pas plus compliqué que ça !

TOTP

Étape 4c : configurer l’application officielle

Rien de bien compliqué : au lancement, il faut simplement remplir 3 champs : l’adresse URL de votre serveur, votre login, et votre mot de passe (en cas d’OTP, voir juste au-dessus).

Et c’est parti.

Pour ajouter la fonctionnalité « InstantUpload » allez dans les paramètres, puis « Téléversement automatique ». Les dossiers contenant des photos apparaissent, et vous pouvez pour ceux de votre choix tapoter le petit nuage, qui virera au bleu : les nouvelles photos seront envoyées directement dans votre cloud. Il y a également davantage d’options, comme l’emplacement de stockage, le téléversement par Wi-Fi uniquement, ce genre de choses.

Étape 4d : configurer DAVdroid/DAVx⁵ (et le reste)

Alors là c’est la magie. Il vous suffit d’ouvrir l’application Nextcloud officielle, d’aller dans les paramètres, et y’a un bouton… « Configurer DAVdroid pour le compte actuel ». 😀

Cela va ouvrir DAVdroid avec tout pré-remplir, sauf votre mot de passe évidemment. Il ne vous reste plus qu’à le saisir et vous connecter.

Si pour une raison X ou Y cela ne fonctionne pas, remplacez l’URL fournie par celle accessible dans l’agenda ( https://nextcloud.mon-domaine.fr/remote.php/dav/principals/users/mon_login ). Il trouvera quand même les contacts, rassurez-vous !

nextcloud bookmarks app

Bonus : mot de passe de mise à jour

Lorsque vous utilisez l’outil de mise à jour intégré, via l’interface web, il est fort probable qu’il vous demande un mot de passe. Qui n’est pas le votre. Il demande la version en clair de ce qui correspond à updater.secret contenu dans votre fichier de configuration serveur. Et évidemment, puisque c’est un hash, ce n’est pas réversible.

La seule solution est donc de générer un nouveau updater.secret et de le remplacer dans config.php, en notant au passage la valeur en clair ! 🙂

Pour ce faire, créez un fichier PHP vierge quelque part sur votre mutu, et placez-y le contenu suivant :

<?php $password = trim(shell_exec("openssl rand -base64 48"));if(strlen($password) === 64) {$hash = password_hash($password, PASSWORD_DEFAULT) . "\n"; echo "Insert as updater.secret: ".$hash; echo "The plaintext value is: ".$password."\n";}else{echo "Could not execute OpenSSL.\n";}; ?>

Accédez à ce fichier depuis votre navigateur, notez les deux valeurs renvoyées, et c’est tout bon, vous pourrez mettre à jour après remplacement du hash et validation de sa valeur en clair !

Mots clés