L'installation d'un serveur internet, Nextcloud sur une RaspberryPi n'a rien de nouveau. La création de ce serveur répond à quelques objectifs personnels :

• serveur de sauvegarde de mes documents, séparé de ma machine principale (auparavant mon serveur Nextcloud de sauvegarde tournait sur ma tour, et servait à synchroniser ma tour et mon portable). En cas de défaillance de la tour, la plupart des données étaient perdues
• soulager mon Nextcloud chez Ouvaton
  • dont l'espace est limité,
  • nombreux messages d'alertes et déconnexions (absence de cron ?)
  • absence d'accès la une console pour executer la commande 'occ'
• éventuellement remplacer mon Nextcloud chez Ouvaton
• apprendre !
• utiliser la carte RaspberryPi 2 achetée il y a déjà 8 ans ! et du matériel d'occasion/réutilisé

Quelques difficultés ou apprentissages à faire :

• accès uniquement en console
• nginx plutôt qu'Apache, car il parait que Nginx est plus adapté au RPi2, mais pas forcément à Nextcloud (il y a débat mais ce n'est pas le sujet)
• sécurisation d'une machine
• certificat HTTPS
• rediriger un sous-domaine vers ma box
• en cas de défaillance du nouveau serveur, il n'y a toujours pas de sauvegarde prévue

Il y a de nombreux blogs traitant du sujet. La plupart sont orientés Nextcloud+Apache et promettent d'inonder le web avec les octets de notre serveur. Relecture de ces blogs, en ayant en tête que ma RPi2 n'est pas aussi puissante que les derniers modèles.

Construction du système :

• boot et système sur carte SD (ext4),
• données et base de données sur SSD (ext4 ou btrfs)

Rien de particulier à signaler sur cette partie.

A date de rédation et réalisation (mars 2021) la version est Raspbian basée sur Debian buster.

Fichiers de configuration sur la clé au premier démarrage : SSH, Wifi ( liens vers sites tiers pour explications)

décrire particularités RPi2, nginx

décrire particularités RPi2, nginx

https://docs.nextcloud.com/server/19/admin_manual/installation/nginx.html

Afin d'économiser les accès sur la carte SD, mais avec à l'inverse le risque de ralentir un peu le système, j'ai fais le choix de déplacer la base de données sur le disque externe.

Les étapes sont les suivantes :

1. Si l'installation n'est pas vierge, sauvegarde préalable
2. Arrêt sur serveur mysql `sudo systemctl stop mysql`
3. Copie à l'identique du répertoire par défaut vers le nouvel emplacement (en conservant les droits d'accès)
4. Renommer le répertoire par défaut par sécurité
5. Modification du fichier de configuration de MariaDB
6. Redémarrage du serveur mysql `sudo systemctl start mysql`
7. Vérification du fonctionnement
8. Effacement de l'ancien répertoire

Le fichier de configuration MariaDB contient alors une ligne similaire à ceci :

/etc/mysql/mariadb.conf.d/50-server.cnf 
datadir                 = /mnt/disk_externe/mysql_data

* Base de connaissance MariaDB, répertoire par défaut * Un tutoriel complet pour déplacer une base de données

décrire particularités RPi2, nginx

A date : Nextcloud 21

La page de paramètres de Nextcloud affiche assez souvent au départ quelques alertes concernant les réglages. Rien de grave et tout a pu se régler en suivant la documentation.

Le module php-imagick n’a aucun support SVG dans cette instance. Pour une meilleure compatibilité, il est recommandé de l’installer.

  apt install php-imagick imagemagicksudo

Aucun cache mémoire n'est configuré. Si possible, configurez un “memcache” pour améliorer les performances. Pour plus d'informations consultez la documentation.

Il a suffit de suivre la documentation qui se trouve ici :

* https://docs.nextcloud.com/server/21/admin_manual/configuration_server/caching_configuration.html * https://docs.nextcloud.com/server/21/admin_manual/configuration_files/files_locking_transactional.html

Le fichier de configuration `config.php` contient alors les lignes suivantes :

'memcache.local' => '\OC\Memcache\Redis',
'memcache.distributed' => '\OC\Memcache\Redis',
'redis' => array(
   'host' => 'localhost',
   'port' => 6379,
   'timeout' => 0,
   'dbindex' => 0,
),
'memcache.locking' => '\OC\Memcache\Redis',
'filelocking.enabled' => true,

Voici 2 autres tutoriels sur le sujet :

* https://www.it-connect.fr/nextcloud-activer-et-configurer-le-cache-redis/ * https://linuxfr.org/wiki/tuto-howto-nextcloud-activer-systeme-de-cache-memcache-avec-redis

L'`OPcache` qui permet de stocker du code php compilé et de gagner en réactivité et temps de calcul :

La documentation PHP est utile à lire : https://www.php.net/manual/en/opcache.installation.php

Il a d'abord fallu trouver quel fichier d'initialisation modifier :

  utilisateur@hote:~ $ php -i | grep php.ini
  Configuration File (php.ini) Path => /etc/php/7.3/cli
  Loaded Configuration File => /etc/php/7.3/cli/php.ini

L'autre fichier est `/etc/php/7.3/fpm/php.ini`, que je n'ai pas modifié.

Par défaut l'OPcache est désactivé :

utilisateur@hote:~ $ sudo more /etc/php/7.3/cli/php.ini | grep "opcache"
[opcache]
;opcache.enable=1
;opcache.enable_cli=0
;opcache.memory_consumption=128
;opcache.interned_strings_buffer=8
;opcache.max_accelerated_files=10000
;opcache.max_wasted_percentage=5
...

Les seules lignes activées après modifications sont :

utilisateur@hote:~ $ more /etc/php/7.3/cli/php.ini | grep opcache
[opcache]
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
opcache.save_comments=1

La limite de mémoire PHP est inférieure à la valeur recommandée de 512 Mo.

J'ai suivi ce tutoriel, c'est l'autre fichier de configuration PHP qu'il a fallu modifier. Le réglage était sur 128Mo. https://greedme.com/install-nextcloud-on-ubuntu-20-04-with-nginx-lemp-stack/

utilisateur@hote:~ $ more /etc/php/7.3/fpm/php.ini | grep memory_limit
memory_limit = 512M

Votre installation n’a pas de préfixe de région par défaut. C’est nécessaire pour valider les numéros de téléphone dans les paramètres du profil sans code pays. Pour autoriser les numéros sans code pays, veuillez ajouter “default_phone_region” avec le code ISO 3166-1 respectif de la région dans votre fichier de configuration.

Il suffit d'ajouter dans le fichier `config.php` :

'default_phone_region' =>  'FR',

Pour d'autres codes pays : https://en.wikipedia.org/wiki/ISO_3166-1

La configuration du serveur web ne permet pas d'atteindre “/.well-known/webfinger”. Vous trouverez plus d'informations dans la documentation.
La configuration du serveur web ne permet pas d'atteindre “/.well-known/nodeinfo”. Vous trouverez plus d'informations dans la documentation.

Ces alertes semblent activées car j'accède à mon serveur via un port qui n'est pas standard, pour tenter d'augmenter la sécurité. En pratique je n'ai pas encore rencontré de problèmes avec les clients DAV.

à faire

Les performances peuvent concerner les disques, le serveur, le temps de réactivité, le ressenti utilisateur. Voici comment j'ai évaluer tout ceci avec des moyens très simples.

Pour les accès disques : http://www.tux-planet.fr/tester-la-vitesse-de-lecture-et-decriture-dun-disque-sous-linux/

Sur mon MacBookAir (2013) qui fonctionne sur Debian, disque SSD :

Test via `hdparm` :

  HOTE:/home/utilisateur/ # hdparm -t -T /dev/sda
  /dev/sda:
  Timing cached reads:   10348 MB in  1.99 seconds = 5190.82 MB/sec
  Timing buffered disk reads: 1710 MB in  3.00 seconds = 569.95 MB/sec

Ecriture d'un fichier de 1GB aléatoire (attention la commande `dd` peut être très dangereuse si utilisée avec des droits administrateurs) :

  HOTE:/home/utilisateur/ # dd if=/dev/zero of=/tmp/test.data bs=1M count=1024 conv=fdatasync
  1024+0 enregistrements lus
  1024+0 enregistrements écrits
  1073741824 octets (1,1 GB, 1,0 GiB) copiés, 5,88258 s, 183 MB/s

Sur la RaspberryPi 2

  utilisateur@raspberrypi2:/tmp $ sudo hdparm -t -T /dev/mmcblk0
  /dev/mmcblk0:
  Timing cached reads:   874 MB in  2.00 seconds = 436.86 MB/sec
  Timing buffered disk reads:  66 MB in  3.04 seconds =  21.69 MB/sec

En conclusion : les performances sont largement en dessous d'un PC, il ne faut pas oublier que la RPi2 n'est qu'un nano-ordinateur. Les performances des disques SSD et HDD sont assez proches, et en fait les valeurs de débit sont proches des débits de la liaison USB. Sans surprise, c'est la liaison USB 2.0 qui limite les débits des disques SATA 3GB/s.

Le serveur est accessible depuis l'extérieur, mais les performances acceptables uniquement en local, ou pour de petits fichiers (contacts, notes, agendas), ou pour envoyer des fichiers vers le serveur (par exemple photographies d'un appareil nomade).

L'utilisation d'un SSD ou d'un HD n'a pas montré de grandes différences, à cause de la liaison USB 2.0. La consommation d'énergie électrique n'a pas semblé très différente non plus entre les 2 disques.

à écrire

Pour diminuer le nombre d'accès (le disque de données est un SSD) à réaliser

C'est un sujet de discussion sur des blogs. A voir, la RPi2 ayant une quantité de RAM limitée. Le choix qui a été réalisé est de créer un fichier de swap de 100MB (puis 256MB). Par rapport à une partition dédiée, le fichier peut “bouger” sur le système de fichier, c'est important sur une carte flash afin de ne pas toujours utiliser les mêmes cellules mémoire.

  sudo dphys-swapfile swapoff
  sudo nano /etc/dphys-swapfile
  CONF_SWAPFILE=256
  sudo dphys-swapfile setup
  want /var/swap=256MByte, checking existing: deleting wrong size file (104857600), generating swapfile ... of 256MBytes
  sudo dphys-swapfile swapon
          

Ne pas oublier les commandes `sudo dphys-swapfile swapoff`, `sudo dphys-swapfile setup` pour regénrer le fichier, puis `sudo dphys-swapfile swapon` avant et après les réglages.

Il est aussi possible de ne pas modifier le fichier de configuration, et d'utiliser une valeur calculée par le système.

Swap ou pas, la discussion est ouverte :

• https://cl-rpi.fr/index.php/2017/09/25/augmenter-swap-de-raspberry-pi/
• https://www.framboise314.fr/et-si-on-se-passait-du-swap/

à essayer L'idée est de limiter le nombre de cycles sur la carte flash microSD

• [ ] Penser à filtrage par MAC address pour l'accès au serveur
• [ ] Authentification à 2 facteurs est intéressante aussi

Mes précédents fichiers étaient hebergés sur ma tour, un serveur Apache+MySQL+Nextcloud. Le transfert était la finalité du projet.

Nextcloud propose des guides de migration qui ont été efficaces, moyennant quelques éléments ci-dessous :

• https://docs.nextcloud.com/server/20/admin_manual/maintenance/migrating.html
• https://docs.nextcloud.com/server/20/admin_manual/maintenance/backup.html
• et aussi https://www.tutorialspoint.com/mysql/mysql-administration.htm

A date, le serveur de test heberge 8Go de données et donne satisfaction en temps de réponse et en durée de fonctionnement. Les données à transférer sont de 135Go, ce qui représente une marche conséquente (base de données, plus contenu du dossier `data` de Nextcloud).

Pour ne pas réinstaller et reconfigurer tout le serveur de test il a été choisi de :

• remplacer la base de données de test par la nouvelle
• remplacer les données par les nouvelles
• tout cela via le fichier config.php de Nextcloud

Les étapes dans l'ordre (en suivant le guide proposé par Nextcloud) :

1. Stopper nginx
2. S'assurer que l'ancien serveur a la même version de Nextcloud que le nouveau
3. Sauvegarder les données (une copie des fichiers de la base données n'a pas réussi, à cause de versions de MySql/MariaDB différentes : la base de données a du être sauvegardée et restaurée via mysqldump et mysql).
4. Transférer les sauvegardes vers le nouveau disque (rsync a été bien utile)
5. Recréer la table dans la base de données (mysql)
6. Donner les droits à l'utilisateur mysql pour accéder à la table
7. Modifier le fichier config.php par rapport au nouveau répertoire `data`
8. Vérifier avec php occ que la connexion à la base de données est correcte
9. Relancer nginx et tester !

Normalement il est possible de se logger et d'accéder aux fichiers ! (cela a été le cas, moyennant quelques oublis de ma part, et non respect des étapes ci-dessus).

Les 4 CPU sont montés à 100% pendant 5 minutes durant le premier login, mais cela n'a pas empéché la navigation sur le site Nextcloud. La swap, auparavant proche de 0Mo, est désormais utilisée (88% des 100Mo parfois).

Ménage :

• suppression base de données serveur de test
• suppression des données de test

A l'usage, la synchronisation totale des fichiers est nettement plus longue qu'auparavant. C'est la plupart du temps sans conséquence lor d'un travail quotidien.

La mise à jour du Nextcloud (21.0.4) via l'interface graphique fonctionne, bien qu'elle soit un peu lente. Il y a des erreurs 504 et des demandes d'authentification via un “updater.secret”. Mes conseils :

• rafraîchir la page, et ne pas cliquer “retry”
• parfois se reconnecter sur l'interface, puis revenir sur la mise à jour permet de reprendre là où elle s'était arrêtée