Re: Apache not honoring SUID/GUID or FACL

[Dan <random.danno@xxxxxxxxx>]

Ben,

I read through the instructions you linked to and I can't find any differences between my config and the one the author suggested. Point of fact, that site was one of the ones that I used when researching my own config. 

After taking (yet another) look at the config, I decided to disable Kerberos authentication (which we use for SSO) and run the same tests with mod_php and mod_fastcgi, and the difference is astonishing. Kerberos auth using a fastcgi configuration doesn't seem to scale well and performance gets dramatically worse with more concurrent sessions. 

Conversely, with kerb disabled the average response time is 150 ms, and the response time with mod_fastcgi is 200 ms. These findings concur with your earlier statement that mod_fastcgi should only be 20% slower (in this case 25%, but still...). 

So here's the synopsis:               
                         With Kerb           Without Kerb
Mod_PHP:         1600 ms              160 ms
Mod_FastCGI     4400 ms              210 ms

I believe we're far enough from the original question to justify a different thread, but if you (or anyone else) have any suggestions for remedying this, I'd love to hear them. I've done some googling already and found references to disabling SELinux, but it's already disabled on this system.

Thanks for your help!

Dan


On Fri, Nov 9, 2012 at 9:47 AM, Ben Johnson <ben@xxxxxxxxxxxxxxxx> wrote:
>
>
> On 11/9/2012 9:21 AM, Dan wrote:
>> Ok folks. I've got this working but performance with mod_fastCGI but I'm
>> disappointed with the results compared to mod_php. I know mod_php is
>> supposed to be the fastest option, but fastcgi is on average 60% slower
>> than mod_php, so I'm hoping someone can verify my configuration.
>
> My experience has been that FastCGI is definitely slower, but 60% seems
> to be a considerable variance. The difference I've observed is more like
> 20%, but performance variances are often largely server configuration
> and application specific.
>
> I recommend reading through
>
> http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/
>
> if you haven't already, and ensuring that APC is, in fact, effective.
> Also, my understanding is that using APC in such a configuration is very
> RAM-intensive, as there is a dedicated cache for each user.
>
> In fact, you may be interested in the same author's benchmarking and
> performance follow-up article:
>
> http://www.brandonturner.net/blog/2009/07/fastcgi_php_opcode_cache_benchmarks/
>
> Disclaimer: I'm in no way affiliated with brandonturner.net; I just
> found the articles useful in my own work.
>
> I'm sure that many of us would be curious to hear back from you once
> you've tinkered a bit more.
>
> Good luck!
>
> -Ben
>
>
>
>> I added the following to my main config:
>>
>>     LoadModule fastcgi_module modules/mod_fastcgi.so
>>     FastCgiWrapper On
>>     FastCgiIpcDir /var/run/fastcgi
>>     FastCgiConfig -idle-timeout 20 -maxClassProcesses 1
>>
>>
>> I also added the following to my vhost block:
>>
>>     SuexecUserGroup wp-itghome www
>>     DirectoryIndex index.php
>>     AddHandler php5-fastcgi .php
>>     Action php5-fastcgi /cgi-itghome-dev/php-fcgi
>>     ScriptAlias /cgi-itghome-dev "/var/www/cgi-itghome-dev/"
>>     FastCgiServer /var/www/cgi-itghome-dev/php-fcgi -socket
>>     /var/run/fastcgi/fastcgi-itghome-dev.socket -user wp-itghome -group
>>     www -idle-timeout 310 -flush
>>       <Directory "/var/www/cgi-itghome-dev">
>>         AllowOverride none
>>         Options None
>>         Order allow,deny
>>         Allow from all
>>       </Directory>
>>       <Location /cgi-itghome-dev>
>>         Order Deny,Allow
>>         Deny from All
>>         Allow from env=REDIRECT_STATUS
>>       </Location>
>>
>>
>> The socket file specified above is owned by apache, and the contents of
>> /var/www/cgi-itghome-dev are all owned by the wp-itghome-dev user and
>> "www" group. Site content loads properly and APC reports it's using the
>> same cache file for every request so it seems to be working.
>>
>> The server in question has a single CPU (3 Ghz) and 2 GB of RAM. I used
>> apache bench to performance-test the VM, having it request phpinfo.php
>> from 100-1000 times, with the test scaling 100 requests at a time and
>> with 100 of those requests concurrent. At peak, this site would
>> reasonably have to accommodate 100 concurrent users, so I figured this
>> was appropriate.
>>
>> The test results with mod_php show an average response time of 1600 ms,
>> and with mod_fastcgi it was almost 4400 ms. Watching top during tests
>> shows a lot of httpd processes waiting for I/O, I assume because of
>> contention for the socket file. To mitigate that I also tried setting
>> fastcgi to listen on a tcp port instead of using a socket file and
>> performance was worse, on average 6000 ms.
>>
>> Can someone tell me whether this performance differential is to be expected?
>>
>> Thanks,
>>
>> Dan
>>
>>
>>
>> On Wed, Nov 7, 2012 at 9:19 AM, Dan <random.danno@xxxxxxxxx
>> <mailto:random.danno@xxxxxxxxx>> wrote:
>>
>>     Thanks Noel.
>>
>>     We can use VSFTPD for developer access post-install via WordPress,
>>     and could in theory use umask in the apache startup script to set
>>     apache's umask (even though as stated in my OP that it wasn't
>>     working), but I'd rather not set up an FTP daemon and stick with
>>     chrooted SFTP access instead.
>>
>>     I have gotten PHP as a (standard) CGI with the "SuexecUserGroup"
>>     directive working to set the correct ownership on uploaded plugins,
>>     but we use APC (Alternate PHP Cache) as our opcode cache and this
>>     doesn't work with standard PHP-CGI deployments. ApacheBench testing
>>     shows an increase of approximately 1 second response time per
>>     request when APC isn't used, so that's a deal-breaker for me. SuPHP
>>     appears to have the same limitation, so it's not an option either.
>>
>>     At this time I'm evaluating mod_fastcgi, which supposedly works with
>>     SuExec and APC. If anyone has an input or past-difficulties with
>>     this proposed deployment, I'd appreciate hearing from you.
>>
>>     Dan
>>
>>
>>
>>     On Fri, Nov 2, 2012 at 10:56 PM, Noel Butler <noel.butler@xxxxxxxxxx
>>     <mailto:noel.butler@xxxxxxxxxx>> wrote:
>>
>>         __
>>         On Fri, 2012-11-02 at 14:31 -0500, Dan wrote:
>>>         Ben,
>>>
>>>         Yes you're right, we are using mod_php, but only because no other
>>>         alternative was required up to this point.
>>>
>>>         This server hosts many vhosts, and I've read that SuEXEC isn't
>>>         appropriate for multi-site installations of apache.
>>>
>>
>>         suexec is perfect for any number of hosts, but I assume you mean
>>         the phpsuexec stuff, which you are in fact correct, it, along
>>         with suphp,  introduce serious performance hits if you have more
>>         than a few hundred vhosts, and given most hosts run a couple of
>>         thousands vhosts per typical, say DL380 type machine, you will
>>         notice it, and your customers will notice it - especially if the
>>         machine has many busy sites.
>>
>>         thats why most large sites use php admin value flags for locking
>>         them down, but some php plugins that are  poorly written dont
>>         always honour those restrictions, which is where suhosin comes
>>         in to try fill the gap ( although I think its mod_php's job to
>>         be more anal about what it allows) in trying to catch those
>>         uselessly written extensions for doing stuff you dont want it
>>         to, even in this configuration, it wont be 100% secure, but it
>>         certainly is not 100% secure using other methods either, suphp
>>         for instance although not too bad in past couple years, has had
>>         a poor history in the past.
>>
>>
>>
>>>         I'm looking into SuPHP right now, but their site _seems_ to be down.
>>>
>>
>>         :)
>>
>>
>>         setfacl chmod etc are no good, they only set existing, you need
>>         to work with umasks, it is not possible to have apache set umask
>>         in virtualhosts, a dirty way would be to set the umask in the
>>         init script for httpd, but I would not recommend that since
>>         allowing httpd to group write access, will introduce major
>>         security issues for all vhosts. You are better off circumventing
>>         this via ftp, what ftpd are you using?
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>