Afficher/cacher Sommaire
KVM Debian Stretch
Package: 4 GB Mémoire, 2 CPU, 30 GB SSD, 100 Mbps
Selected Location: Paris
Debian Stretch 64
Livraison : vps-26381 93.115.96.97
- Domaine : xoyize.xyz
- IPv4 du serveur : 93.115.96.97
- IPv6 du serveur : 2a03:75c0:35:670d::1
- Courrier entrant : imap.xoyize.xyz sur port 993 (imaps)
- Courrier sortant : mail.xoyize.xyz sur port 587 (smtp submission)
- Compte courrier : xyz@xoyize.xyz
- Certificats : Let’s Encrypt
Première connexion SSH
Via SSH
ssh root@93.115.96.97
Màj
apt update && apt upgrade
Installer rsync, jq, figlet, curl et tmux
apt install rsync curl tmux jq figlet p7zip-full
Locales
Locales : fr_FR.UTF-8
dpkg-reconfigure locales
Generating locales (this might take a while)...
fr_FR.UTF-8... done
Generation complete.
TimeZone
Europe/Paris
dpkg-reconfigure tzdata
Current default time zone: 'Europe/Paris'
Local time is now: Wed Sep 6 15:05:31 CEST 2017.
Universal Time is now: Wed Sep 6 13:05:31 UTC 2017.
Définir hôte et FQDN
Votre serveur reçoit les noms: un nom d’hôte et un nom de domaine complet (nom de domaine entièrement qualifié).
- Nom d’hôte local: pour identifier votre serveur dans votre infrastructure locale. Par exemple. “mail”.
- FQDN (Nom de domaine entièrement qualifié): pour identifier votre serveur sur Internet.Par exemple “mail.mysystems.tld”
Vous n’avez pas besoin d’adapter le FQDN de votre serveur de messagerie à n’importe quel domaine auquel vous souhaitez servir.
Ces domaines n’ont pas besoin d’être identiques ou similaires. Définissez votre nom d’hôte local comme suit:
hostnamectl set-hostname --static mail
Le fichier de configuration /etc/hosts contient FQDN et le nom d’hôte local à côté de l’autre. Il devrait être similaire à celui-ci:
127.0.0.1 localhost
127.0.1.1 mail.serveur.tld mail
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Si vous entrez les commandes “hostname” et “hostname -fqdn”, ceci devrait être votre sortie:
# hostname
mail
# hostname --fqdn
mail.serveur.tld
En outre, le FQDN (“mail.xoyize.xyz”) est copié dans /etc/mailname:
echo $(hostname -f) > /etc/mailname
(Le nom d’hôte dans votre invite de shell s’adaptera après un redémarrage)
DNS OVH
Configuration des champs DNS domaine xoyize.xyz (OVH)
$TTL 3600
@ IN SOA dns106.ovh.net. tech.ovh.net. (2017081700 86400 3600 3600000 300)
IN NS dns106.ovh.net.
IN NS ns106.ovh.net.
IN A 93.115.96.97
IN AAAA 2a03:75c0:35:670d::1
IN MX 1 mail.xoyize.xyz.
imap IN A 93.115.96.97
imap IN AAAA 2a03:75c0:35:670d::1
mail IN A 93.115.96.97
mail IN AAAA 2a03:75c0:35:670d::1
Création utilisateur
Utilisateur adxo
useradd -m -d /home/adxo/ -s /bin/bash adxo
Mot de passe adxo
passwd adxo
Visudo pour les accès root via utilisateur adxo
apt install sudo
echo "adxo ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
Déconnexion puis connexion ssh en mode utilisateur
ssh adxo@93.115.96.97
SSH
connexion avec clé
sur l'ordinateur de bureau
Générer une paire de clé curve25519-sha256 (ECDH avec Curve25519 et SHA2) nommé kvm-xoyize pour une liaison SSH avec le serveur KVM.
ssh-keygen -t ed25519 -o -a 100 -f ~/.ssh/kvm-xoyize
Envoyer la clé publique sur le serveur KVM
scp ~/.ssh/kvm-xoyize.pub adxo@93.115.96.97:/home/adxo/
sur le serveur KVM
On se connecte
ssh adxo@93.115.96.97
Copier le contenu de la clé publique dans /home/$USER/.ssh/authorized_keys
$ cd ~
Sur le KVM ,créer un dossier .ssh
pwd #pour vérifier que l'on est sous /home/$USER
mkdir .ssh
cat /home/$USER/kvm-xoyize.pub >> /home/$USER/.ssh/authorized_keys
et donner les droits
chmod 600 /home/$USER/.ssh/authorized_keys
effacer le fichier de la clé
rm /home/$USER/kvm-xoyize.pub
Modifier la configuration serveur SSH
sudo nano /etc/ssh/sshd_config
Vérifier les options par défaut, commentées par un #
#HostKey /etc/ssh/ssh_host_ed25519_key
#PubkeyAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
Modifier
Port = 55026
PermitRootLogin no
PasswordAuthentication no
session SSH ne se termine pas correctement lors d'un "reboot" à distance
Si vous tentez de redémarrer/éteindre une machine distance par ssh, vous pourriez constater que votre session ne se termine pas correctement, vous laissant avec un terminal inactif jusqu’à l’expiration d’un long délai d’inactivité. Il existe un bogue 751636 à ce sujet. Pour l’instant, la solution de contournement à ce problème est d’installer :
sudo apt-get install libpam-systemd #Installer par défaut sur debian stretch
cela terminera la session ssh avant que le réseau ne tombe.
Veuillez noter qu’il est nécessaire que PAM soit activé dans sshd.
Relancer openSSH
sudo systemctl restart sshd
Accès depuis le poste distant avec la clé privée
$ ssh -p 55026 -i ~/.ssh/kvm-xoyize adxo@93.115.96.97
Exécution script sur connexion
Exécuter un fichier utilisateur nommé $HOME/.ssh/rc si présent
Pour tous les utilisateurs exécuter un fichier nommé /etc/ssh/sshrc si présent
Installer les utilitaires curl jq figlet
Le batch
nano ~/.ssh/rc
#!/bin/bash
#clear
PROCCOUNT=`ps -Afl | wc -l` # nombre de lignes
PROCCOUNT=`expr $PROCCOUNT - 5` # on ote les non concernées
GROUPZ=`users`
ipinfo=$(curl -s ipinfo.io) # info localisation format json
publicip=$(echo $ipinfo | jq -r '.ip') # extraction des données , installer préalablement "jq"
ville=$(echo $ipinfo | jq -r '.city')
pays=$(echo $ipinfo | jq -r '.country')
cpuname=`cat /proc/cpuinfo |grep 'model name' | cut -d: -f2 | sed -n 1p`
echo "\033[0m\033[1;31m"
figlet "xoyize.xyz"
echo "\033[0m"
echo "\033[1;35m \033[1;37mHostname \033[1;35m= \033[1;32m`hostname`
\033[1;35m \033[1;37mWired Ip \033[1;35m= \033[1;32m`ip addr show eth0 | grep 'inet\b' | awk '{print $2}' | cut -d/ -f1`
\033[1;35m \033[1;37mKernel \033[1;35m= \033[1;32m`uname -r`
\033[1;35m \033[1;37mDebian \033[1;35m= \033[1;32m`cat /etc/debian_version`
\033[1;35m \033[1;37mUptime \033[1;35m= \033[1;32m`uptime | sed 's/.*up ([^,]*), .*/1/' | sed -e 's/^[ \t]*//'`
\033[1;35m \033[1;37mCPU \033[1;35m= \033[1;32m`echo $cpuname`
\033[1;35m\033[1;37mMemory Use \033[1;35m= \033[1;32m`free -m | awk 'NR==2{printf "%s/%sMB (%.2f%%)\n", $3,$2,$3*100/$2 }'`
\033[1;35m \033[1;37mUsername \033[1;35m= \033[1;32m`whoami`
\033[1;35m \033[1;37mSessions \033[1;35m= \033[1;32m`who | grep $USER | wc -l`
\033[1;35m\033[1;37mPublic Ip \033[1;35m= \033[1;32m`echo $publicip $pays`
\033[0m"
curl fr.wttr.in/Paris?0
Effacer motd
sudo rm /etc/motd
Déconnexion puis connexion
Serveur de messagerie (iRedMail)
Logiciel Open Source utilisé dans iRedMail:
- Postfix
- Dovecot
- Nginx
- OpenLDAP, ldapd
- MySQL / MariaDB, PostgreSQL
- Amavised-new
- SpamAssassin
- ClamAV
- Webmail Roundcube
- SOGo Groupware
- Fail2ban
- Awstats
- iRedAPD
Caractéristiques de iRedMail:
- Tous les composants sont open-source.
- TLS est activé par défaut. SMTP / IMAP sur TLS, HTTPS webmail
- Créez autant de boîtes aux lettres virtuelles que vous le souhaitez dans un panneau d’administration Web.
- Stocke les comptes de messagerie dans OpenLDAP, MySQL / MariaDB ou PostgreSQL.
Il est recommandé de suivre les instructions ci-dessous sur un système d’installation propre Debian qui a au moins 2 Go de RAM.
Au moment de l’écriture, la dernière version d’iRedMail est 0.9.7, diffusée le 1 juillet 2017.
Veuillez vous rendre sur la page de téléchargement iRedMail (http://www.iredmail.org/download.html) pour télécharger la dernière version.
wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.7.tar.bz2
Extraction
tar xvf iRedMail-0.9.7.tar.bz2
Aller dans le dossier
cd iRedMail-0.9.7
Ajout des permissions en exécution sur le script
chmod +x iRedMail.sh
Exécuter le script bash
sudo bash iRedMail.sh
Message à la fin des opérations
********************************************************************
* URLs of installed web applications:
*
* - Roundcube webmail: httpS://mail.serveur.tld/mail/
*
* - Web admin panel (iRedAdmin): httpS://mail.serveur.tld/iredadmin/
*
* You can login to above links with below credential:
*
* - Username: postmaster@xoyize.xyz
* - Password: ****************
*
*
********************************************************************
* Congratulations, mail server setup completed successfully. Please
* read below file for more information:
*
* - /home/adxo/iRedMail-0.9.7/iRedMail.tips
*
* And it's sent to your mail account postmaster@xoyize.xyz.
*
********************* WARNING **************************************
*
* Please reboot your system to enable all mail services.
*
********************************************************************
Redémarrage
sudo systemctl reboot
Modifier Structure nginx
ON va simplifier la configuration nginx
nano /etc/nginx/nginx.conf
user www-data;
worker_processes 1;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
# include /etc/nginx/conf-enabled/*.conf;
client_max_body_size 12m;
default_type application/octet-stream;
gzip on;
gzip_disable "msie6";
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
include /etc/nginx/mime.types;
upstream php_workers {
server unix:/var/run/php-fpm.socket;
}
sendfile on;
# Hide Nginx version number
server_tokens off;
types_hash_max_size 2048;
# include /etc/nginx/sites-enabled/*.conf;
include /etc/nginx/conf.d/*.conf;
}
Création configuration de base
mkdir -p /etc/nginx/conf.d/mail.serveur.tld.d
Fichier de configuration serveur mail.serveur.tld.conf
nano /etc/nginx/conf.d/mail.serveur.tld.conf
server {
index index.php index.html;
# Listen on ipv4
listen 80;
# Listen on ipv6.
# Note: this setting listens on both ipv4 and ipv6 with Nginx release
# shipped in some Linux/BSD distributions.
#listen [::]:80;
root /var/www/html;
server_name _;
include /etc/nginx/templates/redirect_to_https.tmpl;
include /etc/nginx/templates/misc.tmpl;
include /etc/nginx/templates/php-catchall.tmpl;
}
server {
index index.php index.html;
listen 443;
root /var/www/html;
server_name _;
include /etc/nginx/templates/ssl.tmpl;
include /etc/nginx/templates/awstats.tmpl;
include /etc/nginx/templates/iredadmin.tmpl;
include /etc/nginx/templates/roundcube.tmpl;
include /etc/nginx/templates/sogo.tmpl;
include /etc/nginx/templates/misc.tmpl;
include /etc/nginx/templates/php-catchall.tmpl;
include conf.d/mail.serveur.tld.d/*.conf;
}
Vérification et relance service
nginx -t
systemctl restart nginx
Dkim
On met la clé de celle qui est paramétrée dans la dns ovh
cp /var/lib/dkim/xoyize.xyz.pem /var/lib/dkim/xoyize.xyz.pem.sav
On met en place la clé existante
nano /var/lib/dkim/xoyize.xyz.pem
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDCsswhKO2pBS6i
UglTilZrUEZ6BPWPl+Y3LvIHByIE+tV+yDLsKcW6iyWqq58Ae4WLfZowFa8Ch0Nk
...
RaeHMqJdXeajanS0aq7qgpyw
-----END PRIVATE KEY-----
Certificats SSL
acme/Certificats SSL letsencrypt
Installation client acme.sh
cd ~
sudo -s # en mode super utilisateur
apt install netcat # prérequis
git clone https://github.com/Neilpang/acme.sh.git
cd acme.sh
./acme.sh --install # --nocron
# OK, Close and reopen your terminal to start using acme.sh
cd .. && rm -rf acme.sh/
le client est installé dans /root/.acme.sh/
Création des certificats avec API OVH
- Create application key and secret
https://eu.api.ovh.com/createApp/ (un jeu de clés peut être utilisé pour plusieurs domaines)
API OVH :
Création de clé , OVH : Création de clé API application
Application Name : DNS-Api
Application Description : certificats
Application Key : MyBRE3Oq2FZrLC2N
Application Secret : U8rSfBLK0OYNRoeaCZvatqxUcf5aE8bj
- Valider le jeu de clés (Key Secret) pour un domaine.
sudo -s
# application key
export OVH_AK="MyBRE3Oq2FZrLC2N"
# application secret
export OVH_AS="U8rSfBLK0OYNRoeaCZvatqxUcf5aE8bj"
/root/.acme.sh/acme.sh --dns dns_ovh --issue --keylength 4096 -d xoyize.xyz -d mail.xoyize.xyz -d imap.xoyize.xyz
Le premier passage sort en erreur car i faut une authentification OVH par le lien donné dans le message
Please open this link to do authentication: https://eu.api.ovh.com/auth/?credentialToken=nQ8atrKjW5S0NgeObISCSsUfNSO...
Relancer la commande précédente pour obtenir les certificats avec l’option –force si problème
/root/.acme.sh/acme.sh --dns dns_ovh --force --issue --keylength 4096 -d xoyize.xyz -d mail.xoyize.xyz -d imap.xoyize.xyz
...
[jeudi 7 septembre 2017, 10:46:11 (UTC+0200)] Your cert is in /root/.acme.sh/xoyize.xyz/xoyize.xyz.cer
[jeudi 7 septembre 2017, 10:46:11 (UTC+0200)] Your cert key is in /root/.acme.sh/xoyize.xyz/xoyize.xyz.key
[jeudi 7 septembre 2017, 10:46:11 (UTC+0200)] The intermediate CA cert is in /root/.acme.sh/xoyize.xyz/ca.cer
[jeudi 7 septembre 2017, 10:46:11 (UTC+0200)] And the full chain certs is there: /root/.acme.sh/xoyize.xyz/fullchain.cer
Les liens symboliques vers les certificats :
rm -f /etc/ssl/private/iRedMail.key
rm -f /etc/ssl/certs/iRedMail.crt
ln -s /root/.acme.sh/xoyize.xyz/fullchain.cer /etc/ssl/certs/iRedMail.crt
ln -s /root/.acme.sh/xoyize.xyz/xoyize.xyz.key /etc/ssl/private/iRedMail.key
ln -s /root/.acme.sh/xoyize.xyz/xoyize.xyz.cer /etc/ssl/private/xoyize-cert.pem
ln -s /root/.acme.sh/xoyize.xyz/ca.cer /etc/ssl/private/ca-cert.pem
Activer la mise à jour automatique des certificats si l’installation acme s’est faite avec le paramètre –nocron
crontab -e
28 0 * * * “/root/.acme.sh”/acme.sh –cron –home “/root/.acme.sh” > /dev/null
Vérification tous les jours à 00h028
Test manuel
"/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh"
[jeudi 7 septembre 2017, 10:56:24 (UTC+0200)] ===Starting cron===
[jeudi 7 septembre 2017, 10:56:24 (UTC+0200)] Renew: 'xoyize.xyz'
[jeudi 7 septembre 2017, 10:56:24 (UTC+0200)] Skip, Next renewal time is: lundi 6 novembre 2017, 08:46:11 (UTC+0000)
[jeudi 7 septembre 2017, 10:56:24 (UTC+0200)] Add '--force' to force to renew.
[jeudi 7 septembre 2017, 10:56:24 (UTC+0200)] Skipped xoyize.xyz
[jeudi 7 septembre 2017, 10:56:24 (UTC+0200)] ===End cron===
On relance le service
systemctl restart nginx
On sort du mode su
exit
Nextcloud
Toutes les commandes sont exécutées après passage en mode su
Les modules php nécessaires à nextcloud
apt install php7.0 php7.0-fpm php7.0-mysql php7.0-curl php7.0-json php7.0-gd php7.0-mcrypt php7.0-tidy php7.0-intl php7.0-imagick php7.0-xml php7.0-mbstring php7.0-zip
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
Se rendre dans le dossier /opt/www
cd /opt/www
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
Effacer le zip
rm nextcloud-12.0.2.zip
Créer le dossier data
mkdir /opt/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 /opt/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 /opt/www/nextcloud pour lire les ressources statiques (HTML, CSS, JS, etc.). Nous allons donc attribuer le répertoire /opt/www/nextcloud au groupe www-data.
Enfin nous retirerons toutes les permissions de ce répertoire aux autre utilisateurs.
Créez un utilisateur nextcloud :
useradd nextcloud --comment "limited nextcloud user" --no-create-home
Modifiez le propriétaire et le groupe du répertoire /var/www/nextcloud :
chown -R nextcloud:www-data /opt/www/nextcloud
Retirez toutes les permissions aux autres utilisateurs :
chmod -R o-rwx /opt/www/nextcloud
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.0-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.0-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.0/fpm/pool.d/nextcloud.conf
nano /etc/php/7.0/fpm/pool.d/nextcloud.conf
[nextcloud]
listen = /var/run/php-fpm-nextcloud.socket
; Set permissions for unix socket, if one is used.
listen.owner = nextcloud
listen.group = www-data
listen.mode = 0660
; Unix user/group of processes.
user = nextcloud
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 = /opt/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 :
systemctl restart php7.0-fpm.service
Nginx nextcloud virtualhost
Le fichier de configuration nginx /etc/nginx/conf.d/mail.serveur.tld.d/nextcloud.conf
nano /etc/nginx/conf.d/mail.serveur.tld.d/nextcloud.conf
location ^~ /nextcloud {
alias /opt/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:/var/run/php-fpm-nextcloud.socket;
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
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.0/fpm/php.ini, décommentez et modifiez les lignes suivantes dans la section [opcache] :
nano /etc/php/7.0/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 :
systemctl restart php7.0-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 :
apt install php-apcu redis-server php-redis -y
Ajoutez les lignes suivantes dans le fichier /opt/www/nextcloud/config/config.php :
nano /opt/www/nextcloud/config/config.php
'memcache.local' => '\\OC\\Memcache\\Redis',
'filelocking.enabled' => 'true',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => 'localhost',
'port' => 6379,
'timeout' => 0,
'dbindex' => 0,
),
La nouvelle configuration sera prise en compte après redémarrage du service PHP-FPM :
systemctl restart php7.0-fpm.service
Les fichiers log /opt/www/nextcloud/data/nextcloud.log
Relancer nginx
systemctl restart nginx
Accès https://xoyize.xyz/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
Sauvegarde via shuttle
Toutes les commandes sont exécutées après passage en mode su
Ajout utilisateur backupuser qui ne peut exécuter que rsync et de la clé publique du “serveur de sauvegarde”
Création utilisateur backup
useradd backupuser -c "limited backup user" -m -u 4210
Ajout clé publique ssh dans le fichier authorized_keys du nouvel utilisateur
mkdir /home/backupuser/.ssh
nano /home/backupuser/.ssh/authorized_keys #coller le contenu /home/backupuser/.ssh/id_rsa.pub copié sur terminal du serveur shuttle (yanspm.com)
Création script bash rsync-wrapper.sh
nano /home/backupuser/rsync-wrapper.sh
Contenu du script
#!/bin/sh
date > /home/backupuser/backuplog
#echo $@ >> /home/backupuser/backuplog
/usr/bin/sudo /usr/bin/rsync "$@";
Droits sur le fichier
sudo chown backupuser:backupuser /home/backupuser/rsync-wrapper.sh
sudo chmod 755 /home/backupuser/rsync-wrapper.sh
Edition fichier sudoers pour un accès root à l’exécution de rsync
Ajouter ligne suivante en fin de fichier,exécution en mode root de rsync
echo "backupuser ALL=NOPASSWD: /usr/bin/rsync" >> /etc/sudoers
exit
Sécurisé le site
Modifier la configuration nginx
Modifier /etc/nginx/conf.d/mail.serveur.tld.conf pour accepter uniquement https
server {
index index.php index.html;
# Listen on ipv4
listen 80;
# Listen on ipv6.
# Note: this setting listens on both ipv4 and ipv6 with Nginx release
# shipped in some Linux/BSD distributions.
#listen [::]:80;
root /var/www/html;
server_name _;
#include /etc/nginx/templates/redirect_to_https.tmpl;
#include /etc/nginx/templates/misc.tmpl;
#include /etc/nginx/templates/php-catchall.tmpl;
# redirect http to https www
return 301 https://$http_host$request_uri;
}
server {
index index.php index.html;
listen 443 ssl http2;
root /var/www/html;
server_name _;
include /etc/nginx/templates/ssl.tmpl;
include /etc/nginx/templates/awstats.tmpl;
include /etc/nginx/templates/iredadmin.tmpl;
include /etc/nginx/templates/roundcube.tmpl;
include /etc/nginx/templates/sogo.tmpl;
include /etc/nginx/templates/misc.tmpl;
include /etc/nginx/templates/php-catchall.tmpl;
include conf.d/mail.serveur.tld.d/*.conf;
}
Politique de sécurité
Sécuriser son site web sous nginx avec l’ajout d’en-têtes (headers)
Modifier /etc/nginx/templates/ssl.tmpl
#ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# Fix 'The Logjam Attack'.
ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/ssl/dh2048_param.pem;
#HSTS est un dispositif de sécurité par lequel un site web peut déclarer aux navigateurs qu’ils doivent communiquer avec lui en utilisant exclusivement le protocole HTTPS, au lieu du HTTP
add_header Strict-Transport-Security "max-age=31536000;";
#se protéger contre le détournement de clic (clickjacking)
add_header X-Frame-Options "SAMEORIGIN" always;
#faire une vérification stricte des types Mime. Elle n’accepte qu’une seule directive : nosniff.
add_header X-Content-Type-Options nosniff;
#activer les filtres anti-xss incorporés dans certains navigateurs.
add_header X-XSS-Protection "1; mode=block";
#CSP permet d’autoriser seulement les domaines déclarés à exécuter du script JavaScript, une feuille de style css, etc.
add_header Content-Security-Policy "default-src 'self';";
# To use your own ssl cert (e.g. LetsEncrypt), please create symbol link to
# ssl cert/key used below, so that we can manage this config file with Ansible.
#
# For example:
#
# rm -f /etc/ssl/private/iRedMail.key
# rm -f /etc/ssl/certs/iRedMail.crt
# ln -s /etc/letsencrypt/live/<domain>/privkey.pem /etc/ssl/private/iRedMail.key
# ln -s /etc/letsencrypt/live/<domain>/fullchain.pem /etc/ssl/certs/iRedMail.crt
#
ssl_certificate /etc/ssl/certs/iRedMail.crt;
ssl_certificate_key /etc/ssl/private/iRedMail.key;
Vérifications
Par le site de test https://observatory.mozilla.org/analyze.html?host=xoyize.xyz
Date | Score | Grade |
---|---|---|
September 11, 2017 6:34 PM | 105/100 | A+ |
Détails
Test | Pass | Score | Explanation |
---|---|---|---|
Content Security Policy | Y | +5 | Content Security Policy (CSP) implemented without 'unsafe-inline' or 'unsafe-eval' |
Cookies | - | 0 | No cookies detected |
Cross-origin Resource Sharing | Y | 0 | Content is not visible via cross-origin resource sharing (CORS) files or headers |
HTTP Public Key Pinning | - | 0 | HTTP Public Key Pinning (HPKP) header not implemented (optional) |
HTTP Strict Transport Security | Y | 0 | HTTP Strict Transport Security (HSTS) header set to a minimum of six months (15768000) |
Redirection | Y | 0 | Initial redirection is to https on same host, final destination is https |
Referrer Policy | - | 0 | Referrer-Policy header not implemented (optional) |
Subresource Integrity | - | 0 | Subresource Integrity (SRI) is not needed since site contains no script tags |
X-Content-Type-Options | Y | 0 | X-Content-Type-Options header set to "nosniff" |
X-Frame-Options | Y | 0 | X-Frame-Options (XFO) header set to SAMEORIGIN or DENY |
X-XSS-Protection | Y | 0 | X-XSS-Protection header set to "1; mode=block" |