[{"content":"Pour automatiser le déploiement de mes serveurs avec Nginx, PHP, MariaDB et pour créer les vhosts Nginx, j\u0026rsquo;utilisais précédemment EasyEngine v3 - qui avait d\u0026rsquo;ailleurs fait l\u0026rsquo;objet d\u0026rsquo;un article. Le problème, c\u0026rsquo;est qu\u0026rsquo;EasyEngine n\u0026rsquo;était plus vraiment à jour. Et pour cause, ses développeurs (rtCamp) travaillaient sur une nouvelle mouture qui a été publiée fin novembre 2018, EasyEngine v4.\nMalheureusement, cette nouvelle version développée en PHP qui utilise WP-CLI et Docker ne réponds pas vraiment à mes besoins, et ne laisse (à l\u0026rsquo;heure actuelle) que très peu de place à la customisation, aussi bien au niveau des configurations Nginx, que des paquets/containers utilisés.\nN\u0026rsquo;y voyez pas un reproche à l\u0026rsquo;encontre de ses créateurs, puisque je comprends tout à fait le choix fait par l\u0026rsquo;équipe de rtCamp, et il me semble tout à fait normal que l\u0026rsquo;outil qu\u0026rsquo;ils développent soit avant tout adapté à leurs besoins. Il me paraît d\u0026rsquo;ailleurs important de souligner qu\u0026rsquo;ils mettent à disposition, gratuitement, avec une simple licence MIT, une application très complète et documentée, et ceux depuis déjà plusieurs années (la première version d\u0026rsquo;EasyEngine a été publiée en 2014).\nFinalement, c\u0026rsquo;est en parcourant les articles du blog d\u0026rsquo;EasyEngine fin Décembre, que j\u0026rsquo;ai découvert qu\u0026rsquo;un fork de la version 3 d\u0026rsquo;EasyEngine baptisé WordOps était actuellement en développement et qu\u0026rsquo;une première pre-release était disponible sur Github.\nAyant contribué de mon mieux au projet EasyEngine v3 en publiant un certain nombre de scripts ainsi que la majorité de mes configurations Nginx, j\u0026rsquo;ai été contacté par l\u0026rsquo;équipe de WordOps que j\u0026rsquo;ai finalement intégré début Février.\nNous avons publié la première version \u0026ldquo;stable\u0026rdquo; de l\u0026rsquo;application début Mai et il était donc temps de rédiger un article pour vous présenter WordOps.\nWordOps qu\u0026rsquo;est ce que c\u0026rsquo;est ?\rC\u0026rsquo;est un outil en ligne de commande qui facilite l\u0026rsquo;administration d\u0026rsquo;un serveur et le déploiement de sites avec Nginx (notamment WordPress) en utilisant des commandes simples - faciles à mémoriser.\nQuels sont les pré-requis pour installer WordOps ?\rDu côté hardware, il n\u0026rsquo;y a pas vraiment de pré-requis, puisque l\u0026rsquo;application est développée en Python avec le framework Cement et ne nécessite que quelques mégaoctets d\u0026rsquo;espace disque pour le stockage des librairies.\nPour une utilisation en production, les services installés et configurés par WordOps tel que Nginx, PHP-FPM ou MariaDB, nécessitent un minimum de ressources pour fonctionner. Ce minimum peut varier en fonction du trafic des sites hébergés. C\u0026rsquo;est pourquoi nous conseillons d\u0026rsquo;installer WordOps sur un serveur disposant d\u0026rsquo;au moins 2Go de RAM et si possible d\u0026rsquo;un processeur multi-core (qu\u0026rsquo;ils soient virtuels ou non) pour garantir le bon fonctionnement des différents services déployés avec WordOps et donc la disponibilité des sites hébergés.\nPar contre, si vous comptez utiliser WordOps pour du développement, il devrait normalement fonctionner sur n\u0026rsquo;importe qu\u0026rsquo;elle machine/VM disposant de 512mo de RAM ou plus.\nNous avons d\u0026rsquo;ailleurs ajouté depuis peu le support de la distribution Raspbian 9, qui permet donc l\u0026rsquo;installation sur Raspberry Pi (nos tests ont été réalisés sur le modèle 3B+).\nDu côté software, les distributions linux supportées sont :\nUbuntu 16.04 LTS (Xenial) Ubuntu 18.04 LTS (Bionic) Ubuntu 19.04 (Disco) Debian 8 (Jessie) Debian 9 (Stretch) Raspbian 9 (Stretch) Quelles sont ses fonctionnalités ?\rWordOps réalise non seulement l\u0026rsquo;installation et la configuration des paquets nécessaires au déploiement d\u0026rsquo;un site (Nginx, PHP, MariaDB) mais il s\u0026rsquo;occupe également de la création des vhosts Nginx, de la base de données, d\u0026rsquo;installer WordPress et même d\u0026rsquo;obtenir un certificat SSL Let\u0026rsquo;s Encrypt, le tout réalisable en une seule ligne de commande.\nDans le cas d\u0026rsquo;un site WordPress, vous disposez de plusieurs solutions de cache (optionelles) : Nginx fastcgi_cache, Redis (full page cache + object cache) ou WP-Super-Cache.\nEnfin WordOps dispose d\u0026rsquo;un tableau de bord (que j\u0026rsquo;ai réalisé depuis un template bootstrap de Creative Tim et avec la suite de monitoring Netdata) qui permet à la fois de monitorer le serveur mais également d\u0026rsquo;accéder à des outils tel que PhpMyAdmin, Adminer, eXtplorer, phpRedisAdmin etc.. Une démo est disponible à l\u0026rsquo;adresse suivante : demo.wordops.eu.\nQu\u0026rsquo;est ce qu\u0026rsquo;il y a sous le capot ?\rNginx stable v1.16.1 (custom) avec le support du HTTP/2 HPACK de Cloudflare, de la compression avec Brotli, et des modules tiers tel que ngx_cache_purge ou ngx_vts PHP 7.2 \u0026amp; PHP 7.3 MariaDB server 10.3 Redis 5.0 Netdata pour le monitoring Acme.sh pour la gestion des certificats SSL Let\u0026rsquo;s Encrypt WP-CLI pour le déploiement des sites WordPress Et bien sûr, un ensemble de templates de configuration Nginx, qui ont pour objectif de délivrer les meilleures performances possibles ainsi qu\u0026rsquo;un niveau de sécurité optimale. Pour cela, WordOps utilise par exemple Nginx en tant que load-balancer pour répartir la charge sur les pools php-fpm en utilisant plusieurs unix sockets. On retrouve également un certain nombre de directives limitant l\u0026rsquo;accès et/ou l\u0026rsquo;exécution et le téléchargement de certains fichiers afin de bloquer les tentatives d\u0026rsquo;attaques régulièrement utilisées.\nInstaller WordOps\rUn script pour automatiser l\u0026rsquo;installation de WordOps est bien sûr disponible, il s\u0026rsquo;exécute avec la commande suivante :\nwget -qO wo wops.cc \u0026amp;\u0026amp; sudo bash wo Si vous souhaitez installer manuellement WordOps, un guide est disponible dans la documentation\nDurant l\u0026rsquo;installation, WordOps vous demandera un nom d\u0026rsquo;utilisateur et une adresse email. Ces informations sont uniquement utilisées pour générer le fichier .gitconfig nécessaire au fonctionnement de git, qui est utilisé pour enregistrer les différentes configurations du serveur.\nCommencer avec WordOps\rAprès avoir installé WordOps, la première étape est d\u0026rsquo;activer la complétion des commandes, il suffit pour cela d\u0026rsquo;utiliser la commande :\nsource /etc/bash_completion.d/wo_auto.rc Nous pouvons donc commencer à utiliser les commandes WordOps, dont la structure est la suivante :\nwo \u0026lt;commande\u0026gt; [options] Vous souhaitez obtenir la liste des commandes disponibles ? Rien de plus simple, utilisez la commande :\nwo Vous pouvez également obtenir des informations sur chacune des sous-commandes en ajoutant les arguments -h ou --help.\nExemple :\nwo site create -h Installer les services (optionnel)\rWordOps peut installer les services Nginx, PHP ou MySQL via la commande wo stack ou n\u0026rsquo;installer que les services nécessaires lors de la création d\u0026rsquo;un site avec la commande wo site create.\nSi vous comptez utiliser WordOps pour héberger vos sites WordPress, il peut être intéressant de commencer par déployqer les services (Nginx, PHP 7.2, MariaDB) ainsi que les outils additionnels (phpMyAdmin, Adminer, OpcacheGui) qui seront disponibles dans le backend accessible via le port 22222 (exemple : https://IP.DU.SERVEUR:22222 ou https://serveur.hostname:22222).\nPour déployer les services, la commande à utiliser est :\nwo stack install Créer votre premier site\rQue vous ayez suivi ou non l\u0026rsquo;étape précédente, vous pouvez créer votre premier site. La création de site se fait via la commande wo site create avec la structure suivante :\nwo site create [\u0026lt;nom_de_domaine\u0026gt;] [type_de_site] [options] \u0026lt;options\u0026gt; Pour vous donner un exemple relativement simple, nous allons créer un site WordPress, configuré avec PHP 7.3 et le système de cache nginx fastcgi_cache, sécurisé avec un certificat SSL Let\u0026rsquo;s Encrypt :\nwo site create site.tld --wpfc --php73 --letsencrypt Quelques points à retenir\rpar défaut et en l\u0026rsquo;absence de l\u0026rsquo;argument --php73, WordOps utilisera PHP 7.2 l\u0026rsquo;argument --wpfc définit le type de site, ici un site WordPress avec le système de cache Nginx fastcgi_cache. Vous pouvez découvrir tous les autres types de sites dans la documentation. l\u0026rsquo;argument --letsencrypt est optionel et peut être utilisé avec n\u0026rsquo;importe quel type de site. Si le site que vous souhaitez créer est un sous-domaine, utilisez alors l\u0026rsquo;argument --letsencrypt=subdomain pour que WordOps n\u0026rsquo;essaye pas de générer un certificat SSL pour l\u0026rsquo;alias www.site.tld. Voici un exemple qui présente le fonctionnement général de WordOps :\nContribuer\rComme pour la majorité des projets open-source, toute contribution est la bienvenue. Et il n\u0026rsquo;est pas nécessaire d\u0026rsquo;être un développeur ou un administrateur système pour contribuer.\nLe simple fait de faire un signalement détaillé d\u0026rsquo;un bug dans l\u0026rsquo;application est une contribution au projet. Vous pouvez également participer à l\u0026rsquo;amélioration de la documentation de WordOps, qui peut facilement être éditée car elle est rédigée en markdown et hébergée dans un dépôt Github.\nSi vous souhaitez contribuer directement au développement de WordOps, sachez que la rédaction d\u0026rsquo;un guide est en cours, avec un présentation détaillée des librairies utilisées et les règles à suivre notamment pour le style à appliquer au code (PEP8). Je mettrais à jour cet article dès que le guide sera publié sur le dépôt Github.\nLes liens utiles\rle site du projet : https://wordops.net le dépôt Github : https://github.com/WordOps/WordOps le forum : https://community.wordops.net/ la documentation : https://docs.wordops.net/ le compte twitter : https://twitter.com/WordOps_ le compte mastodon : https://mastodon.top/@WordOps ","date":"2019-05-18T12:03:24Z","image":"/images/2019/05/Sans-titre--1-.png","permalink":"/wordops-deployer-wordpress-nginx-simplement/","title":"WordOps - Déployer WordPress avec Nginx simplement"},{"content":"Rocket.Chat est une plateforme de chat open-source et particulièrement complète. Vous pouvez aussi bien l’utiliser pour créer une chat-room, avec une gestion des utilisateurs et des permissions, que pour proposer un live chat via un widget sur votre site web.Cette plateforme est d’autant plus intéressante que vous pouvez la déployer en utilisant les “snaps” sur Ubuntu. Ainsi vous n’aurez pas besoin d’installer/configurer NodeJS ou MongoDB.\nInstaller Rocket.chat avec un snap\rL’installation se fait via une seule ligne de commande :\nsudo snap install rocketchat-server Votre instance Rocket.Chat sera alors accessible à l’adresse : http://IP-de-VOTRE-SERVEUR:3000.\nMettre en place un reverse-proxy avec Nginx\rIl est préférable de mettre en place un reverse-proxy pour accéder à l\u0026rsquo;interface de Rocket.Chat via un port standard et d\u0026rsquo;utiliser un certificat SSL pour sécuriser les échanges. Nous allons pour cela installer Nginx et générer un certificat SSL via Let’s Encrypt.\nCommençons par installer Nginx :\napt update \u0026amp;\u0026amp; apt install nginx On créer ensuite notre vhost dans /etc/nginx/sites-available/ :\nnano /etc/nginx/sites-available/chat.votredomaine.tld Dont voici le contenu :\n# redirection http vers https server { listen 80; listen [::]:80; server_name chat.votredomaine.tld; return 301 https://chat.votredomaine.tld; } # Upstream upstream backend { server 127.0.0.1:3000; } # HTTPS Server server { server_name chat.votredomaine.tld; error_log /var/log/nginx/rocketchat.access.log; location / { proxy_pass http://backend/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection \u0026#34;upgrade\u0026#34;; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forward-For $proxy_add_x_forwarded_for; proxy_set_header X-Forward-Proto http; proxy_set_header X-Nginx-Proxy true; proxy_redirect off; } # permet de stocker la configuration ssl dans le répertoire du site include /var/www/votredomaine.tld/conf/nginx/*conf; } Pour activer ce vhost, on créer un lien symbolique vers le répertoire /etc/nginx/sites-enabled avec la commande :\nln -s /etc/nginx/sites-available/chat.votredomaine.tld /etc/nginx/sites-enabled/ Puis on relance Nginx :\nservice nginx reload Obtenir un certificat SSL Let\u0026rsquo;s Encrypt avec acme.sh\rIl ne nous reste plus qu’à générer le certificat via Let’s Encrypt, on installe donc acme.sh :\nwget -O - https://get.acme.sh | sh sudo source ~/.bashrc Puis on génère le certificat pour notre sous-domaine.\nacme.sh --issue -d chat.votredomaine.tld --pre-hook \u0026#34;systemctl stop nginx\u0026#34; --standalone --post-hook \u0026#34;systemctl start nginx\u0026#34; --ecc -k ec-384 On créer un répertoire pour stocker notre certificat :\nmkdir -p /etc/letsencrypt/live/chat.votredomaine.tld Puis on installe le certificat dans ce répertoire :\nacme.sh --install-cert -d chat.votredomaine.tld --ecc \\ --cert-file /etc/letsencrypt/live/chat.votredomaine.tld/cert.pem \\ --key-file /etc/letsencrypt/live/chat.votredomaine.tld/key.pem \\ --fullchain-file /etc/letsencrypt/live/chat.votredomaine.tld/fullchain.pem \\ --ca-file /etc/letsencrypt/live/chat.votredomaine.tld/ca.pem \\ --reloadcmd \u0026#34;systemctl restart nginx.service\u0026#34; On termine en ajoutant le certificat SSL à notre configuration Nginx, pour cela nous allons créer le fichier /var/www/chat.votredomaine.tld/conf/nginx/ssl.conf qui sera automatiquement ajouté dans notre vhost grâce à la directive include /var/www/chat.votredomaine.tld/conf/nginx/*conf;. Voici son contenu:\nlisten 443 ssl http2; listen [::]:443 ssl http2; ssl_certificate /etc/letsencrypt/live/chat.votredomaine.tld/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/chat.votredomaine.tld/key.pem; ssl_trusted_certificate /etc/letsencrypt/live/chat.votredomaine.tld/ca.pem; La dernière étape pour pouvoir accéder à l\u0026rsquo;instance Rocket.Chat est d\u0026rsquo;appliquer la configuration avec la commande :\nservice nginx reload Vous pourrez alors accéder à votre instance via l\u0026rsquo;adresse https://chat.votredomaine.tld. Pour accéder au panel d\u0026rsquo;administration de Rocket.chat, il vous faudra créer un premier compte utilisateur qui sera automatiquement définit en tant qu\u0026rsquo;administrateur.\n","date":"2019-05-01T16:21:00Z","image":"/images/2019/05/rocket-chat.jpg","permalink":"/installer-rocket-chat-ubuntu-16-04-lts/","title":"Installer Rocket.chat sur Ubuntu 18.04 LTS"},{"content":"Il peut-être intéressant (ou nécessaire) de mettre en place un VPN pour inter-connecter plusieurs serveurs, principalement pour garantir le chiffrement des échanges entre ces derniers. Si des solutions comme OpenVPN sont très populaires car elles proposent des clients sur toutes les plateformes, elles ne sont pas nécessairement les plus pertinentes lorsqu\u0026rsquo;il s\u0026rsquo;agit de créer un réseau privé entre plusieurs serveurs linux. Pour répondre à ce besoin, il existe heureusement d\u0026rsquo;autres solutions, notamment Tinc, le sujet que nous allons aborder aujourd\u0026rsquo;hui.\nDans ce tutoriel nous allons voir comment installer la dernière version stable de Tinc et comment créer un réseau privé pour connecter 3 serveurs. Cet exemple est basé sur mon utilisation actuelle précédente de Tinc, à savoir connecter mon raspberry pi (derrière un NAT) et mon cluster de stockage GlusterFS, réparti sur deux serveurs dédiés. Tinc était alors la solution à deux problématiques :\nétablir une connexion securisée entre les noeuds GlusterFS (j\u0026rsquo;ai préféré mettre en place un VPN à cause des nombreux problèmes rencontrés avec les connexions SSL/TLS et GlusterFS 4.X) accéder aux données d\u0026rsquo;un cluster GlusterFS depuis un client derrière un NAT Les termes utilisés dans ce tutoriel :\nune instance Tinc = un réseau privé Tinc un noeud = un serveur du réseau Installer Tinc\rLa méthode la plus simple pour installer Tinc est d\u0026rsquo;utiliser les dépôts APT d\u0026rsquo;Ubuntu ou de Debian. Cependant les paquets disponibles ne sont pas vraiment à jour. La version actuelle de Tinc est 1.0.35, mais les dépôts Ubuntu ne propose que la version 1.0.33 et ceux de Debian la version 1.0.31.\nEdit du 10/07/2019 : Les mises à jour de sécurité des paquets Debian sont rétro-actives sur les versions précédentes. Il n\u0026rsquo;y a donc pas de danger particulier à utiliser des versions antérieures à 1.0.35 sur Debian.\nIl est donc préférable/recommandé de compiler Tinc depuis les sources, notamment lorsqu\u0026rsquo;on sait que la version 1.0.35 est une release de sécurité suite à la découverte de deux failles qui touchent toutes les versions antérieures (CVE-2018-16737, CVE-2018-16738).\nAjout du 10/07/2019 : Pour simplifer l\u0026rsquo;installation sur Ubuntu 18.04 LTS, j\u0026rsquo;ai réalisé un backport du paquet tinc 1.0.35 depuis les dépôts d\u0026rsquo;Ubuntu 19.04. Le backport est disponible via le service PPA launchpad : https://launchpad.net/~virtubox/+archive/ubuntu/tinc\nCette version n\u0026rsquo;est pas vulnérable aux CVE-2018-16737 et CVE-2018-16738. Pour l\u0026rsquo;installer rien de plus simple :\nsudo add-apt-repository ppa:virtubox/tinc -u -y apt install tinc -t bionic-backports Compilation\rOn commence par installer les dépendances permettant de compiler tinc :\nsudo apt-get install git libssl-dev zlib1g-dev liblzo2-dev \\ build-essential automake autoconf gettext texinfo -y Puis on clone le dépôt Git :\ncd /usr/local/src git clone git://tinc-vpn.org/tinc cd tinc On réalise la configuration avant de compiler :\nautoreconf -fsi ./configure --prefix= Puis on lance la compilation :\n# -j définit le nombre de threads utilisés pour la compilation # $(nproc) permet d\u0026#39;obtenir le nombre de threads disponibles sur le CPU make -j\u0026#34;$(nproc)\u0026#34; Si la compilation se déroule sans erreur, on peut alors installer tinc avec la commande :\nsudo make install Ajout des services systemd\rLa dernière étape pour terminer l\u0026rsquo;installation est la création des services systemd permettant d\u0026rsquo;exécuter Tinc et ses instances (réseaux privés) dès le démarrage de la machine. Il faut en effet créer deux services distincts, le premier permettant de gérer l\u0026rsquo;exécution de Tinc, et le second l\u0026rsquo;exécution des instances Tinc (sous le format tinc@nom_du_reseau).\nLe service tinc\rLe fichier à créer est /lib/systemd/system/tinc.service dont le contenu est le suivant :\n# This is a mostly empty service, but allows commands like stop, start, reload # to propagate to all tinc@ service instances. [Unit] Description=Tinc VPN After=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/true ExecReload=/bin/true WorkingDirectory=/etc/tinc [Install] WantedBy=multi-user.target On peut ensuite activer le service via la commande :\nsudo systemctl enable tinc.service Le service pour les instances tinc@\rLe second service qui permet la gestion des instances Tinc est à créer dans /lib/systemd/system/tinc@.service, voici son contenu :\n[Unit] Description=Tinc net %i PartOf=tinc.service ReloadPropagatedFrom=tinc.service [Service] Type=simple WorkingDirectory=/etc/tinc/%i ExecStart=/usr/sbin/tincd -n %i -D ExecReload=/usr/sbin/tincd -n %i -kHUP KillMode=mixed TimeoutStopSec=5 Restart=always RestartSec=60 [Install] WantedBy=tinc.service Il permettra par la suite d\u0026rsquo;activer séparément les réseaux privés (instances) Tinc via la commande :\nsudo systemctl enable tinc@nom_du_reseau Il n\u0026rsquo;est donc pas nécessaire d\u0026rsquo;utiliser cette commande immédiatement, puisqu\u0026rsquo;il faut tout d\u0026rsquo;abord réaliser la configuration de notre réseau privé.\nConfigurer Tinc\rLa configuration d\u0026rsquo;une instance Tinc\rL\u0026rsquo;ensemble des fichiers de configuration de Tinc sont à placer dans le répertoire /etc/tinc, dans lequel la configuration de chaque instance se fera dans un répertoire portant le nom de l\u0026rsquo;instance.\nQuelques informations sur la configuration utilisée pour notre exemple :\nnotre instance/réseau privé se nomme jesuisadmin_reseau, sa configuration se trouve donc dans le répertoire /etc/tinc/jesuisadmin_reseau nos 3 serveurs se nomment respectivement gfs1, gfs2 et rbpy. Nous avons choisi d\u0026rsquo;utiliser la plage d\u0026rsquo;adresses 10.0.0.0/24 pour notre réseau privé Tinc Afin vous donner tout de suite une vue d\u0026rsquo;ensemble de la configuration d\u0026rsquo;un réseau privé avec Tinc, voici le répertoire de configuration du réseau jesuisadmin_reseau, une fois toutes les étapes du tutoriel terminées :\n├── jesuisadmin_reseau │ ├── hosts │ │ ├── gfs1 │ │ ├── gfs2 │ │ └── rbpy │ ├── rsa_key.priv │ ├── tinc-down │ ├── tinc-up │ └── tinc.conf On y retrouve :\ntinc.conf : fichier de configuration principal qui contient notamment le nom de la machine, l\u0026rsquo;interface réseau à utiliser et le protocole de l\u0026rsquo;instance (ipv4/ipv6). tinc-up et tinc-down : les scripts permettant de démarrer et d\u0026rsquo;arrêter l\u0026rsquo;instance Tinc rsa_key.priv : la clé privée du serveur répertoire hosts : le répertoire qui contient les configurations partagées de chacun des noeuds connectés au réseau privé. Les étapes pour configurer nos 3 machines vont donc être :\nRéaliser la configuration initiale de chaque machine Générer les clés publiques/privées de chaque machine Synchroniser le répertoire hosts entre les machines Configuration initiale\r\u0026ndash; À réaliser sur les 3 serveurs \u0026ndash;\nOn commence donc par créer le répertoire /etc/tinc/jesuisadmin_reseau :\nmkdir -p /etc/tinc/jesuisadmin_reseau Puis on créer le fichier de configuration principal tinc.conf dans ce nouveau répertoire :\nnano /etc/tinc/jesuisadmin_reseau/tinc.conf Dans lequel nous allons définir la configuration de notre réseau privé, en commençant par gfs1 :\n# Interface réseau à utiliser Interface = tun0 # Identifiant de la machine sur le VPN Name=gfs1 AddressFamily = ipv4 On réalise la même opération sur gfs2, avec une petite différence dans le fichier tinc.conf puisqu\u0026rsquo;on y ajoute la directive ConnectTo :\n# Interface réseau à utiliser Interface = tun0 # Identifiant de la machine sur le VPN Name=gfs2 AddressFamily = ipv4 # sur le client ConnectTo = gfs1 On termine par le troisième serveur rbpy dont la configuration sera similaire à gfs2 :\n# Interface réseau à utiliser Interface = tun0 # Identifiant de la machine sur le VPN Name=rbpy AddressFamily = ipv4 # sur le client ConnectTo = gfs2 Générer les clés publiques/privées\rPour pouvoir initier la connexion entre les différents serveurs, Tinc se base sur un échange de clés cryptographiques, sur le même principe que les clés SSH. Il faut donc créer un répertoire hosts dans lequel nous allons définir les adresses IP publiques et privées de chacun des serveurs, ainsi que leurs clés publiques.\nOn commence donc par créer le répertoire hosts :\nmkdir -p /etc/tinc/jesuisadmin_reseau/hosts Avant de générer la clé publique et privée d\u0026rsquo;un serveur, en utilisant la commande :\nsudo tincd -n jesuisadmin_reseau -K4096 L\u0026rsquo;argument -K4096 définit la taille de la clé RSA à générer. Lors de l\u0026rsquo;exécution de cette commande, vous devriez obtenir deux nouveaux fichiers :\nla clé privée du serveur /etc/tinc/jesuisadmin_reseau/rsa_key.priv la clé publique du serveur dans le fichier de configuration portant le nom de l\u0026rsquo;hôte : /etc/tinc/jesuisadmin_reseau/hosts/nom_du_serveur Dans ce dernier fichier, nous allons devoir ajouter avant la clé publique, l\u0026rsquo;adresse publique et privée de l\u0026rsquo;hôte. Il est également possible d\u0026rsquo;y ajouter d\u0026rsquo;autres paramètres, comme par exemple les ciphers à utiliser pour la connexion.\nVoici un exemple de fichier de configuration pour le serveur gfs1 :\nAddress = 5.9.XXX.XXX Subnet = 10.0.0.1/32 Cipher=aes-256-cbc Digest=sha256 -----BEGIN RSA PUBLIC KEY----- MIICCgKCAgEApd4Gf48I1Cnvgb8Hw67yIWmlhoe9yiz80Fr1IF0gjjbDpzsZwkg+ 6r7KaDIWmVdoSYiOlrutohH0105daS+YyJbTVP6heGYAlStVqMFL/rT2CbZvYEfe F1l/PYtEGrbTRJDQgpwByXbmgvha2DcKBJFcfduH85FnYv7KzZ94vmYBwhZe8ArA f/0XeEpR7fYfIdxN7Z5jS0olkd5mUyrpXVwkmbJ/9q3j5vuVMon9BLDAf1XP4oXn ehRPLdh39XswFfF35rrxtLy03a+iPTZuhDBbVl2V/UVcVtyQHUNwTzrOvqBgYfaa Q2L8hW6U/bvvOpj2NCN3YIm8cDR2NNScORXVSqm0xpTk+vCjETrOpBGR1z2JEWdT 3nPw+a7oAwfgCzSOvRx1MW+w1GqF+iil/ADQXcQa78i0xRIl/xCG0taI5EdUnRAq 7R5Y2kDtMt6LUdvOLPGpYFdIP859jTxSXSkkvWeEO7syuvVMdMLfBIGG1zczqQ6+ RLKCV+l0JwZpw4YEiJLHlzZQax3J7eBxlsv3gJoEWeuPZaPP/dUcREisqhrXLLT3 Jiq+aqMolbSzcXvRIGrcNVko4d82SStzpSJwehREhyDrgzOSMhEhTy7m/G3YvcGQ v0F0bnuk1tqf6VUT9+MTBstaRTLEaRsc5RqI26lkCWwfO7c0WHkDLg0CAwEAAQ== -----END RSA PUBLIC KEY----- Dans lequel on retrouve les options :\nAddress est l\u0026rsquo;IP publique du serveur Subnet est l\u0026rsquo;IP privée du serveur Cipher \u0026amp; Digest les paramètres TLS (facultatif) Synchroniser le répertoire hosts\rUne fois cette étape réalisée sur chacun des serveur, il faut également procéder à l\u0026rsquo;échange des clés publiques entre les serveurs. Autrement dit, le contenu du répertoire hosts doit être le même sur chaque serveur. Dans notre cas, on doit y retrouver trois fichiers configurations : gfs1, gfs2 et rpby.\nVous êtes libre d\u0026rsquo;utiliser la méthode de votre choix pour synchroniser le contenu du répertoire hosts entre vos serveurs, voici quelques propositions pour échanger les fichiers de configuration entre les serveur :\nSynchroniser le répertoire avec rsync Transférer les fichiers avec scp Utiliser un dépôt git pour ajouter chaque serveur Une fois de répertoire hosts synchronisé entre les serveurs, il ne reste plus qu\u0026rsquo;à configurer les scripts d\u0026rsquo;initialisation et d\u0026rsquo;arrêt de Tinc.\nConfiguration des exécutables Tinc\rLa dernière étape avant de pouvoir connecter nos serveurs est la création des scripts exécutables de créer et démarrer/arrêter l\u0026rsquo;interface réseau virtuelle utilisée pour se connecter au réseau privé. Pour cela il faut créer les fichiers tinc-up et tinc-down dans /etc/tinc/jesuisadmin_reseau dont voici le contenu pour gfs1 :\ntinc-up\n#!/bin/sh # /etc/tinc/jesuisadmin_reseau/tinc-up ip addr add 10.0.0.1/24 dev $INTERFACE ifconfig $INTERFACE up tinc-down\n#!/bin/sh # /etc/tinc/jesuisadmin_reseau/tinc-down ifconfig $INTERFACE down Sur les deux autres serveurs, le contenu des deux scripts sera quasiment le même, puisque l\u0026rsquo;unique différence sera l\u0026rsquo;adresse IP de l\u0026rsquo;interface réseau.\nUne fois les deux fichiers créés sur chacun des serveurs, il ne reste plus qu\u0026rsquo;à les rendre exécutables :\nsudo chmod 755 /etc/tinc/jesuisadmin_reseau/tinc-* Démarrer et administrer Tinc\rVérifier la configuration du pare-feu\rAvant d\u0026rsquo;initialiser la connexion entre les serveurs, il est important de faire une vérification : le port utilisé par Tinc est-il ouvert ? Par défaut, Tinc utilise le port 655, qu\u0026rsquo;il est donc nécessaire d\u0026rsquo;ouvrir préalablement. Si vous utilisez ufw, il vous suffit d\u0026rsquo;utiliser la commande\nufw allow 655 Mais vous pouvez également le faire directement via iptables :\niptables INPUT -p tcp --dport 655 -j ACCEPT iptables INPUT -p udp --dport 655 -j ACCEPT Démarrer et arrêter Tinc\rSi vous avez réussi à suivre toutes les étapes du tutoriel, vous êtes enfin arrivés**** au bout du tunnel (meilleur jeu de mot de l\u0026rsquo;année) puisque vous allez pouvoir initialiser votre réseau privé depuis votre premier noeud. Cela peut se faire directement via la commande tincd ou en utilisant un service systemd.\nAvec tincd\rdémarrer le réseau jesuisadmin_reseau\nsudo tincd -n jesuisadmin_reseau Vous pouvez ensuite vérifier avec ifconfig ou ip addr show que la création de l\u0026rsquo;interface réseau tun0 s\u0026rsquo;est bien déroulée et que l\u0026rsquo;adresse IP de cette dernière correspond bien à votre configuration. Il ne reste plus qu\u0026rsquo;à tester le ping entre vos machines.\nUn problème de connexion ? Vous pouvez à tout moment arrêter la connexion au réseau tinc avec la commande suivante :\narrêter le réseau jesuisadmin_reseau\nsudo tincd -n jesuisadmin_reseau -k Avec un service systemd\rPour utiliser un service systemd, il faut tout d\u0026rsquo;abord activer le service associé à notre instance Tinc, ce qui se fait via la commande :\nsudo systemctl enable tinc@jesuisadmin_reseau On peut ensuite démarrer le service via la commande :\nsudo service tinc@jesuisadmin_reseau start Et après ?\rUne fois la connexion entre les noeuds établie, vous pouvez librement utiliser votre réseau privé pour faire transiter vos données entre les serveurs.\nIl sera peut-être nécessaire d\u0026rsquo;autoriser le trafic depuis le sous-réseau utilisé par Tinc via votre pare-feu. Dans le cas d\u0026rsquo;UFW, cela se fait via la commande :\nsudo ufw allow from 10.0.0.0/24 Enfin pour un usage derrière un NAT, il vous suffit d\u0026rsquo;ajouter une redirection de port sur votre routeur/box pour pouvoir connecter votre serveur au réseau privé.\n","date":"2019-03-02T15:07:54Z","image":"/images/2018/12/Mettre-en-place-un-VPN-mesh-avec-tinc-sur-Debian_Ubuntu---Raspbian.jpg","permalink":"/mettre-en-place-un-vpn-mesh-avec-tinc/","title":"Mettre en place un VPN Mesh avec tinc sur Debian/Ubuntu"},{"content":"Après un premier article expliquant comment configurer l\u0026rsquo;interface réseau d\u0026rsquo;une machine virtuelle KVM sur Proxmox VE en utilisant qemu-nbd, il était nécessaire d\u0026rsquo;y ajouter une seconde partie pour détailler l\u0026rsquo;une des nouvelles fonctionnalités de Proxmox : le support de Cloud-Init (depuis la release 5.1). Dans ce tutoriel nous allons voir comment déployer et configurer une machine virtuelle KVM avec Cloud-init.\nQu\u0026rsquo;est ce que Cloud-init ?\rCommençons par une présentation de Cloud-Init. Il s\u0026rsquo;agit d\u0026rsquo;une application (ou package en anglais) multi-plateforme dont la fonction est de réaliser la configuration initiale des machines virtuelles (ou instances public cloud) déployées depuis des templates.\nLes tâches généralement réalisées par Cloud-Init sont :\nDéfinir le hostname Générer les clés privées SSH Configurer les interfaces réseaux Définir le mot de passe de l\u0026rsquo;utilisateur Ajouter une clé SSH Redimensionner le(s) disque(s) (si nécessaire) Mettre à jour les paquets via APT Dans le cas de Proxmox, Cloud-Init permet de configurer les machines virtuelles KVM aussi facilement que le containers LXC. Il n\u0026rsquo;est plus nécessaire de se connecter via la console NoVNC pour configurer une machine virtuelle.\nCloud-Init est d\u0026rsquo;autant plus pratique lorsqu\u0026rsquo;il s\u0026rsquo;agit de déployer une machine virtuelle nécessitant une configuration réseau particulière (comme une passerelle par défaut qui n\u0026rsquo;est pas dans le même sous-réseau que la machine virtuelle chez OVH).\nDéployer une machine virtuelle KVM avec Cloud-Init\rCréer un template de machine virtuelle\rLa première étape avant de pouvoir déployer notre première machine virtuelle avec Cloud-Init est la création d\u0026rsquo;un template de VM, qui pourra être cloné pour déployer une nouvelle VM.\nÀ l\u0026rsquo;heure actuelle, il est déjà possible d\u0026rsquo;ajouter un disque Cloud-Init à une machine virtuelle depuis l\u0026rsquo;interface web de Proxmox, cependant l\u0026rsquo;import d\u0026rsquo;une image disque nécessite toujours l\u0026rsquo;utilisation de la CLI de Proxmox.\nPour nous faire gagner du temps, Canonical met à disposition des images minimales de machines virtuelles sur le site cloud-images.ubuntu.com. Cloud-Init est préinstallé sur l\u0026rsquo;ensemble de ces images permettant un déploiement automatisé.\nUbuntu n\u0026rsquo;est pas la seule distribution linux à proposer des images cloud, vous pouvez également télécharger des images Debian ou Centos.\nDans notre exemple, nous allons utiliser l\u0026rsquo;image Ubuntu Server 18.04 LTS Bionic.\nIl est tout à fait possible d\u0026rsquo;installer une distribution linux depuis un ISO avant d\u0026rsquo;installer Cloud-Init pour en faire un template. Il est cependant important de noter que le redimensionnement automatique de la partition root n\u0026rsquo;est possible qu\u0026rsquo;en l\u0026rsquo;absence de partition swap (pratique courante sur les instances public cloud)\nOn se connecte donc en SSH à notre hôte Proxmox VE, et on commence par télécharger l\u0026rsquo;image Ubuntu Server 18.04 LTS :\nwget -O bionic.img \\ http://cloud-images.ubuntu.com/daily/server/bionic/current/bionic-server-cloudimg-amd64.img Pour simplifier l\u0026rsquo;étape suivante, nous allons définir l\u0026rsquo;ID de notre VM Proxmox via une variable. Notre espace de stockage se nomme ici local, mais il généralement nommé local-lvm lorsque Proxmox est installé depuis un ISO.\n# on définit l\u0026#39;ID de la VM ID_VM=1804 # Créer une VM avec 2GB de RAM + une interface réseau connectée au bridge vmbr0 qm create ${ID_VM} --memory 2048 --net0 virtio,bridge=vmbr0 # on importe l\u0026#39;image de VM précédemment téléchargée qm importdisk ${ID_VM} bionic.img local # on associe le nouveau disque virtuel à la machine qm set ${ID_VM} --scsihw virtio-scsi-pci --scsi0 local:${ID_VM}/vm-${ID_VM}-disk-0.raw Nous avons ainsi créé notre VM puis importé l\u0026rsquo;image disque téléchargée depuis cloud-images.ubuntu.com. Il ne nous reste plus qu\u0026rsquo;à configurer Cloud-Init. Pour cela nous allons ajouter un lecteur Cloud-Init qui permettra la configuration de la VM depuis Proxmox.\n# ajouter un disque cloudinit qm set ${ID_VM} --ide2 local:cloudinit # définir sur quel disque la VM doit booter qm set ${ID_VM} --boot c --bootdisk scsi0 # ajout d\u0026#39;une interface vga connectée au serial qm set ${ID_VM} --serial0 socket --vga serial0 Voilà, notre VM est prête, on peut enfin la transformer en template avec la commande :\n# transformer la VM en template qm template ${ID_VM} Configurer une VM avec Cloud-Init\rLa configuration d\u0026rsquo;une VM avec Cloud-Init peut se faire via la CLI de Proxmox ou via l\u0026rsquo;interface web. Dans notre exemple, l\u0026rsquo;ID de notre VM est 158 et son IP est 192.168.0.201.\nConfiguration via l\u0026rsquo;interface web\rOn commence par cloner notre template afin de créer une nouvelle machine virtuelle. On peut alors se diriger vers l\u0026rsquo;onget \u0026ldquo;Hardware\u0026rdquo; de notre VM pour la redimensionner selon nos besoins (notamment le disque dont la taille est de 2.5Go par défaut) :\nEfin, pour configurer notre VM via l\u0026rsquo;interface web, il suffit d\u0026rsquo;aller dans l\u0026rsquo;onglet \u0026ldquo;Cloud-Init\u0026rdquo; pour accéder à la liste des paramètres disponibles :\nParmi les paramètres disponibles, on retrouve\nl\u0026rsquo;utilisateur, qui est généralement le nom de la distribution linux choisie, autrement dit \u0026ldquo;ubuntu\u0026rdquo; dans notre cas. le mot de passe de l\u0026rsquo;utilisateur les paramètres DNS des fichier /etc/hosts et /etc/resolv.conf une ou plusieurs clé SSH publiques la configuration du l\u0026rsquo;interface réseau On peut lorsqu\u0026rsquo;on a terminé, démarrer notre VM.\nConfiguration via la CLI\rVia la CLI, la démarche est relativement similaire puisqu\u0026rsquo;on commence par cloner notre template de machine virtuelle :\nqm clone 1000 158 --name xenial Pour redimensionner le disque, il suffit d\u0026rsquo;utiliser :\nqm resize 158 scsi0 10G On peut alors ajouter une clé SSH pour pouvoir se connecter à la machine virtuelle, par exemple la clé publique de notre hôte Proxmox :\nqm set 158 --sshkey ~/.ssh/id_rsa.pub Et la dernière étape est la configuration de l\u0026rsquo;interface réseau qui se fait via l\u0026rsquo;argument --ipconfig[x] où [x] est le numéro de l\u0026rsquo;interface réseau :\nqm set 158 --ipconfig0 ip=192.168.0.201/24,gw=192.168.0.1 Une fois la configuration terminée, on peut démarrer notre vm avec la commande :\nqm start 158 Quelques informations complémentaires\rAprès quelques mois d\u0026rsquo;utilisation, j\u0026rsquo;ai eu l\u0026rsquo;occasion d\u0026rsquo;utiliser Cloud-Init dans un certain nombre de cas et j\u0026rsquo;ai parfois remarqué des points qu\u0026rsquo;il semble important de souligner.\nLa configuration d\u0026rsquo;IP fail-over chez OVH\nJ\u0026rsquo;ai longtemps cherché la solution pour configurer une IP fail-over OVH sur une VM Ubuntu 18.04 LTS qui utilise netplan pour la configuration de l\u0026rsquo;interface réseau. Je l\u0026rsquo;ai découvert un peu par hasard, et je ne comprends toujours pas pourquoi cette configuration fonctionne.\nDans mon cas, je définis l\u0026rsquo;IP de la VM dans Cloud-Init, du type 178.XX.XX.XX/32 mais au lieu de définir 54.XX.XX.254 en tant que passerelle (IP de l\u0026rsquo;hôte .254), je définis simplement l\u0026rsquo;IP de la VM en tant que passerelle.\nLa configuration post-déploiement\nPar défaut Cloud-Init mettra à jour le fichier /etc/hosts, bloquera l\u0026rsquo;accès SSH en tant que root et mettra à jour le hostname de la machine à chaque démarrage de cette dernière.\nVous pouvez désactiver ces actions en éditant le fichier /etc/cloud/cloud.cfg.\n","date":"2018-12-04T12:48:48Z","image":"/images/2018/11/D-ployez-vos-machines-virtuelles-KVM-sur-Proxmox-avec-Cloud-Init--1-.png","permalink":"/deployer-des-machines-virtuelles-kvm/","title":"Déployez vos machines virtuelles KVM sur Proxmox VE avec Cloud-Init"},{"content":"Lorsqu\u0026rsquo;on héberge un certain nombre d\u0026rsquo;applications \u0026ldquo;open-source\u0026rdquo;, il est était parfois difficile de suivre le flux de mises à jour des applications. Il s\u0026rsquo;agit heureusement d\u0026rsquo;une époque révolue, grâce à l\u0026rsquo;application Release Bell developpée par l\u0026rsquo;équipe de cloudron.io\nRelease-Bell est une application qui permet de recevoir une notification lorsqu\u0026rsquo;une nouvelle release est publiée sur Github parmi la liste des dépôts que vous avez \u0026ldquo;étoilé\u0026rdquo;. Elle est disponible via la plateforme de self-hosting cloudron que j\u0026rsquo;ai précédement présenté dans un article, mais elle peut également être installée manuellement sur n\u0026rsquo;importe quel serveur linux disposant de Nodejs et d\u0026rsquo;un serveur MySQL.\nLes notifications sont envoyées par email, mais il n\u0026rsquo;est absolument pas obligatoire d\u0026rsquo;activer cette fonctionnalité. Dans mon cas, visualiser la liste des dépôts Github qui m\u0026rsquo;intéresse, sous la forme d\u0026rsquo;un flux chronologique suivant la date de publication des releases est largement suffisant.\nDans ce tutoriel, nous allons voir comment installer l\u0026rsquo;application Release-Bell sur un serveur Debian(8/9) ou Ubuntu (16.04 LTS/18.04 LTS).\nLes prérequis\rComme je l\u0026rsquo;ai dis précédemment, pour installer Release-Bell, vous aurez besoin d\u0026rsquo;un reverse-proxy (Nginx dans ce tutoriel), de NodeJS (dont la version LTS actuelle est 8.x) et d\u0026rsquo;un serveur MySQL (ou MariaDB).\nNginx\rPour l\u0026rsquo;installation d\u0026rsquo;Nginx, rien de plus simple, sur Ubuntu ou Debian suffit d\u0026rsquo;utiliser :\nsudo apt-get update \u0026amp;\u0026amp; sudo apt-get install nginx -y NodeJS\rPour NodeJS, c\u0026rsquo;est également relativement simple, puisqu\u0026rsquo;il suffit d\u0026rsquo;utiliser les commandes :\ncurl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash sudo apt-get install -y nodejs MariaDB\rEnfin pour le serveur MySQL (MariaDB server 10.3 dans ce tutoriel) :\n# ajout du dépôt APT de MariaDB sudo bash \u0026lt;(wget -qO - https://downloads.mariadb.com/MariaDB/mariadb_repo_setup) --mariadb-server-version=10.3 --skip-maxscale -y # installation de MariaDB sudo apt-get update \u0026amp;\u0026amp; sudo apt-get install mariadb-server -y Je vous recommande de placer les identifiants root du serveur MariaDB dans un fichier .my.cnf placé dans votre home pour pouvoir vous connecter via la commande mysql, sans avoir à copier/coller le mot de passe à chaque opération. Vous trouverez plus d\u0026rsquo;informations sur le sujet dans cet article de la KnowledgeBase de VirtuBox.\nIl vous faudra créer une base de données avant de commencer l\u0026rsquo;installation de Release-Bell. Pour cela connecter vous en tant que root à votre serveur MariaDB :\nmysql puis créez une nouvelle base de données :\nCREATE DATABASE releasebell; Ajouter ensuite un utilisateur avec les permissions nécessaires pour utiliser cette base de données :\nGRANT ALL ON releasebell.* TO \u0026#39;utilisateur_releasebell\u0026#39;@\u0026#39;localhost\u0026#39; IDENTIFIED BY \u0026#39;motdepasse\u0026#39;; Terminez en flushant les privilèges pour appliquer les modifications\nFLUSH PRIVILEGES; Puis quittez l\u0026rsquo;interface en ligne de commande de MySQL :\nEXIT; Installer Release-Bell\rCertaines étapes de l\u0026rsquo;installation de Release-Bell sont peut-être incomplètes ou différentes de la méthode utilisée par Cloudron. La documentation disponible sur le dépôt de l\u0026rsquo;application étant minimaliste, j\u0026rsquo;ai utilisé les mêmes étapes d\u0026rsquo;installation que d\u0026rsquo;autres applications NodeJS.\nPour installer Release-Bell, créer un nouvel utilisateur, de préférence sans mot de passe ou login afin d\u0026rsquo;éviter un éventuel accès non désiré via cet utilisateur :\nMise en place de l\u0026rsquo;application NodeJS\radduser --disabled-password --disabled-login releasebell Puis connecter vous en tant que cet utilisateur :\nsudo su - releasebell Créez un répertoire pour héberger l\u0026rsquo;application :\nmkdir releasebell Puis téléchargez l\u0026rsquo;application avant de extraire de son archive :\ncurl -L https://git.cloudron.io/cloudron/releasebell/-/archive/v1.1.0/releasebell-v1.1.0.tar.gz \\ | tar zxf - --strip-components 1 -C ./releasebell Allez dans le répertoire de l\u0026rsquo;application :\ncd releasebell Et installer des dépendances NodeJS :\nnpm install Importation de la structure de la base de données\rLe structure de la base de donnéees de releasebell est stockée dans le dossier migrations de l\u0026rsquo;application. Pour l\u0026rsquo;importer il suffit donc d\u0026rsquo;utiliser :\nmysql -u utilisateur_releasebell -p releasebell \u0026lt; migrations/initial-schema.sql Configurer Release-Bell\rLa configuration de l\u0026rsquo;application repose sur deux fichiers, il s\u0026rsquo;agit de database.json utilisé pour la configuration de la base de données MySQL, et users.json pour les identifiants des utilisateurs de l\u0026rsquo;application.\nIl faut tout d\u0026rsquo;abord définir les paramètres d\u0026rsquo;accès à la base de données dans le fichier database.json, qui doit ressembler à l\u0026rsquo;exemple suivant :\n{ \u0026#34;defaultEnv\u0026#34;: \u0026#34;local\u0026#34;, \u0026#34;local\u0026#34;: { \u0026#34;host\u0026#34;: \u0026#34;localhost\u0026#34;, \u0026#34;user\u0026#34;: \u0026#34;utilisateur_releasebell\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;motdepasse\u0026#34;, \u0026#34;database\u0026#34;: \u0026#34;releasebell\u0026#34;, \u0026#34;driver\u0026#34;: \u0026#34;mysql\u0026#34;, \u0026#34;multipleStatements\u0026#34;: true } } S\u0026rsquo;il n\u0026rsquo;existe pas encore, créez le fichier users.json dont le contenu doit ressembler à l\u0026rsquo;exemple suivant :\n[ { \u0026#34;username\u0026#34;: \u0026#34;votre_nom_dutilisateur\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;motdepasse\u0026#34;, \u0026#34;email\u0026#34;: \u0026#34;test@example.com\u0026#34; } ] La configuration de l\u0026rsquo;application est désormais terminée, l\u0026rsquo;application peut-être lancée avec la commande :\nnode index.js Ajouter un service systemd pour Release-Bell\rVous souhaitez peut-être pouvoir utiliser l\u0026rsquo;application sans avoir à laisser un terminal ouvert indéfiniment. Pour cela le plus simple sur Debian/Ubuntu est d\u0026rsquo;ajouter un service systemd pour notre application. On y définira notamment certaines variables nécessaires à la configuration de l\u0026rsquo;application.\nPour ajouter un service, nous allons créer un ficher .service dans la répertoire /lib/systemd/system/\nsudo nano /lib/systemd/system/release_bell.service Le contenu de ce ficher de configuration doit ressembler à ceci (il vous faudra l\u0026rsquo;adapter avec vos informations) :\n[Unit] Description=ReleaseBell [Service] Type=simple WorkingDirectory=/home/utilisateur_releasebell/releasebell User=utilisateur_releasebell Environment=\u0026#34;NODE_ENV=production\u0026#34; Environment=\u0026#34;MAIL_SMTP_SERVER=smtp.example.com\u0026#34; Environment=\u0026#34;MAIL_SMTP_PORT=25\u0026#34; Environment=\u0026#34;MAIL_SMTP_USERNAME=releasebell@example.com\u0026#34; Environment=\u0026#34;MAIL_SMTP_PASSWORD=MotdepasseSMTP\u0026#34; Environment=\u0026#34;MAIL_FROM=releasebell@example.com\u0026#34; Environment=\u0026#34;MAIL_DOMAIN=example.com\u0026#34; Environment=\u0026#34;APP_ORIGIN=example.com\u0026#34; ExecStart=/usr/bin/node index.js Restart=always [Install] WantedBy=multi-user.target Activez le service release_bell avec la commande :\nsudo systemctl enable release_bell.service Vous pouvez enfin démarrer le service avec la commande :\nsudo service release_bell start Configurer Nginx\rPour terminer ce tutoriel, voici un exemple de configuration pour utiliser Nginx en tant que reverse-proxy pour notre application :\nserver { server_name release.yourdomain.tld access_log /var/log/nginx/release.yourdomain.tld.access.log rt_cache; error_log /var/log/nginx/release.yourdomain.tld.error.log; location / { proxy_pass http://127.0.0.1:3000; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } Je ne vais pas m\u0026rsquo;étendre sur cette partie de la configuration, mais je vous invite à jeter un oeil à mon article Installer un certificat SSL Let\u0026rsquo;s Encrypt avec acme.sh si vous souhaitez générer un certificat SSL pour sécuriser l\u0026rsquo;accès à l\u0026rsquo;application Release-Bell.\n","date":"2018-10-24T04:42:09Z","image":"/images/2018/09/release-bell-1.png","permalink":"/ne-ratez-release-github-avec-release-bell/","title":"Release Bell : ne ratez plus aucune publication de release sur Github"},{"content":"Dans ce tutoriel, nous allons voir comment convertir vos images en WebP, sans avoir recours à des plugins dans vos CMS, et comment configurer Nginx pour servir automatiquement la version WebP d\u0026rsquo;une image à condition qu\u0026rsquo;elle existe et que le format soit supporté par le navigateur du visiteur.\nWebP est un format d\u0026rsquo;image open-source développé par Google en 2010, basé sur un autre format de fichiers également développé par Google, le VP8.\nLe format WebP par rapport aux autres formats\rSelon Google, le niveau de compression du format WebP permet d\u0026rsquo;obtenir des images 26% plus légères que le PNG et jusqu\u0026rsquo;à 34% plus légères que le JPG. Il faut savoir que le WebP supporte la transparence (canal alpha), mais également les animations (GIF).\nCependant, les chiffres annoncés par Google n\u0026rsquo;ont pas convaincu tout le monde. C\u0026rsquo;est notamment le cas de la fondation Mozilla, qui estime que les gains du WebP en compression ne sont pas aussi élevés et qui remet surtout en cause les protocoles de test utilisés par Google pour obtenir ces résultats.\nMise à jour du 29/01/2019 : Mozilla FireFox supporte officiellement les images au format WebP avec la mise à jour publiée aujourd\u0026rsquo;hui (version 65.0). Les seuls navigateurs modernes qui ne supportent pas le format WebP sont Edge et Safari.\nCe qui nous amène à un point qu\u0026rsquo;il est important de souligner : tous les navigateurs web ne supportent pas le WebP. Ce qui induit qu\u0026rsquo;il est actuellement impossible d\u0026rsquo;utiliser uniquement des images au format WebP sur un site (du moins, pas sans impacter certains visiteurs) et qu\u0026rsquo;il est nécessaire de configurer son serveur web pour servir la version WebP d\u0026rsquo;une image, seulement si le navigateur du visiteur le supporte.\nCompatibilité et gains\rOn peut alors se poser la question, cela vaut-il le coût de supporter le format WebP pour un site web ? Pour y répondre, il faudrait savoir si la majorité des internautes utilise un navigateur qui supporte le WebP. Il est heureusement assez facile d\u0026rsquo;obtenir la réponse, grâce au site caniuse.com, dont voici les résultats :\nCan I Use webp? En se basant sur les parts de marché de chaque navigateur, le site estime que 73% des internautes utilisent un navigateur qui supporte le WebP. Ce qui semble tout à fait plausible étant donné la popularité du navigateur Google Chrome.\nEt le niveau compression dans tout ça ? Est ce que le format WebP permet vraiment d\u0026rsquo;obtenir des images plus légères ?\nD\u0026rsquo;après les tests que j\u0026rsquo;ai réalisé sur mes sites, la réponse est OUI. Qu\u0026rsquo;il s\u0026rsquo;agisse de convertir une image au format JPEG ou au format PNG, la version WebP est plus légère même s\u0026rsquo;il ne s\u0026rsquo;agit parfois que de quelques kilo-octets. Quelques exemples sur les images du blog :\nImage Original WebP MariaDB-10.3-1.jpg 52Ko 32Ko background-869581.png 52Ko 36Ko cloudflare-origin.png 492Ko 344Ko library-898333_1920-1.jpg 348Ko 228Ko La conversion a été effectuée en mode lossless pour les images PNG , avec l\u0026rsquo;argument (-z 9) et avec un indice de qualité de 82 pour les images JPEG, avec l\u0026rsquo;argument (-q 82).\nInstaller cwebp pour convertir les images\rCwebp est l\u0026rsquo;utilitaire en ligne de commande qui permet de convertir les images au format WebP. Cwebp est inclus dans le paquet webp disponible depuis les dépôts APT ou YUM, mais également dans le paquet libwebp qu\u0026rsquo;il est possible de compiler depuis les sources.\nDepuis les dépôts APT ou YUM\rSous Debian/Ubuntu, vous pouvez installer cwebp avec :\nsudo apt install webp -y Sous Centos 7, vous pouvez installer cwebp avec :\nsudo yum install libwebp-tools -y Depuis les sources de libwebp\rSi vous souhaitez installer la dernière version du paquet cwebp (actuellement en v1.0.2) plutôt qu\u0026rsquo;utiliser la version disponible sur les dépôts APT et YUM (version 0.6.0 sur Ubuntu 18.04 LTS), vous pouvez télécharger les sources de libwebp depuis le dépôt Google\nMise à jour du 17/08/2019 : Je propose désormais un script pour automatiquement compiler la dernière version de libwebp :\ncurl -sL git.io/fjdd6 | sudo -E bash Le script est disponible sur Github : https://github.com/VirtuBox/img-optimize/blob/master/scripts/install-webp.sh\nPour cela, il faut tout d\u0026rsquo;abord installer les pré-requis à la compilation :\nsudo apt-get install build-essential libjpeg-dev libpng-dev libtiff-dev libgif-dev libwebp-dev -y Vous pouvez ensuite télécharger les sources de libwebp et les extraire\ncurl -sL https://storage.googleapis.com/downloads.webmproject.org/releases/webp/libwebp-1.0.2.tar.gz | tar zxf - -C /usr/local/src cd /usr/local/src/libwebp-* Il ne reste plus qu\u0026rsquo;à configurer libwebp avant la compilation et l\u0026rsquo;installation\n./configure --prefix=/usr make -j \u0026#34;$(nproc)\u0026#34; sudo make install Vous pouvez ensuite vérifier si vous utilisez la version compilé de cwebp avec la commande\rwhich cwebp Qui vous retournera normalement /usr/local/bin/cwebp\nLa conversion des images en WebP\rConvertir une image en WebP avec cwebp\rLa conversion d\u0026rsquo;une image avec cwebp est on ne peut plus simple puisqu\u0026rsquo;il suffit de définir l\u0026rsquo;image à convertir, suivie de l\u0026rsquo;argument -o permettant de définir le nom du fichier en sortie.\nExemple :\ncwebp monimage.png -o monimage.webp Il est ensuite possible de d\u0026rsquo;ajouter des paramètres de conversion en passant par des arguments après la commande cwebp\nVoici les paramètres principaux à utiliser en arguments avec cwebp :\n-lossless : pour encoder les images sans pertes (PNG) -q : Est un indice de qualité, similaire au niveau de qualité des images JPEG. -z : Est un indice de compression en mode lossless, allant de 0 à 9, où 9 est le niveau le plus haut, cela nécessite un temps de conversion plus long mais permet d\u0026rsquo;obtenir un fichier plus léger en sortie -mt : utiliser le multi-threading si possible Ces paramètres sont très important pour la conversion en WebP, car l\u0026rsquo;utilisation d\u0026rsquo;un argument inadapté au type d\u0026rsquo;image peut rendre le fichier WebP plus lourd que le fichier original.\nPour les images JPEG, il faut privilégier l\u0026rsquo;usage de l\u0026rsquo;indice de qualité -q. Pour les images PNG, le plus simple est d\u0026rsquo;utiliser -z pour définir le niveau de compression en mode lossless.\nLa liste complète des options est disponible sur le site developers.google.com.\nConvertir toutes les images de votre site en WebP\rAprès avoir vu comment convertir une image au format WebP en utilisant cwebp, nous allons aller un peu plus loin en appliquant cette méthode pour convertir toutes les images d\u0026rsquo;un site web.\nPour cela, il nous faut tout d\u0026rsquo;abord lister les images au format JPEG et PNG présentes dans le répertoire images de notre site, avant de les convertir au format WebP. L\u0026rsquo;objectif du tutoriel étant de pouvoir servir les images WebP avec Nginx, il est important de définir la structure que nous allons utiliser pour nommer les images WebP par rapport à la version originale de l\u0026rsquo;image.\nVoici la structure que nous allons utiliser pour nommer les fichiers WebP :\n# une image png monimage.png -\u0026gt; monimage.png.webp # une image jpg monimage.jpg -\u0026gt; monimage.jpg.webp Pourquoi nommer les images converties ainsi ?\nCar cette structure va nous permettre d\u0026rsquo;utiliser la directive Nginx try_files. Ainsi Nginx pourra vérifier l\u0026rsquo;existence du fichier WebP par rapport à l\u0026rsquo;image originale.\nLister les images PNG \u0026amp; JPG dans un répertoire\rPour obtenir récursivement, la liste des images PNG et JPG présentes dans un répertoire, nous allons utiliser la commande find. Petite particularité pour les images au format JPEG, l\u0026rsquo;extension du fichier peut-être .jpg ou .jpeg.\nOn se rend dans le répertoire qui contient les images\ncd /votre/répertoire/images lister les images JPEG\nfind . -type f \\( -iname \u0026#34;*.jpg\u0026#34; -o -iname \u0026#34;*.jpeg\u0026#34; \\) lister les images PNG\nfind . -type f -iname \u0026#39;*.png\u0026#39; Convertir les images en WebP conditionnellement\rMaintenant que nous sommes capables de lister les images PNG et JPG dans un répertoire, nous souhaitons pouvoir les convertir en WebP. Cependant nous ne voulons pas convertir une seconde fois des images déjà converties en WebP.\nNous allons donc procéder en deux étapes :\nlister les images PNG \u0026amp; JPG si la version WebP des images n\u0026rsquo;existe pas, les convertir en WebP Ce qui nous donne :\nConvertir les images PNG\nfind . -type f -iname \u0026#34;*.png\u0026#34; -print0 | xargs -0 -I {} \\ bash -c \u0026#39;[ ! -f \u0026#34;{}.webp\u0026#34; ] \u0026amp;\u0026amp; { cwebp -z 9 -mt {} -o {}.webp; }\u0026#39; convertir les images JPG\nfind . -type f \\( -iname \u0026#34;*.jpg\u0026#34; -o -iname \u0026#34;*.jpeg\u0026#34; \\) -print0 | xargs -0 -I {} \\ bash -c \u0026#39;[ ! -f \u0026#34;{}.webp\u0026#34; ] \u0026amp;\u0026amp; { cwebp -q 82 -mt {} -o {}.webp; }\u0026#39; Détaillons un peu notre exemple :\nOn utilise tout d\u0026rsquo;abord find pour obtenir la liste des images PNG ou JPG dans un répertoire, suivi de l\u0026rsquo;argument -print0 qui permet de transmettre le nom des fichiers à xargs même s\u0026rsquo;ils contiennent des caractères spéciaux\nOn utilise ensuite un pipe | pour connecter cette première commande et récupérer sa sortie standard avec xargs.\nGrâce à xargs -0 nous sommes capables de récupérer les résultats obtenu avec find et de les passer en tant qu\u0026rsquo;argument à la seconde partie de la commande.\nEnfin on utilise bash -c pour invoquer un shell et traiter notre conversion conditionnelle en WebP. Si vous souhaitez en savoir plus, je vous conseille de lire l\u0026rsquo;article de Wikipédia sur xargs.\nDans le shell invoqué, on créer la condition \u0026ldquo;si le fichier monimage.jpg.webp n\u0026rsquo;existe pas, alors utiliser cwebp\u0026rdquo; :\n[ ! -f \u0026#34;{}.webp\u0026#34; ] \u0026amp;\u0026amp; { cwebp -q 82 -mt {} -o {}.webp; } Img-optimize - Un Script pour optimiser et convertir vos images en Webp\rMalgré que la conversion des images en WebP ne soit pas réellement difficile avec cwebp, j\u0026rsquo;ai publié img-optimize sur Github, un script bash qui permet de réaliser la conversion de vos images en WebP mais également l\u0026rsquo;optimisation des images au format JPG et PNG, en ajoutant simplement le répertoire qui contient les images en argument.\nPour utiliser le script il vous suffit de clone le dépot :\ngit clone https://github.com/VirtuBox/img-optimize.git $HOME/.img-optimize Puis d\u0026rsquo;ajouter un alias via le fichier .bashrc\necho \u0026#34;alias img-optimize=$HOME/.img-optimize/optimize.sh\u0026#34; \u0026gt;\u0026gt; $HOME/.bashrc source $HOME/.bashrc Vous pouvez ensuite optimiser et convertir les images présentes dans un répertoire avec :\nimg-optimize /dossier/des/images Le script supporte également les arguments suivants :\nBash script to optimize your images and convert them in WebP Usage: img-optimize [options] \u0026lt;images path\u0026gt; If images path isn\u0026#39;t defined, img-optimize will use the current directory Options: --jpg \u0026lt;images path\u0026gt; ..... optimize all jpg images --png \u0026lt;images path\u0026gt; ..... optimize all png images --webp \u0026lt;images path\u0026gt; ..... convert all images in webp --nowebp \u0026lt;images path\u0026gt; ..... optimize all png \u0026amp; jpg images --all \u0026lt;images path\u0026gt; ..... optimize all images (png + jpg + webp) -i, --interactive ..... run img-optimize in interactive mode -q, --quiet ..... run image optimization quietly Other options : -h, --help, help ... displays this help information Examples: optimize all jpg images in /var/www/images img-optimize --jpg /var/www/images Afficher les images WebP avec Nginx\rIl nous faut ensuite configurer Nginx pour afficher les images en WebP, mais avec plusieurs conditions :\nIl faut que la navigateur du visiteur supporte le format WebP Il faut que la version WebP de l\u0026rsquo;image existe Détecter si un navigateur supporte le format WebP\rPour la première condition, il est assez facile de détecter si un navigateur supporte le WebP avec Nginx, puisque cette informations est transmise par la navigateur via les \u0026ldquo;Requests Headers\u0026rdquo;. Sur un navigateur compatible comme Google Chrome, on y retrouve la ligne :\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Où l\u0026rsquo;on retrouve bien image/webp. Contrairement à un navigateur comme Firefox qui ne supporte pas le format WebP :\nAccept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Définir l\u0026rsquo;extension à utiliser avec la directive map\rLa directive map de Nginx est particulièrement intéressante, puisqu\u0026rsquo;elle permet d\u0026rsquo;associer des valeurs à plusieurs variables, sans avoir recours au if.\nDans notre cas, nous allons associer la variable $http_accept qui fait partie des \u0026ldquo;Requests Headers\u0026rdquo; avec l\u0026rsquo;extension de nos images, variable que j\u0026rsquo;ai nommé $webp_suffix. Nous allons créer un fichier webp.conf dans /etc/nginx/conf.d dans lequel nous allons placer notre directive map :\nmap $http_accept $webp_suffix { default \u0026#34;\u0026#34;; \u0026#34;~*webp\u0026#34; \u0026#34;.webp\u0026#34;; } On définit ici la valeur de la variable $webp_suffix en fonction du contenu de la variable $http_accept. Par défault, $webp_suffix est nulle, mais lorsque $http_accept contient le mot \u0026ldquo;webp\u0026rdquo;, alors $webp_suffix est égale à \u0026ldquo;.webp\u0026rdquo;.\nServir sous conditions les versions WebP des images\rPour servir une image au format WebP, les deux conditions sont :\nque le navigateur accepte les format WebP que la version WebP de l\u0026rsquo;image existe Pour cela nous allons utiliser notre variable $webp_suffix associée à la directive try_files qui permet à Nginx de vérifier si un fichier existe.\nOn commence donc par créer un bloc location pour sélectionner les images PNG \u0026amp; JPG :\nlocation ~ \\.(png|jpe?g)$ {} Dans ce bloc, nous allons ajouter plusieurs directives :\nadd_header Vary \u0026quot;Accept-Encoding\u0026quot;; : permet d\u0026rsquo;annoncer qu\u0026rsquo;il peut exister plusieurs versions du même fichier selon les Requests Headers transmis. add_header \u0026quot;Access-Control-Allow-Origin\u0026quot; \u0026quot;*\u0026quot;; : active les Cross-Origin Resource Sharing (CORS) try_files $uri$webp_suffix $uri =404; : demande à Nginx d\u0026rsquo;essayer l\u0026rsquo;url de l\u0026rsquo;image suivi de notre variable $webp_suffix, et de vérifier que le fichier existe bien. On obtient alors :\nlocation ~ \\.(png|jpe?g)$ { add_header Vary \u0026#34;Accept-Encoding\u0026#34;; add_header \u0026#34;Access-Control-Allow-Origin\u0026#34; \u0026#34;*\u0026#34;; try_files $uri$webp_suffix $uri =404; } Auquel, on peut ajouter quelques options supplémentaires :\nadd_header Cache-Control \u0026quot;public, no-transform\u0026quot;; : pour définir le cache comme public et demander aux éventuels proxy de ne pas le modifier access_log off; : pour désactiver les logs d\u0026rsquo;accès log_not_found off; : désactive les logs d\u0026rsquo;erreurs en cas de fichier introuvable expires max; : définit la durée autorisée de cache par les navigateurs, le plus longtemps possible puisqu\u0026rsquo;il s\u0026rsquo;agit d\u0026rsquo;images. Le dernier point important, est de bien définir le répertoire dans lequel nous allons demander à Nginx de servir des images WebP, plutôt que d\u0026rsquo;appliquer cela à l\u0026rsquo;ensemble d\u0026rsquo;un site.\nVoici un exemple complet à inclure dans un vhost pour WordPress :\nlocation /wp-content/uploads/ { location ~ \\.(png|jpe?g)$ { add_header Vary \u0026#34;Accept-Encoding\u0026#34;; add_header \u0026#34;Access-Control-Allow-Origin\u0026#34; \u0026#34;*\u0026#34;; add_header Cache-Control \u0026#34;public, no-transform\u0026#34;; access_log off; log_not_found off; expires max; try_files $uri$webp_suffix $uri =404; } } Et un autre exemple pour Ghost :\nlocation /content/images { alias /var/www/votredomaine.tld/content/images; location ~ \\.(png|jpe?g)$ { add_header Vary \u0026#34;Accept-Encoding\u0026#34;; add_header \u0026#34;Access-Control-Allow-Origin\u0026#34; \u0026#34;*\u0026#34;; add_header Cache-Control \u0026#34;public, no-transform\u0026#34;; access_log off; log_not_found off; expires max; try_files $uri$webp_suffix $uri =404; } } Le script conversion des images en WebP est inspiré de l\u0026rsquo;article How To Create and Serve WebP Images to Speed Up Your Website publié sur DigitalOcean Community\n","date":"2018-08-10T07:06:32Z","image":"/images/2018/07/WebP-min.png","permalink":"/convertir-vos-images-en-webp-nginx/","title":"Comment convertir vos images en WebP et les afficher avec Nginx"},{"content":"La nouvelle version stable de MariaDB a été publiée le 25 Mai 2018, avec la release 10.3.7. Dans ce tutoriel, nous allons voir comment installer MariaDB 10.3 sur Ubuntu 18.04 LTS et comment mettre à jour MariaDB 10.2 vers la version 10.3\nCe tutoriel est également applicable à Ubuntu 16.04 LTS\nIl est tout d\u0026rsquo;abord important de préciser que les versions précédentes du serveur de base de données restent supportées jusqu\u0026rsquo;en 2020 pour la version 10.1 et 2022 pour la version 10.2. Il n\u0026rsquo;y a donc aucune raison de se précipiter pour effectuer la mise à jour sur votre serveur.\nCependant, comme le précise les notes de publications de MariaDB, la version 10.3 est une évolution de la version 10.2, avec de nombreuses nouvelles fonctionnalités, mais toujours les fonctionalités backportées et réimplémentées de MySQL.\nOn peut même trouver le message suivant dans l\u0026rsquo;article concernant la mise à jour de MariaDB 10.2 vers la version 10.3 :\nOn most servers upgrading from 10.2 should be painless\nLa majorité de mes serveurs utilisant déjà MariaDB 10.2, j\u0026rsquo;ai souhaité vérifier si la mise à jour se faisait effectivement sans problème.\nInstaller MariaDB 10.3\rLa première étape, que ce soit sur pour installer MariaDB sur un nouveau serveur, ou pour mettre à jour MariaDB 10.2 est l\u0026rsquo;ajout des dépôts APT. Et pour cela MariaDB propose un script qui réalise l\u0026rsquo;ajout des dépots et l\u0026rsquo;importation des clés GPG automatiquement. Il est compatible avec les distributions linux les plus populaires : Ubuntu 14/16/18.04 LTS - Debian 7/8/9 - Centos 6/7\ncurl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \\ | sudo bash -s -- --mariadb-server-version=10.3 --skip-maxscale Ce script réalise l\u0026rsquo;ajout des dépôts APT pour MariaDB Server/Cluster et Percona XtraBackup. L\u0026rsquo;argument --mariadb-server-version= permet de choisir la version de MariaDB que l\u0026rsquo;on souhaite installer (10.1 ou 10.2 ou 10.3). Et l\u0026rsquo;argument --skip-maxscale désactive l\u0026rsquo;ajout des dépôts de MariaDB MaxScale.\nSur un nouveau serveur\rS\u0026rsquo;il s\u0026rsquo;agit d\u0026rsquo;une installation initiale, sur un nouveau serveur, après avoir ajouté les dépôts APT, il vous suffit d\u0026rsquo;installer le paquet mariadb-server\nsudo apt-get update \u0026amp;\u0026amp; sudo apt-get install mariadb-server -y Durant l\u0026rsquo;installation, vous pouvez définir le mot de passe root, ou le laisser vide afin d\u0026rsquo;utiliser ensuite la commande mysql_secure_installation qui permet de sécuriser un serveur MySQL en répondant à quelques questions.\nMise à jour depuis MariaDB 10.2\rPour mettre à jour MariaDB depuis la version 10.2 vers la version 10.3, il est nécessaire de prendre quelques précautions avant de mettre à jour les paquets pour être sûr de ne pas perdre de données.\nPour cela, le plus simple est de réaliser une copie du dossier /var/lib/mysql qui contient vos bases de données avant de désinstaller mariadb\n# on arrête le serveur MySQL sudo service mysql stop # on copie le dossier /var/lib/mysql sudo cp -rf /varlib/mysql /var/lib/mysqlold # on désinstalle mariadb 10.2 sudo apt-get autoremove mariadb-server On peut ensuite remplacer les dépôts APT de la version 10.2 par ceux de la version 10.3 en utilisant le script mariadb_repo_setup\ncurl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \\ | sudo bash -s -- --mariadb-server-version=10.3 --skip-maxscale Puis mettre à jour la liste des dépôts :\nsudo apt-get update La dernière étape est de lancer l\u0026rsquo;installation de la nouvelle version de mariadb\nsudo apt-get install mariadb-server Durant la mise à jour, vous pouvez laisser le mot de passe root vide pour conserver celui que vous avez définit précédemment.\nUne fois la mise à jour terminée, vous pouvez vérifié le status de MariaDB avec la commande :\nservice mysql status Si la mise s\u0026rsquo;est bien déroulée, n\u0026rsquo;oubliez pas d\u0026rsquo;utiliser la commande mysql_upgrade pour mettre à jour vos base de données. Si vous n\u0026rsquo;avez placé les identfiants du serveur MySQL dans un fichier .my.cnf, mysql_upgrade s\u0026rsquo;utilise de la même façon que mysql :\nmysql_upgrade -u root -p Revenir à MariaDB 10.2\rJ\u0026rsquo;ai déjà réalisé cette mise à jour sur 6 serveurs sans rencontrer le moindre problème. Mais dans le cas d\u0026rsquo;un problème suite à la mise à jour, vous pouvez à tout moment revenir sur la version 10.2 en utilisant la copie du dossier /var/lib/mysql réalisée plus tôt.\nCommencez par remettre en place les dépôts APT de MariaDB 10.2, qui sont normalement récupérable dans un fichier nommé mariadb.list.old_1\n# cp -f /etc/apt/sources.list.d/mariadb.list.old_1 /etc/apt/sources.list.d/mariadb.list Mais que vous pouvez également ajouter en utilisant le script mariadb_repo_setup :\ncurl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \\ | sudo bash -s -- --mariadb-server-version=10.2 --skip-maxscale Ensuite, désinstaller mariadb-server\nsudo apt-get autoremove mariadb-server Et Remplacez le dossier /var/lib/mysql avec le contenu du dossier /var/lib/mysqlold\n# on déplace le dossier /var/lib/mysql sudo mv /var/lib/mysql /var/lib/mysqlnew # on remet en place le dossier /var/lib/mysqlold sudo mv /var/lib/mysqlold /var/lib/mysql # on définit à nouveau le propriétaire du dossier sudo chown -R mysql:mysql /var/lib/mysql La dernière étape est de réinstaller MariaDB 10.2\nsudo apt-get update sudo apt-get install mariadb-server ","date":"2018-06-03T17:08:32Z","image":"/images/2018/07/MariaDB-10.3-1.jpg","permalink":"/installer-mariadb-10-3-ubuntu-18-04-lts/","title":"Installer MariaDB 10.3 sur Ubuntu 18.04 LTS"},{"content":"Si la configuration réseau d\u0026rsquo;un container LXC peut s\u0026rsquo;effectuer directement depuis l\u0026rsquo;interface web de Proxmox VE, il est était nécessaire (et pénible) de la réaliser via la console NoVNC pour les machines virtuelles KVM tournant sous Debian/Ubuntu.\nNous allons voir dans ce tutoriel, comment configurer le réseau d\u0026rsquo;une machine virtuelle KVM en utilisant qemu-nbd, qui permet de monter le disque d\u0026rsquo;une VM et donc d\u0026rsquo;accéder directement aux fichiers de configuration des interfaces réseau. Si la procédure peut sembler longue pour configurer une seule VM, il sera tout à fait possible de l\u0026rsquo;automatiser avec un script bash par la suite.\nPS : Alors que j\u0026rsquo;écris ces lignes, le module cloud-init a déjà fait son apparition sur Proxmox VE 5.1, et représentera très probablement une excellente alternative à la solution présentée dans cette article. Mais cela fera sûrement l\u0026rsquo;objet d\u0026rsquo;un autre article.\nInstaller le client nbd\rPour commencer, il faut installer le client nbd sur votre serveur Proxmox.\napt-get update \u0026amp;\u0026amp; apt-get install nbd-client -y Puis charger le module :\nmodprobe nbd max_part=16 Et enfin, pour rendre la configuration persistente, on utilise :\necho \u0026#34;nbd\u0026#34; \u0026gt;\u0026gt; /etc/modules cat \u0026gt; /etc/modprobe.d/nbd.conf \u0026lt;\u0026lt;\\EOT options nbd max_part=16 EOT Monter le disque d\u0026rsquo;un VM avec qemu-nbd\rCas d\u0026rsquo;une machine virtuelle sans LVM\rPour monter le disque d\u0026rsquo;une VM, on utilise qemu-nbd :\nqemu-nbd -c /dev/nbd0 vm-101* -f raw vm-101 correspond à l\u0026rsquo;ID de la machine virtuelle dans Proxmox.\nOn créer ensuite un dossier dans lequel nous allons pouvoir monter le disque de la machine virtuelle :\nmkdir /mnt/ma-vm mount /dev/nbd0p1 /mnt/ma-vm Cas d\u0026rsquo;une machine virtuelle avec LVM\rDans le cas d\u0026rsquo;un LVM, il n\u0026rsquo;est pas possible de monter directement la partition car il faut pour cela connaître le nom du volume group qui contient les fichiers de configuration.\nLa procédure pour monter le disque est quasiment la même que précédemment :\nqemu-nbd -c /dev/nbd0 vm-101* Mais cette fois-ci on utilise vgscan pour détecter les volume groups disponibles\nvgscan On obtient alors la liste des volume group et on active le volume auquel on souhaite accéder :\nvgchange -a y vp-vg Nous pouvons alors monter le VG :\nmkdir /mnt/ma-vm mount /dev/vp-vg/root /mnt/ma-vm Configurer l\u0026rsquo;interface réseau\rMaintenant que le disque de notre machine virtuelle est monté dans le répertoire /mnt/ma-vm, nous pouvons modifier la configuation de ses interfaces réseau. On se déplace à la racine du disque :\ncd /mnt/ma-vm/ Et nous pouvons modifier directement le fichier /etc/network/interfaces dans le cas d\u0026rsquo;une machine virtuelle tournant sous Debian ou Ubuntu (exemple avec Ubuntu 16.04 LTS sur un serveur dédié OVH) :\ncat \u0026gt; etc/network/interfaces \u0026lt;\u0026lt; EOF auto ens18 iface ens18 inet static address IP.FAIL.OVER netmask 255.255.255.255 broadcast IP.FAIL.OVER post-up route add IP.SERVEUR.DEDIE.254 dev ens18 post-up route add default gw IP.SERVEUR.DEDIE.254 pre-down route del IP.SERVEUR.DEDIE.254 dev ens18 pre-down route del default gw IP.SERVEUR.DEDIE.254 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 213.186.33.99 iface ens18 inet6 static address IP:V6:FAIL:OVER netmask 64 post-up /sbin/ip -f inet6 route add XXXX:XXXX:XXX:XXff:ff:ff:ff:ff dev ens18 post-up /sbin/ip -f inet6 route add default via XXXX:XXXX:XXX:XXff:ff:ff:ff:ff pre-down /sbin/ip -f inet6 route del XXXX:XXXX:XXX:XXff:ff:ff:ff:ff dev ens18 pre-down /sbin/ip -f inet6 route del default via XXXX:XXXX:XXX:XXff:ff:ff:ff:ff EOF Terminer la configuration\rUne fois la modification terminée, nous pouvons démonter le disque de la VM.\nSans LVM\rSans LVM, la méthode est la même que pour monter le disque\ncd .. umount /dev/nbd0p1 qemu-nbd -d /dev/nbd0 rm -r /mnt/ma-vm Avec LVM\rAvec LVM, il faut utiliser à nouveau vgchange de désactiver le volume group :\ncd .. umount /dev/vp-vg/root vgchange -a n vp-vg qemu-nbd -d /dev/nbd0 rm -r /mnt/ma-vm Dernière étapes, redémarrer la machine virtuelle pour appliquer les modificiations. J\u0026rsquo;espère que cet article vous aidera à automatiser un peu plus vos création de machines virtuelles.\n","date":"2018-05-09T21:14:42Z","image":"/images/2018/05/R-seau-Proxmox.png","permalink":"/configuration-reseau-machine-virtuelle-kvm-proxmox/","title":"Configuration réseau d'une machine virtuelle KVM sur Proxmox"},{"content":"Si la migration de sites web ne pose généralement pas de problème, il est parfois plus délicat de migrer des emails, notamment lorsque deux serveurs n\u0026rsquo;utilisent pas le même software ou lorsqu\u0026rsquo;il s\u0026rsquo;agit d\u0026rsquo;une migration depuis/vers un hébergeur tiers. Heureusement pour simplifier cette étape, il existe de nombreux outils, dont imapsync qui est celui dont nous allons parler aujourd\u0026rsquo;hui.\nimapsync est comme son nom l\u0026rsquo;indique un outil (développé en perl) qui permet de synchroniser des boîtes mail en utilisant le protocol imap. Cela ne fonctionnera bien sûr que si vous utilisez également l\u0026rsquo;IMAP pour récupérer vos emails, ou si vous n\u0026rsquo;effacez pas vos emails du serveur avec le protocol POP.\nNous allons voir dans ce tutoriel comment installer Imapsync (sur Ubuntu 16.04 LTS), puis comment synchroniser deux boîtes mails ainsi que les options proposées par cet outil.\nInstaller imapsync\rTout d\u0026rsquo;abord, il faut installer les pré-requis nécessaires à l\u0026rsquo;éxecution d\u0026rsquo;imapsync :\nsudo apt-get install \\ libauthen-ntlm-perl \\ libclass-load-perl \\ libcrypt-ssleay-perl \\ libdata-uniqid-perl \\ libdigest-hmac-perl \\ libdist-checkconflicts-perl \\ libfile-copy-recursive-perl \\ libio-compress-perl \\ libio-socket-inet6-perl \\ libio-socket-ssl-perl \\ libio-tee-perl \\ libmail-imapclient-perl \\ libmodule-scandeps-perl \\ libnet-ssleay-perl \\ libpar-packer-perl \\ libreadonly-perl \\ libregexp-common-perl \\ libsys-meminfo-perl \\ libterm-readkey-perl \\ libtest-fatal-perl \\ libtest-mock-guard-perl \\ libtest-pod-perl \\ libtest-requires-perl \\ libtest-simple-perl \\ libunicode-string-perl \\ liburi-perl \\ libtest-nowarnings-perl \\ libtest-deep-perl \\ libtest-warn-perl \\ make \\ cpanminus Il peut être nécessaire de mettre à jour le client IMAP et JSON avec cpanm :\nsudo cpanm Mail::IMAPClient sudo cpanm JSON::WebToken On peut ensuite télécharger imapsync :\nsudo wget https://imapsync.lamiral.info/dist/imapsync -O /usr/bin/imapsync Et il ne reste plus qu\u0026rsquo;à le rendre éxecutable :\nsudo chmod +x /usr/bin/imapsync Vous pouvez ensuite obtenir la liste des variables disponibles en utilisant la commande imapsync\nSynchroniser une boîte mail\rPour lancer la synchronisation d\u0026rsquo;une boite mail avec imapsync avec uniquement les options requises ressemble à :\nimapsync \\ --host1 serveur1.imap.tld \\ --user1 boite@email.tld \\ --password1 motdepasse1 \\ --host2 serveur2.imap.tld \\ --user2 boite@email.tld \\ --password2 motdepasse2 Les options\rLes mots de passes\rPour éviter d\u0026rsquo;avoir à entrer les mots de passe des boîte email en clair, vous pouvez les stockers dans des fichiers et utiliser l\u0026rsquo;argument --passfile1 et --passfile2 pour les charger automatiquement depuis les fichiers contenant les mots de passe.\nCe qui donne :\nimapsync \\ --host1 serveur1.imap.tld \\ --user1 boite@email.tld \\ --passfile2 /home/user/pass1 \\ --host2 serveur2.imap.tld \\ --user2 boite@email.tld \\ --passfile2 /home/user/pass2 La connexion au serveur imap\rPlusieurs options sont disponibles pour connecter imapsync à votre serveur mail, notamment le type de connexion utilisée. Par défaut imapsync essaira d\u0026rsquo;utiliser SSL ou TLS sur le port 993 pour se connecter. Voici des exemples pour la connexion sur le serveur à migrer (remplacer 1 par 2 pour le deuxième serveur) :\n--nossl1 pour une connexion non chiffrée via le port 143 (non recommandé) --ssl1 pour une connexion avec SSL via le port 993 --tls1 pour une connexion avec TLS via le port 143 Il y a également des options pour définir le type d\u0026rsquo;authentification que l\u0026rsquo;on peut définir via les arguments --authmech1 et --authmech2 dont les valeurs possibles sont (en majusule) :\nPLAIN LOGIN CRAM-MD5 Les dossiers\rLa synchronisation des dossiers peut être une source de problèmes, notamment si les dossiers par défaut (Inbox, Spam, Archive, Envoyés) ne sont pas nommés de la même façon sur les deux serveurs mails. Pour cela imapsync offre plusieurs options :\n--automap pour utiliser la reconnaissance automatique des dossiers par défaut --nomixfolders pour éviter de fusionner des dossier ayant un nom similaire selon la sensibilité à la casse --prefix1 pour retirer un prefix des dossiers à migrer --prefix2 pour ajouter un prefix aux dossiers migrés --skipemptyfolders pour ne pas recréer les dossiers vides sur le serveur de destination Les options de migration\rPour accélerer la migration des emails, vous pouvez utiliser l\u0026rsquo;argument --usecache afin de stocker temporairement les UIDs des messages et accélérer les synchronisations suivantes (n\u0026rsquo;accélère pas la première migration). Vous pouvez également supprimer les messages du premier serveur avec l\u0026rsquo;argument --delete1. Enfin, avant de lancer votre migration, n\u0026rsquo;hésitez pas à utiliser l\u0026rsquo;argument --dry pour voir ce que ferai imapsync, sans l\u0026rsquo;appliquer.\n","date":"2018-04-21T18:53:00Z","image":"/images/2018/07/imapsync-min.jpg","permalink":"/migrer-emails-facilement-imapsync/","title":"Migrer ses emails facilement avec imapsync"},{"content":"Si le bitcoin fait beaucoup parler de lui, d\u0026rsquo;autres cryptomonnaies commencent également à s\u0026rsquo;imposer, ces dernières semblent ne pas vouloir reproduire les mêmes erreurs que le bitcoin. Avec l\u0026rsquo;usage d\u0026rsquo;algorithmes de hashage différents, il est ainsi possible d\u0026rsquo;utiliser son CPU ou son GPU pour le minage. C\u0026rsquo;est le cas du Monero, basé sur la technologie Cryptonote, dont le code monétaire est XMR.\nDans ce tutoriel, nous allons voir comment miner du Monero avec l\u0026rsquo;outil open-source xmr-stack disponible sur Github. Ce dernier est disponible sur Windows, Linux et Mac OS et permet de miner avec votre CPU et/ou votre GPU AMD/NVIDIA.\nMonero - Comme le bitcoin ?\rSi j\u0026rsquo;ai décidé de parler du minage du Monero dans cet article, c\u0026rsquo;est tout d\u0026rsquo;abord car cette cryptomonnaie est très différente du célèbre bitcoin. Voici les principales différences entre les deux cryptomonnaies :\n1) Un portefeuille et des transactions anonymes Alors que toutes les transactions effectuées avec des bitcoins sont affichées publiquement, elles restent confidentielles avec le Monero. Il est ainsi impossible de lister les transactions réalisées depuis un portefeuille ainsi que le montant de ces transactions.\n2) Des frais de transactions faibles Si de nombreuses personnes ont commencé à s\u0026rsquo;intéresser au bitcoin et à y investir de l\u0026rsquo;argent, la majorité d\u0026rsquo;entre elles ne l\u0026rsquo;utilisent pas comme moyen de paiement en ligne. Cependant au moment où j\u0026rsquo;écris cet article, pour envoyer l\u0026rsquo;équivalent de 1€ à un autre portefeuille bitcoin, les frais de réseaux sont de 20.88€.\nGrâce à des blocks aux dimensions dynamiques, permettant de s\u0026rsquo;adapter aux nombre de transactions par rapport à la puissance de calcul disponible, les transactions avec le Monero sont rapides et les frais de transactions faibles.\n3) Tout le monde peut miner À l\u0026rsquo;inverse du bitcoin, il n\u0026rsquo;est pas nécessaire d\u0026rsquo;investir 1500€ dans un ASIC (Application Specific Integrated Circuit) pour pouvoir miner du Monero. L\u0026rsquo;objectif du Monero étant que chacun puisse participer au réseau et donc garantir que ce dernier soit totalement décentralisé.\nTout savoir sur le Monero\rVoici quelques liens utiles si vous souhaitez en savoir plus sur le Monero :\nLes sites principaux\ngetmonero.org : le site officiel du Monero mymonero.com : portefeuille en ligne conseillé par getmonero.org www.monero.how : Tutoriaux, statisques, informations Les sites pour en discuter\nbitcointalk.org stackexchange reddit Les sites pour miner\nmonerobenchmarks.info : benchmark CPU \u0026amp; GPU moneropools.com : comparateur des pools de minage reddit monero mining Miner du Monero\rComme expliqué précédemment, avec le Monero, il peut ainsi être intéressant de miner avec votre PC ou votre serveur dédié, sans pour autant utiliser tous les cores de votre CPU. Par exemple, avec 2 Cores d\u0026rsquo;un Intel Core i7-4790K, j\u0026rsquo;obtiens un hashrate moyen de 240 H/s.\nIl reste possible de monter des machines dédiées pour le minage et pour cela les GPU AMD restent plus intéressants que ceux proposés par Nvidia. Les RX 570 \u0026amp; 580 proposent un tarif abordable pour commencer, et la nouvelle gamme VEGA est visiblement beaucoup plus intéressante pour le minage que pour les jeux-vidéos.\nLe minage du monero est similaire au bitcoin sur le fonctionnement puisque vous pouvez miner seul ou via un pool. Pour débuter il est souvent plus intéressant d\u0026rsquo;utiliser un pool.\nSuite à de nombreuses plaintes sur reddit, je vous déconseille l\u0026rsquo;usage du site minergate.com\nLes alternatives à Monero\rmise à jour du 24/10/2018\nJe ne mine plus de Monero depuis Février suite à la forte augmentation du hashrate et de la difficulté sur le réseau Monero, qui a réduit de moitié la récompense obtenu à puissance égale. Monero n\u0026rsquo;est pas le seule cryptomonnaie basée sur cryptonote, et de nombreux autres projets ont vu le jour dont le Stellite (XTL) ou le Graft (GRFT) pour ne citer que les plus prometteurs. Si vous souhaitez découvrir et/ou miner d\u0026rsquo;autres cryptomonnaies similaires au Monero, je vous invite à visiter le site de référence Cryptunit.com.\nLe Monero reste un projet stable, et ses développeur nous l\u0026rsquo;ont prouvés en ce début Avril, en réalisant un nouveau hardfork, ou du moins une mise à jour de l\u0026rsquo;algorithme du PoW(Proof of Work) en Français afin de lutter contre les ASICs (application-specific integrated circuit), ces machines dédiées au minage d\u0026rsquo;une cryptomonnaie et qui propose un ratio hashrate/consommation exceptionnel.\nSi vous vous demandez pourquoi le Monero fait la guerre aux ASICs, c\u0026rsquo;est tout simplement parce que ses développeurs ont bien retenu la leçon du bitcoin (12 sociétés représente 87% de la puissance de calcul du réseau Bitcoin).\nQuasiment toutes les cryptomonnaies partagent une même logique de décentralisation, mais à l\u0026rsquo;heure actuelle, le projet Monero est clairement celui qui fait le plus d\u0026rsquo;efforts pour que le réseau reste décentralisé.\nLe résultat de ce hardfork, une baisse de 50% du hashrate sur le réseau Monero. Un autre hardfork est déjà programmé dans 6 mois, et il y en aura désormais un tous les 6 mois, rendant la conception et la vente d\u0026rsquo;ASICs totalement impossible.\nXMR-STACK : Un mineur tout-en-un\rDepuis sa release v2.0, xmr-stack est un mineur tout-en-un, puisqu\u0026rsquo;il permet de miner avec votre CPU et/ou GPU AMD ou Nvidia et il dispose d\u0026rsquo;un interface web pour suivre votre hashrate en temps réel.\nInstaller xmr-stack\rSur Windows\rSur Windows, il vous suffit de télécharger la version pré-compilée disponible sur la page release du projet xmr-stack.\nSur Linux\rSur Linux, il est par contre nécessaire de compiler xmr-stack. Il est alors possible d\u0026rsquo;ajouter la librarie OpenCL pour un GPU AMD ou CUDA pour un GPU Nvidia.\nLe CUDA Toolkit est disponible via le lien suivant : CUDA\nEt l\u0026rsquo;APP SDK pour ADM est disponible via le lien suivant : AMD\nPour la compilation, xmr-stack nécessite gcc 5.1+. Si votre système d\u0026rsquo;exploitation vous propose uniquement une version antérieur de gcc, vous pouvez dans ce cas utiliser le script bash docker disponible sur le dépôt d\u0026rsquo;xmr-stack, pour réaliser la compilation.\nCompiler xmr-stack avec le script bash docker\nInstaller Docker curl -fsSL get.docker.com -o get-docker.sh sh get-docker.sh Lancer le script wget https://raw.githubusercontent.com/fireice-uk/xmr-stak/master/scripts/build_xmr-stak_docker/build_xmr-stak_docker.sh bash build_xmr-stak_docker.sh Le script réalise la compilation d\u0026rsquo;xmr-stack pour Ubuntu 14.04, 16.04, Centos 6, 7 et Fedora 27. Une fois la compilation terminée, chaque version sera disponible dans un dossier distinct.\nCompiler xmr-stack sur Ubuntu\n\u0026gt; apt install libmicrohttpd-dev libssl-dev cmake build-essential libhwloc-dev -y git clone https://github.com/fireice-uk/xmr-stak.git mkdir xmr-stak/build cd xmr-stak/build Vous pouvez alors ajouter des arguments à la commande cmake pour désactiver les librairies OpenCL (-DOpenCL_ENABLE=OFF) et CUDA (-DCUDA_ENABLE=OFF) si vous souhaitez miner uniquement avec votre CPU. Et si vous ne souhaitez pas utiliser la dashboard web, vous pouvez également définir l\u0026rsquo;option (-DMICROHTTPD_ENABLE=OFF).\nCe qui donne\n# CPU only + Interface web cmake .. -DCUDA_ENABLE=OFF -DOpenCL_ENABLE=OFF make install # AMD + CPU + Interface web cmake .. -DCUDA_ENABLE=OFF make install # Nvidia + CPU + Interface web cmake .. -DOpenCL_ENABLE=OFF make install # CPU only sans Interface web cmake .. -DCUDA_ENABLE=OFF -DOpenCL_ENABLE=OFF -DMICROHTTPD_ENABLE=OFF make install L\u0026rsquo;exécutable xmr-stack sera disponible dans le dossier bin après la compilation. Vous pouvez le lancer en vous rendant dans le dossier :\ncd xmr-stack/build/bin/ ./xmr-stack Configuration d\u0026rsquo;xmr-stack\rLors du premier lancement de l\u0026rsquo;application, xmr-stack va détecter la configuration de votre ordinateur (CPU \u0026amp; GPU), puis vous afficher un menu interactif pour générer les différents fichiers de configuration :\nconfig.txt : fichier de configuration principal où vous pouvez définir les options relative à l\u0026rsquo;affichage console, aux logs ou à l\u0026rsquo;interface web pools.txt : ficher de configuration du/des pool(s) cpu.txt : fichier de configuration pour le CPU, qui définit le nombre de threads a utiliser et l\u0026rsquo;intensité gpu.txt : fichier de configuration pour le GPU (si un GPU est présent) Globalement, les options par défaut sont optimisées grâce à la détection des périphériques disponibles. Cependant il est possible de les ajuster, en réduisant par exemple le nombre de coeurs utilisés pour le minage.\nOptimisation\rWindows\rAfin d\u0026rsquo;obtenir un meilleur hashrate sous Windows, il est nécessaire d\u0026rsquo;autoriser le verrouillage des pages en mémoire. Pour cela, il faut se rendre dans l\u0026rsquo;éditeur de stratégie de groupe locale, accessible via le commande gpedit.msc dans le menu démarrer. Puis dans Paramètres Windows \u0026gt; Paramètres de sécurité \u0026gt; Attribution des droits utilisateur comme sur l\u0026rsquo;image ci-dessous :\nVous pouvez ensuite ajouter des utilisateurs (votre utilisateur et/ou l\u0026rsquo;Administrateur) dans le menu contextuel de l\u0026rsquo;option \u0026ldquo;Verrouiller les pages en mémoire\u0026rdquo;. Un redémarrage est nécessaire pour appliquer la modification.\nLinux\rTout comme avec Windows, il vous faudra ajuster certaines options concernant la gestion de la mémoire de votre système pour obtenir un meilleur hashrate.\nVia le fichier sysctl.conf\necho \u0026#39;vm.nr_hugepages=128\u0026#39; \u0026gt;\u0026gt; /etc/sysctl.conf sysctl -p Via le fichier limits.conf\necho \u0026#39;* soft memlock 262144\u0026#39; \u0026gt;\u0026gt; /etc/security/limits.conf echo \u0026#39;* hard memlock 262144\u0026#39; \u0026gt;\u0026gt; /etc/security/limits.conf Pour appliquer la nouvelle configuration, il n\u0026rsquo;est pas nécessaire de redémarrer, mais simplement de fermer votre session, puis de l\u0026rsquo;ouvrir à nouveau.\nMettre à jour xmr-stack\rWindows\rSous Windows, il vous suffit de télécharger la nouvelle version disponible sur la page release, tout en conservant vos fichier de configurations.\nLinux\rSous Linux, on récupère les modifications depuis le dépôt Github, avant de sélectionner la dernière release, et on relance la compilation :\ncd xmr-stack git fetch git checkout v2.2.0 cd build cmake .. -DCUDA_ENABLE=OFF -DOpenCL_ENABLE=OFF make install Mes astuces et chiffres\rSur des processeurs avec suffisament de cache, il peut-être intéressant d\u0026rsquo;activer le l\u0026rsquo;option low_power_mode via le fichier cpu.txt si vous ne souhaitez pas utiliser tous les cores disponibles pour miner. Sur un XEON E3-1270v6, j\u0026rsquo;obtiens ainsi un hashrate de 220 H/s avec 2 Cores. Sous Windows, avec un GPU Nvidia, activer l\u0026rsquo;option \u0026ldquo;optimiser pour les performances de calcul\u0026rdquo; via le panneau de configuration Nvidia, dans la section Gérer les paramètres 3D, comme sur l\u0026rsquo;image ci-dessous : Je suis passé d\u0026rsquo;un hashrate de 300 H/s à 430 H/s avec une GTX 970 après avoir activé cette option.\nQuelques chiffres\rGPU :\nNvidia GTX 970 : 430 H/s CPU :\nIntel(R) Core(TM) i5-2400 @ 3.10GHz : 150 H/s\nIntel(R) Core(TM) i7-3770 CPU @ 3.40GHz : 250 H/s\nIntel(R) Core(TM) i7-2600 @ 3.40GHz : 260 H/s\nIntel(R) Core(TM) i7-4790K CPU @ 4.00GHz : 260 H/s\nIntel(R) Core(TM) i7-7700 CPU @ 3.60GHz : 260 H/s\nIntel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz : 250 H/s\nIntel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz : 250 H/s\nIntel(R) Xeon(R) CPU E5-1630 v3 @ 3.70GHz : 280 H/s\nIntel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz : 260 H/s\nIntel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz : 390 H/s\n2 x Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz : 930 H/s\n","date":"2017-12-31T13:43:51Z","image":"/images/2017/12/miner-du-monero.png","permalink":"/miner-du-monero-xmr-stack-linux-windows-cpu-gpu/","title":"Miner du Monero (XMR) avec xmr-stak - CPU \u0026 GPU"},{"content":"La gestion des backups peut rapidement devenir un problème lorsque l\u0026rsquo;on gère un grand nombre de serveurs, aussi bien pour gérer l\u0026rsquo;espace de stockage que pour le suivi des backups. Je vais donc vous présenter la solution UrBackup.\nUrBackup est une solution de sauvegarde client/serveur qui propose plusieurs système de backup, sous forme d\u0026rsquo;image disque ou par répertoire de fichiers. Les principaux avantages de cette solution sont sa facilité de déploiement, sa gestion de l\u0026rsquo;espace de stockage avec des backups complets ou incrémentaux. Mais également sa compabilité avec Windows, MacOS et Linux.\nDans mon cas, UrBackup me sert à réaliser des sauvegardes de serveurs web. Il est installé sur un serveur Kimsufi KS-2A avec 2To de stockage commandé dans le cadre d\u0026rsquo;une offre à 8.99€/mois.\nMais il est tout à fait possible d\u0026rsquo;utiliser directement le backup storage proposé avec les serveurs OVH ou Online.net. Il suffit pour cela de monter le backup storage en NFS et de définir l\u0026rsquo;emplacement des sauvegardes UrBackup durant l\u0026rsquo;installation.\nInstallation du serveur UrBackup\rL\u0026rsquo;installation du serveur UrBackup peut se faire sur Windows, Linux mais également sur les distributions comme FreeNas, OpenMediaVault ainsi que sur des NAS QNAP.\nVous pouvez trouver les instructions d\u0026rsquo;installation sur la page Downloads du site Urbackup. Dans mon cas j\u0026rsquo;ai choisi d\u0026rsquo;utiliser Ubuntu 16.04 LTS qui permet l\u0026rsquo;installation via les dépôts PPA.\nOn commence donc par ajouter le dépôt puis on installe le paquet urbackup-server :\nsudo add-apt-repository ppa:uroni/urbackup sudo apt-get update sudo apt-get install urbackup-server Durant le processus, vous serez inviter à choisir le répertoire dans lequel UrBackup va réaliser les sauvegardes. On peut ensuite accéder à l\u0026rsquo;interface d\u0026rsquo;administration via l\u0026rsquo;adresse http://IP-DU-SERVEUR:55414.\nLes réglages principaux à définir après l\u0026rsquo;installation sont :\nla création d\u0026rsquo;un utilisateur pour protéger l\u0026rsquo;accès à l\u0026rsquo;interface le type de sauvegarde que vous souhaitez utiliser (image, fichiers, les deux) le dossier par défaut à sauvegarder la fréquence et le nombre de sauvegardes le type de réseau (local ou sur internet) les informations smtp pour l\u0026rsquo;envoi des notifications Pour mes serveurs web, je n\u0026rsquo;utilise pour le moment que les sauvegardes de fichiers et le dossier par défaut à sauvegarder est /var/www.\nInstallation du client UrBackup\rPour linux, l\u0026rsquo;installation du client UrBackup se fait via une seule ligne de commande :\nTF=`mktemp` \u0026amp;\u0026amp; wget \u0026#34;https://hndl.urbackup.org/Client/2.3.4/UrBackup%20Client%20Linux%202.3.4.sh\u0026#34; -O $TF \u0026amp;\u0026amp; sudo sh $TF; rm $TF Durant l\u0026rsquo;installation, il vous sera demandé quel type de sauvegarde vous souhaitez utiliser pour la réalisation d\u0026rsquo;image disque (dans le cas où le système de fichier le permet). Par la suite la mise à jour du client sera automatique. Il est nécessaire d\u0026rsquo;ouvrir les ports 35621, 35622 et 35623 pour pouvoir connecter votre client au serveur Urbackup.\nSi vous utilisez UFW, vous pouvez les ouvrir uniquement vers l\u0026rsquo;IP de votre serveur Urbackup :\nufw allow from IP.DE.VOTRE.SERVEUR-URBACKUP to any port 35621 ufw allow from IP.DE.VOTRE.SERVEUR-URBACKUP to any port 35622 ufw allow from IP.DE.VOTRE.SERVEUR-URBACKUP to any port 35623 Dès la première connexion au serveur (après avoir ajouté l\u0026rsquo;IP ou le hostname du client via l\u0026rsquo;interface UrBackup Server), une première sauvegarde complète du client sera réalisée, en fonction des options que vous aurez définie. Les sauvegardes suivantes seront incrémentielles.\nLa configuration du client urbackup se trouve dans le fichier /etc/default/urbackupclient, dans lequel vous pouvez changer l\u0026rsquo;option RESTORE=\u0026quot;disabled\u0026quot; par RESTORE=\u0026quot;server-confirms\u0026quot; pour autoriser la restauration d\u0026rsquo;un backup depuis l\u0026rsquo;interface d\u0026rsquo;administration de UrBackup Server.\nModification qui peut être effectuée avant de connecter le client au serveur avec la commande :\nsed -i \u0026#39;s/RESTORE=disabled/RESTORE=\u0026#34;server-confirms\u0026#34;/\u0026#39; /etc/default/urbackupclient Sauvegarder vos bases de données\rSi vous utilisez Urbackup en mode sauvegarde de fichiers, vous allez sûrement souhaitez sauvegarder vos bases de données. Et pour cela il y a deux solutions avec UrBackup.\nUtiliser mysqldump\rC\u0026rsquo;est la solution la plus simple à mettre en place, puisque vous pouvez utiliser un cronjob pour exécuter un script bash régulièrement. J\u0026rsquo;utilise par exemple un script modifié par mes soins disponible sur Github, que vous pouvez télécharger et utiliser librement. Voici les étapes à suivre :\nTélécharger le script et le rendre exécutable wget -O mysqldump.sh vtb.cx/mysqldump chmod +x mysqldump.sh Définir les identifiants root pour MySQL dans .my.cnf Pour accéder à vos bases de données, le script utilise les identifiants stockés dans le fichier ~/my.cnf. Ce fichier doit ressembler à : [client] user = root password = votremotdepasse ajouter un cronjob On ajoute une crontab en utilisant la commande crontab -e, puis en ajoutant la ligne : @daily /root/mysqldump.sh \u0026gt; /dev/null Il ne reste plus qu\u0026rsquo;à enregister la modification et le cronjob réalisera ainsi un backup journalier de chacune des bases de données, stocké par défaut dans le dossier /var/www/mysqldump.\nUtiliser Percona XtraBackup pour des sauvegardes incrémentielles\rUrBackup a une fois de plus prévu tout ce qu\u0026rsquo;il vous faut, puisqu\u0026rsquo;il permet de réaliser des sauvegardes incrémentales de votre serveur MySQL, en utilisant l\u0026rsquo;outil Percona XtraBackup qui réalise des sauvegardes à chaud du dossier /var/lib/mysql que vous pouvez restaurer en quelques minutes.\nAvant de pouvoir utiliser XtraBackup, il vous faut installer le paquet percona-xtrabackup. Pour MariaDB, le dépôt apt est automatiquement ajouté par le script mariadb_repo_setup.\nExemple pour MariaDB 10.1\ncurl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \\ | sudo bash -s -- --mariadb-server-version=10.1 --skip-maxscale sudo apt update \u0026amp;\u0026amp; sudo apt install percona-xtrabackup -y Exemple pour MariaDB 10.2\ncurl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \\ | sudo bash -s -- --mariadb-server-version=10.2 --skip-maxscale sudo apt update \u0026amp;\u0026amp; sudo apt install percona-xtrabackup-24 -y Une fois XtraBackup installé, il faut éditer le fichier /usr/local/etc/urbackup/mariadbxtrabackup.conf, dans lequel il faut remplacer MARIADB_XTRABACKUP_ENABLED=0 par MARIADB_XTRABACKUP_ENABLED=1 et définir le mot de passe root de MySQL à la fin du fichier.\nOn peut ensuite activer la configuration avec la commande :\n/usr/local/share/urbackup/scripts/setup-mariadbbackup Et vérifier que la sauvegarde fonctionne avec la commande :\n/usr/local/share/urbackup/scripts/mariadbxtrabackup \u0026gt; /dev/null Pour restaurer la dernière sauvegarde, vous pourrez utiliser la commande :\n/usr/local/share/urbackup/scripts/restore-mariadb ","date":"2017-11-13T19:03:46Z","image":"/images/2018/07/Centraliser-Backup--2-.jpg","permalink":"/deployer-systeme-backup-centralise-urbackup/","title":"Déployer un système de backup centralisé avec UrBackup"},{"content":"Ayant récemment migré de WordPress vers Ghost, j\u0026rsquo;ai souhaité utiliser une autre solution que Disqus pour la gestion des commentaires sur le blog, de préférence self-hosted. Je me suis donc tourné vers Isso, un système de gestion de commentaires open-source permettant de gérer plusieurs sites.\nNous allons dans ce tutoriel voir comment installer Isso et comment le configurer pour gérer les commentaires de plusieurs sites.\nInstaller Isso\rPour l\u0026rsquo;installation, on commence par créer un nouvel utilisateur avec les droits sudo. De la même façon que pour installer ghost via la ghost-cli\nadduser isso adduser isso sudo On se connecte ensuite avec cet utilisateur\nsu - isso Et on commence par installer les paquets nécessaires pour isso\nsudo apt-get install python3-setuptools python3-virtualenv python3-dev sqlite3 build-essential On définit alors notre environnement pour python.\npython3 -m venv /opt/isso source /opt/isso/bin/activate Il y a plusieurs options pour installer isso, mais la plus simple étant visiblement via pip, c\u0026rsquo;est cette dernière que j\u0026rsquo;ai utilisé :\npip install isso On peut ensuite sortir du virtualenv avec la commande :\ndeactivate Pour pouvoir utiliser directement la commande isso depuis le virtualenv, il suffit de créer un symlink entre /opt/isso/bin/isso et /usr/local/bin/isso :\nln -s /opt/isso/bin/isso /usr/local/bin/isso Pour mettre à jour isso, il suffit de faire :\nsource /opt/isso/bin/activate pip install --upgrade isso deactivate Configurer Isso\rNous avons terminé l\u0026rsquo;installation d\u0026rsquo;Isso, et nous allons pouvoir passer à la configuration. Pour cela on créer un fichier yourwebsite1.cfg et yourwebsite2.cfg dans le dossier de Isso dans lesquel nous allons définir les options suivantes :\nla base de donnée la modération le serveur SMTP Pour construire vos fichiers de configuration, utilisez l\u0026rsquo;exemple officiel disponible sur github : https://github.com/posativ/isso/blob/master/share/isso.conf Comme vous pourrez le voir, il nous faut créer un dossier /var/lib/isso et créer un fichier vide pour chacun de nos sites :\nmkdir -p /var/lib/isso \u0026amp;\u0026amp; cd /var/lib/isso touch comments.yourwebsite1.db comments.yourwebsite2.db On pourra donc compléter la section générale dans la configuration de Isso :\n[general] name = yourwebsite1 host = http://yourwebsite1.tld/ dbpath = /var/lib/isso/yourwebsite1.db Importer des commentaires\rAvant de démarrer Isso, vous pouvez importer des commentaires provenant de WordPress ou de Disqus. Pour cela utililsez la commande suivante :\nisso -c /path/to/isso.cfg import /path/to/disqus-or-wordpress.xml L\u0026rsquo;opération est à réaliser pour chaque site.\nConfiguration du serveur Gunicorn\rPour exécuter Isso en multi-site, nous avons besoin d\u0026rsquo;installer Gunicorn. Cela se fait avec pip :\npip install gunicorn On peut désormais lancer Isso, pour cela on définit tout d\u0026rsquo;abord l\u0026rsquo;emplacement de nos fichiers de configurations via la commande :\nexport ISSO_SETTINGS=\u0026#34;/etc/isso.d/yourwebsite1.cfg;/etc/isso.d/yourwebsite2.cfg\u0026#34; Puis on lance Gunicorn :\ngunicorn isso.dispatch -b localhost:8080 Configuration de Nginx\rLe serveur Gunicorn écoute sur le port 8080, accessible uniquement localement, nous allons donc utiliser Nginx en tant que reverse-proxy, pour rendre accessible notre système de commentaire via un sous-domaine, et installer un certificat SSL let\u0026rsquo;s encrypt.\nOn installe donc Nginx si ce n\u0026rsquo;est pas déjà fait :\nwget -O - https://nginx.org/keys/nginx_signing.key | sudo apt-key add - sudo echo \u0026#34;deb http://nginx.org/packages/ubuntu/ $(lsb_release -sc) nginx\u0026#34; \u0026gt; /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install nginx Et on créer notre vhost, ici sur le sous domaine comments.yourdomain.ltd\nupstream app_server { server 127.0.0.1:8080 fail_timeout=0; } server { listen 443 ssl http2; listen [::]:443 ssl http2; ssl on; ssl_certificate /etc/letsencrypt/live/comments.yourdomain.tld/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/comments.yourdomain.tld/privkey.pem; keepalive_timeout 5; server_name comments.yourdomain.tld; access_log /var/log/nginx/comments.yourdomain.tld.access.log rt_cache; error_log /var/log/nginx/comments.yourdomain.tld.error.log; location / { try_files $uri @proxy_to_app; } location @proxy_to_app { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://app_server; } } On installe ensuite acme.sh pour générer notre certificat SSL :\nwget -O - https://get.acme.sh | sh source ~/.bashrc Et on génère le certificat via le serveur standalone de validation certbot, en arrêtant le service nginx pour libérer le port 80 et 443, durant la validation.\nacme.sh --issue -d comments.yourdomain.tld --keylength ec-384 --standalone --pre-hook \u0026#34;systemctl stop nginx\u0026#34; --post-hook \u0026#34;systemctl start nginx\u0026#34; Il ne reste plus qu\u0026rsquo;à déployer le certificat :\n# créer le répertoire mkdir -p /etc/letsencrypt/live/comments.yourdomain.tld # déployer le certificat acme.sh --install-cert -d comments.yourdomain.tld --ecc \\ --cert-file /etc/letsencrypt/live/comments.yourdomain.tld/cert.pem \\ --key-file /etc/letsencrypt/live/comments.yourdomain.tld/key.pem \\ --fullchain-file /etc/letsencrypt/live/comments.yourdomain.tld/fullchain.pem \\ --reloadcmd \u0026#34;service nginx restart\u0026#34; Et à ajouter la configuration suivante dans votre vhost Nginx :\nlisten 443 ssl http2; listen [::]:443 ssl http2; ssl_certificate/etc/letsencrypt/live/comments.yourdomain.tld/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/comments.yourdomain.tld/key.pem; ssl_trusted_certificate/etc/letsencrypt/live/comments.yourdomain.tld/cert.pem; Lancer Isso automatiquemement\rPour lancer Isso automatiquement au démarrage de votre machine, nous allons le déclarer en tant que service systemd. On créer pour cela un fichier /lib/systemd/system/isso.service avec le contenu suivant :\n[Unit] Description=lightweight Disqus alternative [Service] User=isso Group=isso Environment=\u0026#34;ISSO_SETTINGS=/etc/isso.d/foo.example.cfg;/etc/isso.d/other.bar.cfg\u0026#34; ExecStart=/usr/local/bin/gunicorn --log-file /var/log/isso.log isso.dispatch -b localhost:8080 SyslogIdentifier=isso [Install] WantedBy=multi-user.target Il suffit alors d\u0026rsquo;activer le service avec systemd pour créer un symkink entre le dossier /lib/systemd/system et /etc/systemd/system avant de le lancer.\nsystemctl enable isso.service systemctl start isso.service Ajouter Isso à son site\rSi vous tentez d\u0026rsquo;accéder au sous-domaine d\u0026rsquo;Isso, il vous affichera les nom des différents sites sur lesquels vous pouvez installer le module de commentaire, sous la forme :\n/yourblogname /yourblogname2 /yourblogname3 Pour installer Isso sur votre blog, il vous suffit d\u0026rsquo;insérer le code suivant, en remplaçant yourblogname par le nom de votre blog :\n\u0026lt;script data-isso=\u0026#34;//comments.example.tld/yourblogname/\u0026#34; src=\u0026#34;//comments.example.tld/yourblogname/js/embed.min.js\u0026#34;\u0026gt;\u0026lt;/script\u0026gt; \u0026lt;section id=\u0026#34;isso-thread\u0026#34;\u0026gt;\u0026lt;/section\u0026gt; Vous pouvez également ajouter des paramètres via ce code, dont la liste est disponible dans la documentation officielle de Isso.\n","date":"2017-10-19T16:55:39Z","image":"/images/2018/07/Installer-Isso-sur-Ubuntu-16.04-LTS.jpg","permalink":"/installer-isso-sur-ubuntu-16-04-lts-remplacer-disqus/","title":"Installer Isso sur Ubuntu 16.04 LTS pour remplacer disqus"},{"content":"Article écrit par Wonderfall. Suite à la fermeture de son blog, j\u0026rsquo;ai souhaité (avec son accord) remettre en ligne ce dernier pour que son contenu reste accessible.\nCet article est adressé principalement aux administrateurs système, ou devrais-je plutôt dire aux administrateurs de système puisque parmi vous il y a non seulement des personnes qui en ont fait leur métier, et d\u0026rsquo;autres personnes qui en font leur passion (comme moi, peut-être\u0026hellip;). Par manque de temps et surtout parce que je parlerai des outils sur lesquels j\u0026rsquo;ai mis la main, j\u0026rsquo;utiliserai un seul serveur web au cours de cet article, le bien connu nginx. Cet article reprendra en partie un ancien article de mon précédent blog : Des certificats ECDSA avec Let\u0026rsquo;s Encrypt.\n1. Mettons les choses en ordre\u0026hellip;\rJetez un coup d\u0026rsquo;oeil à l\u0026rsquo;image d\u0026rsquo;en-tête de l\u0026rsquo;article. Vous vous y reconnaitrez peut-être. Ou peut-être pas. Certains parmi vous sont complètement perdus, et ces noms ne leurs évoqueront rien. D\u0026rsquo;autres sont déjà à l\u0026rsquo;aise, savent grossièrement à quoi cela correspond. Eh bien, j\u0026rsquo;en fais moi-même partie. Dans un esprit d\u0026rsquo;humilité, je reconnais ne pas avoir les capacités nécessaires pour comprendre à 100% les notions conceptuelles, mathématiques, et toutes les subtilités derrière les technologies que je mentionnerai. Cela dit, ça ne m\u0026rsquo;empêchera pas de tenter, au moins, de vulgariser et de montrer des exemples. Ma vulgarisation sera approximative, elle comportera peut-être des erreurs, je l\u0026rsquo;admets. Mais tant que j\u0026rsquo;estime ne pas mettre en danger la sécurité des personnes (au contraire\u0026hellip;), et tant que vous avez compris ce que je voulais dire dans ce paragraphe, je me sens libre de continuer à écrire cet article.\nCe qui m\u0026rsquo;a poussé à le faire, c\u0026rsquo;est que le nombre de demandes d\u0026rsquo;aide à propos de la configuration HTTPS est devenu croissant. Vous vous souvenez de Mastodon ? Aujourd\u0026rsquo;hui le nombre d\u0026rsquo;instances est bien plus important, et plus d\u0026rsquo;instances, ça veut dire aussi plus de configurations. Le principal site qui recense les différentes instances classe désormais les instances en fonction de leur configuration HTTPS, à travers Cryptcheck et depuis peu l\u0026rsquo;Observatoire Mozilla (qui comprend Cryptcheck également puisqu\u0026rsquo;il fait appel à des tests tiers). Évidemment, c\u0026rsquo;est la folie : tout le monde veut absolument avoir son instance le plus haut possible dans la liste, donc il faut à tout prix mieux sécuriser\u0026hellip; si seulement c\u0026rsquo;était le cas pour les banques aussi, mais passons.\nEt puis, certains iraient bien se masturber un coup sur un A+ de Cryptcheck/Qualys. Mais, pourquoi pas ? Ces questions ne me concernent pas. On atteindra cette finalité si c\u0026rsquo;est ce que vous voulez, vos motivations sont les vôtres. Quand je parle d\u0026rsquo;une excellente configuration, c\u0026rsquo;est effectivement une configuration qui vous donnera une note maximale sur ces outils. Dans le titre, je n\u0026rsquo;ai pas parlé de \u0026ldquo;comment configurer HTTPS\u0026rdquo;, nuance. Mais il ne faut pas non plus suivre mon tutoriel n\u0026rsquo;importe comment, parce que premièrement, la compatibilité des clients en prend forcément un coup, et deuxièmement, certains mécanismes tels que HPKP peuvent vous casser la gueule si vous les utilisez n\u0026rsquo;importe comment. Lisez, puis faites. Pas l\u0026rsquo;inverse\u0026hellip;\nD\u0026rsquo;avance, j\u0026rsquo;annonce que je ne me prendrai pas la tête avec la compatibilité. Donc ne venez pas me dire que votre site ne fonctionne pas sur X ou Y, parce que je vous aurais prévenu.\n2. Choix de la bibliothèque SSL/TLS\rLes bibliothèques SSL/TLS fournissent une implémentation d\u0026rsquo;algorithmes cryptographiques et de protocoles de communication sécurisés (les différentes versions de SSL et TLS : SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3..). Aujourd\u0026rsquo;hui, 3 bibliothèques sont compatibles avec nginx :\nOpenSSL : la plus connue, et la plus présente. LibreSSL : fork d\u0026rsquo;OpenSSL par OpenBSD. BoringSSL : fork d\u0026rsquo;OpenSSL par Google. Il faut dire que Heartbleed a porté en 2014 un coup à la popularité d\u0026rsquo;OpenSSL. Non pas que ce fut la première faille découverte, loin de là, mais il y a eu une prise de conscience sur la qualité du code d\u0026rsquo;OpenSSL et des implémentations trop anciennes qui y sont présentes. OpenBSD fidèle à sa réputation, créa son fork LibreSSL dans le but de littéralement nettoyer OpenSSL et de le débarrasser d\u0026rsquo;algorithmes dépassés et dangereux d\u0026rsquo;utilisation. Aujourd\u0026rsquo;hui, il n\u0026rsquo;y a pas seulement OpenBSD qui utilise LibreSSL à la place d\u0026rsquo;OpenSSL en tant que bibliothèque par défaut du système. En effet, d\u0026rsquo;autres distributions ont sauté le pas, y compris macOS.\nQuant à Google, ce n\u0026rsquo;est pas vraiment la même raison qui a conduit à créer BoringSSL. En effet, ils maintenaient déjà une version d\u0026rsquo;OpenSSL interne avec de nombreux patchs, Heartbleed a seulement été l\u0026rsquo;élément déclencheur pour repartir d\u0026rsquo;une page blanche, et c\u0026rsquo;est bien ce travail qui a été mené. Peu importe si les mises à jour cassent la compatibilité API/ABI avec d\u0026rsquo;autres logiciels comme nginx, Google met de toute façon en garde :\nEN : Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don\u0026rsquo;t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.\nFR : Bien que BoringSSL soit un projet open-source, il n\u0026rsquo;est pas destiné à un usage général, comme OpenSSL l\u0026rsquo;est. Nous ne recommandons pas que les tierces parties dépendent dessus. Faire ainsi sera probablement source de frustrations puisqu\u0026rsquo;il n\u0026rsquo;y aucune garantie de la stabilité de l\u0026rsquo;API/ABI.\nEn pratique, BoringSSL fonctionne avec nginx et les développeurs ont accepté de faire quelques efforts pour satisfaire les quelques curieux qui souhaitent l\u0026rsquo;utiliser de cette façon. En revanche, pas de support de OCSP stapling.\nEn pratique, qu\u0026rsquo;est-ce que je dois choisir ?\nUtiliser la bibliothèque de son système est une bonne chose car les mises à jour sont simples, donc il n\u0026rsquo;est pas nécessaire de recompiler nginx à chaque fois. Sur Debian, ça reste pour le moment OpenSSL. La version de Jessie est maintenue, mais elle est figée du point de vue technologique, donc en pratique, on aura pas quelques algorithmes récents (même si on peut s\u0026rsquo;en passer) et quelques features intéressantes compatibles avec nginx, mais nécessitant une version d\u0026rsquo;OpenSSL supérieure. La version d\u0026rsquo;OpenSSL fournie par Stretch (1.1.0) est aujourd\u0026rsquo;hui la version la plus récente d\u0026rsquo;OpenSSL.\nSi vous êtes prêts à ne pas utiliser une bibliothèque système, je vous recommande sans hésiter LibreSSL, pour les raisons que j\u0026rsquo;ai énoncées plus haut. OpenBSD est une équipe de confiance, vraiment (et même un peu trop) perfectionniste. BoringSSL est celui qui vous proposera le plus de nouveautés, dont l\u0026rsquo;utilisation des versions drafts de TLS 1.3, des expérimentations d\u0026rsquo;algorithmes quantum proofs qui peuvent être retirées du jour au lendemain par Google (comme CECPQ1), etc. mais de mon point de vue, ce n\u0026rsquo;est vraiment pas quelque chose à utiliser sur une machine en production, il n\u0026rsquo;y a même pas de versioning, à utiliser plus pour la curiosité donc.\nSi vous avez fait le choix d\u0026rsquo;utiliser une autre bibliothèque que la bibliothèque utilisée par défaut par le système, vous allez devoir recompiler nginx. Inutile que je passe mon temps à faire un tutoriel, il y en a\u0026hellip; plein : ici (2015) pour LibreSSL, là (2016) pour BoringSSL (je me fais un peu de publicité, je sais). Mais si vous ne voulez pas vous prendre la tête, je vous propose des scripts voire des images Docker :\nAngristan/nginx-autoinstall : compile nginx sur Debian, avec le choix entre OpenSSL et LibreSSL et d\u0026rsquo;autres modules ! wonderfall/boring-nginx : une image Docker basée sur Alpine Linux, avec nginx compilé depuis les sources avec BoringSSL. xataz/nginx : une image Docker basée sur Alpine Linux qui installe simplement nginx, mais Alpine Linux utilise LibreSSL par défaut. ajhaydock/BoringNginx : des scripts pour Debian/CentOS et une image Docker basée sur CentOS pour utiliser nginx avec BoringSSL. 3. D\u0026rsquo;abord, les certificats !\ra. Savoir (un peu) de quoi on parle\rInutile de s\u0026rsquo;attaquer à la configuration d\u0026rsquo;HTTPS sans passer par la génération de certificats. Mais d\u0026rsquo;abord, pourquoi parle-t-on de certificats ? Deux mots pour décrire les buts d\u0026rsquo;HTTPS : chiffrement et authenticité. Ce dernier point repose sur la certification de la clé publique avec un certificat (d\u0026rsquo;un certain format nommé X.509) signé par une autorité connue (CA pour Certificate Authority). L\u0026rsquo;ensemble des composantes visant à gérer le cycle de vie des certificats porte le nom de Public Key Infrastructure (PKI). Les certificats définissent les informations d\u0026rsquo;appartenance de la clé publique, et définissent également les hostnames pour lesquels le certificat est valide. Par exemple, le certificat que j\u0026rsquo;utilise pour psychedeli.cat est aussi valable pour isso.psychedeli.cat (un sous-domaine). Ces informations, vous pouvez les obtenir très simplement depuis votre navigateur qui lit ces informations depuis le certificat fourni par le serveur web.\nVoyez l\u0026rsquo;illustration comme un arbre, on part de la racine (= root), on passe par les branches ramifiées (certificats intermédiaires) et enfin on atteint les feuilles (= leaf)\nNous allons ici utiliser Let\u0026rsquo;s Encrypt, qui est comme je vous l\u0026rsquo;ai dit une autorité de certification. Le principe est celui d\u0026rsquo;une chaîne de confiance : le certificat root (fourni ici par ISRG) est le certificat originel, qui peut signer des certificats intermédiaires (ceux de Let\u0026rsquo;s Encrypt). Ces certificats intermédiaires permettront de signer les certificats que nous utilisons tous les jours, qu\u0026rsquo;on appelle aussi leaf certificate, ils permettront de signer des clés temporaires dérivées de la paire clé publique/privée qui sera utilisée pour sécuriser une session. Ces certificats sont en fin de chaîne et ce sont eux que nous allons obtenir.\nb. Générer des certificats ECDSA (P-384)\rPlus précisément, on va le faire d\u0026rsquo;une façon un peu plus manuelle mais loin d\u0026rsquo;être difficile. Cela nous permettra :\nDe gérer nous-même le renouvellement de la paire de clés, ce qui nous permet d\u0026rsquo;utiliser plus sereinement et efficacement HPKP. D\u0026rsquo;utiliser une autre approche d\u0026rsquo;algorithme asymétrique que RSA, ECDSA qui repose donc sur la cryptographie sur les courbes elliptiques (ECC). Les algorithmes de la famille des courbes elliptiques proposent d\u0026rsquo;utiliser des clés bien plus courtes, pour une sécurité comparable à celle offerte par RSA, et ils permettent également d\u0026rsquo;économiser des ressources. Voici des tests de performance que j\u0026rsquo;ai réalisés avec ma machine :\n$ openssl speed rsa sign verify sign/s verify/s rsa 2048 bits 0.000549s 0.000025s 1821.4 39636.0 rsa 3072 bits 0.002579s 0.000051s 387.7 19471.4 rsa 4096 bits 0.005829s 0.000089s 171.5 11270.1 $ openssl speed ecdsa sign verify sign/s verify/s 256 bit ecdsa (nistp256) 0.0000s 0.0001s 25425.7 10819.8 384 bit ecdsa (nistp384) 0.0002s 0.0007s 5749.2 1340.1 521 bit ecdsa (nistp521) 0.0003s 0.0006s 3007.0 1659.5 ECDSA en soit n\u0026rsquo;est pas directement comparable à RSA, il doit être associé à des courbes elliptiques, et ici, ce sont les courbes NIST P-256, P-384, et P-521, qui sont utilisées. Le nombre de signatures/secondes est tout simplement bien meilleur avec ECDSA. Quid de la sécurité ? Selon la NSA elle-même, une clé ECC de taille 384 bits offrirait une sécurité équivalente à une clé RSA de taille 7680 bits.\nDepuis Février 2016, Let\u0026rsquo;s Encrypt peut émettre des certificats ECDSA (les choix sont P-256 et P-384). Malheureusement, le client officiel certbot ne le permet pas. Alors soit on peut utiliser d\u0026rsquo;autres clients comme lego qui vont mâcher le travail, soit on peut toujours utiliser certbot mais se débrouiller nous-même pour générer notre clé privée et notre demande de signature de certificat (dans un fichier CSR).\nCommençons par générer une clé privée P-384 :\nopenssl ecparam -genkey -name secp384r1 \u0026gt; privkey.pem On peut maintenant créer un fichier CSR, qui contient toutes les informations relatives à une demande de certificat. Comme moi, vous aurez peut-être envie de générer un seul certificat pour plusieurs domaines, ceci peut se faire avec l\u0026rsquo;extension SAN de X.509. Vous devez tout d\u0026rsquo;abord copier le fichier /etc/ssl/openssl.cnf dans votre répertoire de travail. Par exemple :\ncp /etc/ssl/openssl.cnf custom.cnf On va modifier ce custom.cnf pour bénéficier de SAN et donc d\u0026rsquo;un certificat valable, en gros, pour plusieurs domaines. Voici comment. Dans la section [ req ], décommettez req_extensions = v3_req. Dans la section [ v3_req ], ajoutez une nouvelle ligne : subjectAltName = @alt_names. Enfin, tout se passe dans [ alt_names ] pour ajouter vos domaines. Cette section n\u0026rsquo;existe pas, il faut la créer, par exemple tout à la fin du fichier.\n# custom.cnf ... [ req ] ... req_extensions = v3_req ... [ v3_req ] ... subjectAltName = @alt_names ### OCSP Must-Staple, cf. plus loin #tlsfeature = status_request # OpenSSL \u0026gt;=1.1.0 #1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05 # OpenSSL \u0026lt;=1.0 ... [ alt_names ] DNS.1 = domain.tld DNS.2 = sub1.domain.tld DNS.3 = sub2.domain.tld ... DNS.n = subn.domain.tld Pour chaque domaine souhaité, on l\u0026rsquo;associe à la directive DNS.k où k, allant de 1 à n, est incrémenté sur chaque nouvelle ligne. Le SAN que peut signer Let\u0026rsquo;s Encrypt peut atteindre 100 (autrement dit, 100 domaines différents dans un seul certificat X.509), donc n \u0026lt;= 100.\nEnregistrez toutes ces modifications. Vous pouvez désormais générer votre CSR avec la commande suivante :\nopenssl req -new -sha256 -key privkey.pem -out csr.der -config custom.cnf Rentrez des informations, mais laissez Common Name vide, et ne protégez pas avec un mot de passe. Vous devez, à ce stade, avoir en votre possession un privkey.pem et un csr.der.\nPour demander à Let\u0026rsquo;s Encrypt de nous émettre un certificat à partir de notre demande, il suffit d\u0026rsquo;utiliser certbot de cette façon, avec l\u0026rsquo;argument --csr pour fournir le CSR :\ncertbot certonly --standalone --agree-tos -m admin@domain.tld \\ --csr /path/to/csr.der \\ --cert-path /path/to/cert.pem \\ --chain-path /path/to/chain.pem \\ --fullchain-path /path/to/fullchain.pem Congrats! Vous avez ainsi obtenu :\ncert.pem : leaf certificate, contient entre autres la clé publique chain.pem : certificat de la chaîne Let\u0026rsquo;s Encrypt fullchain.pem : concaténation des deux fichiers ci-dessus privkey.pem : clé privée qu\u0026rsquo;on avait générée tout à l\u0026rsquo;heure DNS CAA : N\u0026rsquo;oubliez pas d\u0026rsquo;ajouter des enregistrements CAA dans votre zone DNS, ils permettent de définir quel CA est autorisé à émettre un certificat pour le domaine domain.tld. Exemple pour ce domaine avec Let\u0026rsquo;s Encrypt :\ndomain.tld. CAA 0 issue \u0026#34;letsencrypt.org\u0026#34; domain.tld. CAA 0 iodef \u0026#34;mailto:admin@domain.tld\u0026#34; 4. Le protocole SSL/TLS\rJe vous recommande la lecture de cet article : CryptCheck, vérifiez vos implémentations de TLS.\nTLS et son ancêtre SSL sont des protocoles qui sont utilisés pour sécuriser des échanges sur Internet. Par exemple conjointement avec HTTP pour donner HTTPS, le joli cadenas vert que vous avez dans votre barre d\u0026rsquo;adresse et qui ne veut pas dire grand chose parfois. Ils sont utilisés pour l\u0026rsquo;intégrité, l\u0026rsquo;authentification, la confidentialité (chiffrement), etc.\nAujourd\u0026rsquo;hui, la compatibilité de TLS 1.2 est répandue et il s\u0026rsquo;agit de la dernière version datant de 2008. TLS 1.0 (quoique\u0026hellip;) et 1.1 peuvent être activés en cas de besoin de compatibilité. Pour cet article je ne vais garder que TLS 1.2. Il est par contre hors de question d\u0026rsquo;utiliser SSL. SSLv3 c\u0026rsquo;est poubelle (POODLE), SSLv2 c\u0026rsquo;est poubelle aussi (DROWN). D\u0026rsquo;ailleurs j\u0026rsquo;en profite : arrêtez de véhiculer cet abus de langage comme quoi SSL/TLS = SSL. J\u0026rsquo;aurais d\u0026rsquo;ailleurs trouvé ça appréciable si LibreSSL s\u0026rsquo;appelait plutôt LibreTLS, bref.\nDonc on configure nginx pour n\u0026rsquo;accepter que TLS 1.2 :\nssl_protocols TLSv1.2; TLS 1.3 arrivera incessamment sous peu, à l\u0026rsquo;heure où j\u0026rsquo;écrit cet article la 19e draft est encore très récente. OpenSSL 1.1.0 aura droit à TLS 1.3, tout comme LibreSSL qui devrait suivre. BoringSSL propose déjà TLS 1.3, j\u0026rsquo;ai testé et ça fonctionne même s\u0026rsquo;il faut l\u0026rsquo;activer de force. Cela dit je ne peux pas vraiment recommander d\u0026rsquo;utiliser un protocole au stade de brouillon et dont l\u0026rsquo;implémentation est encore trop jeune.\nHistoire de faire une transition avec la partie suivante : avec TLS, tout commence par un handshake entre le client et le serveur. Le client envoie au serveur un message ClientHello avec une liste de suites cryptographiques supportées et de protocoles (par exemple pour HTTP/2). Le serveur renvoie à son tour un ServerHello avec entre autres, le choix de la suite cryptographique pour la session.\n5. La suite cryptographique\rVous auriez déjà dû entendre parler du terme cipher. Cela désigne pour ceux qui ne le savent pas un algorithme qui chiffre et déchiffre, c\u0026rsquo;est une notion simple et cela existe depuis l\u0026rsquo;antiquité en fait, puisque ce sont les débuts même de la cryptographie. Mais avant que les 2 parties (ici, le serveur et le client) ne puissent chiffrer/déchiffrer leurs communications (par exemple du chiffrement par bloc avec un algorithme de cryptographie symétrique comme AES), il faut que les deux s\u0026rsquo;échangent une clé temporaire qui a été dérivée de la paire de clés du certificat, pour une session. Donc la question est de le faire d\u0026rsquo;une façon sécurisée à travers Internet, et éviter à tout prix les attaques MiTM.\na. L\u0026rsquo;échange de clés\rPour cela, on préfère l\u0026rsquo;échange de clés Diffie-Hellman (DH) car il y a la propriété de confidentialité persistante (Forward Secrecy FS ou Perfect Forward Secrecy PFS) : si la clé privée à partir de laquelle les clés de session ont été dérivés est compromise dans le futur, les clés de session utilisées précédemment pour des communications passées ne seront pas compromises. On pourrait en parler mathématiquement, mais là n\u0026rsquo;est pas vraiment le sujet, des personnes plus compétentes en parleront mieux que moi.\nAvec TLS, on utilise DHE (Diffie-Hellman Exchange) ou ECDHE (Elliptic Curve Diffie-Hellman Exchange), ECDHE étant une variante de DHE. Sans rentrer dans les détails, la différence est dans la génération des clés : pour ce faire, DHE repose sur de l\u0026rsquo;algorithmique modulaire (simple), tandis que ECDHE repose sur le problème mathématique des courbes elliptiques (algébriques). Ces courbes (NIST, Brainpool, X25519\u0026hellip;) ont les bénéfices que nous avons en partie évoqué plus haut.\nDe mon côté, je vous recommande carrément de n\u0026rsquo;utiliser que ECDHE pour l\u0026rsquo;échange de clés. Si vous voulez continuer à utiliser DHE, générez au moins une bonne clé de taille 4096 bits. Souvenez-vous des conséquences d\u0026rsquo;une clé trop petite, je parle bien sûr de Logjam. DHE souffre également d\u0026rsquo;un autre problème qui consiste en une MiTM assez violente : il est possible de downgrade vers une suite EXPORT dès que le serveur la supporte, et même si le client ne la supporte pas (merci @aeris pour cette remarque). Je persiste, utilisez donc seulement ECDHE, c\u0026rsquo;est très bien et dans la continuité de cet article. Et il n\u0026rsquo;y a rien de plus simple pour nginx puisqu\u0026rsquo;il suffit de jouer avec la directive ssl_ecdh_curve.\nOn peut ne pas renseigner cette directive, c\u0026rsquo;est possible, et dans ce cas le client et le serveur se mettront d\u0026rsquo;accord comme des grands sur la courbe à utiliser. Avec des versions de nginx relativement récentes (1.11+) et OpenSSL 1.1.0+ / LibreSSL / BoringSSL, il est possible de définir, côté serveur, un ordre de préférence. De mon côté, je préfère le faire (et si vous ne pouvez pas préciser plusieurs courbes, ne pas renseigner la directive est plus sage, sinon vous pouvez utiliser P-384 seulement) :\nssl_ecdh_curve X25519:P-521:P-384; # ssl_ecdh_curve secp521r1:secp384r1; # Autres noms # ssl_ecdh_curve secp384r1; # Si nginx pas récent Petite aparté sur X25519 : cette courbe elliptique est le fruit des recherches du Dr. Bernstein. Comme indiqué sur ce site, la sécurité offerte par les courbes NIST n\u0026rsquo;est pas parfaite et mathématiquement douteuse. X25519 est \u0026ldquo;meilleur\u0026rdquo;, et en plus, il ne vient pas d\u0026rsquo;une agence proche de la NSA qui a tout intérêt à rendre la cryptanalyse des courbes NIST plus avantageuse pour elle.\nX25519 n\u0026rsquo;étant disponible que sur des versions récentes de Chromium, il faut accepter d\u0026rsquo;autres courbes pour supporter par exemple Firefox et d\u0026rsquo;autres plateformes : P-521 et P-384, c\u0026rsquo;est très bien aussi. Ajoutez P-256 si la compatibilité est vraiment un problème.\nb. Le chiffrement des données\rMaintenant que la clé temporaire de session a été communiquée de façon sécurisée grâce à ECDH au client, ce dernier et le serveur peuvent échanger dans un canal chiffré dans une configuration symétrique, d\u0026rsquo;où l\u0026rsquo;utilisation d\u0026rsquo;algorithmes symétriques comme AES. C\u0026rsquo;est aujourd\u0026rsquo;hui le plus éprouvé. RC4, DES, 3DES\u0026hellip; sont à bannir. Des chatons meurent à chaque fois que ces algorithmes sont utilisées. En 2017, on utilise normalement AES.\nAES faisant du chiffrement par bloc, on introduit deux notions :\nLe mode d\u0026rsquo;opération des blocs : CCM, CBC, GCM\u0026hellip; La taille des clés utilisées : 128, 256\u0026hellip; TLS 1.2 standardise notamment des suites cryptographiques qui reposent sur AES-CBC et AES-GCM, avec des clés 128 et 256 bits. Le mode GCM est nettement préférable à CBC. Pourquoi ? Dans le mode CBC, on utilise la fonction XOR (disjonction exclusive) avec un bloc de données en clair et un vecteur d\u0026rsquo;initialisation (IV), ensuite la sortie de XOR est chiffrée avec notre clé symétrique. Le mode GCM diffère de par son fonctionnement : un compteur pour chaque bloc est chiffré par la clé symétrique (dans le Corps de Galois), puis on utilise la fonction XOR avec la sortie obtenue et le bloc de données en clair : le bloc chiffré est formé ainsi. Pour ne pas aller plus loin dans les détails même si ce sont de grands mots qui peuvent faire peur, le fonctionnement inhérent de GCM est plus sécurisé que celui de CBC. Il est aussi très rapide. CBC est vulnérable aux attaques padding oracle.\nNe faites pas une erreur tentante : Qualys ne vous mettra pas du 100/100 partout si vous avez le malheur d\u0026rsquo;utiliser AES avec une clé 128 bits, même AES GCM. Donc certains vont forcer AES avec une clé 256 bits, mode GCM et CBC, parce que AES-256-GCM n\u0026rsquo;est pas forcément très bien supporté partout encore. C\u0026rsquo;est une fausse bonne idée ! AES-128-GCM est très bien, et quoiqu\u0026rsquo;il arrive, il faut privilégier GCM à CBC. C\u0026rsquo;est le comportement de la suite EECDH+AES par défaut, inutile d\u0026rsquo;en préciser plus. Pour utiliser GCM seulement, ce que je fais, vous pouvez utiliser EECDH+AESGCM.\nChaCha20 est un autre algorithme symétrique, qui a un fonctionnement intrinsèquement différent puisqu\u0026rsquo;il fonctionne par flot et non par blocs (comme RC4). C\u0026rsquo;est une alternative à AES proposée par le Dr. Bernstein encore une fois. Bien que la cryptanalyse faite sur ChaCha20 ne soit pas aussi importante qu\u0026rsquo;avec AES, on le considère comme sûr, et de toute façon, avoir une alternative est toujours une bonne chose (et le monopole cryptographique n\u0026rsquo;étant pas idéal de toute façon\u0026hellip;). Il est moins rapide que AES sur des CPU qui disposent des instructions AES-NI, c\u0026rsquo;est-à-dire presque tous les CPU x86_64 actuels si je ne me trompe pas. Mais ChaCha20 offre des performances remarquables et se défend bien, si bien qu\u0026rsquo;il est préféré à AES quand on est sur des SoC ARM par exemple.\nChaCha20 est combiné à Poly1305, un type de code d\u0026rsquo;authentification de message (MAC) assurant l\u0026rsquo;intégrité des données, alors qu\u0026rsquo;on combine AES-GCM à HMAC-SHA2 par exemple. La qualité du HMAC dépendant de la fonction de hashage utilisée, je préfère ne pas utiliser SHA1 (et il est hors de question d\u0026rsquo;utiliser MD5), mais s\u0026rsquo;en séparer convient de faire une croix sur la compatibilité avec certains clients encore une fois. Pour continuer l\u0026rsquo;analogie entre ChaCha20 et AES, est-ce que Poly1305 est mieux que HMAC-SHA2 ? C\u0026rsquo;est différent, et c\u0026rsquo;est bien d\u0026rsquo;avoir le choix. Il y a certainement des subtilités qui feront pencher les cryptographes d\u0026rsquo;un côté plus que l\u0026rsquo;autre\u0026hellip; De mon côté, je préfère même mettre ChaCha20+Poly1305 en tête de liste parce que je préfère Docteur Bernstein. Mais il ne faut pas basher AES non plus : bien qu\u0026rsquo;il ait vu le jour lors du concours NIST au début des années 2000, les critères autour de sa création sont rigoureusement transparents. Tout ce dont on peut être sûr c\u0026rsquo;est que la NSA par exemple a eu le temps de faire sa cryptanalyse.\nDonc la configuration que je propose est la suivante :\nssl_ciphers EECDH+CHACHA20:EECDH+AESGCM; Restrictive, certes. Mais il ne devrait pas y avoir de soucis avec des clients modernes. Chrome et Firefox supportent déjà ChaCha20+Poly1305. AES-GCM fera l\u0026rsquo;affaire pour Edge, Safari (jusqu\u0026rsquo;à la version incluse dans Yosemite, mais n\u0026rsquo;oubliez pas que Mavericks a le droit à des updates majeures de Safari par exemple), et Android jusqu\u0026rsquo;à KitKat.\nBonus si vous utilisez BoringSSL : vous pouvez définir des groupes de suites cryptographiques équivalentes. Au sein d\u0026rsquo;un même groupe, vous laissez le client choisir selon son ordre à lui. Cela peut-être utile si vous voulez utiliser AES sur votre PC, mais ChaCha20 sur votre smartphone ARM, par exemple. Le groupe est défini entre crochets [] et avec une barre verticale pipe | entre chaque ciphersuite, ça donnerait ceci :\nssl_ciphers [EECDH+CHACHA20|EECDH+AESGCM]; 6. HTTP Strict Transport Security\rHSTS est un mécanisme de sécurité qui consiste à indiquer par un header envoyé au client qu\u0026rsquo;il doit communiquer, pour un domaine donné, avec le serveur web par une connexion sécurisée HTTPS uniquement. L\u0026rsquo;intérêt est évident, car si HSTS est actif, le client est protégé de diverses attaques réseau et d\u0026rsquo;une MiTM. Mais je n\u0026rsquo;ai pas mis le précédent \u0026ldquo;si\u0026rdquo; en gras pour rien, en effet si HSTS n\u0026rsquo;a jamais été actif ou ne l\u0026rsquo;est plus, HSTS ne peut plus plus offrir cette sécurité. C\u0026rsquo;est pour cela qu\u0026rsquo;a été inventé le mécanisme de HSTS Preloading, qui consiste en des listes préchargées et intégrées aux navigateurs pour indiquer la politique HSTS utilisée pour un domaine ; en quelque sorte, HSTS est déjà actif avant même que vous n\u0026rsquo;ayez visité le site.\nPour utiliser HSTS, il faut utiliser :\nLe header Strict-Transport-Security. max-age : durée d\u0026rsquo;activité une fois actif (recommandé : 6 mois+) includeSubDomains : protéger tous les sous-domaines. preload : activer HSTS preloading. De mon côté, je vais mettre max-age à 1 an soit 31536000 secondes. J\u0026rsquo;activerai HSTS preloading, et j\u0026rsquo;indiquerai de protéger tous les sous-domaines, soyez sûr que vous souhaitez faire de même :\nadd_header Strict-Transport-Security \u0026#34;max-age=31536000; includeSubDomains; preload\u0026#34;; Pour s\u0026rsquo;inscrire à la liste préchargée, il faut aller inscrire son domaine ici. La propagation peut prendre plusieurs semaines. Attention, HSTS Preload n\u0026rsquo;est pas là pour remplacer la redirection 301 vers HTTPS depuis HTTP.\n7. OCSP Stapling et OCSP Must-Staple\rOCSP Stapling est une alternative au protocole OCSP qui consiste à vérifier auprès de l\u0026rsquo;autorité de certification la validité du certificat. Avec OCSP, c\u0026rsquo;est le client lui-même qui fait cette démarche de vérification auprès du CA ; tandis qu\u0026rsquo;avec OCSP Stapling, c\u0026rsquo;est le serveur qui fait cette tâche et qui envoie la réponse OCSP au début de l\u0026rsquo;échange TLS. Bien que ce soit discuté d\u0026rsquo;un point de vue sécurité, les gains apportés par OCSP Stapling pour la vie privée sont non-négligeables, il est donc préférable de l\u0026rsquo;activer. Voyons comment cela se configure avec nginx, d\u0026rsquo;abord les paramètres OCSP Stapling à proprement parler :\nssl_stapling on; ssl_stapling_verify on; resolver 213.133.98.98 213.133.99.99 valid=300s; resolver_timeout 5s; Les deux premières lignes activeront OCSP Stapling. Mais il faut fournir un résolveur DNS à stapling pour qu\u0026rsquo;il puisse fonctionner. On peut fournir plusieurs IPs ou des FQDN pour pointer vers des résolveurs DNS, IPv4 et IPv6. Il faut également fournir à nginx le certificat de la chaîne Let\u0026rsquo;s Encrypt chain.pem dans chaque configuration :\nssl_trusted_certificate /path/to/chain.pem; Une fois que c\u0026rsquo;est fait et nginx redémarré, vous pouvez tester vos paramètres OCSP Stapling sur Qualys SSL. Si OCSP Stapling s\u0026rsquo;affiche en vert avec Yes, c\u0026rsquo;est que logiquement ça fonctionne bien.\nQuant à OCSP Must-Staple, imaginez tout simplement la même problématique qu\u0026rsquo;avec HSTS : au départ, le client n\u0026rsquo;a aucune idée si le serveur supporte HSTS, ou OCSP Stapling. OCSP Must-Staple est la solution pour OCSP Stapling qui a été proposée pour résoudre ce problème. C\u0026rsquo;est une extension à activer dans le certificat, qui indique au client qu\u0026rsquo;il doit être livré en même temps qu\u0026rsquo;une réponse OCSP du serveur, sinon c\u0026rsquo;est niet (donc vérifiez bien, et régulièrement, que vos paramètres fonctionnent\u0026hellip;). Comment faire ? J\u0026rsquo;en ai déjà parlé plus haut, lors de la génération du certificat, quand vous modifiez custom.cnf dans la section [ v3_req ].\nSi vous êtes sur OpenSSL 1.1.0 ou supérieur :\ntlsfeature = status_request Si vous êtes sur OpenSSL 1.0 et inférieur (moins sexy) :\n1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05 Encore une fois vous pouvez vérifier que le flag est bien présent dans votre certificat après un petit tour sur Qualys SSL, ou en regardant les détails du certificat depuis votre navigateur.\nRemarque : Firefox est ici le bon élève puisqu\u0026rsquo;apparemment il supporte bien OCSP Must-Staple. Cependant il se peut que dès le démarrage du serveur web et lors de la première tentative de connexion, Firefox vous colle une belle erreur OCSP : c\u0026rsquo;est normal. En fait, il faut que nginx remplisse son cache OCSP, et c\u0026rsquo;est ce que vous avez fait lors de la première connexion. Une idée toute bête pour contourner ce problème est de faire un script qui va faire la connexion. Vous pouvez même l\u0026rsquo;ajouter dans une entrée cron pour être sûr qu\u0026rsquo;il n\u0026rsquo;y ait aucun problème de ce genre sur le long terme.\nProblème : le cache OCSP ne se remplit pas automatiquement lors du démarrage d\u0026rsquo;nginx et il a besoin de se remplir de temps en temps. \u0026ldquo;Oui, et ?\u0026rdquo; me diriez-vous. Le problème c\u0026rsquo;est que quand le cache doit se remplir sur demande d\u0026rsquo;un client, le client balancera une erreur. Si on rafraîchit la page, hop, l\u0026rsquo;erreur part. C\u0026rsquo;est donc une limitation de OCSP stapling que l\u0026rsquo;on peut contourner avec un script (merci @href pour la piste) à mettre en cron où $domain est le domaine concerné, voici un bout de code pour vous montrer :\n/bin/echo \u0026#34;Q\u0026#34; | /usr/bin/openssl s_client -connect $domain:443 -status \u0026gt; /dev/null 2\u0026gt;\u0026amp;1 pm## 8. HTTP Public Key Pinning (HPKP) HPKP est un autre mécanisme de sécurité, basé sur un header HTTP, qui vise à faire mémoriser au client une liste sûre de clés. Si le CA est compromis et se met à faire de faux certificats pour votre domaine, HPKP s\u0026rsquo;il est bien configuré vous protégera d\u0026rsquo;une MiTM. Vu qu\u0026rsquo;on utilise Let\u0026rsquo;s Encrypt, et avec la méthode que je vous ai fournie pour gérer vos certificats, nous pouvons directement pin la clé publique du leaf certificate. Pourquoi ? Parce que comme je vous l\u0026rsquo;ai dit, on peut désormais utiliser nos propres clés privées donc on peut se passer de la régénération automatique de Let\u0026rsquo;s Encrypt qui rend l\u0026rsquo;usage de HPKP très délicat.\nPrudence. Le problème avec HPKP, c\u0026rsquo;est qu\u0026rsquo;une fois actif chez le client, il le reste pendant la durée max-age fournie dans le header. Si par malheur la clé privée est compromise mais que vous avez pin un seul certificat, pardonnez-moi le terme, mais vous êtes littéralement baisé (et plus concrètement votre site sera inaccessible chez ceux qui auront l\u0026rsquo;ancienne version du header active chez eux). Voilà pourquoi il faut pin plusieurs clés :\nSi la clé privée est compromise, on peut changer de clé. Par mesure de bon sens, il faut parfois rouler les clés. Si l\u0026rsquo;algo est pété, on peut changer sur une autré clé d\u0026rsquo;un autre type d\u0026rsquo;algo. Concrètement, moi, ce que je vous recommande, c\u0026rsquo;est de générer 2 clés P-384 et une clé RSA 4096, et de faire le tutoriel pour créer le certificat ECDSA à partir d\u0026rsquo;une clé P-384 générée.\n# Génération des 3 clés : 2x P-384, 1x RSA-4096 openssl ecparam -genkey -name secp384r1 \u0026gt; privkey_ec_1.pem openssl ecparam -genkey -name secp384r1 \u0026gt; privkey_ec_2.pem openssl genrsa -out privkey_rsa.pem 4096 # Configurez comme indiqué plus haut le custom.cnf cp /etc/ssl/openssl.cnf custom.cnf # Les 3 CSR à générer openssl req -new -sha256 -key privkey_ec_1.pem -out csr_ec_1.der -config custom.cnf openssl req -new -sha256 -key privkey_ec_2.pem -out csr_ec_2.der -config custom.cnf openssl req -new -sha256 -key privkey_rsa.pem -out csr_rsa.der -config custom.cnf # Récupérer les empreintes openssl req -pubkey \u0026lt; csr_ec_1.der | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64 openssl req -pubkey \u0026lt; csr_ec_2.der | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64 openssl req -pubkey \u0026lt; csr_rsa.der | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64 # Génération d\u0026#39;un certificat à partir de la première clé letsencrypt certonly --standalone --agree-tos -m admin@domain.tld \\ --csr /path/to/csr_ec_1.der \\ --cert-path /path/to/cert.pem \\ --chain-path /path/to/chain.pem \\ --fullchain-path /path/to/fullchain.pem Le header Public-Key-Pins est à renseigner avec les 3 empreintes obtenues et un max-age. Pour l\u0026rsquo;instant, et pour commencer, je le mettrais à 2 mois (de toute façon, Chrome limite la validité du header à 60 jours\u0026hellip;) ; libre à vous de monter plus haut ensuite. Il est également possible d\u0026rsquo;appliquer HPKP à tous les sous-domaines une fois actif sur un domaine.\nadd_header Public-Key-Pins \u0026#39;pin-sha256=\u0026#34;empreinte_ec_1\u0026#34;; pin-sha256=\u0026#34;empreinte ec_2\u0026#34;; pin-sha256=\u0026#34;empreinte_rsa\u0026#34;; max-age=5184000; includeSubdomains\u0026#39;; Il va de soit que les clés ne doivent pas être idéalement sur la même machine, car si celle-ci est compromise, ce n\u0026rsquo;est pas une mais les trois clés privées que vous allez perdre. N\u0026rsquo;hésitez pas à rouler les clés, c\u0026rsquo;est-à-dire passer sur la deuxième clé privée puis en générer une nouvelle et l\u0026rsquo;ajouter à HPKP, en virant la première et en laissant la deuxième.\n9. DANE, une alternative à HPKP ?\rDANE pour DNS-based Authentication of Named Entities est un autre mécanisme sécurité, qui a la même finalité que HPKP mais qui repose sur des entrées DNS (des enregistrements TLSA). La condition pour son utilisation est l\u0026rsquo;activation de DNSSEC, sans quoi DANE n\u0026rsquo;a aucun intérêt. Je vais éviter la redite parce que mon ami Hardware a rédigé un billet sur le sujet, n\u0026rsquo;hésitez pas à le consulter.\nLes entrées TLSA se présentent sous cette forme :\nPour extraire l\u0026rsquo;empreinte SHA-256 du fullchain.pem, voici comment :\nopenssl x509 -noout -in fullchain.pem -fingerprint -sha256 | cut -c 20- | sed s/://g | awk \u0026#39;{print tolower($0)}\u0026#39; Puis il \u0026ldquo;suffit\u0026rdquo; d\u0026rsquo;ajouter une entrée TLSA dans votre zone DNS :\n_443._tcp.domain.tld. IN TLSA 3 0 1 EMPREINTE # À faire pour chaque sous-domaine. Du coup si on met le fullchain.pem, il convient de mettre à jour l\u0026rsquo;entrée TLSA à chaque fois qu\u0026rsquo;on crée un nouveau certificat. Personnellement j\u0026rsquo;ai automatisé ça à coups de sed dans mon script de renouvellement, et ça marche bien.\nMalheureusement DANE n\u0026rsquo;est pas présent dans la plupart des clients modernes (même pas Chrome et Firefox), c\u0026rsquo;est pour cela qu\u0026rsquo;il vaut mieux garder HPKP à côté. Pour tester si DANE fonctionne correctement, je vous recommande l\u0026rsquo;utilisation du plugin DNSSEC/TLSA Validator. Vous devriez voir cela :\n10. Certificate Transparency\rCertificate Transparency (CT) est en passe de devenir un standard. L\u0026rsquo;objectif derrière est de rendre public et transparent par les CAs toutes les informations autour de la génération d\u0026rsquo;un certificat. Ainsi, c\u0026rsquo;est une façon de lutter contre l\u0026rsquo;apparition de certificats frauduleux.\nLors de la création du certificat, le CA envoie des informations au log server qui répond avec un SCT (signed certificate timestamp). Ce SCT est soit intégré au certificat, soit présenté au travers d\u0026rsquo;autres moyens : une extension TLS, ou OCSP Stapling. Let\u0026rsquo;s Encrypt est déjà compatible avec certificate transparency, mais il ne présente pas encore de SCT (il est prévu que OCSP Stapling s\u0026rsquo;en occupe d\u0026rsquo;ici la fin d\u0026rsquo;année). Pour le moment on peut donc utiliser une extension TLS, il faudra compiler nginx avec le module nginx-ct. Il ne fonctionnera qu\u0026rsquo;avec une version d\u0026rsquo;OpenSSL assez récente.\nPour obtenir le SCT de fullchain.pem il nous faut utiliser ct-submit.\ngit clone https://github.com/grahamedgecombe/ct-submit --depth=1 cd ct-submit \u0026amp;\u0026amp; go build ./ct-submit ct.googleapis.com/pilot \u0026lt;fullchain.pem\u0026gt;fullchain.sct xxd fullchain.sct # Pour tester 00000000: 00a4 b909 90b4 1858 1487 bb13 a2cc 6770 .......X......gp 00000010: 0a3c 3598 04f9 1bdf b8e3 77cd 0ec8 0ddc .\u0026lt;5.......w..... 00000020: 1000 0001 4bc7 e617 c800 0004 0300 4830 ....K.........H0 00000030: 4602 2100 b9fe e206 f0f5 f600 93d5 e04c F.!............L 00000040: d2fd 75c9 e1fc a5c8 4812 a8b7 bc2c eb0c ..u.....H....,.. 00000050: ee16 1fe9 0221 008a 5974 e1b6 a0e0 281a .....!..Yt....(. 00000060: 61e8 3447 895f 7ad4 2f70 f528 6133 a445 a.4G._z./p.(a3.E 00000070: 4fd4 ab60 ba36 db O..`.6. Je vous suggère ici de créer un fichier ct_domain.tld.conf où l\u0026rsquo;on mettra les paramètres nginx pour servir le SCT.\nssl_ct on; ssl_ct_static_scts /path/to/sct/dir; Normalement nginx devrait servir les SCTs qui sont dans ce dossier. Si jamais ça ne marche pas, il est possible que ce soit dû à une limitation pour laquelle le serveur par défaut doit impérativement servir des SCTs (ajoutez default_server aux directives listen d\u0026rsquo;un vhost d\u0026rsquo;un domaine qui utilise CT). Pour vérifier si Certificate Transparency est opérationnel, Chrome et Qualys SSL feront l\u0026rsquo;affaire.\nA ce fichier de configuration on peut aussi ajouter un header, Expect-CT. Il indique au browser que l\u0026rsquo;on attend l\u0026rsquo;utilisation de Certificate Transparency. Au jour d\u0026rsquo;aujourd\u0026rsquo;hui aucun browser ne l\u0026rsquo;utilise mais ce sera bientôt le cas. Surtout vérifiez bien que Certificate Transparency fonctionne et que les SCTs sont bien servis.\nadd_header Expect-CT \u0026#34;enforce; max-age=86400\u0026#34;; Dans ce cas-ci le browser devrait forcer l\u0026rsquo;utilisation de Certificate Transparency (erreur si pas possible) pendant un jour.\n11. On récapitule ?\rEt c\u0026rsquo;est après, je l\u0026rsquo;espère, vous avoir expliqué en quoi consistent les mécanismes utilisés, que je vais vous fournir les exemples de configuration. À chaque fois qu\u0026rsquo;il y a un domain.tld, c\u0026rsquo;est bien sûr à remplacer par votre domaine. Créons peut-être un dossier /etc/nginx/conf dans lequel on mettra des fichiers de configuration personnalisés, histoire d\u0026rsquo;éviter la redondance plus tard et de pouvoir maintenir plus facilement.\nCréons un fichier tls.conf où l\u0026rsquo;on mettra les paramètres TLS :\nssl_protocols TLSv1.2; ssl_ecdh_curve X25519:P-521:P-384; ssl_ciphers EECDH+CHACHA20:EECDH+AESGCM; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:20m; ssl_session_timeout 15m; ssl_session_tickets off; On désactive les tickets TLS car leur mauvaise implémentation nuit au principe de confidentialité persistance (FS). Les autres directives modifient le cache alloué aux sessions et le timeout d\u0026rsquo;une session, elles sont à adapter selon les capacités de votre serveur et l\u0026rsquo;affluence des connexions.\nUn fichier hsts.conf pour HSTS :\nadd_header Strict-Transport-Security \u0026#34;max-age=31536000; includeSubDomains; preload\u0026#34;; Un fichier hpkp_domain.tld.conf pour HPKP d\u0026rsquo;un domaine :\nadd_header Public-Key-Pins \u0026#39;pin-sha256=\u0026#34;empreinte_ec_1\u0026#34;; pin-sha256=\u0026#34;empreinte ec_2\u0026#34;; pin-sha256=\u0026#34;empreinte_rsa\u0026#34;; max-age=5184000; includeSubdomains\u0026#39;; Un fichier ocsp.conf avec les paramètres OCSP :\nssl_stapling on; ssl_stapling_verify on; resolver 213.133.98.98 213.133.99.99 valid=300s; resolver_timeout 5s; Un fichier headers.conf qui peut être ajouté si l\u0026rsquo;application n\u0026rsquo;ajoute pas déjà ces headers :\nadd_header X-Frame-Options SAMEORIGIN; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection \u0026#34;1; mode=block\u0026#34;; Dans sites-enabled/, on aura notre fichier lambda.conf ainsi construit :\nserver { listen 80; listen [::]:80; server_name domain.tld; return 301 https://$host$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name domain.tld; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; ssl_trusted_certificate /path/to/chain.pem; include /etc/nginx/conf/tls.conf; include /etc/nginx/conf/hsts.conf; include /etc/nginx/conf/headers.conf; include /etc/nginx/conf/ocsp.conf; include /etc/nginx/conf/hpkp_domain.tld.conf; #include /etc/nginx/conf/ct_domain.tld.conf; ... } N\u0026rsquo;oubliez pas de redémarrer nginx une fois les paramètres appliqués, sans oublier un nginx -t avant pour éviter les mauvaises surprises.\nLes tests pour voir si vous avez tout bon :\nQualys SSL (SSL/TLS) : https://www.ssllabs.com/ssltest/ Cryptcheck (SSL/TLS): https://tls.imirhil.fr/ (v2 bientôt) Observatoire Mozilla (SSL/TLS + headers) : https://observatory.mozilla.org DNSSEC Analyzer (DNS) : https://dnssec-debugger.verisignlabs.com/ DANE Checker (DNS) : https://www.huque.com/bin/danecheck Si vous en avez d\u0026rsquo;autres, proposez ! Ce n\u0026rsquo;est pas difficile, et je ne pense pas avoir menti sur la marchandise, il s\u0026rsquo;agit d\u0026rsquo;une excellente configuration HTTPS, peut-être même un peu trop extrémiste. Si la compatibilité est un trop gros problème, appliquez les conseils que j\u0026rsquo;ai disséminés le long de l\u0026rsquo;article.\nArticle rédigé par Wonderfall, vous pouvez le suivre sur Mastodon ou Twitter\n","date":"2017-10-13T00:05:47Z","image":"/images/2017/10/https-2017-wonderfall.png","permalink":"/comment-avoir-une-excellente-configuration-https-en-2017/","title":"Comment avoir une excellente configuration HTTPS en 2017 ?"},{"content":"La nouvelle release 4.0 de Redis est désormais disponible en version stable, cependant si vous souhaitez installer la dernière version de redis-server, il est nécessaire de le compiler.\n==Edit du 10/10/2017 : redis-server est désormais disponible depuis les dépôts officiel pour Ubuntu 16.04 LTS==. Il vous suffit donc de mettre à jour votre liste de dépôts et d\u0026rsquo;installer redis-server via apt :\napt update \u0026amp;\u0026amp; apt install redis-server Nous allons donc voir dans ce tutoriel, comment compiler redis 4.0 et comment le déclarer en tant que service via systemd, sur Ubuntu 16.04 LTS ou Debian 8/9.\nIl nous faut tout d\u0026rsquo;abord installer les paquets nécessaires pour compiler depuis les sources :\napt-get install build-essential apt-get install tcl wget On télécharge ensuite la dernière release depuis le site avant d\u0026rsquo;extraire les fichiers :\nwget http://download.redis.io/releases/redis-4.0.1.tar.gz tar xzf redis-4.0.1.tar.gz cd redis-4.0.1 On commence par nettoyer la configuration\nmake distclean Puis on lance la compilation :\nmake -j $(nproc) Avant d\u0026rsquo;installer redis-server, il est préférable d\u0026rsquo;utiliser make test pour s\u0026rsquo;assurer qu\u0026rsquo;il n\u0026rsquo;y a aucune erreur. Si cette opération se déroule bien, on peut alors installer redis :\nmake install redis-server est désormais installé, mais pour faciliter sa gestion et pour qu\u0026rsquo;il démarre automatiquement nous allons le déclarer en tant que service systemd. Pour cela il suffit d\u0026rsquo;aller dans le dossier utils situé dans le dossier redis-4.0.1, puis d\u0026rsquo;utiliser le script install_server.sh. Vous pourrez alors choisir le nom de votre service redis.\ncd utils ./install_server.sh On peut enfin démarrer redis-server, dont le service se nomme par défaut redis_6379:\nsystemctl start redis_6379 Redis 4.0 est maintenant installé et opérationel sur votre serveur, mais certaines options sont à ajouter dans votre fichier /etc/sysctl.conf pour assurer un bon fonctionnement, notamment la ligne :\nvm.overcommit_memory = 1 Pour appliquer la modification, utilisez la commande sysctl -p. Vous pouvez également utiliser mon fichier de configuration systcl.conf disponible sur mon instance gogs et qui contient la plupart des options pour optimiser les performances de votre serveur et vous protéger de certaines attaques réseaux du type SYN flood :\nwget -O /etc/sysctl.conf https://git.virtubox.net/virtubox/debian-config/raw/master/etc/sysctl.conf sysctl -e -p /etc/sysctl.conf Il peut également être nécessaire de désactiver la fonction transparent hugepage de votre kernel qui a normalement pour but d\u0026rsquo;optimiser la gestion de la mémoire. Cela se fait via la commande :\necho never \u0026gt; /sys/kernel/mm/transparent_hugepage/enabled Enfin, si vous souhaitez optimiser la configuration de redis-server, vous pouvez définir les valeurs suivantes dans /etc/redis/redis.conf\nmaxclients 20000 tcp-backlog 8192 ","date":"2017-09-16T15:32:27Z","image":"/images/2017/09/installer-redis--1-.png","permalink":"/installer-redis-4-ubuntu/","title":"Installer Redis 4.0 sur Ubuntu 16.04 LTS"},{"content":"Si pour mon utilisation personnelle, je préfère configurer moi même un serveur avec nginx pour bénéficier des meilleures performances possibles, il m\u0026rsquo;arrive tout de même régulièrement d\u0026rsquo;installer Plesk Onyx.\nVoici donc un tutoriel pour installer Plesk Onyx sur Ubuntu 16.04 LTS avec une configuration optimisée permettant d\u0026rsquo;avoir un serveur stable, sécurisé et performant.\nOn commence par optimiser un peu la configuration du kernel via le fichier sysctl.conf :\nwget -O /etc/sysctl.conf https://raw.githubusercontent.com/VirtuBox/ubuntu-nginx-web-server/master/etc/sysctl.conf sysctl -p echo never \u0026gt; /sys/kernel/mm/transparent_hugepage/enabled wget -O /etc/security/limits.conf https://raw.githubusercontent.com/VirtuBox/ubuntu-nginx-web-server/master/etc/security/limits.conf Par défaut, Plesk Onyx utilise MySQL 5.7 sur Ubuntu Xenial, mais il est tout à fait possible d\u0026rsquo;utiliser MariaDB 10.1. Il suffit pour cela d\u0026rsquo;installer mariadb-server avant de débuter l\u0026rsquo;installation de Plesk.\nOn ajoute donc le dépôt MariaDB 10.1 :\ncurl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version=10.1 --skip-maxscale Puis on met à jour la liste des dépôts avant d\u0026rsquo;installer MariaDB. Durant l\u0026rsquo;installation, laissez le mot de passe root vide. Il sera automatiquement mis à jour durant l\u0026rsquo;installation de Plesk.\nsudo apt update sudo apt install mariadb-server MariaDB 10.1 est désormais installé sur notre serveur, nous pouvons donc passer à l\u0026rsquo;installation de Plesk en mode personnalisé. Il vous suffit de suivre les étapes pour choisir les composants et les extensions que vous souhaitez installer :\nsh \u0026lt;(curl https://autoinstall.plesk.com/plesk-installer || wget -O - https://autoinstall.plesk.com/plesk-installer) Une fois l\u0026rsquo;installation terminée, n\u0026rsquo;ouvrez pas tout de suite l\u0026rsquo;interface web pour réaliser la configuration initiale. Nous allons tout d\u0026rsquo;abord activer le mode vps_optimized. Ce dernier désactive un bon nombre de modules apache, qui ne sont pas nécessaires sur un VPS.\nplesk bin vps_optimized --turn-on Vous pouvez enfin définir le langage par défaut via la CLI de Plesk :\nplesk bin locales --set-default fr-FR Pour sécuriser notre serveur, nous allons également activer l\u0026rsquo;option pci_compliance, cela va configurer les différents services pour rendre le serveur pci compliant.\nplesk sbin pci_compliance_resolver --enable all Si comme moi, vous pensez qu\u0026rsquo;une clé d\u0026rsquo;échange Diffie-Hellman de 2048 bits est insuffisant, vous pouvez sans problème utiliser une clé ECC.\nIl vous suffira ensuite de modifier la configuration SSL de Nginx, avec une meilleure suite de ciphers, et notre clé Diffie-Hellman :\nnano /etc/nginx/conf.d/ssl Voici le contenu de mon fichier de configuration SSL pour Nginx :\nssl_ciphers \u0026#39;EECDH+AESGCM:EECDH+CHACHA20\u0026#39;; ssl_prefer_server_ciphers on; ssl_protocols TLSv1.2; ssl_ecdh_curve secp384r1; ssl_session_cache shared:SSL:20m; ssl_session_timeout 15m; ssl_session_tickets off; Il vous suffit ensuite de reload nginx pour appliquer les changement :\nnginx -t \u0026amp;\u0026amp; service nginx reload Après avoir optimiser la configuration Nginx, nous pouvons passer à Apache. Pour cette partie, je me contente de modifier le fichier /etc/apache2/conf-enabled/security.conf et d\u0026rsquo;y ajouter les headers suivants :\nHeader set X-Content-Type-Options: \u0026#34;nosniff\u0026#34; Header set X-Frame-Options: \u0026#34;sameorigin\u0026#34; Header set Referrer-Policy \u0026#34;strict-origin-when-cross-origin\u0026#34; Header set x-xss-protection \u0026#34;1; mode=block\u0026#34; On relance Apache via la commande service apache2 restart\nVous pouvez désormais vous connecter à l\u0026rsquo;interface Plesk via l\u0026rsquo;adresse affichée après l\u0026rsquo;installation. Vous pouvez à tout moment générer une autre adresse de connexion avec la commande plesk login.\nSi vous souhaitez modifier la configuration générale de Plesk, cela est faisable en utilisant l\u0026rsquo;extension Panel.ini editor, ou en modifiant directement le fichier /usr/local/psa/admin/conf/panel.ini. L\u0026rsquo;extension vous permet de définir depuis l\u0026rsquo;interface web vos propre variables pour les options Plesk, ainsi que pour les extensions. Par exemple, pour que l\u0026rsquo;extension let\u0026rsquo;s encrypt utilise des clés RSA de 4096 bits plutôt que de 2048 bits, il vous suffit d\u0026rsquo;ajouter au fichier panel.ini (via le fichier ou via l\u0026rsquo;extension dans la partie editor), les lignes suivantes :\n[ext-letsencrypt] renew-before-expiration = 45 rsa-key-size = 4096 Vous pouvez également désactivé les publicités pour certaines extensions, et les propositions de certificats SSL Symantec en ajoutant les lignes suivantes :\n[ext-security-advisor] promoteSymantec = false [ext-catalog] contextAds = off Vous pouvez appliquer ces configurations en téléchargeant directement mon ficher panel.ini\nwget https://raw.githubusercontent.com/VirtuBox/ubuntu-plesk-onyx/master/usr/local/psa/admin/conf/panel.ini -O /usr/local/psa/admin/conf/panel.ini Il est même possible d\u0026rsquo;aller plus loin avec Plesk Onyx, puisque vous pouvez compiler Nginx avec les modules de votre choix afin de remplacer le paquet installé par Plesk.\nEdit du 11/12/2017 :\nJe propose désormais un script bash pour compiler la dernière release mainline de Nginx (v1.13.8) avec certains modules tel que Brotli, support de TLS 1.3, dynamic-tls-records-patch, pagespeed etc \u0026hellip;\nLe script est pour le moment mis à jour uniquement pour Plesk Onyx sur Ubuntu 16.04 LTS, vous pouvez trouver toutes les informations sur mon dépôt Github.\nN\u0026rsquo;hésitez pas à ouvrir une Issue sur Github si vous rencontrez des erreurs durant la compilation.\n","date":"2017-09-15T18:53:00Z","image":"/images/2017/09/Installer-Plesk-Onyx--4-.png","permalink":"/installer-plesk-onyx-ubuntu-16-optimiser/","title":"Installer Plesk Onyx sur Ubuntu 16.04 LTS et optimiser la configuration"},{"content":"Ghost à publié sa nouvelle release 1.0, qui introduit également l\u0026rsquo;outil ghost-cli permettant d\u0026rsquo;installer ghost, de le mettre à jour et d\u0026rsquo;intéragir plus facilement avec la plateforme.\nLe thème de base \u0026ldquo;casper\u0026rdquo; a également été mis à jour, et je trouve le nouveau design absolument génial, bien que j\u0026rsquo;ai effectué certaines modifications dans les styles, notamment concernant la dimensions des images.\nJe n\u0026rsquo;ai donc pas hésité trop longtemps, car je trouvais déjà que Ghost était une solution très intéressante pour écrire des articles, sans avoir pour autant à ajouter des dizaines de plugins comme sur wordpress.\nJe vais donc expliquer dans cet article comment installer Ghost via l\u0026rsquo;outil ghost-cli, et comment réaliser la migration depuis WordPress.\nPour résumer les fonctionnalités principales de Ghost :\nArticles en markdown Organisation des articles par tags Support natif des meta datas Support natif de l\u0026rsquo;AMP Application Desktop De quoi avons nous besoin ?\nUn VPS avec Ubuntu 16.04 LTS Un serveur MySQL NGINX Node v6 Un utilisateur avec sudo Installation des pré-requis\rOn commence par créer un utilisateur et lui donner les droits sudo, puis on se connecte via cet utilisateur. Cet utilisateur ne doit pas s\u0026rsquo;appeller ghost, car l\u0026rsquo;utilisateur ghost sera automatiquement ajouté par ghost-cli\nadduser --disabled-password --disabled-login monghost usermod -aG sudo monghost su - monghost On met à jour la liste des paquets et le serveur\nsudo apt-get update sudo apt-get upgrade On installe la dernière release de nginx\nwget -O - https://nginx.org/keys/nginx_signing.key | sudo apt-key add - sudo echo \u0026#34;deb http://nginx.org/packages/ubuntu/ $(lsb_release -sc) nginx\u0026#34; \u0026gt; /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install nginx On installe MariaDB 10.3\ncurl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \\ | sudo bash -s -- --mariadb-server-version=10.3 --skip-maxscale sudo apt update \u0026amp;\u0026amp; sudo apt install mariadb-server On installe nodejs v8 LTS\ncurl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash sudo apt-get install -y nodejs Installation de Ghost\rOn commence par installer ghost-cli\nsudo npm i -g ghost-cli Puis on créer le répertoire pour notre blog\nsudo mkdir -p /var/www/ghost sudo chown monghost:monghost /var/www/ghost cd /var/www/ghost Et on peut enfin lancer l\u0026rsquo;installation de Ghost, qui est totalement interactive et qui va :\nConfigurer la base de donnée Installer la dernière version de Ghost Configurer Ghost Configurer Nginx et installer un certificat SSL avec Let\u0026rsquo;s Encrypt Déclarer Ghost en tant que service via systemd Vous avez le choix pour chacune des étapes, de le faire via ghost-cli ou manuellement. Dans le cas de Nginx par exemple, si vous utiliser une configuration particulière, il sera préférable d\u0026rsquo;ajouter votre vhost manuellement.\nOn lance donc l\u0026rsquo;installation avec :\nghost install configuration de nginx\rPour la configuration de Nginx, pour des performances optimales, j\u0026rsquo;utilise personnellement la fonctionnalité proxy-cache d\u0026rsquo;Nginx pour mettre en cache les pages du blog, cette technique est également appelée micro-caching puisque le délai d\u0026rsquo;expiration du cache est relative court mais autorise par contre Nginx à utiliser les fichiers en cache dans le cas ou l\u0026rsquo;upstream (le serveur nodejs Ghost dans ce cas) est indisponible.\nPour cela je commence par créer un répertoire pour stocker le cache nginx :\nsudo mkdir -p /var/cache/nginx/static sudo chown -R www-data:www-data /var/cache/nginx Je peux ensuite créer mon vhost et définir le stockage du cache dans ce répertoire\nproxy_cache_path /var/cache/nginx/static levels=1:2 keys_zone=GHOST:75m inactive=24h max_size=512m; server { # redirection du http vers https listen 80; listen [::]:80; server_name votredomain.tld www.votredomain.tld; return 301 https://votredomain.tld$request_uri; } server { # redirection du www vers non-www server_name www.votredomain.tld listen 443 ssl http2; listen [::]:443 ssl http2; ssl on; ssl_certificate /etc/letsencrypt/live/votredomaine.tld/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/votredomaine.tld/key.pem; ssl_trusted_certificate /etc/letsencrypt/live/votredomaine.tld/cert.pem; return 301 https://votredomain.tld$request_uri; } server { server_name votredomain.tld; root /var/www/votredomain.tld/system/nginx-root; listen 443 ssl http2; listen [::]:443 ssl http2; ssl on; ssl_certificate /etc/letsencrypt/live/votredomaine.tld/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/votredomaine.tld/key.pem; ssl_trusted_certificate /etc/letsencrypt/live/votredomaine.tld/cert.pem; access_log /var/log/nginx/votredomaine.tld.access.log; error_log /var/log/nginx/votredomaine.tld.error.log; location / { proxy_cache STATIC; proxy_cache_valid 200 5m; proxy_cache_valid 404 1m; proxy_cache_key \u0026#34;$scheme$request_method$host$request_uri\u0026#34;; proxy_cache_use_stale http_500 http_502 http_503 http_504 http_403 http_404 updating; proxy_cache_background_update on; proxy_ignore_headers X-Accel-Expires Expires Cache-Control; proxy_ignore_headers Set-Cookie; proxy_hide_header Set-Cookie; proxy_hide_header X-powered-by; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; proxy_pass http://127.0.0.1:2368; } location ~ ^/(?:ghost|signout) { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; proxy_pass http://127.0.0.1:2368; add_header Cache-Control \u0026#34;no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0\u0026#34;; } location /content/images { alias /var/wwww/votredomaine.tld/content/images; access_log off; expires max; } location /assets { alias /var/wwww/votredomaine.tld/content/themes/casper/assets; access_log off; expires 30d; } client_max_body_size 50m; } Pour installer le certificat SSL, j\u0026rsquo;utilise actuellement acme.sh, un client Acme écrit en bash que je trouve plus facile à utiliser que certbot, notamment pour la mise en place des renouvellement automatique.\nJe vous met le lien de mon article qui explique comment installer acme.sh et comment générer un certificat SSL : Installer un certificat SSL Let\u0026rsquo;s Encrypt avec Acme.sh\nMettre à jour Ghost\rLà aussi, la nouvelle CLI de Ghost facilite vraiment le processus de mise à jour, puisqu\u0026rsquo;il suffit de se rendre dans le dossier de votre blog en tant que l\u0026rsquo;utilisateur définit pour utiliser la CLI puis d\u0026rsquo;utiliser ghost update\nsu - monghost cd /var/www/ghost ghost update Migrer depuis WordPress\rPour migrer depuis WordPress, il faut tout d\u0026rsquo;abord extraire votre contenu au format .json en utilisant le plugin officiel publié par Ghost. Il est disponible dans l\u0026rsquo;annuaire de plugins WordPress\nAprès avoir extrait votre contenu, vous pourrez l\u0026rsquo;importer dans Ghost, il est restera cependant quelques tâches à réaliser manuellement :\nLes images devront être importées manuellement ou hébergées sur un hébergeur externe Les commentaires devront être importés sur une plateforme comme Disqus ou sur une solution self-hosted comme Isso Les méta-data de vos articles devront être ajoutées manuellement, l\u0026rsquo;importateur Ghost ne traite que le contenu des articles et les tags Je vais traiter dans un prochain article comment installer Isso pour héberger l\u0026rsquo;ensemble de vos commentaires et ne pas avoir à utiliser une solution comme disqus.\n","date":"2017-08-28T14:24:14Z","image":"/images/2018/07/Sans-titre.jpg","permalink":"/ghost-deploiement-ghost-cli-migration-wordpress/","title":"Ghost 1.0 - Installer Ghost avec ghost-cli et Nginx - Migrer depuis wordpress"},{"content":"Il n’est pas toujours facile de mettre en place un serveur mail, notamment si lorsque l’on souhaite utiliser l’ensemble des protocoles qui assurent l’authentification des emails tel que SPF, DKIM et DMARC. C’est pourquoi je vais vous présenter dans ce tutoriel une solution pour installer un serveur mail sécurisé et stable avec mail-in-a-box.\nArticle mis à jour le 29/07/2019\nPourquoi mail-in-a-box ?\rJ’ai testé de nombreuses autres solutions dont notamment Modoboa, Mailcow ou encore iRedMail, et mail-in-a-box est d’après moi la solution la plus simple à déployer, elle propose l’ensemble des fonctionnalités requises pour avoir un serveur mail stable, sécurisé et dispose d\u0026rsquo;un système de backup.\nLes principales fonctionnalités sont :\nServeur Mail supportant les protocoles : SPF, DKIM \u0026amp; DMARC Serveur DNS avec DNSSEC Certificats SSL/TLS Let’s Encrypt Webmail Roundcube Gestion et synchronisation des contacts \u0026amp; calendrier via OwnCloud Backup local, Amazon S3 ou via Rsync Statud check hebdomadaire incluant le blacklisting de l’IP du serveur Installer mail-in-a-box\rPré-requis :\n– Un VPS avec Ubuntu 18.04 LTS et 2Go de RAM – Un nom de domaine – Se connecter au serveur distant avec des clés SSH\nOn passe à l’installation :\ncurl -s https://mailinabox.email/setup.sh | sudo bash Lors de l’installation, choisissez le hostname de votre serveur en utilisant un sous-domaine. Par défaut mail-in-a-box utilisera box.votredomaine.com\nDéfinissez ensuite la première adresse email que vous souhaitez créer, ce sera également votre nom d’utilisateur pour accéder à l’interface d’administration\nSélectionnez votre zone géographique pour mettre à jour le serveur de temps puis validez.\nSélectionnez ensuite la ville correspondant à votre fuseau horaire, dans mon cas Paris.\nUne fois l’installation terminée, vous pourrez accéder au panel d’administration via l’adresse : https://IP-de-Votre-Serveur/admin\nConfigurer le serveur mail\rVous avez ensuite le choix d’utiliser la box pour gérer vos DNS ou non. En effet Mail-in-a-box inclut un serveur DNS qui mettra en place automatiquement l’ensemble des enregistrements DNS nécessaires pour utiliser le serveur en tant que serveur mail pour votre domaine.\nCependant, vous pouvez très bien utiliser un service DNS externe et il vous suffira dans ce cas de vous rendre sur la page System \u0026gt; External DNS pour obtenir un listing complet des enregistrements DNS. Il vous faudra alors copier ces enregistrements du côté de votre registar pour utiliser la box en tant que serveur mail.\nLes enregistrements nécessaires pour utiliser la box en tant que serveur mail sont :\nvotredomaine.com MX(10) \u0026quot;box.votredomaine.com\u0026quot; : pour définir la box en tant que serveur mail principal\nvotredomaine.com TXT \u0026quot;v=spf1 a:box.votredomaine.com -all\u0026quot; : pour spécifier que la box est le seul serveur autorisé à envoyer des emails pour ce domaine\n_dmarc.votredomaine.com TXT \u0026quot;v=DMARC1; p=quarantine\u0026quot; : pour indiquer que les emails ne respectant pas les règles DKIM ou SPF doivent être envoyé en quarantaine.\nmail._domainkey.votredomaine.com TXT \u0026quot;v=DKIM1; k=rsa; s=email; p=la-signature-très-longue-pour-le-dkim\u0026quot; : qui correspond à la signature DKIM utilisée pour signer les emails sortant de votre serveur.\nMail-in-a-box ajoute également les enregistrements associés au sous domaine www pour éviter que des emails soient envoyés via www.votredomaine.tld. Ils sont facultatifs mais cela ne coûte rien de les mettre en place.\nUne fois les enregistrements DNS configurés pour le domaine de votre box, vous pourrez aller dans l’onglet System TLS (SSL) Certificates, et installer un certificat SSL Let’s Encrypt pour sécuriser votre serveur web et mail.\nUne fois le processus terminé, vous pourrez accéder à l’interface d’administration via l’adresse : https://box.votredomaine.com/admin\nN’oubliez pas également de définir le reverse-DNS sur l’IP du serveur. Cela se fait via le panel de gestion de votre VPS et nécessite que l’enregistrement DNS associé soit existant. Dans cet exemple, le reverse DNS à spécifié sur l’IP du serveur est box.vtbox.xyz\nConnecter un client mail\rPour connecter vos clients mail, l’adresse pour les services pop/imap et smtp sera box.votredomaine.com. Les ports à utiliser pour se connecter avec SSL/TLS sont :\nIMAP : 993 avec SSL/TLS\nPOP : 995 avec SSL/TLS\nSMTP : 587 avec TLS\nAjouter un domaine\rPour ajouter un domaine, il vous suffit d’aller dans l’onglet Mail \u0026gt; Users et d’ajouter une adresse email utilisant un autre domaine que celui de votre box.\nMail-in-a-box mettra automatiquement en place les enregistrements DNS associés et vous n’aurez alors qu’à modifier les nameservers du nouveau domaine, ou les retrouver dans l’onglet External DNS si vous souhaitez les copier via votre registar.\nMettre à jour mail-in-a-box\rPour la mise à jour de votre serveur mail, rien de plus simple, puisqu\u0026rsquo;il vous suffit d\u0026rsquo;utiliser à nouveau la commande d\u0026rsquo;installation :\ncurl -s https://mailinabox.email/setup.sh | sudo bash Backup \u0026amp; Migration\rLe processus de backup de mail-in-a-box est relativement simple, puisque par défaut les backups sont stockés dans le répertoire /home/user-data/backup. Dans ce répertoire, vous trouverez un fichier secret_key.txt qui contient la clé privée utilisée pour chiffrer les sauvegardes stockées dans le répertoire encrypted.\nPour migrer ou restaurer un serveur depuis un sauvegarde, il vous suffit de réinstaller mail-in-a-box sur un serveur, avant de transférer le dernier backup dont vous disposez ainsi que la clé privée.\nVous pourrez ensuite restaurer les données en utilisant l\u0026rsquo;outil duplicity :\nexport PASSPHRASE=$(cat your_backup_secret_key_file.txt) sudo -E duplicity restore --force file:///emplacement/des/backup /home/user-data/ Il suffira ensuite d\u0026rsquo;utiliser la commande mailinabox pour appliquer à nouveau la configuration du serveur :\nsudo mailinabox ","date":"2017-07-08T14:07:30Z","image":"/images/2019/07/mailinabox.jpg","permalink":"/mettre-place-serveur-mail-mail-in-a-box/","title":"Mettre en place un serveur mail avec mail-in-a-box sur Ubuntu 18.04 LTS"},{"content":"Il s’agit peut-être de la fonctionnalité la plus intéressante avec Cloudflare, la possibilité d’installer un certificat SSL fournit par Cloudflare sur votre serveur web. Cela permet de chiffrer les connexions entre votre serveur et les serveurs de Cloudflare, et vous pouvez générer un certificat valide pour 15 ans, soit largement plus que les 90 jours d’un certificat Let’s Encrypt.\nGénérer un certificat ainsi qu’une clé privée avec Cloudflare\rPour commencer, vous devez vous rendre dans la partie “Crypto” du domaine pour lequel vous souhaitez générer un certificat. Vous trouverez alors la section Origin Certificates dans laquelle nous allons pouvoir générer notre certificat SSL ainsi que notre clé privée.\nVous pouvez donc cliquer comme dans l’exemple ci-dessous sur le bouton Create Certificate.\nVous pouvez si vous le souhaitez générer une requête de Certificat nommé CSR (Certificate Signing Request) ainsi qu\u0026rsquo;une clé privée, ou laisser Cloudflare le faire pour vous. Par contre il préférable de choisir un certificat de type ECDSA plutôt que RSA, aussi bien pour les performances, que pour la sécurité.\nVous allez alors obtenir votre certificat ainsi que votre clé privée.\nCopiez tout d\u0026rsquo;abord la clé dans un fichier votredomaine-key.pem, à conserver précieusement car vous ne pourrez pas la télécharger à nouveau depuis Cloudflare.\nCopiez ensuite le certificat SSL dans un deuxième fichier que nous allons nommer votredomaine-crt.pem. Et placez les deux fichiers dans un dossier votre choix, par exemple un dossier nommé ssl dans /etc/nginx.\nCependant avant de pouvoir ajouter le certificat dans la configuration Nginx, il faut ajouter la signature de l’autorité de certification dans le même fichier que notre certificat. Pour cela nous allons télécharger le certificat root de Cloudflare et le fusionner avec notre certificat :\nwget wget https://support.cloudflare.com/hc/en-us/article_attachments/206709098/cloudflare_origin_ecc.pem cat votredomaine-crt.pem cloudflare_origin_ecc.pem \u0026gt; votredomaine-fullchain.pem Installer le certificat avec nginx\rPour utiliser ce certificat dans votre configuration nginx, il vous suffit d’ajouter les lignes suivantes à votre bloc server :\nlisten 443 ssl http2; listen [::]:443 ssl http2; ssl on; ssl_certificate /etc/nginx/ssl/votredomaine-fullchain.pem; ssl_certificate_key /etc/nginx/ssl/votredomaine-key.pem; Vous pouvez vérifier que tout est correct avant t d’appliquer la configuration en utilisant nginx -t. Si il n\u0026rsquo;y a aucune erreur, vous pouvez alors utiliser service nginx reload\nVous pouvez alors changer le niveau SSL de votre domaine en Full (strict) via l’interface Cloudflare :\nAllez plus loin avec les Authenticated Origin Pulls\rNous pouvons même aller plus loin et mettre en place un certificat pour authentifié notre serveur. Ce service est nommé “Authenticated Origin Pulls” dans le panel Cloudflare et permet d’éviter que des requêtes soient faites à votre serveur sans passer par le proxy Cloudflare.\nPour le mettre en place il nous suffit de télécharger le certificat suivant :\nwget -O /etc/nginx/ssl/origin-pull-ca.pem https://support.cloudflare.com/hc/en-us/article_attachments/201243967/origin-pull-ca.pem Et de l’inclure dans notre configuration nginx :\nssl_client_certificate /etc/nginx/ssl/origin-pull-ca.pem; ssl_verify_client on; Nous pouvons alors activer depuis l’interface Cloudflare la fonctionnalité Authenticated Origin Pulls.\n","date":"2017-04-20T22:15:57Z","image":"/images/2018/07/cloudflare-origin.jpg","permalink":"/installer-un-certificat-ssl-cloudflare-origin-avec-nginx/","title":"Installer un certificat SSL Cloudflare Origin avec Nginx"},{"content":"Si vous utilisez comme moi EasyEngine/WordOps sur votre serveur, vous souhaitez peut-être proposer un accès via ftp, tout en limitant l’accès aux fichiers d’un site web pour chaque utilisateur.\nPour cela, nous allons installer et configurer proftpd afin que chaque utilisateur ne puisse accéder qu\u0026rsquo;à son répertoire, sans causer de problèmes de permissions sur les fichiers d\u0026rsquo;un site. Enfin nous mettrons en place un certificat SSL pour chiffrer les échanges avec le serveur distant.\nInstallation de profpd\rOn commence par installer proftpd :\napt-get update \u0026amp;\u0026amp; apt-get install proftpd Puis on modifie la configuration de proftpd :\nnano /etc/proftpd/proftpd.conf Pour empêcher les utilisateurs de remonter dans l\u0026rsquo;arboresence des fichiers du serveur, il faut de décommenter la ligne suivante en supprimant le # :\nDefaultRoot ~ Il est également préférable décommenter l\u0026rsquo;option RequireValidShell afin de pouvoir ajouter des utilisateurs sans accès ssh :\nRequireValidShell off Enfin, si vous utilisez un pare-feu sur votre serveur, il est nécessaire de décommenter la ligne PassivePorts en définissant une intervalle de ports. Dans mon exemple, j\u0026rsquo;ai choisi d\u0026rsquo;utiliser les ports 49000 à 50000 pour les connexions FTP passives :\nPassivePorts 49000 50000 Il suffit ensuite d\u0026rsquo;autoriser ces ports dans votre pare-feu. Si vous utilisez UFW, il suffit d\u0026rsquo;utiliser la commande :\nufw allow 49000:50000/tcp On redémarre ensuite proftpd pour appliquer les modifications :\nservice proftpd restart Ajouter un utilisateur\rPour ajouter un utilisateur, il faut définir son dossier home qui correspond au dossier du site web concerné, et l’ajouter au groupe www-data pour qu’il n’y ai pas de problème au niveau des permissions. Remplacez dans la commande suivante le dossier utilisé après \u0026ndash;home et le nom de l\u0026rsquo;utilisateur :\nadduser --home /var/www/votredomaine.tld/ --shell /bin/false --ingroup www-data votre-utilisateur La commande précédente inclut la directive \u0026ndash;shell /bin/false, interdisant ainsi l\u0026rsquo;accès au shell pour le nouvel utilisateur puisque nous avons précédemment définit que l\u0026rsquo;utilisation du serveur FTP ne nécessitait pas un accès valide au shell.\nEnfin pour ajouter les permissions au groupe sur un dossier on utilise :\nchmod -R g+rw /var/www/domainname Votre utilisateur pourra ainsi ajouter ou supprimer des fichiers en se connectant via un client ftp, mais il ne pourra pas accéder à d\u0026rsquo;autres fichiers que ceux présents dans son répertoire \u0026ndash;home et il ne pourra pas se connecter au serveur en SSH.\nConfiguration TLS\rPour les transferts de fichiers sur internet, le chiffrement, c\u0026rsquo;est mieux avec. Nous allons donc voir comment configurer proftpd pour en faire un serveur FTPS.\nAvec un certificat auto-signé\rUn certificat auto-signé n\u0026rsquo;apparaîtra peut-être pas comme valide, mais vous permettra de bénéficier du chiffrement autant qu\u0026rsquo;un certificat issue d\u0026rsquo;une authorité de certificats.\nOn commence par créer un répertoire pour stocker notre certificat :\nmkdir /etc/proftpd/ssl Puis on génère à l\u0026rsquo;aide d\u0026rsquo;OpenSSL notre certificat :\nopenssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem Voici le déroulement de la procédure :\nroot@vps~# openssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem Generating a 2048 bit RSA private key .................+++ ..............+++ writing new private key to \u0026#39;/etc/proftpd/ssl/proftpd.key.pem\u0026#39; ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter \u0026#39;.\u0026#39;, the field will be left blank. ----- Country Name (2 letter code) [AU]:FR State or Province Name (full name) [Some-State]:- Locality Name (eg, city) []: Paris Organization Name (eg, company) [Internet Widgits Pty Ltd]: VirtuBox Organizational Unit Name (eg, section) []:IT Common Name (e.g. server FQDN or YOUR name) []:server.virtubox.net Email Address []:admin@virtubox.net On s\u0026rsquo;assure ensuite de définir des permissions correctes sur le certificat et la clé privée :\nchmod 600 /etc/proftpd/ssl/proftpd.* Et on peut alors éditer le fichier /etc/proftpd/tls.conf dont le contenu devra ressembler à :\nTLSEngine on TLSLog /var/log/proftpd/tls.log TLSProtocol TLSv1.2 TLSCipherSuite AES128+EECDH:AES128+EDH TLSOptions NoCertRequest AllowClientRenegotiations NoSessionReuseRequired TLSRSACertificateFile /etc/proftpd/ssl/proftpd.cert.pem TLSRSACertificateKeyFile /etc/proftpd/ssl/proftpd.key.pem TLSVerifyClient off TLSRequired on RequireValidShell no \u0026lt;/IfModule\u0026gt; Une fois les modifications enregistrées, il vous suffit de décommenter la ligne\nInclude /etc/proftpd/tls.conf dans le fichier /etc/proftpd/protftpd.conf\nVous pouvez ensuite relancer le service proftpd pour appliqer la nouvelle configuration.\nsudo service proftpd restart ","date":"2017-04-16T17:20:02Z","image":"/images/2019/04/Copie-de-Mettre-en-place-un-VPN-mesh-avec-tinc-sur-Debian_Ubuntu---Raspbian.png","permalink":"/installer-serveur-ftp-plusieurs-utilisateurs-proftpd/","title":"Installer et configurer proftpd en serveur FTP avec TLS"},{"content":"Pourquoi migrer mon instance Mastodon ?\rUne semaine après l’installation de ma première instance Mastodon, il est déjà temps de migrer. Mais la raison n’est pas le besoin de plus de ressources pour l’instance.\nNon, c’est plutôt que je n’était pas totalement satisfait de ma première installation, et que je rencontrais certains bugs récurrents dont je ne trouvais pas la source. Donc je me suis dit, autant refaire une installation propre maintenant que je connais bien l’outil. Premier point, je suis passé de Ubuntu 16.04 LTS à Debian 8.7, principalement pour bénéficier des packages de dotdeb.org dont notamment redis-server en v3.2.8 contre v3.0.6 sur Ubuntu. Et pour simplifier un petit peu l’installation, j’ai utilisé EasyEngine pour mettre en place nginx et redis. Le principal avantage de EasyEngine est qu’il permet d’organiser très proprement les fichiers de configuration de Nginx avec une nomenclature claire et simple. Je suis également passer de Cloudflare à Let’s Encrypt notamment pour bénéficier d’un meilleur chiffrement et de plus d’options sur les headers Nginx.\nPréparer le nouveau serveur\rPour la migration il vous faut exporter la base de donnée postgresql et faire une copie du dossier /home/mastodon. Pour cela il faudra arrêter tous les services de mastodon et avoir préalablement préparé le nouveau serveur. Pour cela commençons par réinstaller ce qui est nécessaire pour Mastodon.\nInstallation des dépendances\necho \u0026#34;deb http://ftp.debian.org/debian jessie-backports main\u0026#34; \u0026gt;\u0026gt; /etc/apt/sources.list apt-get update apt-get install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev nodejs file git curl Installation de NodeJS\ncurl -sL https://deb.nodesource.com/setup_4.x | bash - apt-get install nodejs npm install -g yarn Installation de PostgreSQL (en v9.6 via les backports) et création de l’utilisateur mastodon, avec un mot de passe et de la base de donnée mastodon_production\napt-get -t jessie-backports install postgresql postgresql-contrib su - postgre psql CREATE USER mastodon CREATEDB; ALTER USER \u0026#34;mastodon\u0026#34; WITH PASSWORD \u0026#39;new_password\u0026#39;; CREATE DATABASE mastodon_production OWNER mastodon; \\q exit Pour l’installation de Nginx et Redis, comme dit précédemment, j’ai utilisé EasyEngine, on installe donc d’abord EE :\nwget -qO ee rt.cx/ee \u0026amp;\u0026amp; bash ee\nEt on installe Nginx et Redis :\nee stack install --nginx --redis\nInstallation des dépendances pour Ruby :\napt-get install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev\nadduser --disabled-password --disabled-login mastodon git clone https://github.com/rbenv/rbenv.git ~/.rbenv echo \u0026#39;export PATH=\u0026#34;$HOME/.rbenv/bin:$PATH\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.bashrc echo \u0026#39;eval \u0026#34;$(rbenv init -)\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.bashrc source ~/.bashrc Il faut alors se déconnecter puis se reconnecter en tant que mastodon pour appliquer les modifications faites au bash\nexit su - mastodon On installe ruby-build\ngit clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build\nPuis on installe Ruby, en version 2.4.1 désormais\nrbenv install 2.4.1 rbenv global 2.4.1 On peut désormais remettre en place la configuration de Nginx avant de commencer la migration. Mise en place des services :\nwget https://git.virtubox.net/virtubox/mastodon/raw/master/services/mastodon-web.service -O /etc/systemd/system/mastodon-web.service wget https://git.virtubox.net/virtubox/mastodon/raw/master/services/mastodon-streaming.service -O /etc/systemd/system/mastodon-streaming.service wget https://git.virtubox.net/virtubox/mastodon/raw/master/services/mastodon-sidekiq.service -O /etc/systemd/system/mastodon-sidekiq.service Pour créer le virtualhost avec EasyEngine :\nee site create votredomaine.com\nVous pouvez ensuite editer /etc/nginx/sites-availables/votredomaine.com, en se basant sur le modèle d’Angristan\nmap $http_upgrade $connection_upgrade { default upgrade; \u0026#39;\u0026#39; close; } # redirection http vers https server { listen 80; listen [::]:80; server_name www.votredomaine.com votredomaine.com; return 301 https://votredomaine.com$request_uri; access_log /dev/null; error_log /dev/null; } # block https server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name www.votredomaine.com votredomaine.com; if ($host = www.votredomaine.com) { return 301 https://votredomaine.com$request_uri; } access_log /var/log/nginx/votredomaine.com-access.log; error_log /var/log/nginx/votredomaine.com-error.log; # configuration ssl avec letsencrypt ssl_certificate /etc/letsencrypt/live/votredomaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/votredomaine.com/privkey.pem;; ssl_protocols TLSv1.2; ssl_ciphers EECDH+AESGCM:EECDH+CHACHA20:EECDH+AES; ssl_prefer_server_ciphers on; # ajout des headers pour le HSTS, CSP et Referrer-Policy add_header Strict-Transport-Security \u0026#34;max-age=15552000; includeSubDomains; preload\u0026#34;; add_header Content-Security-Policy \u0026#34;default-src \u0026#39;self\u0026#39;; style-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39;; script-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39;; img-src \u0026#39;self\u0026#39; data:; connect-src \u0026#39;self\u0026#39; wss://votredomaine.com;\u0026#34;; add_header Referrer-Policy \u0026#34;strict-origin-when-cross-origin\u0026#34;; keepalive_timeout 70; sendfile on; client_max_body_size 0; gzip off; root /home/mastodon/live/public; location / { try_files $uri @proxy; } location @proxy { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_pass_header Server; proxy_pass http://127.0.0.1:3000; proxy_buffering off; proxy_redirect off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; tcp_nodelay on; } location /api/v1/streaming { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_pass http://127.0.0.1:4000; proxy_buffering off; proxy_redirect off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; tcp_nodelay on; } error_page 500 501 502 503 504 /500.html; } Transfert des données depuis l’ancien serveur\rA partir de là, cette fois on ne clone pas le dépôt Github puisque l’on veut réutiliser l’installation précédente. Pour réaliser la copie depuis le serveur précédent, il faut tout d’abord arrêter les services de mastodon sur l’ancien serveur:\nsystemctl stop mastodon* redis\nOn dump ensuite l’ancienne base de donnée :\npg_dump mastodon_production \u0026gt; fichier_de_sortie\nPour les fichier, j’ai simplement zippé le dossier /home/mastodon avant de le transférer sur le nouveau serveur avec scp.\nzip backupmaston -r /home/mastodon\nPourquoi ne pas utiliser rsync ? Car lors de l’extraction du zip, il est facile de ne pas écraser les fichiers déjà présent, notamment pour rbenv et rbenv-build en utilisant “N” lorsque le programme unzip nous demande ce que l’on souhaite faire. Pour importer la base de donnée après le transfert sur le nouveau serveur :\nsu - postgre psql mastodon_production \u0026lt; fichier_d_entree exit Ne pas oublier après le transfert de vérifier les propriétaires des fichiers dans /home/mastodon, ne pas hésiter à faire :\nchown -R mastodon:mastodon /home/mastodon\nIl faut également penser à copier votre certificat Let’s Encrypt\nRelancer mastodon après le transfert\rNe pas oublier de modifier le fichier .env.production avec le mot de passe postgreSQL notamment. Pour relancer mastodon, cela se déroule comme une mise à jour si ce n’est que l’on installe bundler\nsu - mastodon cd live gem install bundler --no-ri git fetch git pull git checkout $(git tag | tail -n 1) bundle install --deployment --without development test NODE_ENV=production npm upgrade --global yarn yarn install RAILS_ENV=production bundle exec rails assets:clean RAILS_ENV=production bundle exec rails assets:precompile RAILS_ENV=production bundle exec rails db:migrate exit Puis activer et démarrer les services :\nsystemctl enable /etc/systemd/system/mastodon-*.service systemctl start mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service Mise en place des crons\ncrontab -e -u mastodon\nEt ajouter les lignes\nRAILS_ENV=production @daily cd /home/mastodon/live \u0026amp;\u0026amp; /home/mastodon/.rbenv/shims/bundle exec rake mastodon:daily Voilà ! Vous pouvez désormais changer vos DNS pour pointer votre domaine vers le nouveau serveur. N’hésitez pas à me signaler d’éventuelles erreurs en commentaire ou à proposer des améliorations.\nSi vous souhaitez mettre en place une architecture basée sur plusieurs serveurs, je vous recommande l’article matuni.xyz.\n","date":"2017-04-13T13:40:33Z","image":"/images/2017/08/migration-mastodon-1.png","permalink":"/migration-dune-instance-mastodon/","title":"Migration d'une instance Mastodon"},{"content":"Pourquoi mettre en place un résolveur DNS ?\rAvec une généralisation de la censure et de nombreuses pannes sur les résolveurs DNS des FAI, beaucoup d’articles recommandent l’utilisation des résolveurs DNS Google. Mais si ce dernier propose un service stable et performant, il peut être inquiétant de laisser google analyser l’ensemble des requêtes DNS que vous pouvez faire en naviguant sur le web.\nDans ce tutoriel, je vais donc vous expliquer comment mettre en place un résolveur DNS récursif, supportant la norme DNSSEC avec unbound. Pour l’installation, j’ai utilisé un VPS avec Ubuntu 16.04 LTS.\nInstaller et configurer unbound\rTout d’abord, il faut installer unbound :\napt update apt install unbound Après quoi, il faut créer un fichier de configuration dans le dossier /etc/unbound/unboud.conf.d/ que vous pouvez nommer mondns.conf par exemple. Voici le contenu de ce fichier :\nserver: interface: 0.0.0.0 interface: ::0 access-control: 0.0.0.0/0 allow access-control: ::/0 allow root-hints: \u0026#34;/var/lib/unbound/root.hints\u0026#34; verbosity: 0 qname-minimisation: yes num-threads: 2 msg-cache-slabs: 4 rrset-cache-slabs: 4 infra-cache-slabs: 4 key-cache-slabs: 4 rrset-cache-size: 100m msg-cache-size: 50m outgoing-range: 465 so-rcvbuf: 4m so-sndbuf: 4m port: 53 do-ip4: yes do-ip6: yes do-udp: yes do-tcp: yes do-daemonize: yes hide-identity: yes hide-version: yes harden-glue: yes harden-dnssec-stripped: yes harden-referral-path: yes use-caps-for-id: yes prefetch: yes Attention, l’option *qname-minimisation: yes *ne fonctionne que sur Ubuntu car unbound 1.5.7 n’est pas disponible sur le repository debian.\nOn télécharge ensuite le fichier contenant les IPs des 13 serveurs de la racine.\nwget https://www.internic.net/domain/named.cache -O /var/lib/unbound/root.hints\nIl ne nous reste plus qu’à redémarrer le service unbound :\nservice unbound restart\nEt votre résolveur DNS est désormais opérationnel ! (vérifiez que le service unbound fonctionne correctement avec la commande service unbound status) Vous pouvez maintenant éditer le fichier /etc/resolv.conf pour remplacer l’IP du nameserver utilisé par 127.0.0.1.\nEnsuite, si vous souhaitez automatiser la mise à jour des serveurs de la racine, vous pouvez le faire en ajoutant un cron avec le script suivant :\nwget https://git.virtubox.net/virtubox/unbound-dns-server/raw/master/update-root-dns.sh\nchmod +x update-root-dns.sh\ncrontab -e\n0 0 * * * ./update-root-dns.sh\nRésolveur DNS Public Ouverts de VirtuBox\rSi vous n’avez pas l’envie ou la patience de mettre en place votre propre résolveur DNS, vous pouvez utiliser ceux mis à disposition par VirtuBox :\nNom : **dns.vtbox.net **\nIPv4 : 163.172.189.181 IPv6 : 2001:bc8:4400:2100::25:5 Nom : sdns.vtbox.net\nIPv4 : 217.182.205.213 IPv6 : 2001:41d0:302:2100::7a77 Les deux résolveurs utilisent la même configuration que ci-dessus, avec l’ajout de trois lignes afin d’avoir les statistiques d’utilisation :\nstatistics-interval: 0 extended-statistics: yes statistics-cumulative: yes Si vous souhaitez aller encore plus loin, vous pouvez également mettre en place un résolveur DNSCrypt qui permet de chiffrer les requêtes faites entre votre machine et le résolveur DNS.\nJe vous invite à jeter un coup d’œil sur le tutoriel de noobunbox.\nTutoriel inspiré de l’article de shaftinc.fr.\n","date":"2017-04-06T13:23:11Z","image":"/images/2018/07/resolveur-DNS.jpg","permalink":"/installer-resolveur-dns-unbound/","title":"Installer votre résolveur DNS avec unbound"},{"content":"Alors que ce nouveau réseau social fait actuellement beaucoup parler de lui, je me suis décidé à créer ma propre instance Mastodon pour contribuer à ce projet.\nJ’en ai donc profiter pour faire un tutorial listant les étapes à suivre pour lancer vous aussi votre instance dès aujourd’hui. Je suis parti sur un VPS tournant avec Ubuntu 16.04 LTS et du côté ressources 8 vCores, 8Go de RAM et 50Go de SSD. Je verrais à l’usage si l’instance nécessite plus de ressources.\nPour suivre les étapes de ce tutorial, un utilisateur avec les droits sudo est suffisant, vous n’avez pas besoin de vous connecter en tant que root.\nInstaller les pré-requis\rsudo apt-get update\nInstallation de nodejs\ncurl -sL https://deb.nodesource.com/setup_4.x | sudo bash - sudo apt-get install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev nodejs sudo npm install -g yarn Installation de redis-server\nsudo apt-get install redis-server redis-tools\nInstallation de postgresql\nsudo apt-get install postgresql postgresql-contrib sudo su - postgres psql CREATE USER mastodon CREATEDB; \\q Il nous faut également activer le daemon d’authentification pour que les utilisateurs puissent se connecter dans mot de passe :\nsudo sed -i \u0026#39;/^local.*postgres.*peer$/a host all all 127.0.0.1/32 ident\u0026#39; /etc/postgresql/9.?/main/pg_hba.conf sudo apt-get install pidentd sudo systemctl enable pidentd sudo systemctl start pidentd sudo systemctl restart postgresql Installation de Ruby\rOn installe les dépendances pour Ruby.\nsudo apt-get install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev\nOn créer un utilisateur mastodon :\nadduser --disabled-password --disabled-login mastodon\nPuis on s’identifie avec cet utilisateur\nsu - mastodon\nOn installe rbenv et rbenv-build :\nadduser --disabled-password --disabled-login mastodon git clone https://github.com/rbenv/rbenv.git ~/.rbenv echo \u0026#39;export PATH=\u0026#34;$HOME/.rbenv/bin:$PATH\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.bashrc echo \u0026#39;eval \u0026#34;$(rbenv init -)\u0026#34;\u0026#39; \u0026gt;\u0026gt; ~/.bashrc source ~/.bashrc On se déconnecte pour appliquer la modification au bash, puis on installe ruby-build.\nexit su - mastodon git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build Puis on installe Ruby v2.4.1 pour Mastodon :\nrbenv install 2.4.1 rbenv global 2.4.1 On vérifie la version de ruby installé via la commande :\nruby -v\nInstallation de Mastodon\rNous allons pouvoir passer à l’installation de Mastodon et pour cela on commence par cloner le dépôt Github, puis on utilise git checkout pour sélectionner la dernière release plutôt que de rester sur la branche master :\ncd ~ git clone https://github.com/tootsuite/mastodon.git live cd live git checkout $(git tag | tail -n 1) On installe bundler pout gérer l’installation des dépendances et on désactive la documentation pour chaque gem.\necho \u0026#34;gem: --no-document\u0026#34; \u0026gt; ~/.gemrc gem install bundler --no-ri Puis on passe à l’installation\nbundle install --deployment --without development test yarn install On peut désormais copier le fichier de configuration d’exemple et l’éditer avec nos informations :\ncp .env.production.sample .env.production nano .env.production Les informations à remplir sont :\n# Service dependencies REDIS_HOST=localhost REDIS_PORT=6379 DB_HOST=/var/run/postgresql DB_USER=mastodon DB_NAME=mastodon_production DB_PASS= DB_PORT=5432 # Federation LOCAL_DOMAIN=votredomaine.com LOCAL_HTTPS=true Ainsi que la partie SMTP qui permettra aux utilisateurs de confirmer leur inscription :\n# E-mail configuration SMTP_SERVER=mail.votredomaine.com SMTP_PORT=587 SMTP_LOGIN=noreply@votredomaine.com SMTP_PASSWORD=VotreMotdePasse SMTP_FROM_ADDRESS=noreply@votredomaine.com Pour la partie application secret, utilisez la commande bundle exec rake secret pour générer 3 clés et vous n’avez plus qu’à les copier dans le fichier de configuration.\nPour mettre en place l’instance du côté base de donnée et assets :\nRAILS_ENV=production bundle exec rails db:setup RAILS_ENV=production bundle exec rails assets:precompile Création des services systemd\rPour le processus web\nnano /etc/systemd/system/mastodon-web.service\n[Unit] Description=mastodon-web After=network.target [Service] Type=simple User=mastodon WorkingDirectory=/home/mastodon/live Environment=\u0026#34;RAILS_ENV=production\u0026#34; Environment=\u0026#34;PORT=3000\u0026#34; ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb TimeoutSec=15 Restart=always [Install] WantedBy=multi-user.target **Pour le processus en arrière-plan **\nnano /etc/systemd/system/mastodon-sidekiq.service\n[Unit] Description=mastodon-sidekiq After=network.target [Service] Type=simple User=mastodon WorkingDirectory=/home/mastodon/live Environment=\u0026#34;RAILS_ENV=production\u0026#34; Environment=\u0026#34;DB_POOL=5\u0026#34; ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 5 -q default -q mailers -q pull -q push TimeoutSec=15 Restart=always [Install] WantedBy=multi-user.target Pour le processus de l’API\nnano /etc/systemd/system/mastodon-streaming.service\n[Unit] Description=mastodon-streaming After=network.target [Service] Type=simple User=mastodon WorkingDirectory=/home/mastodon/live Environment=\u0026#34;NODE_ENV=production\u0026#34; Environment=\u0026#34;PORT=4000\u0026#34; ExecStart=/usr/bin/npm run start TimeoutSec=15 Restart=always [Install] WantedBy=multi-user.target On peut alors activer les services :\nsystemctl enable /etc/systemd/system/mastodon-*.service\nEt enfin démarrer l’instance Mastodon :\nsudo systemctl start mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service\nOn ajoute alors les crons nécessaire pour Mastodon :\ncrontab -u mastodon -e\nRAILS_ENV=production @daily cd /home/mastodon/live \u0026amp;\u0026amp; /home/mastodon/.rbenv/shims/bundle exec rake mastodon:daily Mise en place du reverse-proxy Nginx :\rNous avons désormais une instance mastodon qui fonctionne, mais nous allons devoir mettre en place un reverse-proxy avec Nginx afin de pouvoir utiliser directement notre domaine pour y accéder.\nOn commence par installer nginx :\nwget -O - https://nginx.org/keys/nginx_signing.key | sudo apt-key add - sudo echo \u0026#34;deb http://nginx.org/packages/ubuntu/ $(lsb_release -sc) nginx\u0026#34; \u0026gt; /etc/apt/sources.list.d/nginx.list sudo apt update sudo apt install nginx On créer un fichier de configuration en se basant sur le modèle d’Angristan :\nnano /etc/nginx/sites-enabled/votredomaine.com\nmap $http_upgrade $connection_upgrade { default upgrade; \u0026#39;\u0026#39; close; } # redirection http vers https server { listen 80; listen [::]:80; server_name www.votredomaine.com votredomaine.com; return 301 https://votredomaine.com$request_uri; access_log /dev/null; error_log /dev/null; } # block https server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name www.votredomaine.com votredomaine.com; if ($host = www.votredomaine.com) { return 301 https://votredomaine.com$request_uri; } access_log /var/log/nginx/votredomaine.com-access.log; error_log /var/log/nginx/votredomaine.com-error.log; # configuration ssl avec letsencrypt ssl_certificate /etc/letsencrypt/live/votredomaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/votredomaine.com/privkey.pem;; ssl_protocols TLSv1.2; ssl_ciphers EECDH+AESGCM:EECDH+CHACHA20:EECDH+AES; ssl_prefer_server_ciphers on; # ajout des headers pour le HSTS, CSP et Referrer-Policy add_header Strict-Transport-Security \u0026#34;max-age=15552000; includeSubDomains; preload\u0026#34;; add_header Content-Security-Policy \u0026#34;default-src \u0026#39;self\u0026#39;; style-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39;; script-src \u0026#39;self\u0026#39; \u0026#39;unsafe-inline\u0026#39;; img-src \u0026#39;self\u0026#39; data:; connect-src \u0026#39;self\u0026#39; wss://votredomaine.com;\u0026#34;; add_header Referrer-Policy \u0026#34;strict-origin-when-cross-origin\u0026#34;; keepalive_timeout 70; sendfile on; client_max_body_size 0; gzip off; root /home/mastodon/live/public; location / { try_files $uri @proxy; } location @proxy { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_pass_header Server; proxy_pass http://127.0.0.1:3000; proxy_buffering off; proxy_redirect off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; tcp_nodelay on; } location /api/v1/streaming { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_pass http://127.0.0.1:4000; proxy_buffering off; proxy_redirect off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; tcp_nodelay on; } error_page 500 501 502 503 504 /500.html; } Puis on installe Let’s Encrypt pour générer notre certificat SSL :\ncd /opt git clone https://github.com/letsencrypt/letsencrypt cd letsencrypt ./letsencrypt-auto certonly --webroot -w /home/mastodon/live -d www.votredomaine.com -d votredomaine.com --email vous@votredomaine.com --text --rsa-key-size 4096 Mettre à jour Mastodon\rMastodon est très régulièrement mis à jour, cependant pour des raisons de stabilité, il est préférable d’attendre des releases pour mettre à jour son instance. Il ne sera donc pas nécessaire de lancer 10 fois par jour la commande git pull, et il vous suffit après une release d’utiliser les commandes suivantes sans oublier de remplacer tags/vX.X.X par l’identifiant de la release.\nsu - mastodon cd live git fetch git checkout vX.X.X bundle install --deployment --without development test NODE_ENV=production npm upgrade --global yarn yarn install RAILS_ENV=production bundle exec rails assets:clean RAILS_ENV=production bundle exec rails assets:precompile RAILS_ENV=production bundle exec rails db:migrate exit Si une mise à jour de Ruby est nécessaire pour l’installation d’une release, il vous faudra faire : rbenv install 2.4.1 gem install bundler --no-ri Note pour la release v1.1.2, pour utiliser la nouvelle fonctionnalitée des avatars GIF, utilisez la commande suivante pour générer une version statiques sur des avatars mis en ligne précédemmment. Sinon vos utilisateurs devront ré-uploader l’avatar pour en bénéficier. RAILS_ENV=production bundle exec rake mastodon:maintenance:add_static_avatars\nIl ne reste plus qu’à redémarrer l’instance :\nsudo systemctl restart mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service\nCréation du compte administrateur\rVotre instance est désormais fonctionnelle, il vous suffit donc de vous inscrire et de valider votre adresse mail pour créer votre compte. Ensuite, pour définir ce compte en tant qu’administrateur de l’instance utiliser la commande suivante :\nRAILS_ENV=production bundle exec rails mastodon:make_admin USERNAME=votre-utilisateur\nMon instance Mastodon.top\rAyant des ressources à disposition, j’ai lancé mon instance Mastodon, que vous pouvez rejoindre à l’adresse mastodon.top. Nous sommes déjà 90 utilisateurs et vu l’utilisation des ressources, cela ne devrait pas être un problème d’héberger plus de monde. Vous pouvez visualiser les statistiques de l’instance sur la page about ainsi que le monitoring en temps-réel à l’adresse status.mastodon.top.\nN’hésitez pas à donner votre avis sur ce tutoriel, à corriger d’éventuelles erreurs ou à demander de l’aide pour mettre en place votre instance !\nVous pouvez aussi me suivre sur Mastodon : thomas_virtubox@mastodon.top\n","date":"2017-04-05T20:17:58Z","image":"/images/2017/08/Mastodon-setup.png","permalink":"/installer-instance-mastodon-ubuntu/","title":"Installer une instance Mastodon sur Ubuntu 16.04 LTS"},{"content":" Cet article est ancien et il peut contenir des instructions qui ne sont plus d\u0026rsquo;actualité.\nSi vous aussi, il vous arrive de vous plaindre à propos de WordPress, pourquoi ne pas essayer une autre solution pour votre blog ? C’est ce que j’ai fait pour mon blog anystack.xyz en passant de WordPress à Ghost. Après plusieurs mois d’utilisation, je suis plutôt satisfait de cette plateforme. Il manque effectivement quelques fonctionnalités et l’écosystème de plugins et de thèmes que l’on peut retrouver sur WordPress, mais sa simplicité d’utilisation et son orientation vers ce qui est vraiment important – le contenu – est plutôt agréable.\nJe vais donc dans ce tutorial expliquer comment installer Ghost, puis mettre en place un reverse-proxy avec Nginx et Let’s Encrypt, en utilisant le module proxy-cache de Nginx pour rendre Ghost encore plus rapide.\n1) Installer NodeJs v4 LTS\rwget https://deb.nodesource.com/setup_4.x chmod +x setup_4.x ./setup_4.x apt-get install nodejs -y 2) Installer Ghost\rmkdir /var/www/ghost cd /var/www/ghost curl -L https://ghost.org/zip/ghost-latest.zip -o ghost.zip unzip ghost.zip npm install --production Lancer Ghost :\nnpm start --production Votre instance Ghost est donc désormais lancée, et vous pouvez y accéder à l’adresse http://IP-De-Votre-Serveur:2368. Cependant, si vous fermez votre console SSH, l’instance Ghost s’arrêtera. Pour lancer Ghost de façon définitive :\nnpm install forever -g ## démarrer ghost NODE_ENV=production forever start index.js ## arrêter ghost forever stop index.js 3) Configurer Nginx en tant que reverse-proxy\rNous allons donc passer à la partie configuration de Nginx. Si vous utilisez EasyEngine, vous pouvez créer votre sous domaine en une seule commande :\nee site create votredomaine.com --proxy=127.0.0.1:2368\nEnsuite modifiez le fichier de configuration de votre domaine en suivant le modèle ci-dessous.\nupstream ghost_upstream { server 127.0.0.1:2368; keepalive 64; } proxy_cache_path /var/run/cache levels=1:2 keys_zone=STATIC:75m inactive=24h max_size=512m; server { server_name votredomaine.com wwww.votredomaine.com; add_header X-Cache $upstream_cache_status; location / { proxy_cache STATIC; proxy_cache_valid 200 30m; proxy_cache_valid 404 1m; proxy_pass http://ghost_upstream; proxy_ignore_headers X-Accel-Expires Expires Cache-Control; proxy_ignore_headers Set-Cookie; proxy_hide_header Set-Cookie; proxy_hide_header X-powered-by; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; expires 10m; } location /content/images { alias /path/to/ghost/content/images; access_log off; expires max; } location /assets { alias /path/to/ghost/content/themes/uno-master/assets; access_log off; expires max; } location /public { alias /path/to/ghost/core/built/public; access_log off; expires max; } location /ghost/scripts { alias /path/to/ghost/core/built/scripts; access_log off; expires max; } location ~ ^/(?:ghost|signout) { proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; proxy_pass http://ghost_upstream; add_header Cache-Control \u0026#34;no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0\u0026#34;; } location /.well-known { alias /var/www/html/.well-known; } } Pour appliquer la configuration, on utilise la commande service nginx reload. Cependant il faut également penser à éditer le fichier config.js, situé dans le dossier d’installation de Ghost, et y changer la variable url en la remplaçant par votre nom de domaine :\nurl: 'http://votredomaine.com'\n4) Installer Let’s Encrypt\rOn peut désormais passer à l’installation de Let’s Encrypt si ce n’est pas déjà fait.\ncd /opt git clone https://github.com/letsencrypt/letsencrypt cd letsencrypt Il ne nous reste plus qu’à générer le certificat via la commande :\n./letsencrypt-auto certonly --webroot -w /var/www/html -d votredomaine.com --email votreemail@votredomaine.com --text --agree-tos\nPour utiliser le certificat, ajouter les lignes suivantes après server_name dans votre configuration nginx :\nlisten 443 ssl http2; ssl on; ssl_certificate /etc/letsencrypt/live/votredomaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/votredomaine.com/privkey.pem; ``` Pour terminer, il ne vous reste plus qu’à modifier à nouveau l’url de votre blog dans le fichier config.js et à ajouter un block server pour faire la redirection http vers https : server { listen 80; server_name votredomaine.com www.votredomaine.com; return 301 https://votredomaine.com$request_uri; }\n","date":"2017-03-29T21:17:02Z","image":"/images/2018/07/Installer-Ghost-2.jpg","permalink":"/installer-ghost-nginx-proxy-cache-letsencrypt/","title":"Installer Ghost avec Nginx proxy-cache et Let'sEncrypt"},{"content":"Il y a plusieurs solutions pour sécuriser l’accès à l’interface Proxmox, mais si vous avez l’habitude tout comme moi de nginx, elle est la plus intéressante car elle permet non seulement d’utiliser le domaine de votre choix pour accéder à l’interface sur le port standard 443, mais également de ne pas vous retrouver bloqué par le firewall en cas de mauvaise configuration.\nDans ce tutorial, nous allons donc voir comment installer nginx et comment le configurer pour obtenir un certificat Let’sEncrypt et sécuriser ainsi l’interface de Proxmox.\n==La méthode détaillée dans cet article n\u0026rsquo;est pas compatible avec Proxmox VE 5==\nOn commence par installer nginx :\napt-get install nginx\nPuis on créer un fichier /etc/nginx/conf.d/proxmox.conf :\nupstream proxmox { server \u0026#34;votre.serveur.hostname\u0026#34;; } server { server_name proxmox.votredomaine.com; rewrite ^(.*) https://$host$1 permanent; location /.well-known { alias /var/www/html/.well-known; } } Pour appliquer la configuration, on utilise la commande service nginx reload. On peut désormais passer à l’installation de Let’s Encrypt si ce n’est pas déjà fait.\ncd /opt git clone https://github.com/letsencrypt/letsencrypt cd letsencrypt Il ne nous reste plus qu’à générer le certificat via la commande :\n./letsencrypt-auto certonly --webroot -w /var/www/html -d proxmox.votredomaine.com --email votreemail@votredomaine.com --text --agree-tos\nLet’s Encrypt va alors effectuer l’opération de vérification en créer un dossier .well-known dans /var/www/html puis générer votre certificat. Nous pouvons donc désormais ajouter les lignes suivantes à notre fichier /etc/nginx/conf.d/proxmox.conf afin d’utiliser le certificat :\nserver { listen 443; server_name proxmox.votredomaine.com; ssl on; ssl_certificate /etc/letsencrypt/live/proxmox.votredomaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/proxmox.votredomaine.com/privkey.pem; proxy_redirect off; location / { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection \u0026#34;upgrade\u0026#34;; proxy_pass https://localhost:8006; proxy_buffering off; client_max_body_size 0; proxy_connect_timeout 3600s; proxy_read_timeout 3600s; proxy_send_timeout 3600s; send_timeout 3600s; } } On utilise à nouveau la commande service nginx reload pour appliquer la configuration et nous pouvons désormais accéder à l’interface proxmox via l’adresse : https://proxmox.votredomaine.com. Vous pouvez ajouter un cron pour renouveler automatiquement votre certificat letsencrypt tous les 30 jours :\n0 0 1 * * /opt/letsencrypt-auto certonly --webroot -w /var/www/html -d proxmox.votredomaine.com --email votreemail@votredomaine.com --text --agree-tos\n","date":"2017-03-22T18:33:31Z","image":"/images/2018/07/Proxmox-nginx-1.jpg","permalink":"/configurer-nginx-reverse-proxy-lets-encrypt-proxmox/","title":"Configurer Nginx en reverse-proxy avec Let's Encrypt pour Proxmox 4"},{"content":"Lorsque vous gérez plusieurs sites WordPress, cela peut rapidement devenir difficile de les garder à jour tout le temps, de gérer les backups ou encore de se connecter avec des identifiants différents sur chaque site.\nPour remédier à ce problème, il y a des solutions comme Jetpack. Cependant n’étant pas vraiment en accord avec leurs conditions d’utilisation, j’ai préféré chercher une solution self-hosted qui propose des fonctionnalités similaires.\nEt j’ai ainsi trouvé InfiniteWP. Une dashboard permettant de gérer les mises à jour, les backups et de se connecter sans mot de passe à tous vos sites WordPress.\nInstallation\rPour l’installation, elle est désormais simplifiée puisqu’elle se fait via WordPress, il vous suffit de télécharger l’extension disponible sur le site InfiniteWP, et de l’ajouter à l’un de vos sites WordPress pour installer votre panel dans un sous dossier du site. Il est également possible d’installer InfiniteWP manuellement en suivant ce guide. Le seul bug rencontré lors de l’installation est que la première connexion doit se faire sans https, hors si vous utilisez une redirection 301 du http vers https, cela va créer un boucle de redirection.\nPour ajouter un site, c’est également très simple puisqu’il vous suffit de vous connecter au site WordPress que vous souhaitez ajouter, d’installer InfiniteWP client qui est disponible dans le répertoire des extensions WordPress. Lors de l’activation de l’extension, les identifiants de connexion pour le panel InfiniteWP seront affichés, cliquez sur copier et il vous suffira de les coller pour ajouter votre site à votre dashboard.\nFonctionnalités\rPour ce qui est des fonctionnalités, le tableau n’est pas tout rose puisque une grande parties des fonctionnalités avancés nécessitent de souscrire à une offre premium, dont le prix dépend du nombre de sites que vous gérez. Cependant la version gratuite offre les fonctionnalités suivantes :\nConnexion à WordPress sans mot de passe Mise à jour des thèmes et plugins Installation en masse d’un thème ou plugin Backup local des fichiers + base de données Mettre un site en maintenance Automatisation des backups via un cron Il est donc tout à fait possible de d’ajouter un cron sur votre serveur pour réaliser l’export de vos backup sur un stockage externe puisqu’ils seront automatiquement créés dans le dossier /wp-content/infinitewp/backups.\n","date":"2017-03-08T14:23:35Z","image":"/images/2017/08/app-overview1.gif","permalink":"/infinitewp-gerez-sauvegardez-facilement-wordpress/","title":"InfiniteWP - Gérez et sauvegardez facilement vos sites WordPress"},{"content":"Vous souhaitez pouvoir accéder aux dossiers de votre serveur facilement depuis votre PC Windows ? Samba vous permet de partager les dossiers de votre choix et de les ajouter directement en tant que lecteur réseau depuis votre ordinateur. Vous n’aurez ainsi besoin d’aucun client pour accéder à vos fichiers.\nTout d’abord il faut installer les packages samba :\napt-get install libcups2 samba samba-common cups\nEnsuite on déplace la configuration samba par défaut afin de créer notre propre configuration.\nmv /etc/samba/smb.conf /etc/samba/smb.conf.bak\nOn peut désormais créer notre fichier configuration :\nnano /etc/samba/smb.conf\nOn commence par la partie principale (je nomme ici mon serveur debian) :\n[global] workgroup = WORKGROUP server string = Samba Server %v netbios name = debian security = user map to guest = bad user dns proxy = no Puis on redémarre le serveur samba\nsystemctl restart smbd.service\nPour partager un dossier communs à tous les utilisateurs, ajouter le code suivant à votre fichier smb.conf :\n[allusers] comment = All Users path = /home/shares/allusers valid users = @users force group = users create mask = 0660 directory mask = 0771 writable = yes Puis créez ce dossier en utilisant :\nmkdir -p /home/shares/allusers chown -R root:users /home/shares/allusers/ chmod -R ug+rwx,o+rx-w /home/shares/allusers/ Pour partager le dossier home de chaque utilisateur, il vous suffit d’ajouter le code suivant à votre fichier smb.conf :\n[homes] comment = Home Directories browseable = no valid users = %S writable = yes create mask = 0700 directory mask = 0700 Nous devons désormais ajouter un utilisateur, pour cela :\nuseradd jesuisadmin -m -G users\nOn définit un mot de passe pour l’utilisateur\npasswd jesuisadmin\nPuis on ajoute cet utilisateur à la base de donnée samba :\nsmbpasswd -a jesuisadmin\nDu côté de votre ordinateur windows, ajouter les lignes suivantes à votre fichier C:\\Windows\\System32\\drivers\\etc\\hosts :\n192.168.XX.XX\tdebian.example.com\tdebian\nVous pouvez désormais accéder à votre serveur directement depuis votre navigateur de fichier en utilisant l’adresse \\debian ou \\debian\\jesuisadmin si vous souhaitez accéder directement au dossier de l’utilisateur :\n","date":"2017-03-04T17:04:53Z","image":"/images/2017/08/Copy-of-Seedbox-Plex.png","permalink":"/installer-serveur-samba-debian-8-jessie/","title":"Installer un serveur samba sur debian 8 jessie"},{"content":"Vous souhaitez pouvoir monitorer votre serveur, mais sans avoir à déployer une suite complète comme librenms ? Alors Netdata est fait pour vous !\nC’est une solution de monitoring très légère qui affiche via un dashboard l’ensemble des informations sur l’usage des ressources de votre serveur. On y retrouve l’usage CPU, RAM, des disques avec chaque partitions mais également le détail des applications comme memcached, postfix ou redis. Cependant, à la différence des autres solutions, Netdata ne liste absolument aucune information pouvant présenter un risque sur le plan sécurité. L’avantage est qu’il n’est pas nécessaire de limiter l’accès à la dashboard et cette dernière dispose de son propre web server qui ne démarre que lorsque vous consulter la page.\nComment installer netdata ?\rVous pouvez utiliser le kickstart script pour installer netdata :\n# Tous les systèmes linux bash \u0026lt;(curl -Ss https://my-netdata.io/kickstart.sh) all Si vous choisissez l’installation manuelle, il faut d’abord installer les packages suivant :\n# Debian / Ubuntu apt-get install zlib1g-dev uuid-dev libmnl-dev gcc make git autoconf autogen automake pkg-config curl jq nodejs # Centos / Fedora / Redhat yum install zlib-devel libuuid-devel libmnl-devel gcc make git autoconf autogen automake pkgconfig curl jq nodejs Puis il vous suffit alors de cloner le dépôt github, puis d’exécuter netdata-installer.sh :\n# download it - the directory \u0026#39;netdata\u0026#39; will be created git clone https://github.com/firehol/netdata.git --depth=1 cd netdata # build it, install it, start it ./netdata-installer.sh Vous pourrez alors accéder à netdata via l’adresse http://IP-DE-VOTRE-SRV:19999 Enfin pour ce qui est des mise à jour de netdata, vous pouvez ajouter un cron pour exécuter régulièrement le fichier netdata-updater.sh.\nMonitorer nginx :\rPour monitorer nginx, il suffit d’autoriser l’accès à la page des status pour que netdata puisse récupérer les statistiques d’utilisation. La façon la plus simple de procéder est d’ajouter cette autorisation dans le vhost defaut. On modifie donc le fichier :\nnano /etc/nginx/sites-available/default\nEt on y ajoute l’emplacement :\n# Status pages location /stub_status { stub_status on; access_log off; allow 127.0.0.1; deny all; } Pour que netdata prennent en compte le changement, on redémarre le service.\nservice netdata restart\nEt vous pourrez alors visualiser dans votre dashboard la section nginx local.\nNetdata derrière un reverse-proxy\rSi vous souhaitez accéder au panel netdata directement via votre domaine et/ou y accéder via https, il vous faudra mettre en place un reverse-proxy.\nAyant une préférence pour nginx, voici le fichier de configuration à créer pour utiliser netdata pour un domaine :\nupstream backend { # the netdata server server 127.0.0.1:19999; keepalive 64; } server { # the virtual host name of this server_name netdata.example.com; location / { proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://backend; proxy_http_version 1.1; proxy_pass_request_headers on; proxy_set_header Connection \u0026#34;keep-alive\u0026#34;; proxy_store off; } } Et la configuration si vous préférez accéder à netdata via un sous-dossier :\nupstream netdata { server 127.0.0.1:19999; keepalive 64; } server { # the virtual host name of this subfolder should be exposed #server_name netdata.example.com; location /netdata { return 301 /netdata/; } location ~ /netdata/(?.*) { proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_pass_request_headers on; proxy_set_header Connection \u0026#34;keep-alive\u0026#34;; proxy_store off; proxy_pass http://netdata/$ndpath$is_args$args; gzip on; gzip_proxied any; gzip_types *; } } Utiliser les badges\rUne des raisons pour lesquelles vous allez probablement utiliser un reverse-proxy est la possibilité d’afficher en temps réel des badges avec les informations de votre serveur. Exemple de code pour afficher quelques badges de votre serveur :\n\u0026lt;img src=\u0026#34;https://netdata.votredomaine.tld/api/v1/badge.svg?chart=system.cpu\u0026amp;alarm=10min_cpu_usage\u0026amp;refresh=auto\u0026#34;/\u0026gt; \u0026gt;\u0026lt;img src=\u0026#34;https://netdata.votredomaine.tld/api/v1/badge.svg?chart=system.ram\u0026amp;alarm=ram_in_use\u0026amp;refresh=auto\u0026#34; /\u0026gt; \u0026gt;\u0026lt;img src=\u0026#34;https://netdata.votredomaine.tld/api/v1/badge.svg?chart=disk_util.sda\u0026amp;alarm=10min_disk_utilization\u0026amp;refresh=auto\u0026#34; /\u0026gt; \u0026gt;\u0026lt;img src=\u0026#34;https://netdata.votredomaine.tld/api/v1/badge.svg?chart=nginx_local.connections\u0026amp;refresh=auto\u0026#34; /\u0026gt; Vous pouvez trouver plus d’informations à propos de netdata dans la documentation officielle.\nEdit du 22/07/2017 :\rJ’ai commencé la réalisation d’une dashboard custom basée sur un template bootstrap 4, que vous pouvez voir sur la page de demo et dont le code est disponible sur github.\n","date":"2017-02-23T19:02:24Z","image":"/images/2018/07/Screenshot_12.jpg","permalink":"/netdata-solution-monitoring-legere-serveur-linux/","title":"Netdata - Une solution monitoring légère pour votre serveur Linux"},{"content":"L’application Plex va sans aucun doute marquer cette année 2017, puisque nous sommes de plus en plus nombreux à organiser nos bibliothèque grâce au Plex Media Server.\nEt ayant craqué lors des dernières soldes Kimsufi pour un serveur KS-4G équipé d’un Atom N2800 et de 2To de disque (7,99€ HT /mois), je commençais tout de même à me demander pourquoi j’avais pris ce serveur …\nJ’ai donc souhaité en faire une Seedbox avec Plex \u0026amp; qBittorrent. Pour cela, j’ai d’abord installé le serveur avec Ubuntu Xenial 16.04 LTS, puis une fois connecté, j’ai commencé par télécharger Plex Media Server :\nwget -O plex.deb https://downloads.plex.tv/plex-media-server/1.4.1.3362-77c6a4f80/plexmediaserver_1.4.1.3362-77c6a4f80_amd64.deb dpkg -i plex.deb C’est là que commencent les hostilités, puisque la première connexion à Plex ne peut se faire que via le réseau local d’un serveur, et sans environnement graphique, impossible d’ouvrir Firefox pour faire la validation en localhost.\nPour pouvoir accéder au serveur sur le port 32400, il est nécessaire d’utiliser un tunnel SSH, de façon très simple avec linux en faisant :\nssh ip.address.of.server -L 8888:localhost:32400 Et un peu plus difficilement avec Windows, puisqu’il faut utiliser Putty afin de créer le tunnel comme dans l’exemple ci-dessous avant de clicker sur “open” :\nVous pourrez ensuite via votre navigateur accéder à l’adresse : http://127.0.0.1:32400/web/index.html#\nNotre serveur Plex est donc désormais opérationnel, mais le serveur est tout de même vide. Nous allons donc passer à l’installation de qBittorrent, et pour cela :\napt-get update \u0026amp;\u0026amp; apt-get install qbittorrent-nox\nOn créer ensuite un nouvel utilisateur, qui sera notre utilisateur principal et on déclare qbittorrent en tant que service :\nadduser qbtuser touch /etc/systemd/system/qbittorrent.service nano /etc/systemd/system/qbittorrent.service [Unit] Description=qBittorrent Daemon Service After=network.target [Service] Type=forking User=qbtuser ExecStart=/usr/bin/qbittorrent-nox -d [Install] WantedBy=multi-user.target Il ne nous reste alors plus qu’à recharger les services avant de s’identifier avec notre nouvel utilisateur pour faire le premier lancement de qbittorrent.\nsystemctl daemon-reload su - qbtuser qbittorrent-nox On se retrouve alors dans la même situation qu’avec Plex, puisqu’il vous faudra utiliser un tunnel SSH pour accéder via votre navigateur à l’addresse : http://127.0.0.1:8080\nL’utilisateur par défaut est admin, et le mot de passe adminadmin. Pensez à les changer avant d’arrêter qbittorrent. On peut alors repasser en tant que root, pour démarrer le service qbittorrent et l’activer au démarrage :\nsystemctl enable qbittorrent systemctl start qbittorrent Il reste désormais un dernier détail à régler, les permissions. En effet, les fichiers téléchargés via qBittorrent seront la propriété de qbtuser, alors que Plex Media Server est identifié en tant que l’utilisateur plex.\nPour régler ce problème, je vais ajouter l’utilisateur plex au groupe qbtuser, puis donner les droits d’accès au groupe sur le dossier Downloads. Pour cela j’utilise :\nusermod -aG qbtuser plex chmod -R g+rw /home/qbtuser/Downloads Pour ce qui est des performances sur les films, même avec un processeur atom les résultats sont très corrects. Il faudra tout de même préférer une version Core-i3 ou i5 si vous souhaitez être plusieurs connectés en même temps.\n","date":"2017-02-22T15:26:02Z","image":"/images/2017/08/Seedbox-Plex-1.png","permalink":"/creer-seedbox-qbittorrent-plex/","title":"Créez votre seedbox avec qBittorrent et Plex"},{"content":"Le Self-Hosting c\u0026rsquo;est bien, mais cela représente souvent beaucoup de temps pour déployer les applications et les mettre à jour, sans pour autant toujours bénéficier des mêmes fonctionnalités et garanties que des services tiers ou des solutions SaaS.\nSur les aspects comme la sécurité, le self-hosting est d\u0026rsquo;une certaine façon La solution ultime, cependant cela requiert quelques connaissances.\nMais si vous souhaitez vous lancer dans l’auto hébergement, il y a heureusement des plateformes comme Yunohost, DPlatform ou Cloudron qui vous permettent de déployer en quelques minutes vos applications préférées. Mais nous allons nous attarder sur Cloudron, car c’est pour moi la solution la plus aboutie à ce jour, et les fonctionnalités proposées sont nombreuses.\nMais Cloudron c’est quoi ?\rC’est une plateforme permettant de déployer en quelques minutes de nombreuses applications tel que NextCloud, RocketChat ou encore Gogs avec un service clé en main incluant l’hébergement et le backup. Mais pour l’équipe de Cloudron, si vous ne souhaitez pas vous abonner à leurs services, ils vous proposent de l’héberger vous même sur le serveur de votre choix.\nLes fonctionnalités principales\r40+ applications disponibles : FreshRSS, NextCloud, Rocket.chat, Gogs etc .. serveur mail complet avec SPF, DKIM, et DMARC backup en local, sur amazon S3 ou via Minio Sécurité : iptables, SSH keys et let’s encrypt avec HSTS pour tous les sous domaines Cloudron est basé sur une architecture Docker, autrement dit chaque application est déployée dans un container, ce qui simplifie à la fois la sauvegarde, mais également l’installation ou la mise à jour. Les seuls pré-requis pour installer Cloudron sont :\nUn serveur Ubuntu 16.04 LTS avec 1Go+ RAM Un nom de domaine complet (pas seulement un sous-domaine) Une connexion SSH en utilisant un clé SSH. L\u0026rsquo;installation est relativement simple :\nwget https://cloudron.io/cloudron-setup chmod +x ./cloudron-setup ./cloudron-setup --provider [ec2/digitalocean/scaleway/ovh/generic] L’installation nécessite quelques minutes, et vous pourrez accéder à votre Cloudron en vous rendant à l’adresse : https://IP-DE-VOTRE-SERVEUR Vous pourrez alors débuter la configuration de votre Cloudron, incluant le nom de domaine et la gestion des DNS, soit via Amazon Route 53, DigitalOcean, avec un Wildcard ou manuellement. Une fois l’installation terminée l’adresse principale de votre Cloudron sera https://my.votredomaine.com.\nVous pouvez trouvez la documentation complète de Cloudron sur leur site.\n","date":"2017-02-17T20:40:39Z","image":"/images/2017/08/Screenshot_6.png","permalink":"/cloudron-solution-self-hosting-facile/","title":"Cloudron - La solution Self-Hosting facile"},{"content":"J’utilise un certain nombre d’outils au quotidien pour installer des serveurs, et EasyEngine est sans aucun doute dans le top 3. Je vais donc vous présenter se petit outil à utiliser en ligne de commande sur votre serveur debian/ubuntu pour installer Nginx avec/sans WordPress en quelques minutes.\nEasyEngine doit être installé sur un nouveau serveur, n’ayant déjà Apache ou MySQL.\nPour installer EasyEngine, utilisez la commande :\nwget -qO ee rt.cx/ee \u0026amp;\u0026amp; sudo bash ee Il vous sera uniquement demandé un nom d’utilisateur et votre adresse mail. Une fois l’installation terminée, pour vérifier son fonctionnement, utilisez simplement la commande :\nee Vous aurez alors la liste des arguments disponibles. Pour installer WordPress sur un domaine par example :\nee site create votredomaine.fr --wp Lors du premier lancement de cette commande, EasyEngine va installer Nginx, php et MariaDB puis WordPress. Vous pouvez ajoutez des arguments supplémentaires après “–wp” afin d’ajouter une solution de cache, choisir php7 plutôt que php5 ou utiliser letsencrypt pour générer un certificat SSL.\nDans le cas du blog, j’ai utilisé la commande :\nee site create jesuisadmin.fr --wpredis --php7 --letsencrypt –wpredis afin d’installer WordPress avec Redis-server et le plugin Redis-object-cache –php7 pour installer php7 –letsencrypt pour générer et installer un certificat letsencrypt. Vous pouvez retrouvez cette liste des commandes disponibles sur le site d’EasyEngine.\n","date":"2017-02-05T00:45:11Z","image":"/images/2017/08/Screenshot_4.png","permalink":"/easyengine-nginx-wordpress/","title":"EasyEngine - Nginx et WordPress en quelques minutes"},{"content":"Si je m’efforce depuis un certain temps de proposer des articles via AnyStack en anglais, cela requiert tout de même beaucoup plus de temps car en plus du contenu, il faut s’adapter aux structures de phrases imposées par la langue anglaise.\nJe vais donc continuer à proposer des articles en anglais, mais je voulais aussi faire une version française, qui ne soit pas uniquement orientée tutoriels et poster dès que possible des articles orientés SysAdmin, open-source, high-tech, gaming etc …\nJe devrais ainsi pouvoir proposer les articles tout d’abord en français, et adapter les plus pertinents en anglais via AnyStack sous l’aspect de tutoriels.\nBref, le contenu proposé ici, sera plus spontané, selon les découvertes que je ferais en fouillant sur internet, et sans la moindre promotion (en échange d\u0026rsquo;une rémunération) pour un produit ou un service puisque je souhaite avant tout partager des connaissances et échanger des astuces ou solutions à ce problème mondial qu’est l’informatique.\nN’hésitez pas à donner votre avis, ou à proposer des sujets d’articles, car si il n’est absolument pas question que ce blog deviennent une démocratie, j’ai toujours apprécié d’avoir l’avis des autres avant de repartir sur mes idées pré-conçues. x)\nQuelques sujets proposés prochainement :\nMonitoring Virtualisation Control Panels WordPress \u0026amp; CMS Self-Hosting ","date":"2017-01-13T22:52:37Z","image":"/images/2017/08/sysadmin.png","permalink":"/webadminbox-sysadmin-blog-en-francais/","title":"Je suis admin - SysAdmin Blog"}]