Outils pour utilisateurs

Outils du site


informatique:installation_et_securisation_d_un_serveur_nextcloud_et_nginx_sur_un_raspberrypi_2_et_disque_ssd

FIXME Cette page est en cours de rédaction !

Mes objectifs

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.

Installations

Construction du système :

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

Installation Raspbian OS

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 (FIXME liens vers sites tiers pour explications)

Installation serveur nginx

FIXME décrire particularités RPi2, nginx

Installation serveur Mysql/MariaDB

FIXME 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

Installation Nextcloud

FIXME décrire particularités RPi2, nginx

A date : Nextcloud 21

Messages d'alerte Nextcloud

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.

Tests de performances

FIXME à 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
Test MacBook Air RaspberryPi 2 RaspberryPi 2
Type disque SSD SATA MicroSD SSD (via USB3)
hdparm (en cache) 5190 MB/sec 436.86 MB/sec 420.87 MB/sec
hdparm (buffer) 569 MB/sec 21.69 MB/sec 28.65 MB/sec
Ecriture (dd) 183 MB/s (1GB) 197 MB/s (51Mo) 13,8 MB/s (1GB)

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.

Conclusion pour les performances

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.

Optimisations

FIXME à écrire

Système de fichiers EXT4

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

Utilisation de la swap

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 :

Ecriture des journaux systèmes en décalé

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

Sécurisation

FIXME

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

Transfert serveur "local" vers le nouveau serveur

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 :

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

Ressenti à l'usage

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
/var/www/vhosts/kadavrhusky.net/httpdocs/data/pages/informatique/installation_et_securisation_d_un_serveur_nextcloud_et_nginx_sur_un_raspberrypi_2_et_disque_ssd.txt · Dernière modification: 2021/10/21 14:05 de Pascal Delrot