Afficher/cacher Sommaire
nextcloud (nginx,php7 et mariadb)
Privilégier la Méthode A pour installer Nextcloud
Installer Nextcloud (Méthode A)
Installer Nextcloud à partir de la ligne de commande
Il est maintenant possible d’installer Nextcloud entièrement depuis la ligne de commande. Ceci est pratique pour les opérations scriptées, les serveurs sans affichage et les administrateurs système qui préfèrent la ligne de commande. L’installation de Nextcloud se fait en trois étapes via la ligne de commande :
- Téléchargez le code de Nextcloud Server et décompressez l’archive dans les répertoires appropriés (/var/www/).
- Changez la propriété de votre répertoire nextcloud à votre utilisateur HTTP.Vous devez exécuter occ en tant qu’utilisateur HTTP:
sudo chown -R www-data:www-data /var/www/nextcloud/ - Utilisez la commande occ pour terminer votre installation. Ceci remplace l’exécution de l’assistant d’installation graphique :
cd /var/www/nextcloud/
sudo -u www-data php occ maintenance:install --database "mysql" --database-name "nextcloud" --database-user "admin" --database-pass "zgSgWv1S7oON" --admin-user "admin" --admin-pass "DxShMzcc4v"
En cas de succès
Nextcloud was successfully installed
Notez que vous devez passer dans le répertoire racine Nextcloud (
cd /var/www/nextcloud/), pour exécuterocc maintenance:install, sinon l’installation échouera avec un message d’erreur fatale PHP.
Poursuivre au § Php-fpm Nginx OPcache APCu & Redis
Modifier les lignes suivantes dans le fichier /var/www/nextcloud/config/config.php (à adapter au domaine,ex: xoyize.xyz/nextcloud , nextcloud.xoyize.xyz, etc…)
'trusted_domains' =>
array (
0 => 'nextcloud.xoyize.xyz',
),
'overwrite.cli.url' => 'https://nextcloud.xoyize.xyz',
Installer Nextcloud (Méthode B)
On passe en mode super utilisateur
sudo -s
Base mysql nextcloud
Créer une base mariadb Nextcloud
mysql -uroot -p
sur le prompt MariaDB [(none)]>
CREATE DATABASE nextcloud;
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost' IDENTIFIED BY 'mot-de-passe-base-nextcloud';
FLUSH PRIVILEGES;
quit
Installer nextcloud
Télécharger la denière version de nextcloud (https://download.nextcloud.com/server/releases/)
wget https://download.nextcloud.com/server/releases/nextcloud-12.0.2.zip # Au 23 août 2017
Extraction après téléchargement du fichier
unzip nextcloud-12.0.2.zip
Déplacer le dossier extrait vers le répertoire web /var/www/
mv nextcloud /var/www/
Effacer le zip
rm nextcloud-12.0.2.zip
Créer le dossier data
mkdir /var/www/nextcloud/data
Droits nextcloud
Lors du déploiement basique d’un serveur HTTP, l’utilisateur sous lequel fonctionne ce serveur (Apache, Nginx…) est la plupart du temps www-data, nobody ou apache. Cela signifie que si plusieurs sites existent sous la même instance de Nginx, tous utilisent le même utilisateur. Or si l’un des sites s’avère corrompu par un utilisateur malveillant alors l’assaillant peut profiter pleinement de tous les droits de l’utilisateur sous lequel tourne le serveur web. Tous les sites s’avèrent donc vulnérables.
Pour des raisons évidentes de sécurité, il est donc recommandé de cloisonner ces utilisateurs et d’avoir un utilisateur dédié à la gestion du dossier nextcloud. Cet utilisateur aura des droits aussi restreints que possible à ce répertoire.
Par défaut, les fichiers de Nextcloud possèdent les permissions suivantes :
répertoires : 755 (permission de lecture, d’écriture et d’exécution pour le propriétaire et permission de lecture et d’exécution pour le groupe et les autres)
fichiers : 644 (permission de lecture et d’écriture pour le propriétaire et permission de lecture uniquement pour le groupe et les autres).
Nous allons donc modifier le propriétaire du répertoire /var/www/nextcloud et l’attribuer à un nouvel utilisateur dédié : nextcloud.
Par ailleurs, Nginx est lancé sous l’utilisateur www-data et doit avoir accès en lecture au répertoire /var/www/nextcloud pour lire les ressources statiques (HTML, CSS, JS, etc.). Nous allons donc attribuer le répertoire /var/www/nextcloud au groupe www-data.
Enfin nous retirerons toutes les permissions de ce répertoire aux autre utilisateurs.
Créez un utilisateur nextcloud :
sudo useradd nextcloud
Modifiez le propriétaire et le groupe du répertoire /var/www/nextcloud :
sudo chown -R nextcloud:www-data /var/www/nextcloud
Retirez toutes les permissions aux autres utilisateurs :
sudo chmod -R o-rwx /var/www/nextcloud
Local (Stockage Externe)
Les stockages locaux permettent d’accéder à n’importe quel répertoire du serveur Nextcloud. Comme il s’agit d’un risque de sécurité important, le stockage local ne peut être configuré que dans les paramètres d’administration Nextcloud. Les utilisateurs non administrateurs ne peuvent pas créer de montages de stockage local.
Utilisez-le pour monter n’importe quel répertoire sur votre serveur Nextcloud qui se trouve en dehors de votre répertoire de données Nextcloud. Ce répertoire doit être lisible et inscriptible par l’utilisateur de votre serveur HTTP. Ces exemples de propriété et d’autorisation sont sous Ubuntu Linux :
sudo chown -R www-data:www-data /path/to/localdir
sudo chmod -R 0750 /path/to/localdir
Important : Si vous utilisez des commandes consécutives, assurez-vous que vous êtes bien l’utilisateur www-data :
sudo -u www-data bash
cd /path/to/localdir
mkdir data
Dans le champ Nom du dossier, entrez le nom du dossier que vous voulez voir apparaître sur votre page Fichiers Nextcloud.
Dans le champ Configuration, entrez le chemin complet du répertoire que vous voulez monter.
Dans le champ Disponible pour, entrez les utilisateurs ou groupes qui ont la permission d’accéder à la monture. Par défaut, tous les utilisateurs y ont accès.
Mise à niveau manuelle de Nextcloud
Commencez toujours par faire une nouvelle sauvegarde et désactiver toutes les applications tierces.
- Sauvegardez votre base de données, répertoire de données et fichier config.php Nextcloud Server existants. (Voir Sauvegarde, pour plus d’informations sur la restauration, voir Restauration de la sauvegarde)
- Téléchargez et décompressez la dernière version de Nextcloud Server (fichier archive) de nextcloud.com/install/ dans un répertoire vide en dehors de votre installation actuelle.
Note : Pour décompresser votre nouvelle archive, lancez : unzip nextcloud-[version].zip ou tar -xjf nextcloud-[version].tar.bz2 - Arrêtez votre serveur Web.
- Renommez votre répertoire Nextcloud actuel, par exemple nextcloud-old.
- En décompressant la nouvelle archive, vous créez un nouveau répertoire nextcloud contenant vos nouveaux fichiers serveur. Déplacez ce répertoire et son contenu à l’emplacement d’origine de votre ancien serveur. Par exemple /var/www/, pour qu’une fois de plus vous ayez /var/www/nextcloud.
- Copiez le fichier config/config.php de votre ancien répertoire Nextcloud dans votre nouveau répertoire Nextcloud.
- Si vous conservez vos données/répertoire dans votre répertoire nextcloud/, copiez-le de votre ancienne version de Nextcloud vers votre nouveau répertoire nextcloud/. Si vous le gardez en dehors de nextcloud/ alors vous n’avez rien à faire avec lui, parce que son emplacement est configuré dans votre fichier config.php original, et aucune des étapes de mise à jour ne le touche.
- Si vous utilisez une application tierce, elle n’est pas toujours disponible dans votre instance Nextcloud mise à niveau ou nouvelle. Pour vérifier cela, comparez une liste des applications du nouveau dossier nextcloud/apps/ à une liste des applications de votre ancien dossier nextcloud/apps/ sauvegardé. Si vous trouvez des applications tierces dans l’ancien dossier qui doivent se trouver dans l’instance new/upgraded, copiez-les simplement et assurez-vous que les permissions sont configurées comme indiqué ci-dessous.
- Si vous utilisez un thème tiers, assurez-vous de le copier de votre répertoire themes/ directory vers votre nouveau thème. Il est possible que vous deviez y apporter quelques modifications après la mise à jour.
- Ajustez la propriété et les permissions des fichiers :
chown -R www-data:www-data nextcloud
find nextcloud/ -type d -exec chmod 750 {} \;
find nextcloud/ -type f -exec chmod 640 {} \; - Redémarrez votre serveur Web.
- Lancez maintenant la mise à jour à partir de la ligne de commande en utilisant occ, comme cet exemple sur Ubuntu Linux :
sudo -u www-data php occ upgrade
( !) ceci DOIT être exécuté à partir de votre répertoire d’installation nextcloud. - L’opération de mise à niveau prend de quelques minutes à quelques heures, selon la taille de votre installation. Lorsqu’il est terminé, vous verrez un message de réussite (
Update successful) ou un message d’erreur qui vous dira où il s’est mal passé.
Connectez-vous et jetez un coup d’œil au bas de votre page Admin pour vérifier le numéro de version. Vérifiez vos autres réglages pour vous assurer qu’ils sont corrects. Allez à la page Apps et passez en revue les applications principales pour vous assurer que les bonnes sont activées. Réactivez vos applications tierces.
Php-fpm Nginx OPcache APCu & Redis
Php-fpm
Le module PHP-FPM permet la communication entre le serveur Nginx et PHP, basée sur le protocole FastCGI. Ce module, écoutant sur le port 9000 par défaut ou sur un socket UNIX, permet notamment l’exécution de scripts PHP dans un processus indépendant de Nginx avec des UID et GID différents. Il sera alors possible, dans le cas de la gestion de plusieurs applications sur un même serveur, de créer et configurer un groupe (appelé aussi pool) par application. Un pool définit notamment le UID/GID des processus PHP et le nombre de processus minimum, maximum ou encore le nombre de processus en attente à lancer.
[nextcloud] : nom du pool. Il est possible de créer plusieurs pools par fichier. Chaque pool doit commencer par cette directive.
listen : interface d’écoute des requêtes. Les syntaxes acceptées sont ADRESSE_IP:PORT (exemple : listen = 127.0.0.1:9000) et /path/to/unix/socket (exemple : listen = /var/run/nextcloud.sock). Le socket est représenté comme un simple fichier sur le système et permet d’interfacer des processus entre eux sans passer par la couche réseau du système, ce qui est inutile lorsque Nginx et PHP-FPM sont hébergés sur le même serveur. Je vous conseille donc d’utiliser un socket.
listen.owner & listen.group : affecte l’utilisateur et le groupe au socket Unix si utilisé. Ces deux paramètres peuvent être associés au paramètre listen.mode qui définit les permissions du socket (660 par défaut). Il est important que Nginx ait les droits de lecture sur le socket Unix.
user & group : utilisateur et groupe sous lesquels le pool de processus sera exécuté. Cet utilisateur et ce groupe doivent bien sûr exister sur votre système et surtout accéder aux fichiers PHP de votre Nextcloud. Cela veut dire aussi que chaque fichier et répertoire créé dans Nextcloud appartiendra à cet utilisateur et à ce groupe. Comme nous l’avons vu dans le chapitre dédié aux droits Unix, chaque fichier devra appartenir à l’utilisateur nextcloud et au groupe www-data.
pm : directive acceptant les 3 valeurs suivantes : static, dynamic et ondemand.
pm = static : les processus, au nombre de pm.max_children, sont continuellement actifs (quelle que soit la charge et l’affluence de votre Nextcloud) et sont susceptibles de consommer de la mémoire inutilement. Cette directive est recommandée si Nextcloud est l’unique application de votre serveur.
pm = dynamic : le nombre de processus fils pourra varier suivant la charge. Cependant, nous gardons le contrôle sur le nombre de processus fils à créer au démarrage du serveur, le nombre de processus maximum, en attente de requêtes, etc. Les directives suivantes deviennent obligatoires : pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers. Cette directive est recommandée si vous avez plusieurs pools avec un fort trafic (plus de 10 000 requêtes/jour).
pm = ondemand : aucun processus fils n’est lancé au démarrage du serveur, les processus s’activent à la demande et auront une durée de vie définie par la directive pm.process_idle_timeout. L’intérêt de cette directive est de libérer de la mémoire en cas de faible charge mais celle-ci peut légèrement augmenter le temps de réponse de votre Nextcloud. Cette directive est recommandée si vous avez plusieurs pools avec potentiellement une faible affluence.
pm.max_children : nombre maximum de processus fils. La valeur du paramètre pm.max_children varie d’un système à l’autre et est importante avec le paramètre pm = ondemand.
Pour déterminer la valeur de ce paramètre ,arrêtez le service php-fpm :
sudo systemctl stop php7.3-fpm.service
Affichez la mémoire disponible (colonne available) sur votre système :
free -m # available = 1630, le système dispose de 1630Mo de RAM disponible.
La quantité de RAM que vous souhaitez allouer au maximum à Nextcloud est au maximum 768Mo de RAM pour Nextcloud.
Affichez la mémoire utilisée par un processus fils php-fpm :
sudo systemctl start php7.3-fpm.service && ps --no-headers -o "rss,cmd" -C php-fpm7.0 | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'
14M
Déterminez le nombre de pm.max_children en appliquant la méthode de calcul suivante : pm.max_children = mémoire allouée / mémoire utilisée par un processus fils , 768/14 = 54
pm.process_idle_timeout : durée en secondes avant qu’un processus fils inactif soit détruit.
pm.max_requests : nombre de requêtes que chaque processus fils devra exécuter avant d’être détruit. Cette valeur ne doit pas être trop élevée afin de contourner d’éventuelles fuites mémoires, ni trop faible pour ne pas solliciter régulièrement le CPU à chaque création de processus fils. 500 reste une valeur recommandée.
env[] : variables d’environnement nécessaires à PHP-FPM.
Création du pool dédié à Nextcloud /etc/php/7.3/fpm/pool.d/nextcloud.conf
[nextcloud]
listen = /run/php/php7.3-fpm-nextcloud.sock
; Set permissions for unix socket, if one is used.Méthoe B listen.owner = nextcloud
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
; Unix user/group of processes. user = nextcloud (méthode B)
user = www-data
group = www-data
pm = dynamic
pm.max_children = 6
pm.start_servers = 3
pm.min_spare_servers = 3
pm.max_spare_servers = 5
pm.max_requests = 500
pm.status_path = /fpm-status
ping.path = /ping
request_terminate_timeout = 1d
request_slowlog_timeout = 5s
slowlog = /var/log/nginx/nextcloud.slow.log
rlimit_files = 4096
rlimit_core = 0
chdir = /var/www/nextcloud/
catch_workers_output = yes
clear_env = no
php_value[upload_max_filesize] = 10G
php_value[post_max_size] = 10G
php_value[default_charset] = UTF-8
Redémarrez le service php-fpm afin d’activer le nouveau pool nextcloud :
sudo systemctl restart php7.3-fpm.service
Nginx virtualhost
Nextcloud dans la racine web de nginx
La configuration suivante doit être utilisée lorsque Nextcloud est placé dans la racine Web de votre installation nginx. Dans cet exemple, il s’agit de /var/www/nextcloud et il est accessible via https://nextcloud.xoyize.xyz
Le fichier de configuration nginx /etc/nginx/conf.d/nextcloud.xoyaz.xyz.conf
upstream php-handler {
#server 127.0.0.1:9000;
server unix:/run/php/php7.3-fpm-nextcloud.sock;
}
server {
listen 80;
listen [::]:80;
server_name nextcloud.xoyaz.xyz;
# enforce https
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name nextcloud.xoyaz.xyz;
ssl_certificate /etc/ssl/private/xoyaz.xyz-fullchain.pem;
ssl_certificate_key /etc/ssl/private/xoyaz.xyz-key.pem;
ssl_session_timeout 5m;
ssl_session_cache shared:SSL:50m;
# As suggested by Mozilla : https://wiki.mozilla.org/Security/Server_Side_TLS and https://en.wikipedia.org/wiki/Curve25519
# (this doesn't work on jessie though ...?)
# ssl_ecdh_curve secp521r1:secp384r1:prime256v1;
# As suggested by https://cipherli.st/
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers on;
# Ciphers with modern compatibility
#---------------------------------
# https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-1.6.2&openssl=1.0.1t&hsts=yes&profile=modern
# Uncomment the following to use modern ciphers, but remove compatibility with some old clients (android < 5.0, Internet Explorer < 10, ...)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS13+AESGCM+AES128:EECDH+AESGCM:EECDH+CHACHA20:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
# Add headers to serve security related headers
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy no-referrer;
# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;
# Path to the root of your installation
root /var/www/nextcloud/;
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
location = /.well-known/carddav {
return 301 $scheme://$host/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}
# set max upload size
client_max_body_size 512M;
fastcgi_buffers 64 4K;
# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;
location / {
rewrite ^ /index.php$request_uri;
}
location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
deny all;
}
location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+)\.php(?:$|\/) {
fastcgi_split_path_info ^(.+?\.php)(\/.*|)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS on;
#Avoid sending the security headers twice
fastcgi_param modHeadersAvailable true;
fastcgi_param front_controller_active true;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
}
location ~ ^\/(?:updater|ocs-provider)(?:$|\/) {
try_files $uri/ =404;
index index.php;
}
# Adding the cache control header for js and css files
# Make sure it is BELOW the PHP block
location ~ \.(?:css|js|woff2?|svg|gif)$ {
try_files $uri /index.php$request_uri;
add_header Cache-Control "public, max-age=15778463";
# Add headers to serve security related headers (It is intended to
# have those duplicated to the ones above)
# Before enabling Strict-Transport-Security headers please read into
# this topic first.
# add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
#
# WARNING: Only add the preload option once you read about
# the consequences in https://hstspreload.org/. This option
# will add the domain to a hardcoded list that is shipped
# in all major browsers and getting removed from this list
# could take several months.
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy no-referrer;
# Optional: Don't log access to assets
access_log off;
}
location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
try_files $uri /index.php$request_uri;
# Optional: Don't log access to other assets
access_log off;
}
}
Nextcloud dans un sous-dossier de nginx
La configuration suivante doit être utilisée lorsque Nextcloud est placé dans un sous-répertoire de votre installation nginx.
Le fichier de configuration nginx /etc/nginx/conf.d/shuttle.d/nextcloud.conf
location ^~ /nextcloud {
alias /var/www/nextcloud/;
if ($scheme = http) {
rewrite ^ https://$server_name$request_uri? permanent;
}
# Add headers to serve security related headers
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains;';
# Set max upload size
client_max_body_size 10G;
fastcgi_buffers 64 4K;
# Disable gzip to avoid the removal of the ETag header
gzip off;
# Errors pages
error_page 403 /nextcloud/core/templates/403.php;
error_page 404 /nextcloud/core/templates/404.php;
# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /nextcloud/public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /nextcloud/public.php?service=host-meta-json last;
location /nextcloud {
rewrite ^ /nextcloud/index.php$uri;
}
location = /nextcloud/robots.txt {
allow all;
log_not_found off;
access_log off;
}
location ~ ^/nextcloud/(?:build|tests|config|lib|3rdparty|templates|data)/ {
deny all;
}
location ~ ^/nextcloud/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ ^/nextcloud/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
include fastcgi_params;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_param SCRIPT_FILENAME $request_filename;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true;
fastcgi_param REMOTE_USER $remote_user;
fastcgi_pass unix:/run/php/php7.3-fpm-nextcloud.sock;
fastcgi_intercept_errors on;
}
location ~ ^/nextcloud/(?:updater|ocs-provider)(?:$|/) {
try_files $uri/ =404;
index index.php;
}
# Adding the cache control header for js and css files
location ~* \.(?:css|js)$ {
add_header Cache-Control "public, max-age=7200";
# Add headers to serve security related headers
add_header Strict-Transport-Security "max-age=15768000;";
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
# Optional: Don't log access to assets
access_log off;
}
location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
# Optional: Don't log access to other assets
access_log off;
}
}
Vérifier nginx
nginx -t
Relancer php-fpm et nginx
sudo systemctl restart php7.3-fpm nginx
Accès https://cinay.pw/nextcloud
Créer un compte administrateur admin + mot de passe
Répertoire des données /var/www/nextcloud/data
Base MariaDb (MySql) nextcloud , utilisateur nextcloud + mot de passe accès
Cache PHP : OPcache
OPcache (qui signifie Optimizer Plus Cache) est introduit depuis la version 5.5.0 de PHP. Il sert à cacher l’opcode de PHP, c’est-à-dire les instructions de bas niveau générées par la machine virtuelle PHP lors de l’exécution d’un script. Autrement dit, le code pré-compilé est stocké en mémoire. Cela évite ainsi l’étape de compilation à chaque requête PHP. De plus, OPcache va optimiser l’exécution du code afin d’en améliorer les performances.
Éditez le fichier /etc/php/7.3/fpm/php.ini, décommentez et modifiez les lignes suivantes dans la section [opcache] :
sudo nano /etc/php/7.3/fpm/php.ini
[opcache]
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
La nouvelle configuration sera prise en compte après redémarrage du service PHP-FPM :
sudo systemctl restart php7.3-fpm.service
Cache de données : APCu & Redis
APCu permet notamment de mettre en cache les variables PHP et de les stocker en mémoire vive. Redis est un système de gestion de base de données NoSQL avec un système de clef-valeur scalable (s’adapte à la charge). Une des principales caractéristiques de Redis est de conserver l’intégralité des données en RAM. Cela permet d’obtenir d’excellentes performances en évitant les accès disques, particulièrement coûteux.
Installez les paquets APCu et Redis :
sudo apt install php-apcu redis-server php-redis -y
Ajoutez les lignes suivantes dans le fichier /var/www/nextcloud/config/config.php :
sudo nano /var/www/nextcloud/config/config.php
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => 'localhost',
'port' => 6379,
],
La nouvelle configuration sera prise en compte après redémarrage du service PHP-FPM :
sudo systemctl restart php7.3-fpm.service
Nextcloud sécurité et configuration
Lors de la première connexion en mode administrateur au “nuage”, https://nextcloud.xoyize.xyz par exemple, il faut aller vérifier la configuration (Paramètres et Vue d’ensemble) , le compte rendu dans Avertissements de sécurité & configuration
Dnas le cas d’une configuration correcte
Correction anomalie Big Int
Message du type: Certaines colonnes de la base de données n’ont pas été converties en BigInt (64 bits). Changer le type de colonne dans de grandes tables peu prendre beaucoup de temps, elles n’ont donc pas été converties automatiquement. En exécutant ‘occ db:convert-filecache-bigint’ ces changements en suspens peuvent être déclenchés manuellement. Cette opération doit être exécutée pendant que l’instance est hors ligne.
Depuis Nextcloud 13 les BigInt sont utilisés pour stocker les identifiants et les clés auto-incrément dans la base de données. Comme le changement de colonnes sur de grandes tables peut prendre un certain temps (jusqu’à plusieurs heures ou jours), la mise à jour de Nextcloud 12 ou plus tôt n’a pas effectué cette migration sur le cache de fichiers et la table d’activité.
Pour faciliter la mise à jour de ces tables, nous avons ajouté une commande console, qui peut être utilisée pour migrer les colonnes restantes vers bigints.
La commande peut être exécutée en toute sécurité.
$ sudo -u www-data php occ db:convert-filecache-bigint
Following columns will be updated:
* filecache.mtime
* filecache.storage_mtime
This can take up to hours, depending on the number of files in your instance!
Continue with the conversion (y/n)? [n] y
Il affichera un message de réussite lorsqu’il n’y a rien à faire :
$ sudo -u www-data php occ db:convert-filecache-bigint
All tables already up to date!
Note : Comme pour une mise à jour normale, vous devriez fermer votre serveur apache ou nginx ou activer le mode maintenance avant d’exécuter la commande pour éviter les problèmes avec vos clients de synchronisation.