Régler php-fpm

Bonjour,

Il y a quelques années, j’utilisais suexec pour qu’apache gère php en tant qu’utilisateur local. Cette solution ne marche que sous certaines conditions, et cgi n’en fait pas partie.

Quand j’ai mis php en fast-cgi afin d’en utiliser plusieurs versions, la création et modification de fichiers via php est devenu problématique.

Il y a plusieurs solutions à ce problème.

  • chmod 777
  • mount bind avec changement d’utilisateur
  • acl

Celle que j’ai retenu, c’est de régler php-fpm pour changer l’uid et gid du site.

Par défaut c’est www-data qui exécute les pages du site. Pour changer celà, on va regarder pas a pas ce qu’il faut faire.

Il faut avoir php en fast-cgi.

Je donne ci-dessous un exemple pour php7.2, mais on peut facilement adapter et faire fonctionner le truc pour php5 ou 7.0.

On arrete le service php-fpm

sudo /etc/init.d/php7.2-fpm stop

On règle certaines variables

site=www.symfony.loc
repertoire=/home/brahim/symfony/www
utilisateur=brahim
groupe=brahim
sudo /etc/init.d/php7.2-fpm stop
sudo cp /etc/php/7.2/fpm/pool.d/www.conf  /etc/php/7.2/fpm/pool.d/${site}.conf

On copie et modifie le fichier pool fpm

site=www.symfony.loc repertoire=/home/brahim/symfony/www utilisateur=brahim groupe=brahim sudo /etc/init.d/php7.2-fpm stop sudo cp /etc/php/7.2/fpm/pool.d/www.conf /etc/php/7.2/fpm/pool.d/${site}.conf

On modifie le fichier fraîchement copié

sudo nano -w /etc/php/7.2/fpm/pool.d/${site}.conf

Il faut remplacer :

  • [www] -> [www.symfony.loc]
  • user = www-data -> user = brahim
  • group = www-data -> group = brahim
  • listen = /run/php/php7.2-fpm.sock -> listen = /run/php/php7.2-www.symfony.loc.sock

Il faut adapter les changements en fonction du site.

Enfin, on lance le service

sudo /etc/init.d/php7.2-fpm start

Voilà, le site tournera sous les droits de brahim:brahim.

Plus besoin de changer via chmod ou autre.

Installer plusieurs version de php

Bonjour,

Introduction

Quand on installe php5 et php7 sur son ordinateur (ou serveur), on ne peut en utiliser qu’un. Malheureusement, des fois, il nous faut tester le même site sous différentes versions de php. Et des fois, on aimerais travailler sur 2 projets qui nécessitent des versions de php différentes.

Je suis passé par plusieurs solutions plus ou moins efficaces, comme les machines virtuelles, 2 serveurs apaches sur 2 ports différents, etc.

La solution en théorie

J’ai fini par trouver la solution idéale :

Php en fast cgi et une variable dans htaccess pour choisir la version à executer. Théoriquement on pourrait avoir au sein du même site, une version différente de php par répertoire (site vitrine, blog…). Dans la pratique, on met un seul htaccess à la racine du site et c’est tout.

On peut aussi paramétrer php-fpm pour que les sites aient l’utilisateur et le groupe d’un compte spécifique, utile pour accorder les droits sur le site et sur ftp et les mettant sur un utilisateur système commun.

On va détailler ici uniquement la partie transformation de php de module vers fast cgi.

Je pars du principe que les 2 versions ont été installées via le repository de la distribution, pour debian :

sudo apt-get install apache2 php7.2 libapache2-mod-php7.2 mysql-server mysql-client php7.2-mysql phpmyadmin php7.2-odbc php7.2-curl php7.2-json php7.2-xml php7.2-mbstring

C’est typiquement ce que j’installe pour avoir un serveur de développement lamp fonctionnel.

On imagine donc que sur le serveur il y ait php5, php7.0 et php7.2 d’installés.

La version exécutée par apache dépend de l’ordre d’installation. Je suppose que dans une utilisation normale, on a installé php7.2 en dernier et c’est donc lui qui anime tous les sites sur lesquels on travail.

La soluton en pratique

Il faut tout d’abord arrêter apache

sudo service apache2 stop

Ensuite on supprime tous les modules php

sudo rm -f /etc/apache2/mods-enabled/php*
sudo apt-get remove --purge 'libapache2-mod-php*'

On installe la version cgi de php

sudo apt-get install libapache2-mod-fastcgi php5-fpm php5-cgi php7.0-fpm php7.0-cgi php7.2-fpm php7.2-cgi

On active le module actions

sudo a2enmod actions

On configure fastcgi

sudo nano -w /etc/apache2/mods-enabled/fastcgi.conf

Mettre le contenu suivant

<IfModule mod_fastcgi.c>
	AddHandler fastcgi-script .fcgi
	#FastCgiWrapper /usr/lib/apache2/suexec
	FastCgiIpcDir /var/lib/apache2/fastcgi
	AddType application/x-httpd-php5 .php5 .php
	AddHandler php5 .php5 .php
	Action php5 /cgi-php5
	Alias /cgi-php5 /usr/lib/cgi-bin/php5
	FastCgiExternalServer /usr/lib/cgi-bin/php5 -socket /var/run/php5-fpm.sock -pass-header Authorization
	AddType application/x-httpd-php7.0 .php7 .php
	AddHandler php7.0 .php7 .php
	Action php7.0 /cgi-php7.0
	Alias /cgi-php7.0 /usr/lib/cgi-bin/php7.0
	FastCgiExternalServer /usr/lib/cgi-bin/php7.0 -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization
	AddType application/x-httpd-php7.2 .php7 .php
	AddHandler php7.2 .php7 .php
	Action php7.2 /cgi-php7.2
	Alias /cgi-php7.2 /usr/lib/cgi-bin/php7.2
	FastCgiExternalServer /usr/lib/cgi-bin/php7.2 -socket /var/run/php/php7.2-fpm.sock -pass-header Authorization
	<Directory /usr/lib/cgi-bin>
		Require all granted
	</Directory>
</IfModule>

Le bloc précédent est un peu indigest mais en le lisant, on voit qu’il y a 3 blocs, 1 pour chaque version de php.

Il ne reste plus qu’a activer apache

sudo service apache2 start

Tout devrait fonctionner comme avant. Y compris, la version php7.2 par defaut.

Pour changer cela, dans le htaccess, on mettra le code suivant

<IfModule mod_fastcgi.c>
 AddHandler php5 .php
 #AddHandler php7.0 .php
 #AddHandler php7.2 .php
</IfModule>

Il suffit de décommenter la ligne qui nous intéresse et de commenter les autres. On peut aussi supprimer celles qui ne nous intéressent plus.

Conclusion

Voilà, c’est la configuration que j’utilise sur les serveurs de développement. Cela permet d’avoir un seul serveur qui pourra s’adapter à toutes les versions de php.

Je ne sais pas comment c’est fait chez free.fr, mais je suppose que c’est très similaire, on peut donc supposer que cette méthode (avec un réglage de fpm plus approfondi pour les droits) peut convenir à un serveur de prod.

 

Mettre en place https

Bonjour,

Aujourd’hui j’ai du mettre en place https.

La méthode qui fût demandée est via Let’s encrypt. L’avantage c’est le prix : gratuit. L’inconvénient c’est qu’il faut renouveler la clé régulièrement (tous les 90 jours, il me semble) et ne peut pas l’utiliser pour tous les services.

J’ai essayé avec une ip dynamique et ça marche très bien.

On télécharge certbot et on le lance en tant que root.

On met en place
/etc/apache2/sites-available/mon-site.conf

On alias vers
/etc/apache2/sites-enabled/mon-site.conf

Et le tour est joué.

Mettre un site en maintenance

Bonjour,

Lorsqu’on gère un site, il faut savoir rester professionnel.

Un peu de bla bla

Il y a beaucoup de façons de faire « amateur », et une de celles-ci est de laisser une page blanche, ou une page d’erreur quand le site est cassé.

Mettre une page « site en maintenance » montre que l’on fait attention à notre site et par conséquent à ceux qui le voient.

Bien sûr, on ne peut pas toujours prévoir les pannes, mais une action rapide est de rigueur. Ce qui serait mieux c’est une action pro-active. On met d’abord la page « en maintenance », puis on travail à l’aise.

Si on sait que la base de données ne sera pas disponible, une page « revenez dans une heure » est beaucoup mieux qu’une page avec des warnings « database not found » sur chaque texte dynamique.

Un peu de pratique

Maintenant c’est bien de paraître pro, mais on fait comment ?

Une option serait d’installer un plug-in qui affiche la page désirée aux heures prévues. Mais cela suppose que l’on soit sur un cms ou framework qui donne ce genre d’extension.

Pour ma part, je fais beaucoup plus basique : je mets une page _index.html à la racine du site (à côté de la page index.php).

Notez bien l’extention, .html. C’est important pour nous faciliter la vie plus tard.

Les sites ont généralement et par défaut une précédence de index.html sur index.php. C’est important aussi.

La page _index.html doit être la plus simple possible, sobre sans image. Ce ne sont que des suggestions, rien d’obligatoire ici. Par contre interdit d’avoir du contenu dynamique.

Maintenant que tout est en place, on renomme la page _index.html en index.html et le site n’est plus visible pour les nouveaux visiteurs.

Il reste les « pas nouveaux » visiteurs qui ont des chemins en cache dans leur navigateur ou des signets directement sur cetaines pages.

Pour tout ce beau monde, on fait un .htaccess (que l’on nommera .htaccess_ quand on n’est pas en maintenance) qui donnera index.html à tout le monde avec un code erreur 302 pour satisfaire les robots.

Garder ces fichiers a portée permet de changer le nom des fichiers sans faire de transfert et d’éviter d’avoir des accidents.

nginx et apache

Bonjour,

J’ai du faire une installation qui est de plus en plus répendue sur les serveurs.

Installer nginx et apache sur le même serveur. Apache est en back-end et nginx comme serveur front.

Je vais d’abord donner l’avis de ceux qui mettent en place cette architecture :

Nginx est un serveur rapide, donc on l’utilise. Ensuite, on s’apperçoit que tout ne marche pas (attention, j’ai pas dit que rien ne marchait !). Parmis ce qui ne marche pas, il y a php et l’url rewriting. Pour php, on peut le mettre en fast cgi et le tour est joué. Même si il y a le mot « fast », c’est quand même plus lent qu’un module, comme apache sait le faire. Les experts nginx ne courent pas les rues, donc transcrire le .htaccess n’est pas toujours envisageable (ou suffisament bien fait).

Avec tous ces problèmes, on est tenté de réinstaller apache et de ne plus se casser la tête, mais c’est sans compter sur la hiérarchie qui veut nginx car c’est plus rapide !!!

Il faut donc utiliser nginx pour le contenu statique (pages html, images, javascript, css, etc.) et quand il y a des pages php, il fait passer ça à apache. C’est le reverse proxying.

Et pour le rewriting ?

Là aussi, on voit la grande utilité d’nginx, on sert les fichiers qui existent, sinon on donne la requête à apache.

On a théoriquement le meilleur des 2 mondes. Nginx donne rapidement les pages qui ne demande pas de traitement et apache prête main forte quand il y a du contenu dynamique.

Alors, oui, il y a des pointes de sarcasme dans ce billet.

Pourquoi ?

Et bien j’ai déjà émis mon point de vue sur l’utilisation du cache et que c’est un troc, de l’espace mémoire contre du temps de calcul.

Ici on installe 2 fois le même service (on utilise plus de place en mémoire, c’est un bon départ pour le troc vu plus haut). Il faut régler les téléscopages, donc faire écouter apache sur un autre port (utilisation de resource en plus). Il faut bloquer le port depuis l’extérieur (un peu plus de travail pour le firewall). Nginx doit être réglé pour donner les fichiers directement et faire suivre tout ce qu’il ne comprend pas (on perd donc du temps à rediriger tout le contenu dynamique).

On gagne beaucoup sur le statique et on perd un peu sur le dynamique, mais au final, c’est mieux non ? Comme à mon habitude, la réponse est non !

Il y a dans apache un module mod_expires, il permet de gérer le cache client. Et quand on le règle bien, on ne télécharge plus rien.

Alors c’est quoi qui est mieux ? Nginx qui donne du contenu très rapidement ou apache qui donne un contenu beaucoup plus lentement mais une seule fois dans l’année !

Mon opinion en clair : il faut en prendre 1 et bien le régler. Nginx seul peut gérer les pages statiques, les pages dynamiques, le rewriting et la gestion du cache client. Il faut juste s’investir un peu. Apache peut en faire autant. La combinaison des 2 marche bien pour ceux qui ne font pas d’effort ni de mesure.

Si vous voulez des détails techniques su la mise en place de l’une des configurations, demandez le en commentaire.