Tag: apache

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

3 October 202105 janvier 2018 by Matt Biscay · Lecture: 2 minutes

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

« Serveur dédié : créer un certificat ECDSA avec Let’s Encrypt

Serveur dédié : mise à jour vers PHP 7.2 »

PHP : résoudre l’erreur “PHP Fatal error: Uncaught Error: Class DOMDocument”

12 March 202226 juin 2016 by Matt Biscay · Lecture: 2 minutes

Aujourd’hui, petite mise à jour mineure de PHP7, en utilisant les dépôts DotDeb.

Le problème : PHP-FPM désactivé par défaut

A la fin de l’installation, j’obtiens ce message d’avertissement :

Setting up php7.0-fpm (7.0.8-1~dotdeb+8.1) ...
Installing new version of config file /etc/init.d/php7.0-fpm ...
NOTICE: Not enabling PHP 7.0 FPM by default.
NOTICE: To enable PHP 7.0 FPM in Apache2 do:
NOTICE: a2enmod proxy_fcgi setenvif
NOTICE: a2enconf php7.0-fpm
NOTICE: You are seeing this message because you have apache2 package installed.
[ ok ] Restarting PHP 7.0 FastCGI Process Manager: php-fpm7.0.

C’est bien la première fois qu’une mise à jour de PHP désactive PHP-FPM, ce n’est pas vraiment une mise à jour mineure et sans accroc.

On réactive donc les deux modules indiqués et on relance la configuration de PHP-FPM avant de relancer Apache et PHP-FPM :

a2enmod proxy_fcgi setenvif
a2enconf php7.0-fpm
service apache2 restart && service php7.0-fpm restart

Je lance le site : page d’erreur de certificat la première fois, et page blanche ensuite !

Des modules PHP à installer séparément

Après analyse des dernières lignes du fichier log d’Apache, je me suis rendu compte que le site avait besoin des modules mbstring et xml or, cette nouvelle version ne les fournit plus : ce sont maintenant des paquets à installer à part.

Voici le message d’erreur des logs:

[26-Jun-2016 08:39:12 UTC] PHP Fatal error:  Uncaught Error: Class 'DOMDocument' not found in /public_html/wp-content/plugins/ginger/front/gingerfront.core.php:171
Stack trace:
#0 /public_html/wp-includes/plugin.php(235): ginger_parse_dom('...')

On installe donc mbstring et xml avant de relancer Apache et PHP :

apt install php7.0-mbstring php7.0-xml
service apache2 restart && service php7.0-fpm restart

Cette fois-ci, c’est tout bon. Tous les services sont actifs et le site est de nouveau opérationnel.

Attention donc : c’est une mise à jour mineure que j’aurais pu faire en SSH depuis mon téléphone, sans avoir les moyens de réparer à distance. Cela remet en perspective les mises à jour “on-the-go“.

Voici les nouveaux modules qui ne sont plus inclus par défaut avec PHP : bcmath, dba, mbstring, soap, xml et zip. Ce sont donc maintenant des paquets à part entière, à installer séparément.

Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”

24 March 202204 avril 2016 by Matt Biscay · Lecture: 6 minutes

Les inodes perdues ! Cette semaine, j’ai eu droit à un problème particulier sur le serveur : alors que rien dans la configuration des services n’a été changé, je me suis rendu compte que WordPress ne réagissait pas comme d’habitude.

Les symptômes les plus visibles sont la lenteur de l’application, l’impossibilité de mettre à jour ou corriger un article ou encore ajouter des tags à un nouvel article.

J’avais déjà connu cet état lors d’un crash de la base SQL il y a maintenant quelques années donc je me suis dit que j’allais commencer par redémarrer Apache puis réparer la base de données.

Suppression des instances Apache et redémarrage du service

Dès le lancement de la session SSH, il est évident que quelque chose ne tourne pas rond. Après le message de bienvenue, un message d’erreur apparaît :

/usr/bin/xauth:  error in locking authority file /root/.Xauthority

Et en voulant arrêter Apache, on obtient:

Restarting web server: apache2. [error]
There are processes named 'apache2' running which do not match your pid

On commence donc par régler ce problème et on regarde quels sont les PID utilisés par Apache:

pidof apache2

La commande pidof nous retourne toute une liste de pid:

32691 31385 31154 30917 30663 29150 27368 24820 24563 17531 15227 14235 13559 13064 11028 10906 10256 9156 9144 9042 8855 8542

On met fin à toutes ces instances avec un simple kill -9:

kill -9 32691 31385 31154 30917 30663 29150 27368 24820 24563 17531 15227 14235 13559 13064 11028 10906 10256 9156 9144 9042 8855 8542

Une fois toutes les instances d’Apache supprimées, il nous est de nouveau possible de redémarrer le service normalement:

service apache2 restart

Ménage dans l’espace disque et le nombre d’inodes disponibles

Au moment de réparer les tables de la base de données, rebelote, erreur :

No space left on device (error 28)

On commence par un petit ménage dans les paquets obsolètes, qui ne résoudra pas grand-chose:

apt-get autoclean && apt-get autoremove

Je tente un simple df pour vérifier si les disques sont pleins :

df

mais visiblement, non, il reste bien de la place :

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       9.8G  4.4G  5.0G  47% /
devtmpfs        2.0G     0  2.0G   0% /dev
tmpfs           390M  408K  390M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           780M     0  780M   0% /run/shm
/dev/sda2       683G  531G  118G  82% /home

Je tente alors un df -i pour vérifier le nombres d’inodes disponibles :

df -i

Un nœud d’index ou inode (contraction de l’anglais index et node) est une structure de données contenant des informations à propos d’un fichier stocké dans les systèmes de fichiers Linux/Unix.

À chaque fichier correspond un numéro d’inode (i-number) dans le système de fichiers dans lequel il réside, unique au périphérique sur lequel il est situé.

Les inodes contiennent notamment les métadonnées des systèmes de fichiers, et en particulier celles concernant les droits d’accès.

Les inodes sont créés lors de la création du système de fichiers. La quantité d’inodes (généralement déterminée lors du formatage et dépendant de la taille de la partition) indique le nombre maximum de fichiers que le système de fichiers peut contenir.

Dans notre cas, catastrophe, il ne reste quasiment plus d’inodes disponibles !

Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/root        640K  640K     6   100% /
devtmpfs         487K  1.5K  486K    1% /dev
tmpfs            488K   864  487K    1% /run
tmpfs            488K    10  488K    1% /run/lock
tmpfs            488K     2  488K    1% /run/shm
/dev/sda2         44M   37K   43M    1% /home

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

« Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND

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

Apache : résoudre l’erreur “421 Misdirected Request”

29 March 202207 janvier 2016 by Matt Biscay · Lecture: 2 minutes

Après la mise à jour d’Apache et HTTP/2, il est apparu un nouveau type d’erreur : l’erreur 421 Misdirected Request.

Erreur 421 : erreur de configuration mod_ssl entre Virtual Hosts

Ce type d’erreur arrive lorsque:

HTTP/2 est activé,
les paramètres SSL de plusieurs Virtual Hosts diffèrent du serveur responsable du handshake SSL/TLS.

En analysant le changelog d’Apache 2.4.18, je me suis rendu compte que si les paramètres SSL et notamment la liste des ciphers utilisables ne sont pas équivalentes entre les différents Virtual Hosts, alors l’erreur 421 est déclenchée.

Solution : harmoniser la configuration mod_ssl

La solution est donc toute simple, il suffit de comparer la configuration mod_ssl des Virtual Hosts et l’harmoniser de manière à lisser les différences. Je vous recommande un outil comme Meld pour comparer les différences entre vos fichiers.

Meld est disponible dans les dépôts de base, vous pouvez l’installer sur votre machine de dév avec un simple:

apt-get install meld

Le domain sharding ou servir les ressources statiques sur un sous-domaine

Sur le site, cela est dû à la mise en place du domain sharding que j’avais mis en place il y a quelques années pour charger plusieurs fichiers ressources en parallèle et accélérer les temps de chargement.

HTTP/2 promet beaucoup de choses et apparemment le domain sharding serait maintenant devenu inutile. J’attends un peu de voir comment vont évoluer les choses avant de changer toute ma configuration et éditer tous mes liens.

Serveur dédié : mettre à jour Apache et configurer le mod_h2 pour HTTP/2 photo

Serveur dédié : mettre à jour Apache pour HTTP/2

12 September 202120 décembre 2015 by Matt Biscay · Lecture: 6 minutes

C’est sur toutes les lèvres : 2015 aura vu l’arrivée de PHP7 et de la révision du protocole HTTP qui passe à la version 2, en remplacement du mod_spdy de Google.

Tout cela promet pas mal de gains de performance donc il est très tentant de le vérifier par nous-mêmes.

HTTP/2 : une évolution du protocole HTTP

Avec HTTP/1.1, la vie des développeurs n’était pas simple. L’optimisation d’un site revenait à plusieurs techniques qui tournaient toutes autour de l’idée de minimiser le nombre de requêtes HTTP vers un serveur d’origine.

Un navigateur ne peut ouvrir qu’un nombre limité de connexions TCP simultanées vers une origine et le chargement des ces ressources via chacune de ces connexions est un processus en série : la réponse de chaque ressource doit être retournée avant que la réponse de la ressource suivante ne soit envoyée. C’est ce qu’on appelle le head-of-line blocking.

HTTP/2 promet donc une gain de perfomance d’environ 30%, sans avoir à gérer ni minification ni concaténation dans le processus de création et déploiement des pages.

Plus besoin (normalement!) d’optimiser les connexions TCP ou les requêtes HTTP avec la création de sprites, le chargement des ressources directement dans le corps des pages, la concatenation ou la création de sous-domaines pour charger les ressources en parallèle (domain sharding) pour contourner les limitations d’HTTP 1.1.

Optimiser pour HTTP/2

Avec HTTP/2, il faut maintenant concentrer les efforts d’optimisation sur les scénarios de cache du site. La nouvelle règle est d’utiliser de petites ressources, granulaires, qui peuvent être mises en cache indépendamment et transferrées en parallèle.

Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2 photo

Ce changement est possible grâce aux nouvelles fonctions de multiplexing et de compression des entêtes d’HTTP/2.

Le multiplexing permet à plusieurs requêtes de partager une connexion TCP unique, ce qui permet le chargement de plusieurs ressources en parallèle, sans le délai dû à la création de connexions multiples. Cela élimine le problème d’head-of-line blocking que l’on rencontre avec HTTP/1.1.

La compression des entêtes réduit encore davantage la pénalité lors du chargement de plusieurs ressources (requêtes HTTP multiples) puisque l’overhead de chaque requête est plus petit que leur équivalent non-compressé en HTTP/1.1.

HTTP/2 offre aussi la hiérarchisation des flux (stream prioritization) qui permet aux navigateurs de spécifier dans quel ordre ils souhaitent recevoir les ressources, ainsi que le server push qui laisse le serveur envoyer des ressources supplémentaires par anticipation, alors que le navigateur ne sait pas encore qu’il en aura besoin.

Cela implique donc pas mal de changements dans les manières et l’état d’esprit d’optimisation par rapport à HTTP/1.1.

Configuration initiale du serveur

Mon serveur dédié tourne sur la dernière version stable de Debian, c’est-à-dire sous Jessie à l’heure où j’écris ces lignes, qui ne dispose que d’Apache 2.4.10. Or le module http2 ne fonctionne qu’à partir d’Apache 2.4.17.

Il va donc falloir mettre Apache à jour ! Nous allons temporairement basculer sur les dépôts sid le temps de mettre à jour Apache et OpenSSL.

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

« Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO

Serveur dédié : ajouter le domaine à la liste HSTS preload »

Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP photo

Serveur dédié : optimiser la couche TCP

12 September 202114 décembre 2015 by Matt Biscay · Lecture: 4 minutes

Aujourd’hui, nous allons mettre quelques petites astuces qui permettent d’optimiser un peu le temps de réaction du serveur Apache.

Nous allons commencer par réduire le nombre de connexions TIME_WAIT des sockets TCP et nous verrons ensuite comment optimiser un peu la couche TCP.

Réduire le TIME_WAIT des sockets TCP

De temps à autre, on tombe sur un serveur Apache qui possède des tonnes de connexions TIME_WAIT qui semblent errer dans les limbes. Même si ces connexions ne prennent pas autant de ressources que des connexions ESTABLISHED, il n’est pas vraiment utile de les garder aussi longtemps.

Commençons par faire un petit état des lieux de nos connexions :

netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n

Résultat :

      1 established)
      1 Foreign
      2 ESTABLISHED
      3 FIN_WAIT1
     20 LISTEN
    228 TIME_WAIT

Nous avons donc 228 connexions dans les limbes en TIME_WAIT, qui sont totalement inutiles. Voyons donc comment nous pouvons réduire ce nombre.

Vérifiez ces valeurs:

cat /proc/sys/net/ipv4/tcp_fin_timeout
cat /proc/sys/net/ipv4/tcp_tw_recycle
cat /proc/sys/net/ipv4/tcp_tw_reuse

Vous devriez obtenir, respectivement, les valeurs 60 pour le timeout, 0 pour le reyclage et 0 pour la réutilisation.

Nous allons modifier ces valeurs pour réduire le timeout à 30 secondes, et recycler et réutiliser nos connexions :

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

Pour que les changements soient persistants, il faut ajouter ces valeurs au fichier sysctl.conf.

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

« Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian

Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO »

Serveur dédié : installer PHP7 FPM avec FastCGI photo

Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian

29 March 202208 décembre 2015 by Matt Biscay · Lecture: 4 minutes

Aujourd’hui, on passe de PHP5 à PHP7 en moins de 20 minutes montre en main sur notre serveur dédié qui tourne sous la version stable de Debian.

Pré-requis : les dépôts Dotdeb

Avant toute chose, vous devez avoir les dépôts Dotdeb installés dans votre apt.

On édite donc la liste des dépôts:

nano /etc/apt/sources.list

puis on y ajoute :

# Dotdeb stable
deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

On installe la clé GPG de Dotdeb:

wget https://www.dotdeb.org/dotdeb.gpg
sudo apt-key add dotdeb.gpg

et on met notre liste de paquet à jour :

apt-get update && apt-get upgrade

Lorsque vous avez complété cette étape, vous êtes prêt à lancer la mise à jour de PHP.

Installation de PHP7

Je découpe volontairement cette installation en plusieurs sous-étapes, par souci de clarté.

Suppression des paquets PHP5

On commence par supprimer tous les paquets relatifs à PHP5 sur le serveur:

apt-get purge php5-*

Résultat:

The following packages will be REMOVED:
libapache2-mod-php5* php-pear* php5* php5-apc* php5-cli* php5-common* php5-curl* php5-dev* php5-fpm* php5-gd* php5-json* php5-mcrypt* php5-mysql* php5-mysqlnd* php5-pecl-http* php5-propro* php5-raphf* php5-ssh2*

On garde cette liste sous le coude en cas de problème.

Installation des paquets PHP7

On installe les paquets PHP7 qui nous sont nécessaires:

apt-get install php7.0 php7.0-fpm php7.0-gd php7.0-mysql php7.0-cli php7.0-common php7.0-curl php7.0-opcache php7.0-json

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

« 8 règles d’or pour bien déployer DNSSEC et DANE

Serveur dédié : optimiser la couche TCP »

Serveur dédié : la mise à jour vers Debian 8 Jessie

29 March 202229 avril 2015 by Matt Biscay · Lecture: 6 minutes

Hier soir, j’ai mis à jour le serveur : nous passons de Debian 7.8 (wheezy) à 8.0 (jessie).

Tout s’est plutôt bien passé, il y a eu environ 10 minutes de downtime, le temps que je comprenne ce qui avait changé, notamment dans la configuration Apache et celle de Postfix.

Voici un petit compte-rendu de la mise à jour.

debian-8-jessie

Mise à jour des dépôts

On édite notre fichier source APT :

nano /etc/apt/sources.list

et on remplace toutes les occurences de wheezy par jessie.

Chez moi, cela donne :

# DEBIAN
deb http://mirror.ovh.net/debian/ stable main contrib non-free
deb-src http://mirror.ovh.net/debian/ stable main contrib non-free

deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

# mod security
deb http://ftp.debian.org/debian/ jessie-backports main

Préparation à la mise à jour de Debian

J’ai commencé par vérifier qu’aucun paquet n’était à moitié installé :

dpkg --audit

ou en attente :

dpkg --get-selections | grep 'hold

Rien? Tout va bien, on continue et on simule une installation avec :

apt-get -o APT::Get::Trivial-Only=true dist-upgrade

Le résultat est une longue liste de paquets, suivie du message suivant:

439 upgraded, 192 newly installed, 5 to remove and 1 not upgraded.
Need to get 275 MB of archives.
After this operation, 259 MB of additional disk space will be used.
E: Trivial Only specified but this is not a trivial operation.

Nos sauvegardes sont faites, on se lance.

Mise à jour Debian

On rafraichit les dépôts et on lance l’installation:

apt-get update && apt-get upgrade

On obtient un laïus avec ce qui change. J’aperçois plusieurs pages sur Apache, on y reviendra. Cela dure à peu près une dizaine de minutes, bien que je n’ai pas vraiment minuté.

Une fois l’installation terminée, on résout les dépendances et les paquets manquants avec :

apt-get dist-upgrade

Je lance le site pour voir : paf, erreur 403.

Résoudre les lightbox vides dans l’administration WordPress

29 March 202226 avril 2015 by Matt Biscay · Lecture: 3 minutes

Le problème : des iframes entièrement vides dans l’interface d’administration WordPress

Depuis mon passage à HTTPS, j’ai constaté que lorsqu’un plugin possédait une mise à jour et que l’on cliquait sur le lien “voir les détails de la version x.x”, j’avais droit à une jolie lightbox (ThickBox sous WordPress) toute vide.

C’était également le cas lors de la mise à jour des plugins, des thèmes ou de WordPress même : je n’obtenais jamais la ligne qui confirmait que le plugin avait bel et bien été réactivé.

Cette situation a duré des mois : j’ai d’abord soupçonné une mise à jour de WordPress qui aurait abimé un fichier donc j’ai ré-uploadé tous les fichiers, procédé à de multiples mises à jour mineures puis majeures.

J’ai ensuite jeté un œil aux plugins, en désactivant quelques uns pour essayer de trouver celui qui perturbait le système. Rien. Et visiblement, personne n’a jamais été confronté à ce problème sur la toile.

Et puis cette semaine, eurêka !

La solution : la configuration Apache du serveur

J’ai trouvé la solution un jour que je travaillais sur autre chose, en analysant les messages de l’inspecteur de code. Ce dernier me renvoyait de multiples avertissements lorsqu’un message a attiré mon attention :

[quote class=”center”]Load denied by X-Frame-Options…. X-Frame-Options does not permit framing.[/quote]

Et là, banco, j’ai immédiatement compris ce qui clochait. Lors de la bascule vers la version chiffrée du site, j’avais effectivement ajouté un nouvel entête X-Frame-Options comme ceci :

Header always set X-Frame-Options DENY

Cela est bien trop restrictif puisque la valeur DENY empêche l’affichage du site dans un cadre (frame).

Or le back-office de WordPress charge effectivement les messages relatifs aux mises à jour dans un cadre, sous la forme d’une lightbox: il faut donc utiliser la valeur SAMEORIGIN.

Serveur dédié : activer l’IP canonique du serveur sous Apache

29 March 202223 mars 2015 by Matt Biscay · Lecture: 2 minutes

J’ai récemment procédé à quelques tests sur le serveur et me suis rendu compte que l’adresse IP du serveur ne renvoyait pas vers le nom de domaine : la canonisation de l’IP serveur n’était pas activée.

Mise en forme canonique de l’IP du serveur

La mise en forme canonique (canonicalization en anglais) est le procédé par lequel on convertit des données qui ont plusieurs représentations possibles vers un format standard.

Dans le cas des URL, cela va nous permettre d’associer une page à une seule adresse. Cela aide les moteurs de recherche à indexer uniquement les pages sur lesquelles se trouvent les contenus et évite le doublons d’indexation pénalisants.

Au cours d’un test, j’ai donc obtenu ce message :

[quote class=”center”]Your site’s IP does not redirect to your site’s domain name. This could cause duplicate content problems if a search engine indexes your site under both its IP and domain name.[/quote]

En soi, cela n’est pas gênant mais cela signifie que l’on peut accéder au site à partir de l’adresse IP et qu’il n’y a pas de redirection vers le nom de domaine.

Cela me dérange un peu donc nous allons voir comment l’activer en quelques secondes sous Apache.

Editer le VirtualHost par défaut

Sous Apache, il existe les VirtualHost que vous avez défini pour vos sites mais également un VirtualHost par défaut, activé par défaut.

C’est ce VirtualHost que nous allons éditer:

nano /etc/apache2/sites-available/default

On y garde simplement ceci :

    ServerAdmin webmaster@localhost
    DocumentRoot /
    
	Options FollowSymLinks
	AllowOverride None
	RewriteEngine On

	# redirect all domains to skyminds.net
	RewriteCond %{HTTP_HOST} !^((.*)\.skyminds\.net)?$
	RewriteRule (.*) https://www.skyminds.net/$1 [R=301,L]

	# Enforce www and canonicalization
	RewriteCond %{HTTP_HOST} !^www\.skyminds\.net [NC]
	RewriteRule (.*) https://www.skyminds.net/$1 [R=301,L]

	# IP to domain
	RewriteCond %{HTTP_HOST} ^xxx\.xxx\.xxx\.xxx
	RewriteRule (.*) https://www.skyminds.net/$1 [R=301,L]

Il vous suffit de remplacer mon domaine (skyminds.net) avec le votre et de modifier l’adresse IP de votre serveur.

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

« Serveur dédié : installer la dernière version d’OpenSSL sous Debian

Serveur dédié : mise à jour vers PHP 5.6 »

Serveur dédié : retirer Varnish, devenu inutile avec HTTPS

29 March 202220 février 2015 by Matt Biscay · Lecture: 3 minutes

J’ai vraiment aimé jouer avec Varnish.

Le problème, c’est qu’en passant l’intégralité du site en HTTPS, il m’est devenu inutile.

Varnish est incompatible avec HTTPS et ne le sera probablement jamais puisque les connexions chiffrées ne doivent, par définition, jamais être mises en cache.

Par conséquent, j’ai décidé de le retirer temporairement du serveur : cela me fera un service de moins à gérer.

Notez que je ne le désinstalle pas, je m’assure juste qu’on ne fait pas appel à lui. Cela me permettra de le remettre en route si jamais j’héberge un jour un site en HTTP simple.

Ce tutoriel part du principe que vous avez suivi les tutoriels précédents et que votre serveur tourne avec Apache et Varnish comme reverse-proxy.

Configuration d’Apache

On doit éditer plusieurs fichiers :

1. le fichier /etc/apache2/ports.conf :

 nano /etc/apache2/ports.conf

On remet les valeurs par défaut et on écoute sur le port 80 :

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default
# This is also true if you have upgraded from before 2.2.9-3 (i.e. from
# Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and
# README.Debian.gz

# SkyMinds.Net
# Quand Varnish est actif
# NameVirtualHost *:8080
# Listen 8080

# Apache only
NameVirtualHost *:80
Listen 80


    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to 
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.

   NameVirtualHost *:443
   Listen 443



    Listen 443

2. les fichiers de chacun de nos VirtualHosts :

nano /etc/apache2/sites-available/www.skyminds.net
nano /etc/apache2/sites-available/static.skyminds.net

On écoutait sur le port 8080, on se remet sur le port 80 :

#<virtualhost *:8080="">
<virtualhost *:80="">

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

« Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy

Serveur dédié : installer la dernière version d’OpenSSL sous Debian »

MySQL : résoudre l’erreur “mysql_connect(): Headers and client library minor version mismatch”

29 March 202205 janvier 2015 by Matt Biscay · Lecture: 1 minutes

Après la mise à jour vers MySQL 5.6, certaines applications peuvent renvoyer l’avertissement PHP suivant :

PHP Warning: mysql_connect(): Headers and client library minor version mismatch. Headers:50535 Library:50617

C’est le cas lorsqu’une application est liée à l’utilisation d’une version spécifique de libmysqlclient18 alors qu’elle est connectée à un serveur MySQL qui tourne sur une version différente.

C’est libmysqlclient18 qui renvoie cet avertissement mais dans certains cas, cela peut impacter l’application et tient plus de l’erreur que de l’avertissement.

MySQL Native Driver

La solution est toute simple : il suffit d’utiliser le pilote MySQL Native Driver php5-mysqlnd au lieu du paquet php5-mysql.

Les avantages de php5-mysqlnd sont multiples : il vient en remplacement de php5-mysql, n’est pas lié à la librairie libmysqlclient, ne renvoie pas d’avertissement “version mismatch” et possède pas mal d’autres caractéristiques intéressantes.