[BUG] secure_php resets ownership to apache

M

MtK

Verified User
Joined
Aug 2, 2007
Messages
412
after a successful installation of nginx + php-fpm53 everything worked ok.

after using ./build secure_php the ownership of /usr/local/php53/sockets/webapps.sock was reset to webapps.apache.
this caused:
Code: 
connect() to unix:/usr/local/php53/sockets/webapps.sock failed (13: Permission denied) while connecting to upstream, client:...

changing the ownership to webapps.nginx solved the issue.
 
secure_php does not change any permissions. So it is not related to the problem. It could be that php-fpm53 was not restarted after the switch to nginx, that's why the file remained owned by apache.
 
smtalk said:
secure_php does not change any permissions. So it is not related to the problem. It could be that php-fpm53 was not restarted after the switch to nginx, that's why the file remained owned by apache.
Click to expand...
the installation was nginx + php-fpm at once, and it worked fine over a few reboots as well.

then, I decided to do the secure_php and... ownership changed...

I just did that again:
Code: 
# ls -l /usr/local/php53/sockets/webapps.sock
srw-rw---- 1 webapps nginx 0 Oct  3 12:25 /usr/local/php53/sockets/webapps.sock
# ./build secure_php
PHP has been secured.
# ls -l /usr/local/php53/sockets/webapps.sock
srw-rw---- 1 webapps nginx 0 Oct  3 12:25 /usr/local/php53/sockets/webapps.sock
# service php-fpm53 restart
Gracefully shutting down php-fpm53:  done
Starting php-fpm53:  done
# ls -l /usr/local/php53/sockets/webapps.sock
srw-rw---- 1 webapps apache 0 Oct  3 12:26 /usr/local/php53/sockets/webapps.sock
 
this might be the problem:
Code: 
# cat ./php-fpm.conf.53 | grep apache
listen.group = apache
 
No, the problem is that you have listen.group=apache set in /usr/local/php53/etc/php-fpm.conf. If you would do:
Code: 
./build php n

CustomBuild should detect and fix it automatically.
 
smtalk said:
No, the problem is that you have listen.group=apache set in /usr/local/php53/etc/php-fpm.conf. If you would do:
Code: 
./build php n

CustomBuild should detect and fix it automatically.
Click to expand...
I will (later) but whay is it apache, if both php 5.4 & 5.3 were installed while nginx was already ON?
 
nope. still the same:
Code: 
# ls -l /usr/local/php54/sockets/webapps.sock
srw-rw---- 1 webapps apache 0 Oct  3 17:23 /usr/local/php54/sockets/webapps.sock
# ls -l /usr/local/php53/sockets/webapps.sock
srw-rw---- 1 webapps apache 0 Oct  3 17:23 /usr/local/php53/sockets/webapps.sock
I could override this with a custom template, but I think maybe a global variable would be a better idea.

i.e $webserver:
Code: 
#HTTP server. Possible values: apache, nginx
webserver=nginx
 
You seem to have a misconfiguration somewhere, as I am unable to reproduce the problem. I could check it on your server, if you'd like me to. Don't you have 2 instances of the "webserver" option in the options.conf?
 
Hello,

The php-fpm.conf.* files are always going to have listen.group = apache.
CustomBuild copies this file to /usr/local/php53/etc/php-fpm.conf, and after it's there, uses perl to swap apache to perl.
This is done in the fpmChecks() funciton of the build script.

It is possible that there might be a bug in that code somewhere, but neither Martynas nor I can spot it on our test systems.
If you'd like us to check the box for you, we'd need to login to see what's going on (either of us would be fine).

If you want:
https://www.directadmin.com/clients/safesubmit.php

John
 
if it's being replaced then it's better to use a |WEBSERVER| variable, so when people use it in custom they'd know it should be replaced by their selection in option.conf

this leads to 'how to reproduce':
put the file in custom/fpm/conf, apache will not be replaced.
 
custom/nginx/conf/nginx.conf, same issue:
Code: 
# ./build rewrite_confs
Using AAA.BBB.CCC.DDD for your server IP
Gracefully shutting down php-fpm54:  done
Starting php-fpm54:  done
Gracefully shutting down php-fpm53: . done
Starting php-fpm53:  done
Restarting nginx.
nginx: [emerg] host not found in "|IP|:80" of the "listen" directive in /etc/nginx/nginx.conf:64
nginx: configuration file /etc/nginx/nginx.conf test failed
 
MtK said:
custom/nginx/conf/nginx.conf, same issue:
Code: 
# ./build rewrite_confs
Using AAA.BBB.CCC.DDD for your server IP
Gracefully shutting down php-fpm54:  done
Starting php-fpm54:  done
Gracefully shutting down php-fpm53: . done
Starting php-fpm53:  done
Restarting nginx.
nginx: [emerg] host not found in "|IP|:80" of the "listen" directive in /etc/nginx/nginx.conf:64
nginx: configuration file /etc/nginx/nginx.conf test failed
Click to expand...
it looks like NGINXCUSTOMCONFDIR is never used, but NGINXCONFDIR.

looking at ./build:
Code: 
# Variables for nginx
NGINX_CONFIGURE=configure/nginx/configure.nginx
if [ -e custom/nginx/configure.nginx ]; then
	NGINX_CONFIGURE=custom/nginx/configure.nginx
fi
NGINXCONFDIR=${WORKDIR}/configure/nginx/conf
NGINXCUSTOMCONFDIR=0
if [ -d ${WORKDIR}/custom/nginx/conf ]; then
        NGINXCUSTOMCONFDIR=${WORKDIR}/custom/nginx/conf
fi
first clause is OK, second should set NGINXCONFDIR, not NGINXCUSTOMCONFDIR

(same issue for FPM)



looking even deeper:
Code: 
		#copy the new configs
		cp -rf ${NGINXCONFDIR}/* ${NGINXCONF}
		
		tokenize_IP;
		
...
...	
		if [ "${NGINXCUSTOMCONFDIR}" != "0" ]; then
			cp -rf ${NGINXCUSTOMCONFDIR}/* ${NGINXCONF}/
		fi
IP is replaced at the top, but not at the bottom.
 
adding tokenize_IP;
fixes the issue for NGINX, but this needs a better fix.
 
You must log in or register to reply here.
Back
Top