• [^] # Re: uWSGI

    Posté par . 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.conf
    [global]
    pid = /run/${APP_NAME}/pid
    error_log = /var/log/${APP_NAME}/error.log
    [${APP_NAME}]
    listen = /run/php/${APP_NAME}.sock
    access.log = /var/log/${APP_NAME}/access.log
    ; single entry point
    security.limit_extensions = /index.php
    pm = ondemand
    pm.max_children = 5
    pm.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...