This mail is an automated notification from the task tracker
of the project: Administration.
/**************************************************************************/
[task #120] Latest Modifications:
Changes by:
Vincent Caron <[EMAIL PROTECTED]>
'Date:
Fri 05/14/04 at 18:19 (Europe/Paris)
What | Removed | Added
---------------------------------------------------------------------------
Should be Finished on | Fri 04/02/04 at 00:00 | Wed 06/02/04 at 00:00
------------------ Additional Follow-up Comments ----------------------------
Some ressources on load limiting :
* Apache core RLimitCPU, RLimitMEM, RLimitNPROC directives are only effective for
external CGIs, not for embedded scripts like mod_php and mod_perl.
* That's why PHP has its own limits in php.ini :
http://cvs.php.net/co.php/php-src/php.ini-dist
max_execution_time = 30 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request
data
memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
Since the maximum number of PHP interpreter instances is bound by the maximum size
of Apache process pool, there is an indirect way to limit load (and mem usage).
* Apache could be globally ressource controled with ulimit, since it's not alone on
the machine it could help. I've never tested this possibility.
/**************************************************************************/
[task #120] Full Item Snapshot:
URL: <http://gna.org/task/?func=detailitem&item_id=120>
Project: Administration
Submitted by: Vincent Caron
On: Mon 02/02/04 at 18:49
Should Start On: Mon 02/02/04 at 00:00
Should be Finished on: Wed 06/02/04 at 00:00
Category: Services Functionalities
Priority: 3 - Low
Resolution: None
Assigned to: zerodeux
Percent Complete: 0%
Status: Open
Effort: 0.00
Summary: PHP support for homepages
Original Submission: Evaluate load and security issues for PHP support on
home.gna.org.
Follow-up Comments
------------------
-------------------------------------------------------
Date: Fri 05/14/04 at 18:19 By: zerodeux
Some ressources on load limiting :
* Apache core RLimitCPU, RLimitMEM, RLimitNPROC directives are only effective for
external CGIs, not for embedded scripts like mod_php and mod_perl.
* That's why PHP has its own limits in php.ini :
http://cvs.php.net/co.php/php-src/php.ini-dist
max_execution_time = 30 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request
data
memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
Since the maximum number of PHP interpreter instances is bound by the maximum size
of Apache process pool, there is an indirect way to limit load (and mem usage).
* Apache could be globally ressource controled with ulimit, since it's not alone on
the machine it could help. I've never tested this possibility.
-------------------------------------------------------
Date: Fri 05/14/04 at 10:23 By: zerodeux
You're more concerned about load issues, I'm more about security ones, we should
succeed to make a wise decision :)
I'm currently working at an ISP where all issues relate to security and poorly written
Perl and PHP scripts. However I must confess I never had to deal with ressource issues
(wether by user mistake or mal-intentionned DoS).
Not having some scripting support on homepage.gna.org would be a shame IMHO. When you
reach 10 pages to maintain, a little PHP glue makes your life much easier. Maybe
simply enbaling SSI could help, but it's a bit primitive. I would only avoid
installing PHP if there were *dread serious* issues against it.
Proposal: have a severly limited PHP support with only core libs, and NO (ever, ever)
database, GD, and other funky things which regularly jeopardize our first concerns.
I'm searching now for some info on PHP & CPU load management.
-------------------------------------------------------
Date: Fri 05/14/04 at 09:37 By: zerodeux
[notes from Mathieu, support ticket #229]
Hello,
I'd like to stress the fact that the main reason why we do not provide PHP is not
security but resources. It is not really hard to jail PHP in a pretty secure way.
But I do not think we should take the risk to waste CPU time and RAM for PHP. There
are free provider that proposes PHP and people still have the option to run their own
webserver: in this case, we would not fullfill no one else do.
Considering that a company like Free took 3 years to get a clean setup that avoid
having PHP completely sucking a bunch of server resources, I would definitely not be
happy if PHP was set up on Gna! machine will Gna! is not 5 month old and his number of
users increasing at high speed (proportionaly, because Gna! is young -- every hundred
user makes a difference).
So I would definitely not say "we are planning to support PHP soon". It would not be
wise. Also, cvs and home are currently on the same machine : I would not think wise
either to let users use PHP on the machine hosting cvs. It is not even a matter of
having PHP secure: we already can do that. But as secure an installation can be, it
can still be cracked. And it can more easily be cracked with PHP available on the same
box.
-------------------------------------------------------
Date: Mon 02/02/04 at 19:00 By: yeupou
I think that we'll be able to evaluate correctly the load issue only in several month,
once the servers will be running in a state we could consider as usual, with services
really used.
For detailed info, follow this link:
<http://gna.org/task/?func=detailitem&item_id=120>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Project mailing list
[EMAIL PROTECTED]
http://mail.gna.org:8080/listinfo/project
