Resolve error 526 with Cloudflare and NginX.

Résoudre l’erreur 526 entre Cloudflare et NginX

Dernièrement, je me suis apercu qu’une requête curl sur le domaine skyminds.net (sans www donc), donnait une erreur 526 sous Cloudflare (avec le proxy activé, mais aussi sans):

curl -Ik https://skyminds.net


HTTP/2 526
date: Fri, 18 Aug 2023 23:50:35 GMT
content-type: text/html; charset=UTF-8
content-length: 7111
cf-ray: 7f8e0f5538300636-CDG
cf-cache-status: BYPASS
cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
expires: Thu, 01 Jan 1970 00:00:01 GMT
set-cookie: cf_ob_info=526:7f8e0f55430d0636:CDG; path=/; expires=Fri, 18-Aug-23 23:51:05 GMT
vary: Accept-Encoding
cf-apo-via: origin,resnok
referrer-policy: same-origin
set-cookie: cf_use_ob=443; path=/; expires=Fri, 18-Aug-23 23:51:05 GMT
x-frame-options: SAMEORIGIN
report-to: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v3?s=KQ7z1CYzwZD3r%2FzoJ2QLzFRmcgQzql1Oz3KwXyVnHVWHH5mUgxKqwU8p2%2F0C9rn%2FJUOSQG%2BWZl9%2B%2FDdQSPXznmFKKeiqFdqXzpuGFK5xgZbHAohOVxY4Vk6%2F1bM73jNRhrjfYZ42r6FMJ6c%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
alt-svc: h3=":443"; ma=86400

Sous tous les navigateurs par contre, une brève page d’erreur s’affiche (quelques millisecondes) avant que finalement la redirection vers le sous-domaine www ne s’effectue. Je me suis dis que c’était bizarre et que je réglerais le problème plus tard.

Quelques semaines mois passent et j’effectue une petite visite de routine sur mes sous-domaines, notamment celui de postfixadmin. Et là, patatras : erreur 526 avec le proxy Cloudflare actif, mais aussi une ribambelle d’erreurs selon les navigateurs utilisés:

Échec de la connexion sécurisée Une erreur est survenue pendant une connexion à demo.skyminds.net.

Le pair SSL a rejeté un message d’établissement de liaison à cause d’un contenu inacceptable. Code d’erreur : SSL_ERROR_ILLEGAL_PARAMETER_ALERT

La page que vous essayez de consulter ne peut pas être affichée car l’authenticité des données reçues ne peut être vérifiée. Veuillez contacter les propriétaires du site web pour les informer de ce problème.

Firefox

Ce site est inaccessibleIl se peut que la page Web à l’adresse https://demo.skyminds.net soit temporairement inaccessible ou qu’elle ait été déplacée de façon permanente à une autre adresse Web. ERR_QUIC_PROTOCOL_ERROR

Brave

Bon, il va falloir s’atteler à comprendre ce qui se passe vraiment ici!

Vérification du certificat TLS

On vérifie que le certificat est valide:

echo | openssl s_client -connect skyminds.net:443 -servername skyminds.net 2>/dev/null | openssl x509 -noout -dates

notBefore=Aug  6 12:15:26 2023 GMT
notAfter=Nov  4 12:15:25 2023 GMT

Tout est bon, le certificat est toujours valide.

On vérifie ensuite que les sous-domaines sont bien inclus (au cas où, mais je crée toujours des certificats wildcard par défaut):

echo | openssl s_client -connect skyminds.net:4echo | openssl s_client -connect skyminds.net:443 -servername skyminds.net 2>/dev/null | openssl x509 -noout -text


Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:cc:a2:48:39:97:ea:6c:d0:5d:86:5a:e3:f8:e3:d3:b2:1a
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = Let's Encrypt, CN = E1
        Validity
            Not Before: Aug  6 12:15:26 2023 GMT
            Not After : Nov  4 12:15:25 2023 GMT
        Subject: CN = skyminds.net
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:69:84:99:0b:ea:1b:6f:38:ac:ee:fa:76:7d:4f:
                    59:01:02:bd:6e:d8:25:83:a7:8a:c5:d5:a4:b9:c5:
                    64:65:2d:49:20:3d:bc:4c:06:38:7d:73:d0:c0:55:
                    0b:90:cf:44:f7:5a:8c:37:8f:f9:da:51:eb:c3:f0:
                    5b:87:ce:00:ba
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                E7:3A:09:C3:D5:75:02:65:A6:D7:7D:12:D4:F3:5D:42:72:11:75:B4
            X509v3 Authority Key Identifier:
                5A:F3:ED:2B:FC:36:C2:37:79:B9:52:30:EA:54:6F:CF:55:CB:2E:AC
            Authority Information Access:
                OCSP - URI:http://e1.o.lencr.org
                CA Issuers - URI:http://e1.i.lencr.org/
            X509v3 Subject Alternative Name:
                DNS:*.skyminds.net, DNS:skyminds.net
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 7A:32:8C:54:D8:B7:2D:B6:20:EA:38:E0:52:1E:E9:84:
                                16:70:32:13:85:4D:3B:D2:2B:C1:3A:57:A3:52:EB:52
                    Timestamp : Aug  6 13:15:26.501 2023 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : B7:3E:FB:24:DF:9C:4D:BA:75:F2:39:C5:BA:58:F4:6C:
                                5D:FC:42:CF:7A:9F:35:C4:9E:1D:09:81:25:ED:B4:99
                    Timestamp : Aug  6 13:15:26.502 2023 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
    Signature Algorithm: ecdsa-with-SHA384
    

Le certificat couvre bien skyminds.net et *.skyminds.net, donc tous les sous-domaines.

Lire la suite

wordpress rocketstack

WordPress Rocket Stack : envoyez WordPress sur orbite !

Sur Orion, j’ai installé ma WordPress Rocket Stack qui est configurée avec la stack suivante:

  • Ubuntu Server 22.04 LTS
  • MySQL 8+
  • NginX 1.25+
  • PHP 8.0
  • Redis
  • Nginx FastCGI Cache
  • Fail2ban
  • Letsencrypt avec acme.sh

Hébergement

L’hébergement est la base de votre site, c’est tout simplement la fondation sur laquelle va reposer votre code.

Vous avez tout intérêt à avoir un très bon hébergeur : il doit être rapide dès le départ et offrir de bonnes garanties en termes de performance et de sécurité.

Si vous avez un site WordPress ou WooCommerce, je ne peux que vous recommander Kinsta, WPEngine ou Nexcess. Tous trois sont de très bons hébergeurs, particulièrement orientés vers la performance avec des ressources garanties et un support technique réactif et efficace en cas de besoin.

Personnellement, j’utilise un serveur dédié chez OVH parce que j’héberge pas mal de sites et j’ai besoin d’avoir un contrôle fin sur la configuration de chacun des services.

Ubuntu Server

J’étais auparavant sous Debian mais j’ai finalement opté pour Ubuntu Server 22.04 LTS pour ce nouveau serveur.

L’avantage d’Ubuntu est de pouvoir disposer des mises à jour plus rapidement que sous Debian.

Installation de la WordPress Rocket Stack

# MySQL
# Latest link is always on the apt page: https://dev.mysql.com/downloads/repo/apt/
wget -c https://dev.mysql.com/get/mysql-apt-config_0.8.23-1_all.deb
dpkg -i mysql-apt-config_0.8.23-1_all.deb

# Packages
apt install software-properties-common tmux curl wget zip unzip git
add-apt-repository ppa:ondrej/php
add-apt-repository ppa:ondrej/nginx-mainline
apt update -y
apt upgrade -y
apt install mysql-server -y # accept all defaults

# PHP 8.0
# Note: the json module is now part of PHP core
apt install php8.0 php8.0-bcmath php8.0-curl php8.0-gmp php8.0-imap php8.0-mbstring php8.0-readline php8.0-xml php8.0-apcu php8.0-cli php8.0-fpm php8.0-igbinary php8.0-intl php8.0-mysql php8.0-redis php8.0-zip php8.0-common php8.0-gd php8.0-imagick php8.0-opcache php8.0-soap -y

# Run installs
apt install nginx -y
apt install fail2ban -y
apt install redis -y

# Get NginX config files
git clone https://github.com/skyminds/wordpress-rocketstack
cp wordpress-rocketstack/nginx/* /etc/nginx/ -R
rm wordpress-rocketstack

DNS : ajout du site sur le serveur

Mon serveur est hébergé chez OVH donc il faut ajouter le domaine aux DNS secondaires du serveur.

Sur l’interface Kimsufi, cela se fait très simplement:

Ajouter le domaine au serveur (dns secondaire)
Ajouter le domaine au serveur (dns secondaire)

Configurer Cloudflare

Si vous utilisez Cloudflare – ce que je vous recommande fortement – et que vous obtenez une erreur 403 ou alors une page “Welcome to NginX” en lieu et place de votre nouveau site, veillez bien à sélectionner la bonne option SSL dans Cloudflare > Example.com > SSL/TLS > Overview : il faut sélectionner Full ou Full (Strict) mais surtout pas “Flexible“:

Choisissez toujours l'option SSL/TLS Full (Strict) chez Cloudflare
Choisissez toujours l’option SSL/TLS Full (Strict) chez Cloudflare

Ensuite, il ne nous reste qu’à faire pointer le CNAME vers l’adresse IP du serveur et d’ajouter le champs TXT qui a été indiqué par OVH dans l’étape précédente:

Ajout de l'enregistrement DNS au format TXT pour valider le DNS secondaire chez OVH
Ajout de l’enregistrement DNS au format TXT pour valider le DNS secondaire chez OVH

Ajout du server block NginX

DOMAIN="example.com"
DOMAINDIR="example"

mkdir -p /home/www/$DOMAINDIR
chown www-data:www-data /home/www/$DOMAINDIR

mkdir -p /home/nginx-cache/$DOMAINDIR
chown -R www-data:www-data /home/nginx-cache/

cp /etc/nginx/sites-available/wprocketstack.conf /etc/nginx/sites-available/$DOMAINDIR.conf

rm /etc/nginx/sites-enabled/default
rm /etc/nginx/sites-available/default

On édite ensuite la configuration:

nano /etc/nginx/sites-available/$DOMAINDIR.conf

Mettez l’adresse du site dans la directive server_name:

server_name example.com

Lire la suite

No hotlinking for images

NginX: éviter le hotlinking

Le hotlinking

Le hotlinking (ou liaison automatique ; aussi connu en anglais sous les noms de inline linking, leeching, piggy-backing, direct linking ou offsite image grabs) consiste à utiliser l’adresse d’un fichier publié sur un site web, le plus souvent une image, pour l’afficher sur un autre site, sur un blog, dans un forum, etc.

En d’autres termes, au lieu d’enregistrer l’image et de l’installer sur son propre serveur Web, le hotlinkeur crée un lien direct vers le serveur d’origine.

Désactiver le hotlinking sous NginX

Sous NginX, il peut être très utile d’éviter que des gens publient vos photos ou images depuis votre site sur le leur, en gardant les liens de votre serveur et en consommant toute votre bande passante (ce qui peut représenter un surcoût pour vous).

Il suffit d’éditer votre server block et d’y ajouter cette directive:

location ~ .(gif|png|jpeg|jpg|svg)$ {
     valid_referers none blocked ~.google. ~.bing. ~.yahoo. ~.facebook. ~.pinterest. ~.twitter. yourdomain.com *.yourdomain.com server_names;
     if ($invalid_referer) {
        return   403;
    }
}

N’hésitez pas à rajouter les domaines que vous souhaitez whitelister et qui sont autorisés à utiliser vos fichiers média.

Relancez ensuite NginX avec:

service nginx restart

Cela devrait quelque peu soulager votre serveur et garantir votre bande passante à vos visiteurs.

The SEO Framework : résoudre l'erreur 404 du fichier sitemap.xml sous NginX photo

The SEO Framework : résoudre l’erreur 404 du fichier sitemap.xml sous NginX

Cela fait belle lurette que j’ai troqué Yoast SEO pour The SEO Framework, qui est bien mieux codé et plus performant.

Récemment, lors d’un changement de serveur, je me suis aperçu que l’un des sites avait son fichier sitemap.xml qui renvoyait une erreur 404 sous NginX.

Si cela vous arrive, deux solutions s’offrent à vous.

Vérification du server block

Commencez d’abord par vérifier que votre serveur block contient les bonnes directives pour gérer les règles de WordPress:

location / {
        # This is cool because no php is touched for static content.
        # include the "?$args" part so non-default permalinks doesn't break when using query string
        try_files $uri $uri/ /index.php?$args;
}

Sauvez votre server block puis relancez NginX. Il est possible que cela ne soit pas suffisant, si c’est le cas, nous allons ajouter une directive supplémentaire.

Une directive dédiée pour sitemap.xml

Ajoutons une directive supplémentaire à notre server block, qui permettra de rediriger vers la sitemap générée par The SEO Framework :

# sitemap.xml directive
# Matt Biscay
# https://www.skyminds.net/?p=30771
location = /sitemap.xml {
	rewrite ^/sitemap.xml$ "/?the_seo_framework_sitemap=xml" permanent;
}

Sauvez les changements et rechargez NginX – boom, la sitemap est de retour!

NginX : résoudre

NginX : résoudre “upstream sent too big header while reading response header from upstream”

Nginx: des entêtes trop larges

Lors de la mise en ligne d’un nouveau site, je suis tombé sur une page qui ne fonctionnait pas et donnait une erreur 502 avec ce message dans les logs:

upstream sent too big header while reading response header from upstream

Solution: augmenter la taille des entêtes

Si votre serveur utilise NginX, il suffit d’ajouter ces deux lignes à votre server block pour que tout rentre dans l’ordre:

fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;

L’augmentation de la taille des buffers permet d’envoyer toutes les données d’un coup d’un seul, ce qui résout l’erreur.

Il ne reste plus ensuite qu’à relancer le serveur NginX:

service nginx restart

Hop, problème réglé.

PHP : configurer un pool PHP pour chaque site photo

PHP : configurer un pool PHP pour chaque site

Au départ, ce serveur n’avait qu’un seul site – celui que vous lisez en ce moment ;) – mais au fil du temps, plusieurs sites sont venus s’installer dans son giron.

Au début, nous n’avions donc besoin d’une seule configuration PHP – www.conf par défaut – qui est un pool (ou conteneur) selon la terminologie PHP.

Ce fichier de configuration dicte le nombre de threads PHP à lancer, les permissions, etc.

Afin de monter en charge et fournir à chaque site les ressources qui lui sont nécessaires, adoptons la stratégie “un site, un pool”.

Mise en place du nouveau pool PHP

Pour être sûr de partir d’une base éprouvée, copions notre pool de départ dans un nouveau fichier :

cp /etc/php/7.2/fpm/pool.d/www.conf /etc/php/7.2/fpm/pool.d/skyminds.conf

Editons ensuite notre pool :

nano /etc/php/7.2/fpm/pool.d/skyminds.conf

1. Nom du pool : remplacez [www] par le nom de votre site, ici [skyminds] de manière à pouvoir l’identifier plus aisément.

2. Vérifiez l’utilisateur et le groupe dans les directives user et group.

3. On modifie le nom du site dans la directive listen en utilisant le nom du pool que vous avez choisi dans l’étape 1:

listen = /run/php/skyminds.sock

Mise à jour de la configuration NginX

Il nous reste maintenant à mettre à jour la configuration du site :

nano /etc/nginx/sites-available/skyminds.net

Mettez à jour cette ligne (même chemin que la directive listen dans la configuration PHP):

fastcgi_pass unix:/run/php/skyminds.sock;

Relancez les services PHP et NginX:

service php7.4-fpm restart && service nginx restart

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Ajouter un nouveau site WordPress dans un répertoire, sans conflit avec le site principal photo

Nginx : créer un nouveau site WordPress dans un sous-répertoire, sans conflit avec le site principal

Dernièrement, j’ai développé un nouveau site WordPress pour une cliente dont l’hébergement ne prévoit pas de staging site, ce qui est un peu ballot.

Plutôt que d’utiliser son hébergeur, je me suis dit que j’allais travailler sur la nouvelle version depuis un répertoire sous SkyMinds.

Le problème s’est assez rapidement posé : les diverses règles de configuration de SkyMinds (à la racine du domaine) entrent en conflit avec le nouveau site qui se trouve dans un répertoire. Il est donc nécessaire d’ajuster la configuration du bloc serveur NginX.

J’ai bien sûr effectué quelques recherches sur le net et après moults tests, il s’avère que la plupart des configurations nginx que l’on y trouve sont erronées. En relisant les docs, j’ai fini par trouver une solution satisfaisante.

Des erreurs 404, 403 ou 500

Je mentionnais à l’instant les configurations erronées – elles ne permettent pas au nouveau site d’afficher les pages correctement : erreur 404 pour les pages, erreur 404 pour la partie administration ou alors erreur 403 ou même 500…

Le plus surprenant est que l’on retrouve quasiment ces mêmes configurations dans tous les tutoriels. Cela fonctionnait peut-être à une époque mais plus maintenant avec les dernières versions de WordPress et NginX.

La configuration qui fonctionne

Voici donc la configuration que j’ai concoctée et qui permet d’avoir un autre site WordPress (comme par exemple https://example.com/nouveau-site/) lorsqu’un site WordPress (de type https://example.com) existe déjà à la racine du domaine. Le but est donc d’avoir deux sites fonctionnels qui n’entrent pas en conflit au niveau de la gestion des règles.

On édite le server block de notre domaine :

nano /etc/nginx/sites-available/example.com

Dans la partie server de la configuration, on ajoute :


# Script name : Add new WP site in subfolder
# Author : Matt Biscay
# Author URI : https://www.skyminds.net/?p=29604

# Add new location point with rewrite rule
location @nouveausite{
rewrite . /nouveau-site/index.php last;
}

# Add subfolder config
location  /nouveau-site {
         root /home/example/public_html/nouveau-site;
         index index.php;
         try_files $uri $uri/ @nouveausite;
}

Sauvegardez le fichier. On teste la nouvelle configuration:

nginx -t

et on relance nginx et PHP:

service nginx restart 
service php7.2-fpm restart

Et voilà, le nouveau site dans son répertoire devrait maintenant être fonctionnel, sans conflit avec le site principal.

Serveur dédié : transférer et héberger un nouveau domaine sur votre serveur photo

Serveur dédié : transférer et héberger un nouveau domaine sur votre serveur

Aujourd’hui, nous allons voir comment héberger un nouveau domaine sur le serveur, en simplifiant au maximum les procédures.

Serveur dédié : transférer et héberger un nouveau domaine sur votre serveur photo

Le nom de domaine sera réservé chez OVH et le site hébergé sur notre serveur Debian. Nous allons servir le site avec NginX en HTTPS grâce à un certificat SSL fourni gratuitement par Let’s Encrypt.

Enfin, on utilisera le serveur email existant et on ajoutera la configuration OpenDKIM pour signer et authentifier tous les emails sortants du domaine.

Nom de domaine

J’achète mes noms de domaine chez OVH parce que le prix est relativement raisonnable (comparé à mon ancien registrar).

Au moment de la commande, faites pointer le nouveau domaine vers les DNS du serveur.

Si votre serveur n’est pas chez OVH, il suffit d’aller dans Domaines > Serveurs DNS et de renseigner le DNS primaire et secondaire de votre serveur.

Configuration DNS dans BIND

Une fois le domaine commandé, si vous vous rendez dans le Manager OVH, vous vous rendrez compte que le bouton DNS est en rouge : c’est normal puisqu’il nous faut paramétrer notre nouveau domaine dans BIND, notre serveur de noms.

On édite la configuration de BIND :

nano /etc/bind/named.conf.local

et on lui indique que nous créons une nouvelle zone :

zone "example.com" {
        type master;
        file "/etc/bind/example.com.hosts";
        allow-query { any; };
};

On crée maintenant notre fichier de zone:

nano /etc/bind/example.com.hosts
$ttl 84600
$ORIGIN example.com.

@       IN      SOA     XXXXXX.kimsufi.com. root.example.net. (
                        2018012801
                        14400
                        3600
                        604800
                        84600 )

; NAMESERVERS
 IN     NS      XXXXXX.kimsufi.com.
 IN     NS      ns.kimsufi.com.

example.com.   IN      A       XXX.XXX.XXX.XXX
example.com.   IN      AAAA    4001:41d0:1:4462::1
example.com.   IN      MX      10 mail.example.net.

www.example.com.       IN      A        XXX.XXX.XXX.XXX
www.example.com.       IN    AAAA    4001:41d0:1:4462::1
www       IN A          XXX.XXX.XXX.XXX

Ps: example.net est le domaine principal du serveur.

Pous vérifions la configuration BIND:

named-checkconf -z

et nous redémarrons BIND pour prendre en compte nos changements et activer notre nouveau fichier de zone:

service bind9 restart

Vous pouvez vérifier votre configuration DNS à l’aide de l’outil ZoneMaster.

Configuration du bloc serveur sous NginX

On commence par créer le répertoire qui va accueillir les fichiers du site et on lui attribue les bons droits:

mkdir -p /home/example/public_html
chown -R www-data:www-data /home/example/public_html
chmod 755 /home/example/public_html

On crée également un fichier index.php à la racine du site pour éviter une erreur 403 plus tard lors de la génération du certificat SSL :

echo "" >> /home/example/public_html/index.php

On crée maintenant le répertoire de cache du site, toujours avec les bons droits:

mkdir -p /home/nginx-cache/example
chown -R www-data:www-data /home/nginx-cache/example
chmod 755 /home/nginx-cache/example

Voici le server block de départ, en HTTP simple :

server {
       listen         80;
       listen    [::]:80;
       server_name    example.com www.example.com;
       #return         301 https://$server_name$request_uri;
        root /home/example/public_html;
        index index.php index.html;
}

On active le site :

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

On teste la configuration de NginX et on redémarre le service:

nginx -t
service nginx restart

On crée maintenant le certificat SSL avec Let’s Encrypt :

certbot certonly --webroot -w /home/example/public_html -d example.com -d www.example.com

Lire la suite

Serveur dédié : configurer Apache et NginX pour servir des polices de caractères photo

Serveur dédié : configurer Apache et NginX pour servir des polices de caractères

La plupart des sites modernes font appel à des polices de caractères qui ne sont pas installées sur les systèmes d’exploitation de leurs visiteurs.

L’utilisation de Google Fonts est très largement répandue mais cela ajoute un délai de traitement dans le chargement des pages car cela nécessite autant de requêtes externes.

Il est également possible de placer les fichiers dans le répertoire du thème graphique et de les servir directement depuis le serveur de fichier, comme Apache ou NginX.

Tout d’abord, il faut configurer les bons entêtes http. Cela permet aux navigateurs de bien interpréter les fichiers demandés comme polices de caractères.

Configuration des polices pour Apache

Pour définir le bon mime-type pour les polices, ajoutez ce bloc à votre configuration Apache:

AddType application/x-font-ttf ttc ttf
AddType application/x-font-otf otf
AddType application/font-woff woff
AddType application/font-woff2 woff2
AddType application/vnd.ms-fontobject eot

Si vous n’avez pas accès à la configuration du VirtualHost, placez ce bloc dans le fichier .htaccess du site.

Pour les entêtes CORS, ajoutez ce bloc:

<filesmatch ".(eot|ttf|otf|woff|woff2)"="">
  Header set Access-Control-Allow-Origin "*"

Configuration des polices pour NginX

LA configuration par default de NginX ne prend pas en compte les types mime des formats de fontes optimizés pour le web.

Il est à noter également que le type mime des fichiers .eot est erroné, il nous faut donc le modifier.

1. Editez le fichier /etc/nginx/mime.types et supprimez la ligne concernant l’extension eot.

2. Ensuite, ajoutez ce bloc :

application/x-font-ttf ttc ttf;
application/x-font-otf otf;
application/font-woff woff;
application/font-woff2 woff2;
application/vnd.ms-fontobject eot;

3. Pour les entêtes CORS, ajoutez ce bloc à la configuration du vhost:

location ~* \.(eot|otf|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin *;
}

Et voilà, votre serveur de fichier est maintenant capable de servir vos fichiers de polices de caractères.

Il est recommandé de ne pas abuser des fontes de caractères : pas plus de 3 familles de fontes différentes sur un site web. Les navigateurs ayant chacun leurs petites subtilités et standards, ils ne se sont toujours pas mis d’accord sur un seul et même format de fichier.

En pratique, les formats WOFF2 et WOFF sont à privilégier (ils couvrent plus de 96% des utilisateurs) mais suivant le public ciblé, il faut penser à offrir les autres variantes de fichiers.

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian photo

Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Aujourd’hui, nous sautons le pas et passons du serveur Apache au serveur NginX (à prononcer “engine X”) pour booster les performances générales du site.

Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian photo

Cela fait quelques serveurs que je monte pour d’autres en utilisant nginx et force est de constater que c’est beaucoup plus réactif qu’Apache et cela prend moins de temps à configurer pour optimiser les réglages.

Je pars du principe que c’est une nouvelle installation mais si vous aviez déjà votre site qui tournait sous Apache, certaines étapes seront juste optionnelles.

Ce tutoriel vise un serveur Debian mais est adaptable sans problème à ses dérivés comme Ubuntu ou Mint.

Etape 1 : NginX

Nous allons installer la dernière version du serveur nginx, avec le support pour HTTP2, depuis les dépôts Sury :

nano /etc/apt/sources.list

et nous ajoutons :

# SURY, post-Dotdeb
deb https://packages.sury.org/php/ stretch main
deb https://packages.sury.org/nginx-mainline/ stretch main
deb https://packages.sury.org/mariadb/ stretch main

On rafraîchit les dépôts :

apt update

et on installe nginx et openssl :

apt install nginx openssl libssl1.0.2 libssl1.0.1 libssl-dev

Etape 2 : MariaDB

Si vous ne l’avez pas déjà – cela remplace MySQL sans que vous n’ayez rien à changer au niveau du code ou de la configuration du serveur :

apt install mariadb-server

Etape 3 : PHP

Je vous conseille de suivre mon dernier guide pour installer PHP 7.1.

Etape 4 : configurer NginX

Nous allons d’abord configurer toutes les options qui nous sont primordiales : compression des fichiers statiques, implémentation SSL, types mime… afin de gagner du temps (et éviter les erreurs) dans l’étape suivante.

1. Nous voulons un site rapide donc nous allons compresser tout ce qui peut l’être. On crée un nouveau fichier :

nano /etc/nginx/snippets/gzip-config.conf

et on y met :

# MATT : add more mime-types to compress
types {
	application/x-font-ttf           ttf;
	font/opentype                    ott;
}

# MATT : gzip all the things!
 gzip on;
 gzip_disable "msie6";
 gzip_vary on;
 gzip_proxied any;
 gzip_comp_level 6;
 gzip_min_length 256;
 gzip_buffers 16 8k;
 gzip_http_version 1.1;
 #gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  # Compress all output labeled with one of the following MIME-types.
 gzip_types
    application/atom+xml
    application/javascript
    application/json
    application/ld+json
    application/manifest+json
    application/rss+xml
    application/vnd.geo+json
    application/vnd.ms-fontobject
    application/x-font-ttf
    application/x-web-app-manifest+json
    application/xhtml+xml
    application/xml
    font/opentype
    image/bmp
    image/svg+xml
    image/x-icon
    text/cache-manifest
    text/css
    text/plain
    text/vcard
    text/vnd.rim.location.xloc
    text/vtt
    text/x-component
    text/x-cross-domain-policy;
# text/html is always compressed by gzip module
# don't compress woff/woff2 as they're compressed already

J’ai ajouté deux types mime qui ne sont pas dans la configuration de base d’NginX et étendu la liste des types de fichiers à compresser. Certains types le sont déjà donc c’est inutile de gaspiller des ressources en essayant de les compresser.

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Serveur dédié : mise à jour vers PHP7.1 sous Debian photo

Serveur dédié : mise à jour vers PHP7.1 sous Debian

Aujourd’hui, le serveur passe à PHP7.1 !

Ce tutoriel aborde le passage de PHP7.0 à PHP7.1 sur une Debian stable (Jessie).

L’opération prend une vingtaine de minutes, en comptant les opérations de vérifications (pre-flight checks en anglais).

La retraite PHP chez Dotdeb

Guillaume Plessis, qui maintient Dotdeb, a récemment annoncé que pour des raisons personnelles et professionnelles, Dotdeb ne fournira plus les mises à jour de PHP passé la version 7.0.

Je comprends sa décision : c’est chronophage et il faut pouvoir être en mesure de répondre aux commentaires et attentes d’une foule de personnes qui utilisent ce dépôt. Pas toujours simple. Merci Guillaume pour tout le travail accompli !

Vérification de la compatibilité PHP7.x sous WordPress

Si votre site tourne sous WordPress, il existe un plugin très utile – PHP Compatibility Checker – qui permet de vérifier que la mise à jour n’impactera pas votre site.

Je pense notamment aux plugins dont certains peuvent être assez vieillots et dont les fonctions peuvent être maintenant obsolètes.

Lancez-le avant de faire la mise à jour. S’il rapporte des warnings, ce n’est pas un problème. Si ce sont des erreurs par contre, mieux vaut y jeter un oeil avant de mettre à jour votre serveur.

Nouveau dépôt PHP : Ondrey Sury

Si l’on veut PHP7.1, il faut donc changer de dépôt et utiliser celui d’Ondrey Sury.

On installe donc ce nouveau dépôt :

apt install apt-transport-https lsb-release ca-certificates
wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" >> /etc/apt/sources.list

Installation de PHP7.1

On met à jour et on installe PHP7.1 :

apt update && apt upgrade

Résultat :

The following NEW packages will be installed:
  libzip4 php7.1-cli php7.1-common php7.1-curl php7.1-fpm php7.1-gd php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-opcache php7.1-readline php7.1-xml php7.1-xmlrpc
The following packages will be upgraded:
  libssl-doc libssl1.0.2 php-common php-curl php-fpm php-gd php-mbstring php-mcrypt php-xml php-xmlrpc php7.0 php7.0-bcmath php7.0-cli php7.0-common php7.0-curl php7.0-fpm php7.0-gd php7.0-json php7.0-mbstring php7.0-mcrypt php7.0-mysql php7.0-opcache php7.0-readline php7.0-soap php7.0-xml php7.0-xmlrpc php7.0-zip

On installe les paquets manquants :

php7.1-mysql php7.1-soap

Lire la suite