The background
The last time I wrote, it was about to read the screen output correctly and recognize the error correctly and I have already gloriously violated my own rules. I love that – it never gets boring 😀
For a small help project, I actually had to install PHP again – and especially because there are no tests and the code base has grown I needed XDebug.
Usually, you configure your installation to listen for requests with specific cookies, to forward the request to a remote port, the IDE is listening to. Despite it was not working this time, most of the time these lines are enough:
xdebug.remote_enable = 1
xdebug.remote_port = 9000
xdebug.max_nesting_level = 300
xdebug.idekey = "PHPSTORM"
After reviewing the output of phpinfo()
, I could see my settings are active. A cookie is also set. However, let's change our Xdebug configuration so that we can be sure that a session will be passed to port 9000 for each request:
xdebug.default_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.max_nesting_level=300
xdebug.idekey="PHPSTORM"
Nevertheless, the browser does not react, even a test via curl does not provide the desired result:
curl -I --cookie "XDEBUG_SESSION=PHPSTORM;path=/;" localhost
So, another level down and run file directly in the shell:
php -f /var/www/public/index.php
… and hey: Here the IDE is correctly called!
However, the PHP configurations of PHP-CLI and PHP-FPM are identical…
The Issue
To be honest: I spent several hours looking for a solution. Much longer, than actually planned. I checked several previous old projects, studied Nginx logs, switched from Unix socket setup to TCP port, and also to Apache Mod_PHP, but was not able to find the issue.
After that, I started to review the system log by journalctl | grep denied
:
Jul 14 12:42:32 localhost.localdomain audi[76725]t: AVC avc: denied name_connect for pid=76725 comm="php-fpm" dest=9000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
Jul 14 12:42:35 localhost.localdomain audi[76723]t: AVC avc: denied name_connect for pid=76723 comm="php-fpm" dest=9000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
SELinux does not allow to call the port. That explained also, why the issue did not hit me before -> I had no SELinux active/available.
Basically, there are two ways to fix this:
The Quick Fix
Less optimal: We put SELinux into permissive mode so that it no longer intervenes, but still issues a message. Simply adjust the corresponding file yourself and reboot afterward:
sudo sed -i's/! SELINUX.*/SELINUX=permissive/' /etc/selinux/config
More Sophisticated Fix
Better: We leave SELinux intact and supplement the rules of SE1LinuxI follow a post by Jeff Sheltron. In order to analyze our message in more detail, the following command is sufficient:
journalctl _TRANSPORT=audit -o cat | tail -n1| audit2why
The result can look like this:
Was caused by:
One of the following booleans was set incorrectly.
Description
Allow httpd to can network connect
Allow access by executing: setsebool -P httpd_can_network_connect 1
Description
Allow httpd to graceful shutdown
Allow access by executing: setsebool -P httpd_graceful_shutdown 1
Description
Allow httpd to can network relay
Allow access by executing: setsebool -P httpd_can_network_relay 1
Description
Allow nis to enabled
Allow access by executing: setsebool -P nis_enabled 1
Basically, we see some flags/booleans to customize SELinux. Alternatively, this command can also be used:
journalctl _TRANSPORT=audit -o cat | tail -n1| audit2allow
The results are then more compact:
=============== httpd_t ==============
!!!! This avc can be allowed using one of these booleans:
httpd_can_network_connect, httpd_graceful_shutdown, httpd_can_network_relay, nis_enabledallow httpd_t http_port_t:tcp_socket name_connect;
For this case, it was sufficient to set this flag:
sudo setsebool -P httpd_can_network_connect 1