Re: [gull] Question/problème PHP-FPM
Hello, Donc tous les vhosts utilisent le même socket, et parlent à la même instance `père' de php5-fpm, qui ensuite distribue le travail (démultiplexe) vers les différentes instances configurées ? Je me suis mal exprimé. Chaque vhost a un socket dédié. web35 a un socket /var/lib/php5-fpm/web35.sock, web90; web90.sock, etc. Donc il y a bien des processus différents pour chaque vhost et chaque vhost se connecte à un socket différent vers un processus php-fpm qui lui est dédié. ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Question/problème PHP-FPM
On Tue, Jan 08, 2019 at 01:36:15PM +0100, Alexis Domjan wrote: > C'est du mod_proxy_fcgi via un socket unix (on peut aussi utiliser un socket > tcp, c'était d'ailleurs obligatoire jusqu'à Apache 2.4.9). Y'a donc dans la > config du vhost: > > > SetHandler "proxy:unix:/var/lib/php5-fpm/web35.sock|fcgi://localhost" > > > Et dans le pool.d de php5-fpm: > > listen = /var/lib/php5-fpm/web35.sock Donc tous les vhosts utilisent le même socket, et parlent à la même instance `père' de php5-fpm, qui ensuite distribue le travail (démultiplexe) vers les différentes instances configurées ? Si oui, c'est le démultiplexeur de php5-fpm qui a un souci (ou un problème de cache, voir mon autre mail). Dans ce cas, une façon simple d'améliorer l'isolation entre les sites serait d'avoir un php5-fpm PAR vhost (et donc un socket différent par vhost). Ca sera plus lourd, mais ça sera plus sécurisé. ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Question/problème PHP-FPM
Hello, a) php-fpm a fait un nouveau fork, pour une raison ou une autre (p.ex. rechargement de config ou de script PHP, voir le test que te propose Félix), et a passé un descripteur à sa nouvelle instance (fils) -- pourquoi passerait-il le mauvais ? Ce serait en effet étonnant. Mais c'est troublant que le site retourne une erreur HTTP 500 (la fameuse erreur open_basedir()) juste après que les logs indiquent cette information. Peut-être que cette notice n'est pas la cause directe du bug, mais une indication d'un mécanisme qui se produit en même temps ? Ici, j'ai l'impression que ton /var/lib/php5-fpm/web35.sock est peut-être justement le système de communication local (UNIX domain socket) qui permet à apache2 et à php-fpm de communiquer et aussi de se passer les sockets de connexion (c'est plus efficace que de faire du proxying). C'est du mod_proxy_fcgi via un socket unix (on peut aussi utiliser un socket tcp, c'était d'ailleurs obligatoire jusqu'à Apache 2.4.9). Y'a donc dans la config du vhost: SetHandler "proxy:unix:/var/lib/php5-fpm/web35.sock|fcgi://localhost" Et dans le pool.d de php5-fpm: listen = /var/lib/php5-fpm/web35.sock C'est donc bien le moyen de communiquer entre Apache2 et PHP-FPM pour exécuter les scripts PHP. Est-ce que les deux sockets des deux instances php-fpm sont bien différents ? Est-ce que php-fpm est en fait un seul processus qui lance une instance séparée par site ? Il y a deux processus PHP-FPM pour chaque site, car c'est ce qui est configuré par défaut dans php-fpm : pm.start_servers = 2 Quand on lit la doc php-fpm, on voit qu'on peut protéger chacun des sites via chroot (donc le socket doit alors être dans le chroot, et donc une instance séparée php-fpm par client), est-ce ce qui est fait ici? Oui c'est le cas, il y a un chdir / dans la configuration de chaque host sous /etc/php5/fpm/pool.d/*.conf Plutôt avec netstat. Oui, je m'en rappellerai lorsque le problème se reproduira. Tiens, puisque j'ai un compte sur une de tes machines, autant l'utiliser: schaefer@platinum:~$ netstat -anp | grep php (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) unix 2 [ ACC ] STREAM LISTENING 1613770779 - /run/php/php7.1-fpm.sock unix 2 [ ACC ] STREAM LISTENING 1688082839 - /var/run/php5-fpm.sock Sauf que sur cette machine ce n'est pas la même configuration. Sur platinum j'utilise des sockets tcp et il y a aussi un ou plusieurs processus (en fonction du start_servers) pour chaque site. Sur vps, la machine où le problème se produit on peut voir: root@vps:/etc/php5/fpm/pool.d# netstat -anp | grep php | grep web35 unix 2 [ ACC ] STREAM LISTENING 399462849 12125/php-fpm: pool /var/lib/php5-fpm/web35.sock Il y a donc un socket par site aussi. - un socket par version de php-fpm pour communiquer avec apache2 Oui, par version et par site (configuré dans fpm/pool.d/) - un socket pour communiquer entre chaque instance de php-fpm d'une version particulière ? Je ne crois pas que ce soit configuré ainsi, comme je l'ai compris. ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Question/problème PHP-FPM
On Tue, Jan 08, 2019 at 08:30:02AM +0100, Alexis Domjan wrote: > [06-Jan-2019 01:05:03] NOTICE: using inherited socket fd=55, > "/var/lib/php5-fpm/web35.sock" > [06-Jan-2019 01:05:03] NOTICE: using inherited socket fd=55, > "/var/lib/php5-fpm/web35.sock" Un inherited socket, pour moi, ça peut être deux choses: a) php-fpm a fait un nouveau fork, pour une raison ou une autre (p.ex. rechargement de config ou de script PHP, voir le test que te propose Félix), et a passé un descripteur à sa nouvelle instance (fils) -- pourquoi passerait-il le mauvais ? b) apache2 et php-fpm se passent les sockets de connexion entre processus non-fils: https://keithp.com/blogs/fd-passing/ et il y a mélange -- mais dans ce cas ça serait simplement le mauvais site qui s'afficherait Ici, j'ai l'impression que ton /var/lib/php5-fpm/web35.sock est peut-être justement le système de communication local (UNIX domain socket) qui permet à apache2 et à php-fpm de communiquer et aussi de se passer les sockets de connexion (c'est plus efficace que de faire du proxying). Est-ce que les deux sockets des deux instances php-fpm sont bien différents ? Est-ce que php-fpm est en fait un seul processus qui lance une instance séparée par site ? Quand on lit la doc php-fpm, on voit qu'on peut protéger chacun des sites via chroot (donc le socket doit alors être dans le chroot, et donc une instance séparée php-fpm par client), est-ce ce qui est fait ici? > Quand le problème s'est produit, j'ai regardé ce que disait /proc/*/fd pour > les processus php-fpm de ce pool et j'ai juste vu que le socket n'était pas > le même, mais je ne sais pas comment faire pour connaître le chemin du > socket ouvert par un processus, on peut obtenir cette info ? Plutôt avec netstat. Tiens, puisque j'ai un compte sur une de tes machines, autant l'utiliser: schaefer@platinum:~$ netstat -anp | grep php (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) unix 2 [ ACC ] STREAM LISTENING 1613770779 - /run/php/php7.1-fpm.sock unix 2 [ ACC ] STREAM LISTENING 1688082839 - /var/run/php5-fpm.sock A voir oui, les deux sockets sont différents, mais ici pour deux version de PHP; il semblerait qu'il n'y ait qu'un seul socket global pour toutes les instances php5-fpm, et moi je préférerais le chroot. Y-a-t-il toutefois: - un socket par version de php-fpm pour communiquer avec apache2 - un socket pour communiquer entre chaque instance de php-fpm d'une version particulière ? ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Question/problème PHP-FPM
Re, Quand ça se produit (ce qui semble assez rare)... > A tout hasard, cela ne serait pas lié aux rotations de backups? Je ne sais pas, mais en me parlant des logs de php5-fpm (et pas uniquement apache) tu m'as fait penser à y jeter un oeil :-) Et j'ai découvert, je pense, d'où vient probablement le problème: [06-Jan-2019 01:05:03] NOTICE: using inherited socket fd=55, "/var/lib/php5-fpm/web35.sock" [06-Jan-2019 01:05:03] NOTICE: using inherited socket fd=55, "/var/lib/php5-fpm/web35.sock" Donc à 01:05:03 le 6 janvier il y a un héritage de socket, et le problème avec ce site web a commencé à 01:05:06 le même jour ! Et je suis presque sûr que ce fd (no 55) est celui de l'autre site, ce qui permet d'expliquer exactement le problème que je rencontre. Le fait de faire un restart recrée les fd et ça explique aussi pourquoi ça refonctionne... Quand le problème s'est produit, j'ai regardé ce que disait /proc/*/fd pour les processus php-fpm de ce pool et j'ai juste vu que le socket n'était pas le même, mais je ne sais pas comment faire pour connaître le chemin du socket ouvert par un processus, on peut obtenir cette info ? J'avais juste vu que l'id du socket dans /proc (0 -> socket:[399462849]) n'était pas identiques entre web35 et web90, j'ai donc conclu que ce n'était pas les même socket et que le problème était ailleurs. Mais cette notice dans les logs me fait penser que ça pourrait finalement bien être le problème... J'ai cherché rapidement sur le net autour de "using inherited socket", mais je n'ai pas trouvé grand chose... Merci pour tes idées :-) Alexis ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Question/problème PHP-FPM
On Sun, Jan 06, 2019 at 10:00:44PM +0100, Alexis Domjan wrote: > Mais pour un site, une chose très étrange se produit parfois. Un site A > ne fonctionne plus car il tente d'accéder à des fichiers d'un site B. Je ne maîtrise pas trop ce genre de configuration, toutefois, j'ai trouvé ce précédent de mélange de conf files entre projets: http://regilero.github.io/drupal/english/2013/05/16/Warning_chrooted_php_fpm_and_apc/ Il semblerait que c'est lié à l'optimisation PHP de cache, via par exemple APC, qui stocke en dure & binaire certains chemins. Si APC n'est pas actif, ce n'est pas ça. ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Question/problème PHP-FPM
Salut Alexis, On Sun, Jan 06, 2019 at 10:00:44PM +0100, Alexis Domjan wrote: > ...ne fonctionne plus car il tente d'accéder à des fichiers d'un site B. > > Pour résoudre le problème je fait simplement un restart de php5-fpm. > Mais ça reste très étrange. > ... > Comme un redémarrage du serveur web solutionne le problème, c'est qu'il > doit y avoir un problème avec php5-fpm (configuré en socket via > /var/lib/php5-fpm/). Le problème se produit toujours entre ces deux sites... > ... > Quand ça se produit (ce qui semble assez rare)... Hmmm... $ man php5-fpm |grep log tening for CGI requests. Output is logged to /var/log/php-fpm.log. SIGUSR1 re-open log file A tout hasard, cela ne serait pas lié aux rotations de backups? # systemctl restart php5-fpm ... tests # killall -s USR1 php5-fpm ... re rests -- Félix Hauri -- http://www.f-hauri.ch ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Question/problème PHP-FPM
Bonjour Lionel, Merci pour ta réponse. > @Alexis, as tu été voir dans les fichiers autoload.php du client 44 et/ou > client > 28, ça ressemble à un copié collé du fichier du client 28 au client 44, mal > reconfiguré ou il resterai des traces d'appels de scripts du client 44 au > système de fichier du client 28... J'ai vérifié, et il n'y a aucun lien dans les fichiers entre ces deux clients. Aussi, c'est bien le scripts du client44 qui est chargé et exécuté par php-fpm, et pas un include depuis le client28... C'est donc bien que, pour une raison étrange, le processus php-fpm semble charger les fichiers au mauvais endroit... Le client28 n'a pas cette librairie paragonie. > c'est peut être le site B qui fait appel à un script de l'arborescence du > site A > ce qui donne l'impression que c'est le site A qui essaye d’exécuter un script > dans le site B. Si c'était le cas, un redémarrage de php-fpm ne devrait rien résoudre... > Enfin c'est mon simple avis en tant que développeur dans l'embarqué ou ce > genre > de problème peut arriver, je n'ai aucune connaissance en sysadmin, ce n'est > pas > mon métier, donc juste un regard candide extérieur à ce problème tel qu'il est > exposé. Merci pour ton aide. Bonne année également :-) Alexis ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
Re: [gull] Question/problème PHP-FPM
bonjour à tous, @Alexis, as tu été voir dans les fichiers autoload.php du client 44 et/ou client 28, ça ressemble à un copié collé du fichier du client 28 au client 44, mal reconfiguré ou il resterai des traces d'appels de scripts du client 44 au système de fichier du client 28... c'est peut être le site B qui fait appel à un script de l'arborescence du site A ce qui donne l'impression que c'est le site A qui essaye d’exécuter un script dans le site B. Enfin c'est mon simple avis en tant que développeur dans l'embarqué ou ce genre de problème peut arriver, je n'ai aucune connaissance en sysadmin, ce n'est pas mon métier, donc juste un regard candide extérieur à ce problème tel qu'il est exposé. Donc pas frapper svp si je dis de grosses bêtises apparentes :) En fait ce sujet est juste l'excuse pour vous présenter mes Voeux ;) Meilleurs Vœux et salutations à toutes et à tous ! Lionel Le 06.01.19 à 22:00, Alexis Domjan a écrit : Bonsoir à tous, Pour certains clients on offre un hébergement via ISPConfig, configuré avec Apache et PHP-FPM (version 5.6). Ca fonctionne très bien. Mais pour un site, une chose très étrange se produit parfois. Un site A ne fonctionne plus car il tente d'accéder à des fichiers d'un site B. Pour résoudre le problème je fait simplement un restart de php5-fpm. Mais ça reste très étrange. Le site A est www.swissrescue.ch (client28/web35), le site B est www.galaproinfirmis.ch (client44/web90). Voici une des erreurs observées dans les logs de Apache: [Sun Jan 06 21:39:29.682316 2019] [:error] [pid 20339] [client 46.229.168.153:32378] FastCGI: server "/var/www/clients/client28/web35/cgi-bin/php5-fcgi-*-80-swissrescue.ch" stderr: PHP message: PHP Warning: file_exists(): open_basedir restriction in effect. File(/var/www/clients/client44/web90/web/libraries/vendor/paragonie/sodium_compat/src/Compat.php) is not within the allowed path(s): (/var/www/clients/client28/web35/web:/var/www/clients/client28/web35/private:/var/www/clients/client28/web35/tmp:/var/www/swissrescue.ch/web:/srv/www/swissrescue.ch/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin) in /var/www/clients/client44/web90/web/libraries/vendor/paragonie/sodium_compat/autoload.php on line 29 On voit donc que le site A essaie d'exécuter un script PHP situé au mauvais endroit. Comme open_basedir() est en action, c'est refusé... Comme un redémarrage du serveur web solutionne le problème, c'est qu'il doit y avoir un problème avec php5-fpm (configuré en socket via /var/lib/php5-fpm/). Le problème se produit toujours entre ces deux sites... Quand ça se produit (ce qui semble assez rare), j'ai essayé de faire un strace des processus php-fpm, mais c'est très bruyant, donc difficile de voir ce qui se passe. Quelqu'un aurait une idée de ce qui pourrait se passer ou comment diagnostiquer lorsque le problème se produit ? Merci pour votre aide. Alexis ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
[gull] Question/problème PHP-FPM
Bonsoir à tous, Pour certains clients on offre un hébergement via ISPConfig, configuré avec Apache et PHP-FPM (version 5.6). Ca fonctionne très bien. Mais pour un site, une chose très étrange se produit parfois. Un site A ne fonctionne plus car il tente d'accéder à des fichiers d'un site B. Pour résoudre le problème je fait simplement un restart de php5-fpm. Mais ça reste très étrange. Le site A est www.swissrescue.ch (client28/web35), le site B est www.galaproinfirmis.ch (client44/web90). Voici une des erreurs observées dans les logs de Apache: [Sun Jan 06 21:39:29.682316 2019] [:error] [pid 20339] [client 46.229.168.153:32378] FastCGI: server "/var/www/clients/client28/web35/cgi-bin/php5-fcgi-*-80-swissrescue.ch" stderr: PHP message: PHP Warning: file_exists(): open_basedir restriction in effect. File(/var/www/clients/client44/web90/web/libraries/vendor/paragonie/sodium_compat/src/Compat.php) is not within the allowed path(s): (/var/www/clients/client28/web35/web:/var/www/clients/client28/web35/private:/var/www/clients/client28/web35/tmp:/var/www/swissrescue.ch/web:/srv/www/swissrescue.ch/web:/usr/share/php5:/usr/share/php:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin) in /var/www/clients/client44/web90/web/libraries/vendor/paragonie/sodium_compat/autoload.php on line 29 On voit donc que le site A essaie d'exécuter un script PHP situé au mauvais endroit. Comme open_basedir() est en action, c'est refusé... Comme un redémarrage du serveur web solutionne le problème, c'est qu'il doit y avoir un problème avec php5-fpm (configuré en socket via /var/lib/php5-fpm/). Le problème se produit toujours entre ces deux sites... Quand ça se produit (ce qui semble assez rare), j'ai essayé de faire un strace des processus php-fpm, mais c'est très bruyant, donc difficile de voir ce qui se passe. Quelqu'un aurait une idée de ce qui pourrait se passer ou comment diagnostiquer lorsque le problème se produit ? Merci pour votre aide. Alexis ___ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull
