FastCGI on Modern DirectAdmin

Damn Tillo, I hope everything is OK!!! Get well soon!! :-)
Long time no speak by the way. I did notice you are absent from the messengers for a long time now. I just hope you are ok. Feel good! :)
 
tillo said:
I don't mind being pushed a little :) it's on my TODO list, as always. I've got a surgery last week and I'm resting, I'm going to work on it as soon as I'm on my feets.
Click to expand...
I'm also looking forward to this guide, and I hope that your recovery from the surgery went well. :)

If you need anyone to help test the guide, then I'd be more than willing to, if I'm free at the time. Thanks for putting in the effort, tillo.
 
Oh my, I even managed to totally forget about this little project of mine... my profound apologies to those who were waiting, I'll try to complete it soon enough.
@Inquisitor: I'll contact you in private as soon as the first version is done :) thank you!
 
We haven't forgotten! :)

If you get this puppy done don't forget to let us know.

Thanks,
Jerret
 
It's slighty similar, but I've done many improvements since.

I still haven't had time to work on it, but, as request by skaag, some time ago I've gathered a (hopefully) complete set of my config files (see below).
@skaag: how did things go for you?

It's important to note that this config is ment for a very special system: many GB of RAM and very few users all with very high traffic.
Of course the "right" tutorial will guide you into build a correct config for your needs, but this will be enough for skilled people. Also remember that you can use per user php.ini files, allowing you to choose which users will have the APC extension, how much memory will they use and which of their scripts can be ignored.

First, the set of config files: http://www.tillo.ch/temp/fastcgi.txt

And I also sent this message to him afterwards:
tillo said:
Hi there,

There is one huge thing that needs to be done in order to make my FastCGI-driven system work: Apache2 has to be compiled with the Worker MPM.

Code: 
root@edge:/usr/local/directadmin/custombuild# cat custom/ap2/configure.apache 
#!/bin/sh
"./configure" \
	"--prefix=/etc/httpd" \
	"--exec-prefix=/etc/httpd" \
[...]
	"--with-ssl=/usr" \
	"--enable-headers" \
	"--with-mpm=worker" \
	"--enable-proxy-connect" \
[...]

As you can see, after "--enable-headers" I've added "--with-mpm=worker". The other things don't matter.

Here is the worker configuration:
Code: 
root@edge:/etc/httpd/conf/extra# cat httpd-mpm.conf
[...]
# worker MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_worker_module>
    StartServers          1
    ServerLimit           4
    MaxClients          256
    MinSpareThreads      32
    MaxSpareThreads      64 
    ThreadsPerChild      64
    MaxRequestsPerChild   0
</IfModule>
[...]
- StartServers MUST be 1.
- ServerLimit should be set to 1 if you can't afford to have FastCGI to be run more then once. It's a failsave option, if you run 32 php-cgi processes and have 33 users connected at the same time 64 processes will be spawned. If you set 1 the 33th user will timeout.
- MaxClients should be the exact same amount of php-cgi processes spawned by FastCGI
- MaxRequestsPerChild MUST be 0 to have APC cache the opcode forever (or until apache is restarted)

The other values can be modified according to your performance needs.

Here is what the processes should look at the end:

Code: 
$ pstree -u 27854
httpd─┬─httpd(apache)───65*[{httpd}]
      ├─httpd(apache)
      └─httpd(apache)─┬─php-cgi(webapps)───256*[php-cgi]
                      ├─php-cgi(tillo)───256*[php-cgi]
                      ├─php-cgi(noirgame)───256*[php-cgi]
                      ├─php-cgi(lithium)───256*[php-cgi]
                      └─php-cgi(exty)───256*[php-cgi]
Click to expand...
 
Thanks Tillo,

This is my situation indeed - a server with 9GB of ram and only a handful of users. My intention is to preserve the suphp ownership mechanism but increase performance/responsiveness by eliminating the setup/teardown nature of CGI php and adding the performance enhancements of caching the opcode.

I'll look into it in more detail tonight, thanks again!

Best Regards,
Jerret Kinsman
 
I'm glad it fits your needs, please let me know if there is anything missing.
I really wanted to make a nice tutorial out of that, I hope I will someday.
 
Tillo thank you, i have do everything in this post :
http://www.directadmin.com/forum/showpost.php?p=124878&postcount=450

How can i chek of everything is done?

Code: 
[root@serv ~]# php -v
PHP 5.2.10 (cli) (built: Sep  3 2009 21:13:20)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with the ionCube PHP Loader v3.1.32, Copyright (c) 2002-2007, by ionCube Ltd., and
    with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies
 
Last edited:
Another possibility is to run mod_ruid, that runs the entire httpd-proces under a user. A short install guide from my internal wiki: (EL5/x86_64)

Code: 
yum installl libcap-devel
cd /usr/src
wget [url]http://websupport.sk/~stanojr/projects/mod_ruid/mod_ruid-0.6b.tar.gz[/url]
tar -xzf mod_ruid-0.6b.tar.gz
cd mod_ruid-0.6b
/usr/sbin/apxs -a -i -l cap -c mod_ruid.c
cd /usr/local/directadmin/data/templates
cp virtual_host2* custom/
cd custom
wget [url]http://crew.pcextreme.nl/files/linux/util/directadmin/da_vhosts_templates_apache2_mod_ruid.tar.gz[/url]
tar -xzf da_vhosts_templates_apache2_mod_ruid.tar.gz
rm -f da_vhosts_templates_apache2_mod_ruid.tar.gz
nano /etc/httpd/conf/httpd.conf

Add above "ServerAdmin admin@localhost":
# mod_ruid
RMode config
RUidGid apache apache

Code: 
echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
 
Last edited:
grockord said:
Fastcgi is more faster than cli mode?
Click to expand...

Yes and no. But FastCGI runs PHP under the user, not under apache : apache. So a php.ini per user is possible. No more 666/777 chmods. Thus, this is more safe. It's the same as suphp, only now we dont spawn a cgi process for every request but leave these open with an fcgi-deamon. (Use the deamon from lighthttpd). It saves a lot of (disk) i/o too.
 
BLTYNR said:
How can i chek of everything is done?
Click to expand...

First, if FastCGI is used correctly your processes should look something like this:
Code: 
$ pstree -u
[...]
     ├─httpd─┬─httpd(apache)───65*[{httpd}]
     │       ├─httpd(apache)
     │       └─httpd(apache)─┬─php-cgi(webapps)───128*[php-cgi]
     │                       ├─php-cgi───128*[php-cgi]
     │                       ├─php-cgi(tillo)───128*[php-cgi]
[...]

Also, the APC distribution includes an apc.php script that you can place wherever you want to see if caching is well used.
Just like this one: http://www.tillo.ch/apc.php
 
Thanks for the guide tillo.
I succeded to install it. One question.
Is it possible to have php.ini for each user?
 
It is indeed possible, just follow any guide related to DA and PHP-CGI. With my guide you already have a wrapper, so it may just as easy as adding a variable definition into the FastCGI wrapper that instruct PHP to read $USER/php.ini (or whatever).
I never did it, so I can't tell you if that's all.
 
tillo said:
[..]If you are on mod_php/prefork, there is absolutely no need for FastCGI AFAIK.[..]
Click to expand...

At the moment I am using PHP 5.2.12 with CLI. I am not using any firewall solutions (like APC). Would you reccomend me to change to use FCGI?

I am conserned if my server is not "secure" enough with CLI. After I have been reading about it, I don't want suphp or CGI because of the performance is not so good as with CLI.

So I am left with FastCGI then? Should it be OK to run FastCGI without suphp, as I don't want suphp?

The problem is that the technician at my datacenter don't seem to have any qualifications on FastCGI.

I am running a server with shared hosting clients, and I am just about to move all my clients to a new server with the following spesifications:

* Supermicro SYS-6016T-UF
* Dual Intel Xeon Quad-Core E5504 2.00GHz
* 4 x 500GB 7.2kRPM 32MB (using RAID10)
* 12GB DDR3-1333MHz

And it will have CentOS 5.x 64bit, Apache 2.2.14, PHP 5.2.12 and MySQL 5.0.90 (and of course newest DA version).

Can I PM you about a enquiry for setting this new server up with FastCGI, and configure FastCGI it to be optimal for many users on the same server? Maybe it will be to expensive?

I feel uncertain about the security when running CLI, but don't see any other good solutions then FastCGI, but don't have the knowledge to do this myself. Do you think that a server can be secure enough when only using CLI?
 
Last edited:
I see a little bit of confusion, but that's understandable since you have a technician who should do that for you. But if you want to make the good decisions (and that's your role) I suggest you learn some more about it.

A few hints:

- APC (the one I was talking about, of course) is not a firewall. It has absolutely nothing to do with security. APC opcode cacher is an extension for PHP that caches and provides ready "opcode" (that's what PHP creates after parsing a script) to PHP when a script is requested. It is developed by the PHP guys. It requires either mod_php or FastCGI to work, because the PHP handler must be persistent (normal CGI does not have one).

- The problem with mod_php (a.k.a. CLI) is that there is no stable way (experimental ways exist) to execute PHP scripts under the corresponding user, creating vulnerable situations (mainly the possibility to read and/or write each others files)

- suphp and suexec (which are used differently but the result is almost the same) both solve the aforementioned problem, but they need PHP in CGI mode (normal or FastCGI it doesn't matter)

In conclusion, if you want security use either suphp or suexec (therefore PHP in CGI or FastCGI mode).
If you want security with the same performance as mod_php, use FastCGI (the performance loss is caused by process spawning, which is avoided by FastCGI).
If you want even more performance (but make sure it is compatible with all of your customers software) use APC.

Hope I've been clear enough, tell me if I didn't.

EDIT: to answer your request for practical help, I'm not that expensive usually but these days I just don't have time (new job, new home) unless paid *a lot* (I guess money beats stress :D).
 
Last edited:
tillo said:
If you want security with the same performance as mod_php, use FastCGI (the performance loss is caused by process spawning, which is avoided by FastCGI).
Click to expand...

So if I use FastCGI, I would not need to use suphp at all, and still get the better security (better then CLI)?

Thank you for all the valuable information in your post!
 
Nope, I meant: "If you want security use suphp, which requires CGI mode, and if you don't want to lose performance use it with FastCGI and not the normal CGI".

You won't escape from using suphp (or suexec), that's for sure. For any reason you may stick to, that keeps you from using it, there is at least one workaround. :)
 
tillo said:
Nope, I meant: "If you want security use suphp, which requires CGI mode, and if you don't want to lose performance use it with FastCGI and not the normal CGI".

You won't escape from using suphp (or suexec), that's for sure. For any reason you may stick to, that keeps you from using it, there is at least one workaround. :)
Click to expand...

Thank you!
 
You must log in or register to reply here.
Back
Top