Self-Hosting on Jesuisadmin

WordOps - Déployer WordPress avec Nginx simplement

Sat, 18 May 2019 12:03:24 +0000

Pour automatiser le déploiement de mes serveurs avec Nginx, PHP, MariaDB et pour créer les vhosts Nginx, j’utilisais précédemment EasyEngine v3 - qui avait d’ailleurs fait l’objet d’un article. Le problème, c’est qu’EasyEngine n’é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.

Malheureusement, 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’heure actuelle) que très peu de place à la customisation, aussi bien au niveau des configurations Nginx, que des paquets/containers utilisés.

N’y voyez pas un reproche à l’encontre de ses créateurs, puisque je comprends tout à fait le choix fait par l’équipe de rtCamp, et il me semble tout à fait normal que l’outil qu’ils développent soit avant tout adapté à leurs besoins. Il me paraît d’ailleurs important de souligner qu’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’EasyEngine a été publiée en 2014).

Finalement, c’est en parcourant les articles du blog d’EasyEngine fin Décembre, que j’ai découvert qu’un fork de la version 3 d’EasyEngine baptisé WordOps était actuellement en développement et qu’une première pre-release était disponible sur Github.

Ayant contribué de mon mieux au projet EasyEngine v3 en publiant un certain nombre de scripts ainsi que la majorité de mes configurations Nginx, j’ai été contacté par l’équipe de WordOps que j’ai finalement intégré début Février.

Nous avons publié la première version “stable” de l’application début Mai et il était donc temps de rédiger un article pour vous présenter WordOps.

WordOps qu’est ce que c’est ?

C’est un outil en ligne de commande qui facilite l’administration d’un serveur et le déploiement de sites avec Nginx (notamment WordPress) en utilisant des commandes simples - faciles à mémoriser.

Quels sont les pré-requis pour installer WordOps ?

Du côté hardware, il n’y a pas vraiment de pré-requis, puisque l’application est développée en Python avec le framework Cement et ne nécessite que quelques mégaoctets d’espace disque pour le stockage des librairies.

Pour 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’est pourquoi nous conseillons d’installer WordOps sur un serveur disposant d’au moins 2Go de RAM et si possible d’un processeur multi-core (qu’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.

Par contre, si vous comptez utiliser WordOps pour du développement, il devrait normalement fonctionner sur n’importe qu’elle machine/VM disposant de 512mo de RAM ou plus.

Nous avons d’ailleurs ajouté depuis peu le support de la distribution Raspbian 9, qui permet donc l’installation sur Raspberry Pi (nos tests ont été réalisés sur le modèle 3B+).

Du côté software, les distributions linux supportées sont :

Ubuntu 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 ?

WordOps réalise non seulement l’installation et la configuration des paquets nécessaires au déploiement d’un site (Nginx, PHP, MariaDB) mais il s’occupe également de la création des vhosts Nginx, de la base de données, d’installer WordPress et même d’obtenir un certificat SSL Let’s Encrypt, le tout réalisable en une seule ligne de commande.

Dans le cas d’un site WordPress, vous disposez de plusieurs solutions de cache (optionelles) : Nginx fastcgi_cache, Redis (full page cache + object cache) ou WP-Super-Cache.

Enfin WordOps dispose d’un tableau de bord (que j’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’accéder à des outils tel que PhpMyAdmin, Adminer, eXtplorer, phpRedisAdmin etc.. Une démo est disponible à l’adresse suivante : demo.wordops.eu.

Qu’est ce qu’il y a sous le capot ?

Nginx 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 & PHP 7.3
MariaDB server 10.3
Redis 5.0
Netdata pour le monitoring
Acme.sh pour la gestion des certificats SSL Let’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’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’accès et/ou l’exécution et le téléchargement de certains fichiers afin de bloquer les tentatives d’attaques régulièrement utilisées.

Installer WordOps

Un script pour automatiser l’installation de WordOps est bien sûr disponible, il s’exécute avec la commande suivante :

wget -qO wo wops.cc && sudo bash wo

Si vous souhaitez installer manuellement WordOps, un guide est disponible dans la documentation

Durant l’installation, WordOps vous demandera un nom d’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.

Commencer avec WordOps

Après avoir installé WordOps, la première étape est d’activer la complétion des commandes, il suffit pour cela d’utiliser la commande :

source /etc/bash_completion.d/wo_auto.rc

Nous pouvons donc commencer à utiliser les commandes WordOps, dont la structure est la suivante :

wo <commande> [options]

Vous souhaitez obtenir la liste des commandes disponibles ? Rien de plus simple, utilisez la commande :

wo

Vous pouvez également obtenir des informations sur chacune des sous-commandes en ajoutant les arguments -h ou --help.

Exemple :

wo site create -h

Installer les services (optionnel)

WordOps peut installer les services Nginx, PHP ou MySQL via la commande wo stack ou n’installer que les services nécessaires lors de la création d’un site avec la commande wo site create.

Si 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).

Pour déployer les services, la commande à utiliser est :

wo stack install

Créer votre premier site

Que vous ayez suivi ou non l’é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 :

wo site create [<nom_de_domaine>] [type_de_site] [options] <options>

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’s Encrypt :

wo site create site.tld --wpfc --php73 --letsencrypt

Quelques points à retenir

par défaut et en l’absence de l’argument --php73, WordOps utilisera PHP 7.2
l’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’argument --letsencrypt est optionel et peut être utilisé avec n’importe quel type de site. Si le site que vous souhaitez créer est un sous-domaine, utilisez alors l’argument --letsencrypt=subdomain pour que WordOps n’essaye pas de générer un certificat SSL pour l’alias www.site.tld.

Voici un exemple qui présente le fonctionnement général de WordOps :

Contribuer

Comme pour la majorité des projets open-source, toute contribution est la bienvenue. Et il n’est pas nécessaire d’être un développeur ou un administrateur système pour contribuer.

Le simple fait de faire un signalement détaillé d’un bug dans l’application est une contribution au projet. Vous pouvez également participer à l’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.

Si vous souhaitez contribuer directement au développement de WordOps, sachez que la rédaction d’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.

Les liens utiles

le 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

Installer Rocket.chat sur Ubuntu 18.04 LTS

Wed, 01 May 2019 16:21:00 +0000

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.

Installer Rocket.chat avec un snap

L’installation se fait via une seule ligne de commande :

sudo snap install rocketchat-server

Votre instance Rocket.Chat sera alors accessible à l’adresse : http://IP-de-VOTRE-SERVEUR:3000.

Mettre en place un reverse-proxy avec Nginx

Il est préférable de mettre en place un reverse-proxy pour accéder à l’interface de Rocket.Chat via un port standard et d’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.

Commençons par installer Nginx :

apt update && apt install nginx

On créer ensuite notre vhost dans /etc/nginx/sites-available/ :

nano /etc/nginx/sites-available/chat.votredomaine.tld

Dont voici le contenu :

# 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 "upgrade";
 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 :

ln -s /etc/nginx/sites-available/chat.votredomaine.tld /etc/nginx/sites-enabled/

Puis on relance Nginx :

service nginx reload

Obtenir un certificat SSL Let’s Encrypt avec acme.sh

Il ne nous reste plus qu’à générer le certificat via Let’s Encrypt, on installe donc acme.sh :

wget -O - https://get.acme.sh | sh
sudo source ~/.bashrc

Puis on génère le certificat pour notre sous-domaine.

acme.sh --issue -d chat.votredomaine.tld --pre-hook "systemctl stop nginx" --standalone --post-hook "systemctl start nginx" --ecc -k ec-384

On créer un répertoire pour stocker notre certificat :

mkdir -p /etc/letsencrypt/live/chat.votredomaine.tld

Puis on installe le certificat dans ce répertoire :

acme.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 "systemctl restart nginx.service"

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:

 listen 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’instance Rocket.Chat est d’appliquer la configuration avec la commande :

service nginx reload

Vous pourrez alors accéder à votre instance via l’adresse https://chat.votredomaine.tld. Pour accéder au panel d’administration de Rocket.chat, il vous faudra créer un premier compte utilisateur qui sera automatiquement définit en tant qu’administrateur.

Release Bell : ne ratez plus aucune publication de release sur Github

Wed, 24 Oct 2018 04:42:09 +0000

Lorsqu’on héberge un certain nombre d’applications “open-source”, il ~~est~~ était parfois difficile de suivre le flux de mises à jour des applications. Il s’agit heureusement d’une époque révolue, grâce à l’application Release Bell developpée par l’équipe de cloudron.io

Release-Bell est une application qui permet de recevoir une notification lorsqu’une nouvelle release est publiée sur Github parmi la liste des dépôts que vous avez “étoilé”. Elle est disponible via la plateforme de self-hosting cloudron que j’ai précédement présenté dans un article, mais elle peut également être installée manuellement sur n’importe quel serveur linux disposant de Nodejs et d’un serveur MySQL.

Les notifications sont envoyées par email, mais il n’est absolument pas obligatoire d’activer cette fonctionnalité. Dans mon cas, visualiser la liste des dépôts Github qui m’intéresse, sous la forme d’un flux chronologique suivant la date de publication des releases est largement suffisant.

Dans ce tutoriel, nous allons voir comment installer l’application Release-Bell sur un serveur Debian(8/9) ou Ubuntu (16.04 LTS/18.04 LTS).

Les prérequis

Comme je l’ai dis précédemment, pour installer Release-Bell, vous aurez besoin d’un reverse-proxy (Nginx dans ce tutoriel), de NodeJS (dont la version LTS actuelle est 8.x) et d’un serveur MySQL (ou MariaDB).

Nginx

Pour l’installation d’Nginx, rien de plus simple, sur Ubuntu ou Debian suffit d’utiliser :

sudo apt-get update && sudo apt-get install nginx -y

NodeJS

Pour NodeJS, c’est également relativement simple, puisqu’il suffit d’utiliser les commandes :

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash
sudo apt-get install -y nodejs

MariaDB

Enfin pour le serveur MySQL (MariaDB server 10.3 dans ce tutoriel) :

# ajout du dépôt APT de MariaDB
sudo bash <(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 && 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’informations sur le sujet dans cet article de la KnowledgeBase de VirtuBox.

Il vous faudra créer une base de données avant de commencer l’installation de Release-Bell. Pour cela connecter vous en tant que root à votre serveur MariaDB :

mysql

puis créez une nouvelle base de données :

CREATE DATABASE releasebell;

Ajouter ensuite un utilisateur avec les permissions nécessaires pour utiliser cette base de données :

GRANT ALL ON releasebell.* TO 'utilisateur_releasebell'@'localhost' IDENTIFIED BY 'motdepasse';

Terminez en flushant les privilèges pour appliquer les modifications

FLUSH PRIVILEGES;

Puis quittez l’interface en ligne de commande de MySQL :

EXIT;

Installer Release-Bell

Certaines étapes de l’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’application étant minimaliste, j’ai utilisé les mêmes étapes d’installation que d’autres applications NodeJS.

Pour installer Release-Bell, créer un nouvel utilisateur, de préférence sans mot de passe ou login afin d’éviter un éventuel accès non désiré via cet utilisateur :

Mise en place de l’application NodeJS

adduser --disabled-password --disabled-login releasebell

Puis connecter vous en tant que cet utilisateur :

sudo su - releasebell

Créez un répertoire pour héberger l’application :

mkdir releasebell

Puis téléchargez l’application avant de extraire de son archive :

curl -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’application :

cd releasebell

Et installer des dépendances NodeJS :

npm install

Importation de la structure de la base de données

Le structure de la base de donnéees de releasebell est stockée dans le dossier migrations de l’application. Pour l’importer il suffit donc d’utiliser :

mysql -u utilisateur_releasebell -p releasebell < migrations/initial-schema.sql

Configurer Release-Bell

La configuration de l’application repose sur deux fichiers, il s’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’application.

Il faut tout d’abord définir les paramètres d’accès à la base de données dans le fichier database.json, qui doit ressembler à l’exemple suivant :

{
 "defaultEnv": "local",
 "local": {
 "host": "localhost",
 "user": "utilisateur_releasebell",
 "password": "motdepasse",
 "database": "releasebell",
 "driver": "mysql",
 "multipleStatements": true
 }
 }

S’il n’existe pas encore, créez le fichier users.json dont le contenu doit ressembler à l’exemple suivant :

[
 {
 "username": "votre_nom_dutilisateur",
 "password": "motdepasse",
 "email": "test@example.com"
 }
]

La configuration de l’application est désormais terminée, l’application peut-être lancée avec la commande :

node index.js

Ajouter un service systemd pour Release-Bell

Vous souhaitez peut-être pouvoir utiliser l’application sans avoir à laisser un terminal ouvert indéfiniment. Pour cela le plus simple sur Debian/Ubuntu est d’ajouter un service systemd pour notre application. On y définira notamment certaines variables nécessaires à la configuration de l’application.

Pour ajouter un service, nous allons créer un ficher .service dans la répertoire /lib/systemd/system/

sudo nano /lib/systemd/system/release_bell.service

Le contenu de ce ficher de configuration doit ressembler à ceci (il vous faudra l’adapter avec vos informations) :

[Unit]
Description=ReleaseBell

[Service]
Type=simple
WorkingDirectory=/home/utilisateur_releasebell/releasebell
User=utilisateur_releasebell
Environment="NODE_ENV=production"
Environment="MAIL_SMTP_SERVER=smtp.example.com"
Environment="MAIL_SMTP_PORT=25"
Environment="MAIL_SMTP_USERNAME=releasebell@example.com"
Environment="MAIL_SMTP_PASSWORD=MotdepasseSMTP"
Environment="MAIL_FROM=releasebell@example.com"
Environment="MAIL_DOMAIN=example.com"
Environment="APP_ORIGIN=example.com"
ExecStart=/usr/bin/node index.js
Restart=always

[Install]
WantedBy=multi-user.target

Activez le service release_bell avec la commande :

sudo systemctl enable release_bell.service

Vous pouvez enfin démarrer le service avec la commande :

sudo service release_bell start

Configurer Nginx

Pour terminer ce tutoriel, voici un exemple de configuration pour utiliser Nginx en tant que reverse-proxy pour notre application :

server {


 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’étendre sur cette partie de la configuration, mais je vous invite à jeter un oeil à mon article Installer un certificat SSL Let’s Encrypt avec acme.sh si vous souhaitez générer un certificat SSL pour sécuriser l’accès à l’application Release-Bell.

Comment convertir vos images en WebP et les afficher avec Nginx

Fri, 10 Aug 2018 07:06:32 +0000

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’une image à condition qu’elle existe et que le format soit supporté par le navigateur du visiteur.

WebP est un format d’image open-source développé par Google en 2010, basé sur un autre format de fichiers également développé par Google, le VP8.

Le format WebP par rapport aux autres formats

Selon Google, le niveau de compression du format WebP permet d’obtenir des images 26% plus légères que le PNG et jusqu’à 34% plus légères que le JPG. Il faut savoir que le WebP supporte la transparence (canal alpha), mais également les animations (GIF).

Cependant, les chiffres annoncés par Google n’ont pas convaincu tout le monde. C’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.

Mise à jour du 29/01/2019 : Mozilla FireFox supporte officiellement les images au format WebP avec la mise à jour publiée aujourd’hui (version 65.0). Les seuls navigateurs modernes qui ne supportent pas le format WebP sont Edge et Safari.

Ce qui nous amène à un point qu’il est important de souligner : tous les navigateurs web ne supportent pas le WebP. Ce qui induit qu’il est actuellement impossible d’utiliser uniquement des images au format WebP sur un site (du moins, pas sans impacter certains visiteurs) et qu’il est nécessaire de configurer son serveur web pour servir la version WebP d’une image, seulement si le navigateur du visiteur le supporte.

Compatibilité et gains

On 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’obtenir la réponse, grâce au site caniuse.com, dont voici les résultats :

Can 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.

Et le niveau compression dans tout ça ? Est ce que le format WebP permet vraiment d’obtenir des images plus légères ?

D’après les tests que j’ai réalisé sur mes sites, la réponse est OUI. Qu’il s’agisse de convertir une image au format JPEG ou au format PNG, la version WebP est plus légère même s’il ne s’agit parfois que de quelques kilo-octets. Quelques exemples sur les images du blog :

Image	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’argument (-z 9) et avec un indice de qualité de 82 pour les images JPEG, avec l’argument (-q 82).

Installer cwebp pour convertir les images

Cwebp est l’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’il est possible de compiler depuis les sources.

Depuis les dépôts APT ou YUM

Sous Debian/Ubuntu, vous pouvez installer cwebp avec :

sudo apt install webp -y

Sous Centos 7, vous pouvez installer cwebp avec :

sudo yum install libwebp-tools -y

Depuis les sources de libwebp

Si vous souhaitez installer la dernière version du paquet cwebp (actuellement en v1.0.2) plutôt qu’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

Mise à jour du 17/08/2019 : Je propose désormais un script pour automatiquement compiler la dernière version de libwebp :

curl -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

Pour cela, il faut tout d’abord installer les pré-requis à la compilation :

sudo 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

curl -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’à configurer libwebp avant la compilation et l’installation

./configure --prefix=/usr
make -j "$(nproc)"
sudo make install

Vous pouvez ensuite vérifier si vous utilisez la version compilé de cwebp avec la commande

which cwebp

Qui vous retournera normalement /usr/local/bin/cwebp

La conversion des images en WebP

Convertir une image en WebP avec cwebp

La conversion d’une image avec cwebp est on ne peut plus simple puisqu’il suffit de définir l’image à convertir, suivie de l’argument -o permettant de définir le nom du fichier en sortie.

Exemple :

cwebp monimage.png -o monimage.webp

Il est ensuite possible de d’ajouter des paramètres de conversion en passant par des arguments après la commande cwebp

Voici les paramètres principaux à utiliser en arguments avec cwebp :

-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’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’utilisation d’un argument inadapté au type d’image peut rendre le fichier WebP plus lourd que le fichier original.

Pour les images JPEG, il faut privilégier l’usage de l’indice de qualité -q. Pour les images PNG, le plus simple est d’utiliser -z pour définir le niveau de compression en mode lossless.

La liste complète des options est disponible sur le site developers.google.com.

Convertir toutes les images de votre site en WebP

Aprè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’un site web.

Pour cela, il nous faut tout d’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’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’image.

Voici la structure que nous allons utiliser pour nommer les fichiers WebP :

# une image png
monimage.png -> monimage.png.webp

# une image jpg
monimage.jpg -> monimage.jpg.webp

Pourquoi nommer les images converties ainsi ?

Car cette structure va nous permettre d’utiliser la directive Nginx try_files. Ainsi Nginx pourra vérifier l’existence du fichier WebP par rapport à l’image originale.

Lister les images PNG & JPG dans un répertoire

Pour 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’extension du fichier peut-être .jpg ou .jpeg.

On se rend dans le répertoire qui contient les images

cd /votre/répertoire/images

lister les images JPEG

find . -type f \( -iname "*.jpg" -o -iname "*.jpeg" \)

lister les images PNG

find . -type f -iname '*.png'

Convertir les images en WebP conditionnellement

Maintenant 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.

Nous allons donc procéder en deux étapes :

lister les images PNG & JPG
si la version WebP des images n’existe pas, les convertir en WebP

Ce qui nous donne :

Convertir les images PNG

find . -type f -iname "*.png" -print0 | xargs -0 -I {} \
bash -c '[ ! -f "{}.webp" ] && { cwebp -z 9 -mt {} -o {}.webp; }'

convertir les images JPG

find . -type f \( -iname "*.jpg" -o -iname "*.jpeg" \) -print0 | xargs -0 -I {} \
bash -c '[ ! -f "{}.webp" ] && { cwebp -q 82 -mt {} -o {}.webp; }'

Détaillons un peu notre exemple :

On utilise tout d’abord find pour obtenir la liste des images PNG ou JPG dans un répertoire, suivi de l’argument -print0 qui permet de transmettre le nom des fichiers à xargs même s’ils contiennent des caractères spéciaux

On utilise ensuite un pipe | pour connecter cette première commande et récupérer sa sortie standard avec xargs.

Grâce à xargs -0 nous sommes capables de récupérer les résultats obtenu avec find et de les passer en tant qu’argument à la seconde partie de la commande.

Enfin 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’article de Wikipédia sur xargs.

Dans le shell invoqué, on créer la condition “si le fichier monimage.jpg.webp n’existe pas, alors utiliser cwebp” :

[ ! -f "{}.webp" ] && { cwebp -q 82 -mt {} -o {}.webp; }

Img-optimize - Un Script pour optimiser et convertir vos images en Webp

Malgré que la conversion des images en WebP ne soit pas réellement difficile avec cwebp, j’ai publié img-optimize sur Github, un script bash qui permet de réaliser la conversion de vos images en WebP mais également l’optimisation des images au format JPG et PNG, en ajoutant simplement le répertoire qui contient les images en argument.

Pour utiliser le script il vous suffit de clone le dépot :

git clone https://github.com/VirtuBox/img-optimize.git $HOME/.img-optimize

Puis d’ajouter un alias via le fichier .bashrc

echo "alias img-optimize=$HOME/.img-optimize/optimize.sh" >> $HOME/.bashrc
source $HOME/.bashrc

Vous pouvez ensuite optimiser et convertir les images présentes dans un répertoire avec :

img-optimize /dossier/des/images

Le script supporte également les arguments suivants :

Bash script to optimize your images and convert them in WebP
Usage: img-optimize [options] <images path>
If images path isn't defined, img-optimize will use the current directory
 Options:
 --jpg <images path> ..... optimize all jpg images
 --png <images path> ..... optimize all png images
 --webp <images path> ..... convert all images in webp
 --nowebp <images path> ..... optimize all png & jpg images
 --all <images path> ..... 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

Il nous faut ensuite configurer Nginx pour afficher les images en WebP, mais avec plusieurs conditions :

Il faut que la navigateur du visiteur supporte le format WebP
Il faut que la version WebP de l’image existe

Détecter si un navigateur supporte le format WebP

Pour 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 “Requests Headers”. Sur un navigateur compatible comme Google Chrome, on y retrouve la ligne :

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

Où l’on retrouve bien image/webp. Contrairement à un navigateur comme Firefox qui ne supporte pas le format WebP :

Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Définir l’extension à utiliser avec la directive map

La directive map de Nginx est particulièrement intéressante, puisqu’elle permet d’associer des valeurs à plusieurs variables, sans avoir recours au if.

Dans notre cas, nous allons associer la variable $http_accept qui fait partie des “Requests Headers” avec l’extension de nos images, variable que j’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 :

map $http_accept $webp_suffix {
 default "";
 "~*webp" ".webp";
}

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 “webp”, alors $webp_suffix est égale à “.webp”.

Servir sous conditions les versions WebP des images

Pour servir une image au format WebP, les deux conditions sont :

que le navigateur accepte les format WebP
que la version WebP de l’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.

On commence donc par créer un bloc location pour sélectionner les images PNG & JPG :

location ~ \.(png|jpe?g)$ {}

Dans ce bloc, nous allons ajouter plusieurs directives :

add_header Vary "Accept-Encoding"; : permet d’annoncer qu’il peut exister plusieurs versions du même fichier selon les Requests Headers transmis.
add_header "Access-Control-Allow-Origin" "*"; : active les Cross-Origin Resource Sharing (CORS)
try_files $uri$webp_suffix $uri =404; : demande à Nginx d’essayer l’url de l’image suivi de notre variable $webp_suffix, et de vérifier que le fichier existe bien.

On obtient alors :

location ~ \.(png|jpe?g)$ {
 add_header Vary "Accept-Encoding";
 add_header "Access-Control-Allow-Origin" "*";
 try_files $uri$webp_suffix $uri =404;
}

Auquel, on peut ajouter quelques options supplémentaires :

add_header Cache-Control "public, no-transform"; : 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’accès
log_not_found off; : désactive les logs d’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’il s’agit d’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’appliquer cela à l’ensemble d’un site.

Voici un exemple complet à inclure dans un vhost pour WordPress :

location /wp-content/uploads/ {
 location ~ \.(png|jpe?g)$ {
 add_header Vary "Accept-Encoding";
 add_header "Access-Control-Allow-Origin" "*";
 add_header Cache-Control "public, no-transform";
 access_log off;
 log_not_found off;
 expires max;
 try_files $uri$webp_suffix $uri =404;
 }
}

Et un autre exemple pour Ghost :

location /content/images {
 alias /var/www/votredomaine.tld/content/images;
 location ~ \.(png|jpe?g)$ {
 add_header Vary "Accept-Encoding";
 add_header "Access-Control-Allow-Origin" "*";
 add_header Cache-Control "public, no-transform";
 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’article How To Create and Serve WebP Images to Speed Up Your Website publié sur DigitalOcean Community

Migrer ses emails facilement avec imapsync

Sat, 21 Apr 2018 18:53:00 +0000

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’utilisent pas le même software ou lorsqu’il s’agit d’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’hui.

imapsync est comme son nom l’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’IMAP pour récupérer vos emails, ou si vous n’effacez pas vos emails du serveur avec le protocol POP.

Nous 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.

Installer imapsync

Tout d’abord, il faut installer les pré-requis nécessaires à l’éxecution d’imapsync :

 sudo 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 :

sudo cpanm Mail::IMAPClient
sudo cpanm JSON::WebToken

On peut ensuite télécharger imapsync :

sudo wget https://imapsync.lamiral.info/dist/imapsync -O /usr/bin/imapsync

Et il ne reste plus qu’à le rendre éxecutable :

sudo chmod +x /usr/bin/imapsync

Vous pouvez ensuite obtenir la liste des variables disponibles en utilisant la commande imapsync

Synchroniser une boîte mail

Pour lancer la synchronisation d’une boite mail avec imapsync avec uniquement les options requises ressemble à :

 imapsync \
 --host1 serveur1.imap.tld \
	 --user1 boite@email.tld \
	 --password1 motdepasse1 \
	 --host2 serveur2.imap.tld \
	 --user2 boite@email.tld \
	 --password2 motdepasse2

Les options

Les mots de passes

Pour éviter d’avoir à entrer les mots de passe des boîte email en clair, vous pouvez les stockers dans des fichiers et utiliser l’argument --passfile1 et --passfile2 pour les charger automatiquement depuis les fichiers contenant les mots de passe.

Ce qui donne :

 imapsync \
 --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

Plusieurs options sont disponibles pour connecter imapsync à votre serveur mail, notamment le type de connexion utilisée. Par défaut imapsync essaira d’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) :

--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’authentification que l’on peut définir via les arguments --authmech1 et --authmech2 dont les valeurs possibles sont (en majusule) :

PLAIN
LOGIN
CRAM-MD5

Les dossiers

La 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 :

--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

Pour accélerer la migration des emails, vous pouvez utiliser l’argument --usecache afin de stocker temporairement les UIDs des messages et accélérer les synchronisations suivantes (n’accélère pas la première migration). Vous pouvez également supprimer les messages du premier serveur avec l’argument --delete1. Enfin, avant de lancer votre migration, n’hésitez pas à utiliser l’argument --dry pour voir ce que ferai imapsync, sans l’appliquer.

Installer Isso sur Ubuntu 16.04 LTS pour remplacer disqus

Thu, 19 Oct 2017 16:55:39 +0000

Ayant récemment migré de WordPress vers Ghost, j’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.

Nous allons dans ce tutoriel voir comment installer Isso et comment le configurer pour gérer les commentaires de plusieurs sites.

Installer Isso

Pour l’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

adduser isso
adduser isso sudo

On se connecte ensuite avec cet utilisateur

su - isso

Et on commence par installer les paquets nécessaires pour isso

sudo apt-get install python3-setuptools python3-virtualenv python3-dev sqlite3 build-essential

On définit alors notre environnement pour python.

python3 -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’est cette dernière que j’ai utilisé :

pip install isso

On peut ensuite sortir du virtualenv avec la commande :

deactivate

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 :

ln -s /opt/isso/bin/isso /usr/local/bin/isso

Pour mettre à jour isso, il suffit de faire :

source /opt/isso/bin/activate
pip install --upgrade isso
deactivate

Configurer Isso

Nous avons terminé l’installation d’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 :

la base de donnée
la modération
le serveur SMTP

Pour construire vos fichiers de configuration, utilisez l’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 :

mkdir -p /var/lib/isso && 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 :

[general]
name = yourwebsite1
host = http://yourwebsite1.tld/
dbpath = /var/lib/isso/yourwebsite1.db

Importer des commentaires

Avant de démarrer Isso, vous pouvez importer des commentaires provenant de WordPress ou de Disqus. Pour cela utililsez la commande suivante :

isso -c /path/to/isso.cfg import /path/to/disqus-or-wordpress.xml

L’opération est à réaliser pour chaque site.

Configuration du serveur Gunicorn

Pour exécuter Isso en multi-site, nous avons besoin d’installer Gunicorn. Cela se fait avec pip :

pip install gunicorn

On peut désormais lancer Isso, pour cela on définit tout d’abord l’emplacement de nos fichiers de configurations via la commande :

export ISSO_SETTINGS="/etc/isso.d/yourwebsite1.cfg;/etc/isso.d/yourwebsite2.cfg"

Puis on lance Gunicorn :

gunicorn isso.dispatch -b localhost:8080

Configuration de Nginx

Le 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’s encrypt.

On installe donc Nginx si ce n’est pas déjà fait :

wget -O - https://nginx.org/keys/nginx_signing.key | sudo apt-key add -
sudo echo "deb http://nginx.org/packages/ubuntu/ $(lsb_release -sc) nginx" > /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

upstream 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 :

wget -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.

acme.sh --issue -d comments.yourdomain.tld --keylength ec-384 --standalone --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx"

Il ne reste plus qu’à déployer le certificat :

# 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 "service nginx restart"

Et à ajouter la configuration suivante dans votre vhost Nginx :

 listen 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

Pour 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 :

[Unit]
Description=lightweight Disqus alternative

[Service]
User=isso
Group=isso
Environment="ISSO_SETTINGS=/etc/isso.d/foo.example.cfg;/etc/isso.d/other.bar.cfg"
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’activer le service avec systemd pour créer un symkink entre le dossier /lib/systemd/system et /etc/systemd/system avant de le lancer.

systemctl enable isso.service
systemctl start isso.service

Ajouter Isso à son site

Si vous tentez d’accéder au sous-domaine d’Isso, il vous affichera les nom des différents sites sur lesquels vous pouvez installer le module de commentaire, sous la forme :

/yourblogname
/yourblogname2
/yourblogname3

Pour installer Isso sur votre blog, il vous suffit d’insérer le code suivant, en remplaçant yourblogname par le nom de votre blog :

<script data-isso="//comments.example.tld/yourblogname/"
 src="//comments.example.tld/yourblogname/js/embed.min.js"></script>

<section id="isso-thread"></section>

Vous pouvez également ajouter des paramètres via ce code, dont la liste est disponible dans la documentation officielle de Isso.

Ghost 1.0 - Installer Ghost avec ghost-cli et Nginx - Migrer depuis wordpress

Mon, 28 Aug 2017 14:24:14 +0000

Ghost à publié sa nouvelle release 1.0, qui introduit également l’outil ghost-cli permettant d’installer ghost, de le mettre à jour et d’intéragir plus facilement avec la plateforme.

Le thème de base “casper” a également été mis à jour, et je trouve le nouveau design absolument génial, bien que j’ai effectué certaines modifications dans les styles, notamment concernant la dimensions des images.

Je n’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.

Je vais donc expliquer dans cet article comment installer Ghost via l’outil ghost-cli, et comment réaliser la migration depuis WordPress.

Pour résumer les fonctionnalités principales de Ghost :

Articles en markdown
Organisation des articles par tags
Support natif des meta datas
Support natif de l’AMP
Application Desktop

De quoi avons nous besoin ?

Un VPS avec Ubuntu 16.04 LTS
Un serveur MySQL
NGINX
Node v6
Un utilisateur avec sudo

Installation des pré-requis

On 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’appeller ghost, car l’utilisateur ghost sera automatiquement ajouté par ghost-cli

adduser --disabled-password --disabled-login monghost
usermod -aG sudo monghost
su - monghost

On met à jour la liste des paquets et le serveur

sudo apt-get update
sudo apt-get upgrade

On installe la dernière release de nginx

wget -O - https://nginx.org/keys/nginx_signing.key | sudo apt-key add -
sudo echo "deb http://nginx.org/packages/ubuntu/ $(lsb_release -sc) nginx" > /etc/apt/sources.list.d/nginx.list
sudo apt update
sudo apt install nginx

On installe MariaDB 10.3

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \
| sudo bash -s -- --mariadb-server-version=10.3 --skip-maxscale

sudo apt update && sudo apt install mariadb-server

On installe nodejs v8 LTS

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash
sudo apt-get install -y nodejs

Installation de Ghost

On commence par installer ghost-cli

sudo npm i -g ghost-cli

Puis on créer le répertoire pour notre blog

sudo mkdir -p /var/www/ghost
sudo chown monghost:monghost /var/www/ghost
cd /var/www/ghost

Et on peut enfin lancer l’installation de Ghost, qui est totalement interactive et qui va :

Configurer la base de donnée
Installer la dernière version de Ghost
Configurer Ghost
Configurer Nginx et installer un certificat SSL avec Let’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’ajouter votre vhost manuellement.

On lance donc l’installation avec :

ghost install

configuration de nginx

Pour la configuration de Nginx, pour des performances optimales, j’utilise personnellement la fonctionnalité proxy-cache d’Nginx pour mettre en cache les pages du blog, cette technique est également appelée micro-caching puisque le délai d’expiration du cache est relative court mais autorise par contre Nginx à utiliser les fichiers en cache dans le cas ou l’upstream (le serveur nodejs Ghost dans ce cas) est indisponible.

Pour cela je commence par créer un répertoire pour stocker le cache nginx :

sudo 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

proxy_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 "$scheme$request_method$host$request_uri";
 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 "no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0";
 }
 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’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.

Je 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’s Encrypt avec Acme.sh

Mettre à jour Ghost

Là aussi, la nouvelle CLI de Ghost facilite vraiment le processus de mise à jour, puisqu’il suffit de se rendre dans le dossier de votre blog en tant que l’utilisateur définit pour utiliser la CLI puis d’utiliser ghost update

su - monghost
cd /var/www/ghost
ghost update

Migrer depuis WordPress

Pour migrer depuis WordPress, il faut tout d’abord extraire votre contenu au format .json en utilisant le plugin officiel publié par Ghost. Il est disponible dans l’annuaire de plugins WordPress

Après avoir extrait votre contenu, vous pourrez l’importer dans Ghost, il est restera cependant quelques tâches à réaliser manuellement :

Les 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’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’ensemble de vos commentaires et ne pas avoir à utiliser une solution comme disqus.

Mettre en place un serveur mail avec mail-in-a-box sur Ubuntu 18.04 LTS

Sat, 08 Jul 2017 14:07:30 +0000

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.

Article mis à jour le 29/07/2019

Pourquoi mail-in-a-box ?

J’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’un système de backup.

Les principales fonctionnalités sont :

Serveur Mail supportant les protocoles : SPF, DKIM & DMARC
Serveur DNS avec DNSSEC
Certificats SSL/TLS Let’s Encrypt
Webmail Roundcube
Gestion et synchronisation des contacts & 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

Pré-requis :

– 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

On passe à l’installation :

curl -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

Dé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

Sélectionnez votre zone géographique pour mettre à jour le serveur de temps puis validez.

Sélectionnez ensuite la ville correspondant à votre fuseau horaire, dans mon cas Paris.

Une fois l’installation terminée, vous pourrez accéder au panel d’administration via l’adresse : https://IP-de-Votre-Serveur/admin

Configurer le serveur mail

Vous 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.

Cependant, vous pouvez très bien utiliser un service DNS externe et il vous suffira dans ce cas de vous rendre sur la page System > 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.

Les enregistrements nécessaires pour utiliser la box en tant que serveur mail sont :

votredomaine.com MX(10) "box.votredomaine.com" : pour définir la box en tant que serveur mail principal

votredomaine.com TXT "v=spf1 a:box.votredomaine.com -all" : pour spécifier que la box est le seul serveur autorisé à envoyer des emails pour ce domaine

_dmarc.votredomaine.com TXT "v=DMARC1; p=quarantine" : pour indiquer que les emails ne respectant pas les règles DKIM ou SPF doivent être envoyé en quarantaine.

mail._domainkey.votredomaine.com TXT "v=DKIM1; k=rsa; s=email; p=la-signature-très-longue-pour-le-dkim" : qui correspond à la signature DKIM utilisée pour signer les emails sortant de votre serveur.

Mail-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.

Une 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.

Une fois le processus terminé, vous pourrez accéder à l’interface d’administration via l’adresse : https://box.votredomaine.com/admin

N’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

Connecter un client mail

Pour 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 :

IMAP : 993 avec SSL/TLS

POP : 995 avec SSL/TLS

SMTP : 587 avec TLS

Ajouter un domaine

Pour ajouter un domaine, il vous suffit d’aller dans l’onglet Mail > Users et d’ajouter une adresse email utilisant un autre domaine que celui de votre box.

Mail-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.

Mettre à jour mail-in-a-box

Pour la mise à jour de votre serveur mail, rien de plus simple, puisqu’il vous suffit d’utiliser à nouveau la commande d’installation :

curl -s https://mailinabox.email/setup.sh | sudo bash

Backup & Migration

Le 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.

Pour 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.

Vous pourrez ensuite restaurer les données en utilisant l’outil duplicity :

export PASSPHRASE=$(cat your_backup_secret_key_file.txt)
sudo -E duplicity restore --force file:///emplacement/des/backup /home/user-data/

Il suffira ensuite d’utiliser la commande mailinabox pour appliquer à nouveau la configuration du serveur :

sudo mailinabox

Migration d'une instance Mastodon

Thu, 13 Apr 2017 13:40:33 +0000

Pourquoi migrer mon instance Mastodon ?

Une 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.

Non, 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.

Préparer le nouveau serveur

Pour 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.

Installation des dépendances

echo "deb http://ftp.debian.org/debian jessie-backports main" >> /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

curl -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

apt-get -t jessie-backports install postgresql postgresql-contrib
su - postgre
psql
CREATE USER mastodon CREATEDB;
ALTER USER "mastodon" WITH PASSWORD 'new_password';
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 :

wget -qO ee rt.cx/ee && bash ee

Et on installe Nginx et Redis :

ee stack install --nginx --redis

Installation des dépendances pour Ruby :

apt-get install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev

adduser --disabled-password --disabled-login mastodon
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc

Il faut alors se déconnecter puis se reconnecter en tant que mastodon pour appliquer les modifications faites au bash

exit
su - mastodon

On installe ruby-build

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Puis on installe Ruby, en version 2.4.1 désormais

rbenv 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 :

wget 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 :

ee site create votredomaine.com

Vous pouvez ensuite editer /etc/nginx/sites-availables/votredomaine.com, en se basant sur le modèle d’Angristan

map $http_upgrade $connection_upgrade {
 default upgrade;
 '' 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 "max-age=15552000; includeSubDomains; preload";
 add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' wss://votredomaine.com;";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 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

A 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:

systemctl stop mastodon* redis

On dump ensuite l’ancienne base de donnée :

pg_dump mastodon_production > fichier_de_sortie

Pour les fichier, j’ai simplement zippé le dossier /home/mastodon avant de le transférer sur le nouveau serveur avec scp.

zip backupmaston -r /home/mastodon

Pourquoi 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 :

su - postgre
psql mastodon_production < 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 :

chown -R mastodon:mastodon /home/mastodon

Il faut également penser à copier votre certificat Let’s Encrypt

Relancer mastodon après le transfert

Ne 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

su - 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 :

systemctl enable /etc/systemd/system/mastodon-*.service
systemctl start mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service

Mise en place des crons

crontab -e -u mastodon

Et ajouter les lignes

RAILS_ENV=production
@daily cd /home/mastodon/live && /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.

Si vous souhaitez mettre en place une architecture basée sur plusieurs serveurs, je vous recommande l’article matuni.xyz.

Installer une instance Mastodon sur Ubuntu 16.04 LTS

Wed, 05 Apr 2017 20:17:58 +0000

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.

J’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.

Pour 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.

Installer les pré-requis

sudo apt-get update

Installation de nodejs

curl -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

sudo apt-get install redis-server redis-tools

Installation de postgresql

sudo 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 :

sudo sed -i '/^local.*postgres.*peer$/a host all all 127.0.0.1/32 ident' /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

On installe les dépendances pour Ruby.

sudo apt-get install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev

On créer un utilisateur mastodon :

adduser --disabled-password --disabled-login mastodon

Puis on s’identifie avec cet utilisateur

su - mastodon

On installe rbenv et rbenv-build :

adduser --disabled-password --disabled-login mastodon
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
source ~/.bashrc

On se déconnecte pour appliquer la modification au bash, puis on installe ruby-build.

exit
su - mastodon
git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Puis on installe Ruby v2.4.1 pour Mastodon :

rbenv install 2.4.1
rbenv global 2.4.1

On vérifie la version de ruby installé via la commande :

ruby -v

Installation de Mastodon

Nous 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 :

cd ~
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.

echo "gem: --no-document" > ~/.gemrc
gem install bundler --no-ri

Puis on passe à l’installation

bundle install --deployment --without development test
yarn install

On peut désormais copier le fichier de configuration d’exemple et l’éditer avec nos informations :

cp .env.production.sample .env.production
nano .env.production

Les informations à remplir sont :

# 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 :

# 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.

Pour mettre en place l’instance du côté base de donnée et assets :

RAILS_ENV=production bundle exec rails db:setup
RAILS_ENV=production bundle exec rails assets:precompile

Création des services systemd

Pour le processus web

nano /etc/systemd/system/mastodon-web.service

[Unit]
 Description=mastodon-web
 After=network.target

[Service]
 Type=simple
 User=mastodon
 WorkingDirectory=/home/mastodon/live
 Environment="RAILS_ENV=production"
 Environment="PORT=3000"
 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 **

nano /etc/systemd/system/mastodon-sidekiq.service

[Unit]
 Description=mastodon-sidekiq
 After=network.target

[Service]
 Type=simple
 User=mastodon
 WorkingDirectory=/home/mastodon/live
 Environment="RAILS_ENV=production"
 Environment="DB_POOL=5"
 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

nano /etc/systemd/system/mastodon-streaming.service

[Unit]
 Description=mastodon-streaming
 After=network.target

[Service]
 Type=simple
 User=mastodon
 WorkingDirectory=/home/mastodon/live
 Environment="NODE_ENV=production"
 Environment="PORT=4000"
 ExecStart=/usr/bin/npm run start
 TimeoutSec=15
 Restart=always

[Install]
 WantedBy=multi-user.target

On peut alors activer les services :

systemctl enable /etc/systemd/system/mastodon-*.service

Et enfin démarrer l’instance Mastodon :

sudo systemctl start mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service

On ajoute alors les crons nécessaire pour Mastodon :

crontab -u mastodon -e

RAILS_ENV=production
@daily cd /home/mastodon/live && /home/mastodon/.rbenv/shims/bundle exec rake mastodon:daily

Mise en place du reverse-proxy Nginx :

Nous 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.

On commence par installer nginx :

wget -O - https://nginx.org/keys/nginx_signing.key | sudo apt-key add -
sudo echo "deb http://nginx.org/packages/ubuntu/ $(lsb_release -sc) nginx" > /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 :

nano /etc/nginx/sites-enabled/votredomaine.com

map $http_upgrade $connection_upgrade {
 default upgrade;
 '' 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 "max-age=15552000; includeSubDomains; preload";
 add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' wss://votredomaine.com;";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 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 :

cd /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

Mastodon 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.

su - 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

Il ne reste plus qu’à redémarrer l’instance :

sudo systemctl restart mastodon-web.service mastodon-sidekiq.service mastodon-streaming.service

Création du compte administrateur

Votre 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 :

RAILS_ENV=production bundle exec rails mastodon:make_admin USERNAME=votre-utilisateur

Mon instance Mastodon.top

Ayant 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.

N’hésitez pas à donner votre avis sur ce tutoriel, à corriger d’éventuelles erreurs ou à demander de l’aide pour mettre en place votre instance !

Vous pouvez aussi me suivre sur Mastodon : thomas_virtubox@mastodon.top

Installer Ghost avec Nginx proxy-cache et Let'sEncrypt

Wed, 29 Mar 2017 21:17:02 +0000

Cet article est ancien et il peut contenir des instructions qui ne sont plus d’actualité.

Si 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.

Je 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.

1) Installer NodeJs v4 LTS

wget https://deb.nodesource.com/setup_4.x
chmod +x setup_4.x
./setup_4.x
apt-get install nodejs -y

2) Installer Ghost

mkdir /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 :

npm 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 :

npm 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

Nous allons donc passer à la partie configuration de Nginx. Si vous utilisez EasyEngine, vous pouvez créer votre sous domaine en une seule commande :

ee site create votredomaine.com --proxy=127.0.0.1:2368

Ensuite modifiez le fichier de configuration de votre domaine en suivant le modèle ci-dessous.

upstream 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 "no-cache, private, no-store, must-revalidate, max-stale=0, post-check=0, pre-check=0";
 }
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 :

url: 'http://votredomaine.com'

4) Installer Let’s Encrypt

On peut désormais passer à l’installation de Let’s Encrypt si ce n’est pas déjà fait.

cd /opt
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Il ne nous reste plus qu’à générer le certificat via la commande :

./letsencrypt-auto certonly --webroot -w /var/www/html -d votredomaine.com --email votreemail@votredomaine.com --text --agree-tos

Pour utiliser le certificat, ajouter les lignes suivantes après server_name dans votre configuration nginx :

 listen 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;

}

Créez votre seedbox avec qBittorrent et Plex

Wed, 22 Feb 2017 15:26:02 +0000

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.

Et 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 …

J’ai donc souhaité en faire une Seedbox avec Plex & 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 :

wget -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.

Pour 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 :

ssh 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” :

Vous pourrez ensuite via votre navigateur accéder à l’adresse : http://127.0.0.1:32400/web/index.html#

Notre 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 :

apt-get update && apt-get install qbittorrent-nox

On créer ensuite un nouvel utilisateur, qui sera notre utilisateur principal et on déclare qbittorrent en tant que service :

adduser 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.

systemctl 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

L’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 :

systemctl 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.

Pour 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 :

usermod -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.

Cloudron - La solution Self-Hosting facile

Fri, 17 Feb 2017 20:40:39 +0000

Le Self-Hosting c’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.

Sur les aspects comme la sécurité, le self-hosting est d’une certaine façon La solution ultime, cependant cela requiert quelques connaissances.

Mais 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.

Mais Cloudron c’est quoi ?

C’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.

Les fonctionnalités principales

40+ 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 :

Un 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’installation est relativement simple :

wget 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.

Vous pouvez trouvez la documentation complète de Cloudron sur leur site.