IpTables & VPN Admin & php7.0-fpm sur une nouvelle installation de Yunohost

Support
21

Situation

Problème

Au boot le php7.0-fpm ne démarre pas.

# systemctl status php7.0-fpm
● php7.0-fpm.service - The PHP 7.0 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.0-fpm.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2018-08-17 14:53:15 CEST; 42s ago
     Docs: man:php-fpm7.0(8)
  Process: 485 ExecStart=/usr/sbin/php-fpm7.0 --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf (code=exited, status=78)
 Main PID: 485 (code=exited, status=78)

Aug 17 14:53:10 *******.*** systemd[1]: Starting The PHP 7.0 FastCGI Process Manager...
Aug 17 14:53:15 *******.*** php-fpm7.0[485]: [17-Aug-2018 14:53:15] ERROR: [pool vpnadmin] cannot get uid for user 'admin'
Aug 17 14:53:15 *******.*** php-fpm7.0[485]: [17-Aug-2018 14:53:15] ERROR: FPM initialization failed
Aug 17 14:53:15 *******.*** systemd[1]: php7.0-fpm.service: Main process exited, code=exited, status=78/n/a
Aug 17 14:53:15 *******.*** systemd[1]: Failed to start The PHP 7.0 FastCGI Process Manager.
Aug 17 14:53:15 *******.*** systemd[1]: php7.0-fpm.service: Unit entered failed state.
Aug 17 14:53:15 *******.*** systemd[1]: php7.0-fpm.service: Failed with result 'exit-code'.

Ce problème à comme effet de générer une erreur nginx 502 Bad Gateway pour atteindre des sites (services) dépendant de php-fpm comme par exemple vpnadmin ou hotspot.

Étonnamment, au boot le php5-fpm est toujours présent et ne démarre pas non plus.

Php7.0-fpm ou php5-fpm ne démarrent pas à cause de cette erreur:

ERROR: [pool vpnadmin] cannot get uid for user 'admin'

Pourtant, une fois la brique démarrée, le service php7.0-fpm démarre à la main sans soucis. :man_facepalming:

# systemctl start php7.0-fpm
# systemctl status php7.0-fpm
● php7.0-fpm.service - The PHP 7.0 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.0-fpm.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-08-17 14:54:39 CEST; 3s ago
     Docs: man:php-fpm7.0(8)
 Main PID: 2444 (php-fpm7.0)
   Status: "Ready to handle connections"
    Tasks: 9 (limit: 4915)
   CGroup: /system.slice/php7.0-fpm.service
           ├─2444 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
           ├─2447 php-fpm: pool vpnadmin
           ├─2448 php-fpm: pool vpnadmin
           ├─2450 php-fpm: pool vpnadmin
           ├─2451 php-fpm: pool wifiadmin
           ├─2452 php-fpm: pool wifiadmin
           ├─2453 php-fpm: pool wifiadmin
           ├─2454 php-fpm: pool www
           └─2455 php-fpm: pool www

Aug 17 14:54:38 *******.*** systemd[1]: Starting The PHP 7.0 FastCGI Process Manager...
Aug 17 14:54:39 *******.*** systemd[1]: Started The PHP 7.0 FastCGI Process Manager.

Contournement

Masquer l’unité php5-fpm dans systemd (j’ai préféré ne pas désinstaller pour ne pas foutre plus la merde).

# systemctl mask php5-fpm

Modifier le service php7.0-fpm pour que systemd le démarre avec un délais de 30 seconde si il ne démarre pas au boot.

# nano /etc/systemd/system/multi-user.target.wants/php7.0-fpm.service

Y rajouter les lignes Restart=on-failure et RestartSec=30 pour que le fichier ressemble à ceci:

[Unit]
Description=The PHP 7.0 FastCGI Process Manager
Documentation=man:php-fpm7.0(8)
After=network.target

[Service] 
Type=notify
PIDFile=/run/php/php7.0-fpm.pid
ExecStart=/usr/sbin/php-fpm7.0 --nodaemonize --fpm-config /etc/php/7.0/fpm/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID
Restart=on-failure
RestartSec=30

[Install]
WantedBy=multi-user.target

Ce qui a pour effet de tenter une seconde fois de démarrer le service php7.0-fpm après 30 secondes sans avoir cette étrange erreur concernant le user admin.

Solution

Le contournement expliqué ci-dessus n’est pas à probrement parler une solution puisque l’erreur au démarrage existe toujours.

Pour trouver l’explication il faudrait comprendre pourquoi l’utilisateur admin n’est pas disponible pour le démarrage de php7.0-fpm ( ou php5-fpm) sur une Debian9 alors qu’il l’était pour une Debian 8.

Et qui plus est, cet utilisateur admin est disponible une fois que la brique à fini de démarrer.

Est-ce du côté de PAM ou du Open-lpad?

2 Likes
22

Le problème clef est ici : de ce que j’en comprends (ce n’est encore qu’une hypothese) c’est parce que php7.0 veut lancer la pool vpnadmin, qui a besoin de l’utilisateur admin. Si cette opération se produit avant que la base ldap soit lancée, alors l’utilisateur admin “n’existe pas” (il n’a pas d’uid) et on obtient l’erreur cannot get uid for user ‘admin’. Mais plus tard, la base ldap est bien lancée et on peut effectivement lancer la pool vpnadmin …

Idéalement il faudrait modifier la conf systemctl et notamment le After=… pour dire de se lancer apres slapd. Mais c’est pas non plus une manip super facile à intégrer dans le schmilblik de manière automatique (genre php7.0 c’est un paquet apt du coup il réécrase potentiellement ce fichier à chaque update du paquet.

1 Like
23

D’après les logs que j’avais php-fpm se lançait bien après slapd, le problème c’est que nslcd cache les requêtes un moment, du coup c’est vraiment pas évident.

Pour moi créer l’utilisateur admin dans les fichiers (/etc/passwd etc) à l’install avant de configurer le ldap comme source d’users est plus robuste… ou plus simplement faire en sorte que le pool ne tourne pas en admin pour le client vpn; ça me parait abherrant qu’un service web tourne en admin!!!

3 Likes
24

Bonjour !
Y a t-il du nouveau pour ce problème ?
J’ai le même en yunohost 3.2.2.
Il faut lancer le service php7.0-fpm à la main car failed lors du lancement automatique

Fabien