Re: have anyone seen a working fastcgi/php isntallation..?

We use php/mod_fastcgi extensively here - but, with two caveats:

1.  We use "static" configurations, nothing dynamic, AND,
2.  We run Apache 1.3

In these cases, it's worked great for us with no real problems.  The speed 
difference between mod_php and mod_fastcgi seems pretty minimal (we couldn't 
really measure anything meaningful) and we've found it a lot easier to hangle, 
both in terms of managing security as well as reducing memory footprint.

At one point, we had set up dynamic, and it worked pretty well, but that was a 
couple of versions back (mod_fastcgi) so perhaps something has changed/broken 
since then.

FastCGI development is a little bit (well, OK, a lot) stalled right now.  I know 
there's been back-and-forth rumoring that's it's going back into Apache, but I 
haven't heard anything specific.  It's in dire need of some love and attention 
from a real programming expert to whittle off the existing bugs and clean it up 
for true Apache 2.1 support.

Cheers,

David.

-----

On Tue, 21 Mar 2006, Michael Baierl wrote:

> Hey RupS,
>
> I agree with you - you can't track down exploitable scripts. But I sepnd a 
> lot of time setting up FastCGI/PHP and it just did not work - and wit the 
> right mod_php-setup you can also create a very secure setup that is much 
> easier to maintain - at least for me.
>
> If I could get FastCGI/PHP up and running I would run it that way, but 
> nevertheless I would apply the security settings I've writtend down below.
>
> So - if someone provides a solution I will try it again...
>
> Thx,
> Mike
>
> RupS wrote:
>> But you're forgetting one pretty important thing: exploitable scripts.
>> THE main problem we had is tracking down the script that has been used for 
>> an exploit.
>> If there's a "./ircd.cgi" running somewhere as www-data, there is no way 
>> you can track down where it came from. The same with spamruns because of 
>> badly developed mailforms.
>> We have FastCGI running and are pretty satisfied as it is "the best there 
>> is".
>> 
>> We have PHP4 running on FastCGI under FreeBSD. We had a lot of error 500's, 
>> but with a errorhandler written in PHP we could somehow avoid the display 
>> of the error.
>> 
>> One problem we keep having is that some requests take over 30 seconds to 
>> complete. It looks like the FastCGI process is hanging.. We did receive 
>> some complaints about this, but since there is no better solution than the 
>> setup we have right now we'll stick with it. I'm curious if somebody else 
>> experiences the same problem :)
>> We cannot try Linux since the NFS & quota support aren't half as good as 
>> under FreeBSD...
>> 
>> All together we got it running pretty well for a couple of thousand 
>> websites...
>> 
>> 
>> ----
>> Regards,
>> Ruben van der Zwan
>> 
>> 
>> Michael Baierl wrote:
>>> Hey there!
>>> 
>>> Yeah, I had the same problem with PHP/FastCGI and I was not able to
>>> resolve it 'til now. So I reverted back to mod_php (because suphp is
>>> just tooo slow) and set it up in a bit more secure way:
>>> -) use safe_mode On
>>> -) use open_basedir for every vhost
>>> -) set upload_tmp_dir to a separate directory for each vhost
>>> -) set disable_functions to 
>>> passthru,proc_close,proc_get_status,proc_nice,proc_open,
>>>     proc_terminate,shell_exec,apache_note,apache_setenv,closelog,
>>>     debugger_off,debugger_on,define_syslog_variables,openlog,
>>>     popen,pclose,syslog,wget,curl,puf
>>> -) disable PHP by default and enable it for every vhost that needs it
>>> 
>>> With that approach all PHP scripts are executed as www-data, but the
>>> dangerous stuff is disabled and PHP can't break out of the directories
>>> defined in open_basedir. Theoretically. Practically it works perfect and
>>> I don't think someone can harm the system very easily.
>>> 
>>> Best regards,
>>> 
>>> Mike
>>> 
>>> Divák Ádám wrote:
>>>> hello guys,
>>>>
>>>>  i still have the problem of setting up a secure&fast webspace - it
>>>>  seems to be much more difficult than i thought.
>>>>  so what i have: a debian system (maybe the only constant thing in
>>>>  this setup..), apache2 (tried with
>>>>  2.0.54-5 and 2.0.55-4, both custom-built from the original deb
>>>>  sources to change the suexec docroot), php4 (4.3.10-16 from the
>>>>  stable release and 4.4.2 from testing), and fastcgi (2.4.2 and i
>>>>  tried the latest snap as well but i couldn't see any difference).
>>>>  what i'd like to have: a separate user for each virtual host, php
>>>>  under fastcgi&suexec, php using the owners uid/gid.
>>>>  and the problems: i was playing with the configurations a lot (and
>>>>  also tried fcgid but it didn't help much, it produced different
>>>>  errors and noone had any idea about them), i've reinstalled
>>>>  everything in connection with http several times, and so on. i've
>>>>  also tried using the php interpreter straight from /usr/bin/php4-cgi
>>>>  or copying
>>>>  everything to the user's cgi-bin dir, but that wasn't the solution
>>>>  either. what i
>>>>  could achieve is that i have a working config on my home computer and
>>>>  i have the same config on the server - where it produces a variety of
>>>>  errors... (well, at the moment this sentence is not true - the config
>>>>  WAS working on my home comp until i f*cked it up..).
>>>>  /cgi-bin/php is the shell script you can see everywhere,
>>>>  /usr/bin/php4-cgi is of course the normal php installation and
>>>>  /cgi-bin/php4 is the same file copied to the cgi-dir.
>>>>  so, if the config in my virtual host section points to the
>>>>  shell script, and i load my testpage ( phpinfo(); in fact), than
>>>>  i get the shell script printed out in the browser - wow, great.. so i
>>>>  thought to point directly to the php4 file in my vhost config, and it
>>>>  gives this error:
>>>> Warning: Unexpected character in input: '' (ASCII=15) state=1 in 
>>>> /data/files/near.hu/public/cgi-bin/php4 on line 3023
>>>> Parse error: parse error, unexpected '*' in 
>>>> /data/files/near.hu/public/cgi-bin/php4 on line 3023
>>>> (don't forget, this if a simple phpinfo page). the line number wasn't
>>>> always the same, but now it seems to be constant.
>>>> well, i have spent lots of hours playing with all these things - now
>>>> i'm begging you to give me at least a hint or any kind of help, 'cause
>>>> i just don't have any more ideas. i can offer a beer for any good
>>>> solution ( i can't guarantee it'll be served cold..)
>>>> thank you very much in advance
>>>> adam
>>>> 
>>>> /data/files/near.hu/public/cgi-bin/php:
>>>> #!/bin/sh
>>>> PHPRC="/etc/php4/near"
>>>> export PHPRC
>>>> PHP_FCGI_CHILDREN=4
>>>> export PHP_FCGI_CHILDREN
>>>> PHP_FCGI_MAX_REQUESTS=5000
>>>> export PHP_FCGI_MAX_REQUESTS
>>>> exec /usr/bin/php4-cgi
>>>> 
>>>> Vhost:
>>>> ScriptAlias /cgi-bin/ /data/files/near.hu/public/cgi-bin/
>>>> AddType application/x-httpd-fastphp .php
>>>> Action application/x-httpd-fastphp /cgi-bin/php4
>>>> SuexecUserGroup user group
>>>> <Directory "/data/files/near.hu/public/cgi-bin">
>>>>         AllowOverride None
>>>>         Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
>>>>         Order allow,deny
>>>>         Allow from all
>>>> </Directory>
>>>> 
>>>> fastcgi.conf:
>>>> <IfModule mod_fastcgi.c>
>>>>   AddHandler fastcgi-script .fcgi
>>>>   FastCgiWrapper /usr/lib/apache2/suexec2
>>>>   FastCgiIpcDir /var/lib/apache2/fastcgi
>>>>   FastCgiConfig -singleThreshold 100 -killInterval 300 -autoUpdate 
>>>> -idle-timeout 240 -pass-header Authorization
>>>> </IfModule>
>>>> <Location /cgi-bin/>
>>>>   Options ExecCGI
>>>>   SetHandler fastcgi-script
>>>>  </Location>
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------
>>>> 
>>>> ___________________________________
>>>> fastcgi-developers mailing list
>>>> http://fastcgi.com/fastcgi-developers/
>>> 
>>> ------------------------------------------------------------------------
>>> 
>>> ___________________________________
>>> fastcgi-developers mailing list
>>> http://fastcgi.com/fastcgi-developers/
>>> 
>> 
>
>

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/