Per user Configurations with Custombuild 2.0 + PHP-FPM

nservices

Verified User
Joined
Dec 11, 2008
Messages
301
Hi,
on Custombuild + suphp I add configurations per user that add more security
on user_create_post was:
#!/bin/sh

# create custom temp directory
rm -rf /home/$username/tmp
mkdir -p /home/$username/tmp
chown -R $username:$username /home/$username/tmp

# create custom php.ini
rm -rf /usr/local/directadmin/data/users/$username/php/
mkdir /usr/local/directadmin/data/users/$username/php/
chown $username:$username /usr/local/directadmin/data/users/$username/php/
touch /usr/local/directadmin/data/users/$username/php/php.ini
echo "open_basedir = /home/$username/:/tmp/:/var/www/html/:/usr/local/php5/lib/php" >> /usr/local/directadmin/data/users/$username/php/php.ini
echo "upload_tmp_dir = /home/$username/tmp/" >> /usr/local/directadmin/data/users/$username/php/php.ini
echo "session.save_path = /home/$username/tmp/" >> /usr/local/directadmin/data/users/$username/php/php.ini
chown root:root /usr/local/directadmin/data/users/$username/php/php.ini
chattr +i /usr/local/directadmin/data/users/$username/php/

exit 0;

there is some possible to add some alternative for Custombuild 2.0 + PHP-FPM or even with mod_php?

Best Regards,
Star Network.
 
Hello,

Not sure about mod_php, it seems to me also the answer would be NO, it's not possible to set individual php.ini file, but you can still add directives in custom httpd.conf.

For PHP-FPM, it seems you've got answer NO, as there is now way use individual php.ini per vhost or user (but still you can add some directives into individual php-fpm config files). Details can be found here http://www.directadmin.com/forum/showthread.php?t=45307
 
Thanks for that answer!
I was hoping there was something already done...

Best Regards,
Star Network.
 
It's PHP+Apache related things, you might want to read explanations on PHP mailing list and/or bug-tracker, as the developers gave their view on this several time already.
 
With php-fcgid it is possible. If you follow a guide like this
http://www.wingfoss.com/content/install-mod-fcgid-on-direct-admin
you'll see that every DA-user has a separate php.ini in
/fcgi/|USER|/public_html

They use it to give every user another open_basedir.

Edit: Down at the bottom of
http://php.net/manual/en/configuration.file.per-user.php
there is this comment:
Currently .user.ini files aren't read when using php-fpm, instead you can use [HOST] and [PATH] sections in your main php.ini to set per directory and per domain settings:
http://php.net/manual/en/ini.sections.php
You might give it a try.
 
Last edited:
@Jan_E,

Thank you for the hint.

Hmm, for sure I'll check it. But still I would not follow the guide blindly, as it is written for usage with custombuild 1.x, since custombuild 2.0 the things have changed.
 
If smtalk read this, I'm also wondering why don't he goes with mod_fcgid instead of suPHP? The implement shouldn't be too hard and it give you every benefit you can get with suPHP with a better function like.. keep the process for sometime before kill it. specify the maximum process per user if needed and a lot more.

I mean suPHP is no longer maintained in my opinion, last updated is on 2009-03-14 while mod_fcgid is maintained by Apache and last updated is on 2012-04-13 and it works without any source code modification with Apache 2.4.
 
Last edited:
If smtalk read this, I'm also wondering why don't he goes with mod_fcgid instead of suPHP? The implement shouldn't be too hard and it give you every benefit you can get with suPHP with a better function like.. keep the process for sometime before kill it. specify the maximum process per user if needed and a lot more.

It is not "instead", because they're completely different :) suPHP is left for these that like the functionality of it. PHP-FPM is used in CB 2.0 and mod_fastcgi is used as an apache module to make it available. Do you see any point of using mod_fcgid instead of that? About individual php settings, it was already discussed. You can have anything "custom" set in /usr/local/directadmin/data/users/user/php/php-fpm54.conf. Template is here: /usr/local/directadmin/data/templates/php-fpm.conf.
 
It is not "instead", because they're completely different :) suPHP is left for these that like the functionality of it. PHP-FPM is used in CB 2.0 and mod_fastcgi is used as an apache module to make it available. Do you see any point of using mod_fcgid instead of that? About individual php settings, it was already discussed. You can have anything "custom" set in /usr/local/directadmin/data/users/user/php/php-fpm54.conf. Template is here: /usr/local/directadmin/data/templates/php-fpm.conf.

I actually prefer PHP-FPM :) but when I think about mod_fcgid that can do everything that suPHP can do, I don't know why DA still use suPHP. mod_fcgid can be set to be zero process so it will fork when needed like suPHP and PHP-FPM Ondemand. It can also have per user php.ini as suphp does. (In PHP-FPM, some module like XCache can't be loaded via php_admin_value. I'm not sure if there is any other.) Memory usage should be similar. One thing I'm not sure is that when so many requests comes to suPHP. What will happen? But I think it would be the same as mod_fcgid. So, set max processes per server to quite a high number would result in the same as suPHP. I might be wrong with the last one though.

Here is the page I just found and I think it's quite useful -> http://www.cloudlinux.com/blog/clnews/perfecting-fastcgi-settings-for-shared-hosting.php

With very low timeout value in mod_fcgid configuration, it should work the same as suPHP. But it can be tweak by advanced admin to do better with just one simple change in configuration file.
 
I actually dislike PHP-FPM, because mod_rewrite is acting differently. For instance, the default .htaccess for drupal is broken and leads to looping redirects.

And I really like mod_fcgid, because opcode cachers like XCache 3.0.0 work happily with it (contrary to suPHP). And besides that mod_fcgid has the advantage over mod_php that is will not draw Apache with it when it crashes.

See my how-to on mod_fcgid for CB 2.0: http://www.directadmin.com/forum/showthread.php?t=45386
 
And I really like mod_fcgid, because opcode cachers like XCache 3.0.0 work happily with it (contrary to suPHP). And besides that mod_fcgid has the advantage over mod_php that is will not draw Apache with it when it crashes.

Jan_E, can you check if XCache 3.0 is really work on mod_fcgid? I tried that long time ago with XCache Version 2.x but it seems like it works for sometime before it stops working. And you will never know that until you really check. I think in their XCache web stat. You will see that it hardly cache anything. Moreover, I've read the author replied at that time and he stated the same. That's one of the reason I switched to PHP-FPM for some large sites.
 
Of course, I checked that. I have been running XCache 3.0.0 on my Windows 2008R2 server production server for some time now under PHP 5.3 mod_fcgid with great results. That is why I wanted to implement the same on my Centos boxes. Screenshot of the XCache stats after a really small domain had been running for a night with PHP 5.4 as mod_fcgid: xcache_mod_fcgid.gif.

See this Cloudlinux discussion as well. You will have to experiment with the PHP_FCGI_* settings to keep the PHP-instances active as long as possible.

BTW: I checked if the opcode cache was shared between users. It was not.
 
Last edited:
Jan_E Thanks for the info. According to this

With mod_fcgid, each PHP process has its own opcode cache. It is still useful as single process can serve thousands of requests, and opcode cache will greatly speed that up.

My understanding about it to make it works properly, I should not kill the process (Or set it to serve longer before kill.) and I also should set memory to some moderate amount since each process will have its own xCache.

I will have to find sometime to try that :)
 
Check this site for a discussion on PHP_FCGI_CHILDREN:
http://wherethebitsroam.com/blogs/jeffw/apache-php-fastcgi-and-phpfcgichildren
I had to find it back for my mod_fcgid how-to.

On the other hand, there is an intriguing remark on this site:
http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/
Only the child process is restarted, the parent process remains. Since the parent process maintains the opcode cache, the opcode cache persists.
It is a remark on APC, but it sets you thinking...
 
Last edited:
As far as I know PHP_FCGI_CHILDREN > 0 works well with mod_fastcgi but not mod_fcgid. The config for both of them can look the same and I found that lots of the documents over the Internet doesn't really say what the config is really for. I also think that many of those authors think that both of them are the same but they are not.

So it appears that setting PHP_FCGI_CHILDREN is pointless under mod_fcgi/apache as each group will only ever handle 1 request at a time.

Both mod_fcgid and mod_fastcgi can be told to limit the number of PHP processes to 1 per user. The PHP process can then be told how many children to spawn. Unfortunately mod_fcgid will only send one request per child process. The fact that PHP spawns its own children is ignored by mod_fcgid. If we use mod_fcgid with our setup, we can only handle one concurrent PHP request. This is not good. A long running request could easily block multiple smaller requests.

mod_fastcgi will send multiple simultaneous requests to a single PHP process if the PHP process has children that can handle it. This is the reason we must use mod_fastcgi to achieve our goal of one cache per user.

This is the reason PHP-FPM comes up. It does the process manager very well and can actually replace mod_fastcgi :)
 
As far as I know PHP_FCGI_CHILDREN > 0 works well with mod_fastcgi but not mod_fcgid.
The official Apache docs of mod_fcgid.c seem to imply something else.
http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

Any program assigned to the handler fcgid-script is processed using the FastCGI protocol; mod_fcgid starts a sufficient number instances of the program to handle concurrent requests, and these programs remain running to handle further incoming requests. This is significantly faster than using the default mod_cgi or mod_cgid modules to launch the program upon each request. However, the programs invoked by mod_fcgid continue to consume resources, so the administrator must weigh the impact of invoking a particular program once per request against the resources required to leave a sufficient number of instances running continuously.

The pool of fcgid-invoked programs is shared between all httpd workers. Configuration directives below let the administrator tune the number of instances of the program that will run concurrently.
But you are right about the confusion between mod_fastcgi and mod_fcgid. But mod_fcgid is actively maintained and improved a lot between 2.3.5 and 2.3.7.
 
I'm not sure if I will be able to explain it clearly or not but I will give it a try. Actually, it implies the same thing as I said earlier. mod_fcgid will starts each process on its own and talk with Apache directly while PHP-FPM will start a main process and spawn child processes under it. That way, PHP-FPM does manage the process while mod_fcgid doesn't. If you check your server with command pstree -up you will see something like below :

mod_fcgid:

Code:
        ├─httpd(19746)─┬─httpd(11405,apache)
        │              ├─httpd(11406,apache)─┬─php-cgi(22156,ccccc)
        │              │                     ├─php-cgi(2724,aaaaa)
        │              │                     ├─php-cgi(2728,aaaaa)
        │              │                     ├─php-cgi(28040,aaaaa)
        │              │                     ├─php-cgi(4822,bbbbb)
        │              │                     ├─php-cgi(11643,bbbbbb)

php-fpm:

Code:
        ├─php-fpm53(10026)─┬─php-fpm53(10027,xxxxx)
        │                  ├─php-fpm53(10028,xxxxx)
        │                  ├─php-fpm53(10037,ccccc)
        │                  ├─php-fpm53(10038,ccccc)
        ├─php-fpm54(10030)─┬─php-fpm54(10034,xxxxx)
        │                  └─php-fpm54(10036,xxxxx)

As you can see that mod_fcgid is run connect directly with Apache. It looks like mod_fcgid is a child process under Apache. With PHP-FPM all child processes will be under single main PHP-FPM process.

I never try mod_fastcgi alone. But according to here -> http://www.directadmin.com/forum/showthread.php?t=28758&page=3

tillo shows pstree -up as below :

Code:
$ pstree -up
[...]
        |              |                     |-{httpd}(14831)
        |              |                     `-{httpd}(14832)
        |              |-httpd(30625,apache)
        |              `-httpd(30626,apache)-+-php-cgi(3839,webapps)-+-php-cgi(3840)
        |                                    |                       |-php-cgi(3841)
        |                                    |                       |-php-cgi(3842)
[...]

As you can see, it looks like PHP-FPM that has child processes under the main one since both mod_fastcgi and PHP-FPM can have working child processes while mod_fcgid doesn't.

Below is also from the same Apache mod_fcgid page :

PHP child process management (PHP_FCGI_CHILDREN) should always be disabled with mod_fcgid, which will only route one request at a time to application processes it has spawned; thus, any child processes created by PHP will not be used effectively. (Additionally, the PHP child processes may not be terminated properly.) By default, and with the environment variable setting PHP_FCGI_CHILDREN=0, PHP child process management is disabled.

The popular APC opcode cache for PHP cannot share a cache between PHP FastCGI processes unless PHP manages the child processes. Thus, the effectiveness of the cache is limited with mod_fcgid; concurrent PHP requests will use different opcode caches.
 
Last edited:
Back
Top