php-fpm.conf for server hostname

This works:

Edit /usr/local/directadmin/data/templates/custom/php-fpm.conf and add this new line:

Code: 
php_admin_value[opcache.file_cache] = |HOME|/.opcache

I addit it right above this line:

Code: 
|*if LIMIT_EXTENSIONS!=""|

then create the directory ".opcache" at /home/USER/ and set file permission to 755

then I did this:

Code: 
./build rewrite_confs
./build opcache
systemctl restart httpd.service
systemctl restart php-fpm70.service

Then upload a phpinfo file in public_html for that user, visit it in browser and confirm it has correct path "on opcache.file_cache" value.

Hurray! Now I only need to automatie creation of /home/USER/.opcache directory upon user creation.

Edit: After adding a new user in DirectAdmin it is needed to manually reload php-fpm for file cache to work in the new user /home/newuser./opcache directory.
 
Last edited:
I am serious. Maybe it's FreeBSD related, I don't know. Here you go - a proof:

phpinfo with no .htaccess:

3.png

phpinfo with:

Code: 
echo "php_flag bcmath.scale 1" > .htaccess

4.png

Notice that it is indeed PHP-FPM and the variable changed (bottom of the image)?
 
Sorry. I only able to think about one thing now. My solution in previous post do not work anyway! It does not create any cache files for anybody but the first user, like last time. Even the path is correct for every user in phpinfo page.
 
Last update. I changed group on /.opcache directory to be apache and then did ./build opcache , and now it works for all users!
 
I knew it has to be group apache based on the first cached subdirectory that appeared. But why rebuilding? Strange thing.
 
Final update: It did not need to be apache on grup after all. More test and now I see my reply #61 was working all the time! I was only fooling my self. :)

The reason I believed it was not working, is because when I tested, if the php script was already in memory cache, it seems it would not be written to file cache before the file was changed or php-fpm restarted. That was why I was under impression it did not work.

So reply #61 actually seem to work for all users. I have then only set owner/group to the user itself, and permission to 777
 
I guess permissions can be lower now... 777 was needed when they was sharing the same folder. It must be done to work with rwx permissions for owner only as the user is the owner of the files anyway... and the php-fpm process is chrooted to that user too...
 
Yes I think permission can be lower. You are right. It is only during testing.

Disregard my previous reply. New update: It seems that when adding a new user in DirectAdmin with a domain, file cahce for the new user cache directory will not work before I do a php-fpm restart (and maybe also a apache restart). Then it seem to work.

Maybe DirectAdmin only do a php-fpm reload, and maybe that is not enough after adding a new user.
 
I see no need for DA to restart php-fpm when adding a new user. Only Apache graceful restart is necessarily.

... except now you have one valid reason :)
 
Yes. But I can live with this. I don't get new users every day! :) No problem to manually add /.opcache directory and restart apache/fpm manually after adding a new user. Thats fine. I think I got it now! My head is spinning. :)
 
Better add two lines at the end of the DA add user script. Yeah, and don't forget to update it every time you update DA...
 
I did some final testing. It is not needed to restart apache after adding new user. All that is needed to get file cache for new user to work is to reload php-fpm:

systemctl reload php-fpm70.service
 
Can we get a little back on our .htaccess puzzle?

Are you running your PHP-FPM with the new AddHandler setup (not too new but kind of)

Code: 
AddHandler "proxy:unix:/usr/local/php71/sockets/webapps.sock|fcgi://localhost" .inc .php .php5 .php71 .phtml

or your setup is with:

Code: 
ProxyPassMatch...

?
 
Last edited:
I think it is the first one, the line starting with AddHandler. But I am not at the moment sure where I can look to find out for sure. Wich file should I look in to find out that?

Can mention I am running php 7.0 and CentOS 7. I only run one php version. I have disabled mod_ruid2.
 
Found it in "Custom HTTPD Configurations", here is a copy from one of the domains:

Code: 
		<FilesMatch "\.(inc|php|phtml|phps|php70)$">
			AddHandler "proxy:unix:/usr/local/php70/sockets/USER.sock|fcgi://localhost" .inc .php .phtml .php70
		</FilesMatch>
 
I have no idea then.

The ProxyPass was a good shot because that was the common configuration in the past and it was a clause which is handled at the very beginning of the httpd request - meaning that it ignores processing .htaccess and everything else, because they are not reached at all. Most tutorials on the internet say that .htaccess is not supported with FastCGI (and PHP-FPM in particular) because of that.

The AddHandler mode was added to mod_proxy_fcgi (that's what is used to forward requests to PHP-FPM) later (Apache 2.4.10) and it is a clause which is evaluated at the END of the HTTP request, meaning that everything else is processed and then this reverse proxy clause is executed.

Are you 100% sure that if you create a new folder on arbitrary clean hosting account and put .htaccess file with that content:

Code: 
php_flag display_errors on

it will cause 500 Internal Server Error?

If it does, all I can guess it's some kind of OS difference...
 
I just tested again. Created a new directory in one of my domains and added a index.html and .htaccess with this:
php_flag display_errors on

Visited the page, and got internal server error, then removed .htaccess, and index.html worked correct.
 
wattie said:
Wait, I got it! It's the htscanner module in Apache which I have:

http://php.net/manual/en/intro.htscanner.php


Code: 
root@srv2:/usr/local/directadmin/custombuild # cat options.conf | grep htscanner
htscanner=yes
Click to expand...

That explains it, because I do not have htscanner=yes :)

Edit: I wonder if there is any downside to using htscanner? It would be nice to enable it before I change production servers to php-fpm, so that I don't have to make sure none of my customers is using php_flag
 
I remember now that it was a long ago when I was running a server with mod_php and then I switched to suphp which caused some of my website to stop working, then I found that module...

Checking with Google I see that it's enabled by default in DA since 2013 and... funny thing you asked about it, then you probably explicitly disabled it nevermind that it does not matter for you at that time:

http://forum.directadmin.com/showthread.php?t=47077

I think it's a very good option to have that module enabled. You recently migrated from mod_php to php-fpm, so that module is definitely much more compatible for you than having it off (before all users were able to use .htaccess to modify php, now none of your users are able to)...
 
Last edited:
You must log in or register to reply here.
Back
Top