Allez, je partage mon retour, parce que je pense avoir amélioré le truc. Attention, seulement la partie FPM, je suis resté classique pour nginx, il tourne toujours en root.
Ce que je n'aime pas, c'est devoir écrire partout mon-application. Pour installer une nouvelle application, il faut copier-coller un fichier, et faire du rechercher-remplacer partout. Moins j'en fais, mieux je me porte. Et surtout, la maintenance est plus facile en cas d'édition d'un fichier.
Il se trouve que PHP (et donc FPM) supporte les variables dans le fichier de configuration. Donc on peut faire son fichier qui ressemble à :
/etc/php/7.4/fpm/base.conf
[global]pid=/run/${APP_NAME}/piderror_log=/var/log/${APP_NAME}/error.log[${APP_NAME}]listen=/run/php/${APP_NAME}.sockaccess.log=/var/log/${APP_NAME}/access.log; single entry pointsecurity.limit_extensions=/index.phppm=ondemandpm.max_children=5pm.process_idle_timeout=600s;
Oui, je préfère ondemand, mais ce n'est pas le sujet. Le sujet, c'est ${APP_NAME}. Comment on lui passe ? Hé bien, on demande à systemd :
/etc/systemd/system/php-fpm@.service
[Service]Environment="APP_NAME=%i"
Et avec ça, il n'y a parfois aucune configuration supplémentaire. Par exemple, pour Roundcube packagé par Debian, j'ai un simple lien symbolique de roundcube.conf vers base.conf. Le service systemd est édité, pour autoriser les connexions à mon serveur de courriel.
D'ailleurs, je me suis permis de renforcer la sécurité en utilisant security.limit_extensions = /index.php ce qui empêche PHP d'accepter autre chose que /index.php. La valeur par défaut est .php, acceptant tous les fichiers PHP. Comme la plupart des applications n'ont plus qu'un seul point d'entrée, c'est toujours bon à prendre. Même si ça ne vous empêche pas de faire une configuration correcte de votre serveur Web en amont.
Enfin, clairement, DynamicUser=true, c'est compliqué. Par exemple, Roundcube de Debian peuple /var/lib/roundcube avec des liens symboliques un peu partout, et il faut que tout ça soit accessible à cet utilisateur dynamique. C'est quand même compliqué.
Donc j'ai mis en commentaire ça, et pour que les sessions marchent, j'ai remis ReadWritePaths=/var/lib/php/sessions. Oui, a priori ça va mettre les sessions dans le même répertoire, mais les droits semblent corrects...
[^] # Re: uWSGI
Posté par Glandos . En réponse au journal Durcir nginx et PHP avec systemd. Évalué à 5.
Allez, je partage mon retour, parce que je pense avoir amélioré le truc. Attention, seulement la partie FPM, je suis resté classique pour nginx, il tourne toujours en root.
Ce que je n'aime pas, c'est devoir écrire partout
mon-application. Pour installer une nouvelle application, il faut copier-coller un fichier, et faire du rechercher-remplacer partout. Moins j'en fais, mieux je me porte. Et surtout, la maintenance est plus facile en cas d'édition d'un fichier.Il se trouve que PHP (et donc FPM) supporte les variables dans le fichier de configuration. Donc on peut faire son fichier qui ressemble à :
/etc/php/7.4/fpm/base.confOui, je préfère
ondemand, mais ce n'est pas le sujet. Le sujet, c'est${APP_NAME}. Comment on lui passe ? Hé bien, on demande à systemd :/etc/systemd/system/php-fpm@.serviceEt avec ça, il n'y a parfois aucune configuration supplémentaire. Par exemple, pour Roundcube packagé par Debian, j'ai un simple lien symbolique de
roundcube.confversbase.conf. Le service systemd est édité, pour autoriser les connexions à mon serveur de courriel.D'ailleurs, je me suis permis de renforcer la sécurité en utilisant
security.limit_extensions = /index.phpce qui empêche PHP d'accepter autre chose que/index.php. La valeur par défaut est.php, acceptant tous les fichiers PHP. Comme la plupart des applications n'ont plus qu'un seul point d'entrée, c'est toujours bon à prendre. Même si ça ne vous empêche pas de faire une configuration correcte de votre serveur Web en amont.Enfin, clairement,
DynamicUser=true, c'est compliqué. Par exemple, Roundcube de Debian peuple/var/lib/roundcubeavec des liens symboliques un peu partout, et il faut que tout ça soit accessible à cet utilisateur dynamique. C'est quand même compliqué.Donc j'ai mis en commentaire ça, et pour que les sessions marchent, j'ai remis
ReadWritePaths=/var/lib/php/sessions. Oui, a priori ça va mettre les sessions dans le même répertoire, mais les droits semblent corrects...