[PHP-FPM] empty tokens in DA prevent PHP from working in Nginx on Debian 9

HolyDiver

Verified User
Joined
Feb 21, 2016
Messages
51
I updated from Debian 8.10 to Debian 9.3 and had to upgrade my php version to 5.6 (still running some legacy software). It used to run on mod_php, but since Debian 9 doesn't play well with mod_ruid2 I decided to switch to PHP-FPM (already wanted to do so later on). I'm running the nginx_apache reverse proxy option and the most recent version of DA, Nginx and Apache.

Before finding out mod_ruid2 doesn't play well with Debian 9, all pages including php pages served a 502 bad gateway error page. Error logs didn't show much useful.

After I removed mod_ruid2, I got 403 forbidden pages on php pages while the static pages and images were working again. Nginx error log showed permission denied errors.

If I chmoded php pages to 777, I noticed the php pages were getting served but with the php code unprocessed in the source code. So the reverse proxy thing worked well, but Nginx couldn't pass it through to php.

Snooping through the Nginx.conf, the only php bits in it were references like /usr/local/directadmin/data/users/USER/nginx_php.conf. Checking the contents of this conf, turned out to be blank! Checking the original template which was intact, but for some reason the HAVE_PHP1_FPM wasn't triggered. Okay, checking the httpd config section in DA for the tokens, I ran into this:

APACHELOGDIR=/var/log/httpd/domains
CB_VERSION=2
CREATOR=holydiver
DEFAULT_DOMAIN=website.net
GROUP=holydiver
HAVE_MOD_SECURITY=0
HAVE_PHP1_FCGI=0
HAVE_PHP1_FPM=0
HAVE_PHP2_FCGI=0
HAVE_PHP2_FPM=0
HAVE_RUID2=0
HAVE_SUEXEC_PER_DIR=1
HOME=/home/holydiver
HOSTNAME=server.website.net
LSPHP1_RELEASE=
LSPHP2_RELEASE=
NGINX_MOD_SECURITY_ENABLE=
OPEN_BASEDIR_AND_CLI=OFF
OPEN_BASEDIR_ENABLED=OFF
PHP=ON
PHP1_RELEASE=0.000000
PHP2_RELEASE=0.000000
PHP_MAIL_LOG_ENABLED=1
PORT_443=443
PORT_80=80
RUID2_AND_MOD_SECURITY=0
SECURE_ACCESS_GROUP=access
SPACE_HTTP2= http2
SSL=ON
SUPHP=0
SUSPENDED=no
USER=holydiver
USERHOME=/home/holydiver
USER_CLI=0
USE_HOSTNAME_FOR_ALIAS=0

Just to be clear, DA was configured for php 5.6 on fpm and it's running fine. But obviously Nginx can't connect with unix:/usr/local/php0.000000/sockets/holydiver.sock. Every php page is now returning a 404.

My website has been down for 2 days because of this, I'm not sure if it's a bug or something is messed up on my server. I'm trying to change the config files with static values to see if it's running. But I've never had a more severe problem with DA like this, so I figured it's worth mentioning even if most people don't have this problem.
 
Last edited:
The previous problem:
[crit] 1851#0: *27 connect() to unix:/usr/local/php56/sockets/holydiver.sock failed (13: Permission denied) while connecting to upstream, client: 212.143.177.132, server: website.net, request: "GET /news.php HTTP/1.1", upstream: "fastcgi://unix:/usr/local/php56/sockets/holydiver.sock:", host: "www.website.net"

Just to be clear, DA was configured for php 5.6 on fpm and it's running fine. But obviously Nginx can't connect with unix:/usr/local/php0.000000/sockets/holydiver.sock. Every php page is now returning a 404.
Replaced the broken tokens so the socket link features 'php56' and not 'php0.000000'. Nginx can't connect with the sockets if the socket directory gets chmoded to 700. I changed it to 711.

Changed listen.group from $pool to 'nginx' in php-fpm.conf since it defaulted to apache.
[|USER|]
user = $pool
group = $pool

listen = /usr/local/php|PHP_VER|/sockets/$pool.sock
listen.owner = $pool
listen.group = nginx
listen.mode = 660

Commented out try_files from nginx_php.conf since this caused everything to be served with a 404.
location ~ \.php$
{
#try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/nginx_limits.conf;

fastcgi_pass unix:/usr/local/php56/sockets/|USER|.sock;
}

Sadly the chmoded socket directory will revert back to 700 after a reboot/reload, so this is not a solution. Some pages now trigger this error in the nginx log:

[error] 1851#0: *27 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 212.143.177.132, server: website.net, request: "GET/ HTTP/2.0", upstream: "fastcgi://unix:/usr/local/php56/sockets/holydiver.sock:", host: "www.website.net", referrer: "https://www.website.net/news.php"
I don't have selinux installed. It only triggers on php pages without a php extension in the url.

Whatever the problem is, it's just a permission thing. But it sure feels like something that only happens when you switch from mod_php to php-fpm...
 
Hello,

Did you try the following commands:

Code:
/usr/local/directadmin/scripts/set_permissions.sh all

Code:
./build clean
./build update
./build apache
./build php
./build rewrite_confs

Do you have secure_access_group set properly (https://www.directadmin.com/features.php?id=961)?

What do you see with
Code:
ls -la /home/
 
I tried the commands and nothing seems to have effectively changed. I still have to chmod the socket folder to 711 to get nginx communicated with php (or else 502 bad gateway happens).

I think secure_access_group is set properly.

cat etc/group
Code:
[...]
access:x:1005:apache,nobody,mail,majordomo,daemon,nginx
[...]

ls -la /home/
Code:
total 32
drwx--x--x  8 root       root       4096 Feb 10  2017 .
drwxr-xr-x 24 root       root       4096 Jan  2 21:36 ..
drwx--x--x  2 root       root       4096 Feb 10  2017 .disposal
drwx--x--x 10 holydiver holydiver 4096 Nov 13 21:46 holydiver
drwx--x---  8 gary     access     4096 May 21  2017 gary
drwx--x--x 11 mysql      mysql      4096 Jan  1 12:21 mysql
drwxrwxrwt  2 root       root       4096 Jan  3 09:00 tmp

I also just noticed a weird error in phpMyAdmin (which seems to work fine nonetheless)

Code:
Warning in ./libraries/Logging.php#90
fopen(./log/auth.log): failed to open stream: Permission denied

Backtrace

./libraries/Logging.php#90: fopen(
string './log/auth.log',
string 'a',
)
./libraries/Logging.php#45: PMA\libraries\Logging::log_to_file(
string 'xxxxxx_xxxx',
string 'ok',
)
./libraries/common.inc.php#822: PMA\libraries\Logging::logUser(string 'xxxxxx_xxxx')
./index.php#20: require_once(./libraries/common.inc.php)

Group seems fine
Code:
uid=103(webapps) gid=105(webapps) groups=105(webapps)
 
Last edited:
Code:
[...]
HAVE_PHP1_FCGI=0
HAVE_PHP1_FPM=0 [color=red][B]**should be 1**[/B][/color]
HAVE_PHP2_FCGI=0
HAVE_PHP2_FPM=0
[...]
PHP1_RELEASE=0.000000 [color=red][B]**should be 56**[/B][/color]
PHP2_RELEASE=0.000000
[...]
Last year I tried to run PHP7 on a second installment and I couldn't get the PHP configuration in DA to work. It always defaulted to the PHP on mod_php. Now I know why sorta, these tokens were already broken back then long before I upgraded to Debian 9.

I can't seem to get the socket directory changed permanently. Nginx is neither the owner or the group and the default 710 is not sufficient to get Nginx communicating with PHP. PHP on webapps works good for some reason except for the phpMyAdmin error. The actual websites won't work until chmod 711 on the sockets directory or even better, if I chown the socket directory to nginx. But that's not a real solution as ./build rewrite_confs will default it back to 710/apache.

Code:
ls -l /usr/local/php56/
total 32
drwxr-sr-x 2 root   staff  4096 Jan  3 10:29 bin
drwxr-sr-x 2 root   staff  4096 Jan  3 10:29 etc
drwxr-sr-x 3 root   staff  4096 Jan  1 11:24 include
drwxr-sr-x 4 root   staff  4096 Jan  3 10:29 lib
drwxr-sr-x 4 root   staff  4096 Jan  1 11:24 php
drwxr-sr-x 2 root   staff  4096 Jan  3 10:29 sbin
drwx--S--- 2 [color=red][B]apache apache[/B][/color] 4096 Jan  4 14:46 sockets
drwxr-sr-x 4 root   staff  4096 Jan  1 11:24 var

Code:
ls -l /usr/local/php56/sockets
total 0
srw-rw---- 1 [color=red][B]nginx   apache[/B][/color] 0 Jan  4 14:46 holydiver.sock
srw-rw---- 1 [color=red][B]nginx   apache[/B][/color] 0 Jan  4 14:46 gary.sock
srw-rw---- 1 webapps apache 0 Jan  4 14:46 webapps.sock
 
Last edited:
Have custom templates under /usr/local/directadmin/data/templates/custom/ ? Outdated?

I have this:

Code:
srw-rw---- 1 wpsite01  apache 0 Jan  5 11:09 wpsite01.sock
srw-rw---- 1 wpsite02  apache 0 Jan  5 11:09 wpsite02.sock

and no issue with it.
 
Only a DNS conf that has one additional line for a 127.0.0.1 reference.

Code:
ls -l /usr/local/directadmin/data/templates/custom/
total 12
-rw-r--r-- 1 diradmin diradmin 125 Jul 31  2012 dns_a.conf
-rw-r--r-- 1 diradmin diradmin 410 Jan  5 00:51 nginx_php.conf
-rw-r--r-- 1 diradmin diradmin 853 Jan  5 15:42 php-fpm.conf

The problem isn't the permission on the socket files, the problem is the owner of the socket directory. Nginx has no permission to do anything if it's owned by Apache.

Code:
ls -l /usr/local/php56/
[...]
drwx--S--- 2 [color=red][b]apache[/b][/color] apache 4096 Jan  5 15:42 sockets
[...]
 
Chowning the socket directory to nginx apparently lets roundcube and phpmyadmin serve a 500 internal server error, I hadn't checked them recently. Chmodding the socket directory to the unsafe 711 is the only temp solution. Really considering swapping nginx_apache for standalone nginx :(
 
Switched to standalone Nginx, no more permission errors anymore. Websites work, PHP works, webapps works.

The DirectAdmin tokens are still broken though. Also I noticed this new error in an email...

/etc/cron.daily/custombuild:
[1mUpdating DirectAdmin(B[m
/etc/cron.daily/logrotate:
error: Ignoring directadmin because of bad file mode - must be 0644 or 0444.
error: error setting owner of /var/www/html/roundcube/logs/errors to uid 1001 and gid 105: Operation not permitted
run-parts: /etc/cron.daily/logrotate exited with return code 1

uid=1001(apache)
gid=105(webapps)
I'm guessing this is also the cause of the fopen error in phpMyAdmin?
 
Last edited:
Yep, the fopen error in phpMyAdmin has the same cause; it's owned by apache even though I switched to standalone Nginx. I did run set_permissions.sh again, but it didn't fix it. On PMA's Github page it's marked as a Directadmin bug due to changes to the Brute Force Monitor feature. The roundcube error had the same problem. Hopefully these won't revert back after an update or reboot.

Code:
chown -R webapps:webapps /var/www/html/phpMyAdmin/log

Code:
chown -R webapps:webapps /var/www/html/roundcube/logs

According to this 2014 thread the DirectAdmin logrotate error happened on the previous Debian major upgrade too. I can confirm mine was set on 755, while DirectAdmin should automatically chmod it to 644.
Code:
chmod 644 /etc/logrotate.d
 
Last edited:
Back
Top