uWSGI

Très intéressant, merci.

Je m'étais attelé à la même tâche avec uWSGI, que je trouvais justement plus facile d'intégrer à l'activation par socket de systemd. Malheureusement... le plugin PHP (voir uWSGI en entier) est plutôt à l'abandon et le support de PHP 8.1 (qui vient d'arriver dans Debian/testing) est encore bien cassé. Le correctif a été intégré, mais il n'y a toujours pas de version publiée.

Donc je vais me pencher pour l'utilisation de PHP-FPM, en enlevant les pools que j'utilisais jusque là.

J'irais même jusqu'à créer des utilisateurs différents par applications (www-application1, etc) et à le mettre comme paramètre de l'instance php-fpm@.socket:

SocketUser=www-%i
SocketGroup=www-%i

Mais y a un truc que je ne comprends pas... Dans php-fpm@.service il y a SupplementaryGroups=%i ce qui veut dire que le groupe mon-application doit exister. Par contre, php-fpm@.socket crée un socket 0660 appartenant à php:www-data. Il manque pas un truc ?

Ah, et pour ReadWritePaths avec DynamicUser, ça fait quoi ? Les fichiers sont écrits avec un UID/GID qui peut être réutilisé :

Care should be taken that any processes running as part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus gain access to these files or directories.

J'ai l'impression qu'un utilisateur statiquement défini est préférable si l'application a besoin d'écrire son fichier de configuration (au hasard, Nextcloud).

Pour rebondir, d'après la documentation, si DynamicUsers=true, plein d'options sont mises, donc le fichier est plein de redondances. Mais, c'est vrai, des fois, il vaut mieux être explicite...