Un nouvel hébergeur

Souvenez-vous, mon blog est hébergé sur un VPS. C’est donc à moi de maintenir le système à jour. Et vu que l’OS est encore un Ubuntu 16.04, je ne l’avais pas fait depuis longtemps. La mise à jour ne fonctionne pas, je décide donc de réinstaller via l’interface web de mon fournisseur. Et c’est là que les ennuis commencent. Ubuntu 20.04 refuse de s’installer et le support technique est catastrophique.

Je suis donc contraint de changer de fournisseur. Je continue de soutenir la french tech et choisis OVH. J’ai choisi l’offre la moins chère : VPS Starter (1 vCPU 2 GB RAM 20 GB disk) pour 3,6 € par mois. Après quelques minutes, j’ai un nouveau serveur fraichement installé avec Ubuntu 20.04.

La configuration SSH

Juste après l’installation, je fais la configuration minimale pour SSH :

  • je change le port par défaut du serveur SSH pour réduire radicalement les attaques de bots. journalctl montre que ces erreurs disparaissent. 
    sshd[2823]: Invalid user admin from 186.89.246.141 port 24850
sshd[2823]: pam_unix(sshd:auth): check pass; user unknown
sshd[2823]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=186.89.246.141
sshd[2823]: Failed password for invalid user admin from 186.89.246.141 port 24850 ssh2
sshd[2823]: Connection closed by invalid user admin 186.89.246.141 port 24850 [preauth]
  • je mets à jour l’entrée pour mon VPS dans ~/.ssh/config (avec le nouveau port)
  • je copie ma clé SSH sur le serveur avec ssh-copy-id pour me connecter sans mot de passe

La configuration NGINX

J’utilise la configuration par défaut pour /etc/nginx/nginx.conf. Je dois juste :

  • copier la config du blog dans /etc/nginx/sites-available/blog
  • ajouter le lien symbolique vers /etc/nginx/sites-enabled
  • copier le contenu statique dans /var/www/yannmoisan.com
    • créer le répertoire : sudo mkdir -p /var/www/yannmoisan.com
    • changer le propriétaire : sudo chown ubuntu:ubuntu /var/www/yannmoisan.com
    • synchroniser le contenu : rsync -a _site/ blog:/var/www/yannmoisan.com
  • recharger nginx : systemctl reload nginx

HTTPS

Mon site n’était pas disponible en HTTPS. J’ai suivi la documentation pour utiliser Let’s encrypt avec NGINX. L’outil modifie la configuration NGINX; le traffic HTTP est ainsi redirigé en HTTPS. Le cadenas dans le navigateur montre bien que tout fonctionne.

HTTP/2

HTTPS est un prérequis pour HTTP/2. J’ai donc pu l’activer simplement en modifiant la ligne listen 443 ssl; par listen 443 ssl http2;

Sécurité

Le site webpagetest permet de tester la performance de son site. Ma note en sécurité est F. DigitalOcean offre un outil pour configurer nginx. J’ai recopié les valeurs de security.conf qui permettent d’ajouter des headers de sécurité.

On peut utiliser httpie pour vérifier

❯ http https://www.yannmoisan.com
HTTP/1.1 200 OK
...
Content-Security-Policy: default-src 'self' http: https: data: blob: 'unsafe-inline'
Referrer-Policy: no-referrer-when-downgrade
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

Ma note est maintenant A+.

Performance

webpagetest a aussi détecté un problème sur le cache des fonts et un problème sur la compression de certains fichiers.

Après les correctifs, voici l’évolution des différents scores :

  Security score First Byte Time Keep-alive Enabled Compress Transfer Compress Images Cache static content
avant F B A C A C
après A+ A A A A A

Vous pouvez consulter le résultat.

lighthouse est un autre outil populaire. Vous pouvez tester votre site sur web.dev. Un problème remonté est render-blocking resources. Pour résoudre cela, j’ai hébergé les fonts google sur mon serveur comme recommandé ici ou là. La métrique First Contentful Paint est ainsi passé de 2.5 s à 1 s

Migration à jekyll

Mon blog était généré par un script shell maison. Même si cela était intéressant à faire, le code est devenu peu lisible et peu maintenable. Il existe aujourd’hui de nombreux générateurs de sites statiques et j’ai migré sur une solution éprouvée : jekyll et ainsi soigner un peu mon syndrome NIH.

Jusqu’ici, j’écrivais mes articles en HTML. Ce qui est pénible à la longue. Jekyll supportant HTML et Markdown, j’ai migré tous mes posts en Markdown avec l’aide de pandoc.

Et pour finir, j’ai opté pour le thème par défaut : minima. Le site s’affiche mieux sur mobile (à croire que le dev front est un vrai métier).

URL canonique

Mon site était disponible à travers ces 2 urls : http://www.yannmoisan.com et http://yannmoisan.com. Le support de HTTPS a encore ajouté deux nouvelles variantes : https://www.yannmoisan.com et https://yannmoisan.com. Afin d’aider les moteurs de recherche à ne pas détecter ces contenus comme dupliqués, j’ai déclaré une URL canonique sur chaque page.

<link rel="canonical" href="https://www.yannmoisan.com/mise-a-jour-technique-blog.html"/>

L’impact devrait être visible dans la google search console.

Problèmes restants

  • l’administration du système m’incombe (mise à jour des paquets, …)
  • la configuration du serveur est manuelle (elle pourrait être automatisée avec ansible par ex.)
  • il n’y a pas de haute disponibilité. Mon site est inaccessible lors d’un incident comme l’incendie du 10/03/2021..

Nous faisons actuellement face à un incident majeur au sein de notre datacentre de Strasbourg, avec un feu déclaré dans le bâtiment SBG2.

  • il y a peu de monitoring

Liens