This mail is an automated notification from the task tracker
of the project: Gna! Administration.
/**************************************************************************/
[task #120] Latest Modifications:
Changes by:
Vincent Caron <[EMAIL PROTECTED]>
'Date:
Wed 09/22/04 at 10:23 (Europe/Paris)
What | Removed | Added
---------------------------------------------------------------------------
Resolution | Later | Cancelled
Status | Open | Closed
------------------ Additional Follow-up Comments ----------------------------
I agree with the note on static/dynamic content. However, for most people it's
easier to use something wich does not require a 'make pass', and above all PHP
is extremely popular and simple. Sometimes (actually: often!) it's just more
efficient and friendly to let people use the 'wrong tool', provided it's not
utterly wrong.
I personnally use 100 lines of PHP on my site, and even though it looks static,
it's dynamic (play with the buttons on top right corner, http://zerodeux.net).
It's very easy and handy to maintain.
I currently 'manage' some PHP hosting servers for a living, and can see some
pro and cons. We had some attacks, but they were begnin (bouncers installed as
'httpd' user) and on some very badly configured hosts. My company hosts 1500+
PHP sites on a crappy setup (ie. lots of unpatched thingies) and never had
troubles with it, because it uses a very simple reciepe: chroot + turn off all
PHP 'goodies' (which are 'badies'). Oh wait, they have libgd (yuk) and the CPUs
are never hogged (ok, sort of a miracle).
Something like
http://www.modsecurity.org/documentation/apache-internal-chroot.html can do the
trick. Even if PHP is exploitable, it only allows the attacker to deface some
sites, and they are checkouts from CVS anayway.
There is a good chance that the CPU load rises, because Apache 1.x can't really
manage this problem of load control. And I agree that it would be safe to have
PHP only if we had another machine, because Lisa should serve CVS first and
best.
/**************************************************************************/
[task #120] Full Item Snapshot:
URL: <http://gna.org/task/?func=detailitem&item_id=120>
Project: Gna! 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: Mon 06/02/08 at 00:00
Category: Services Functionalities
Priority: 1 - Later
Resolution: Cancelled
Privacy: Public
Assigned to: zerodeux
Percent Complete: 0%
Status: Closed
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: Wed 09/22/04 at 10:23 By: Vincent Caron <zerodeux>
I agree with the note on static/dynamic content. However, for most people it's
easier to use something wich does not require a 'make pass', and above all PHP
is extremely popular and simple. Sometimes (actually: often!) it's just more
efficient and friendly to let people use the 'wrong tool', provided it's not
utterly wrong.
I personnally use 100 lines of PHP on my site, and even though it looks static,
it's dynamic (play with the buttons on top right corner, http://zerodeux.net).
It's very easy and handy to maintain.
I currently 'manage' some PHP hosting servers for a living, and can see some
pro and cons. We had some attacks, but they were begnin (bouncers installed as
'httpd' user) and on some very badly configured hosts. My company hosts 1500+
PHP sites on a crappy setup (ie. lots of unpatched thingies) and never had
troubles with it, because it uses a very simple reciepe: chroot + turn off all
PHP 'goodies' (which are 'badies'). Oh wait, they have libgd (yuk) and the CPUs
are never hogged (ok, sort of a miracle).
Something like
http://www.modsecurity.org/documentation/apache-internal-chroot.html can do the
trick. Even if PHP is exploitable, it only allows the attacker to deface some
sites, and they are checkouts from CVS anayway.
There is a good chance that the CPU load rises, because Apache 1.x can't really
manage this problem of load control. And I agree that it would be safe to have
PHP only if we had another machine, because Lisa should serve CVS first and
best.
-------------------------------------------------------
Date: Fri 05/14/04 at 19:47 By: Mathieu Roy <yeupou>
« homepage.gna.org would be a shame IMHO. When you reach 10 pages to maintain,
a little PHP glue »
I tend to disagree with that opinion. PHP makes sense only if you need to have
dynamic content. If you have static content, there are better ways to generate
it, and generate it once only.
I really think that people that want PHP should host the website somewhere
else. Whatever way it is handled, PHP will still takes much more than apache +
static files (and poses other security troubles) and I think that website
hosting should be the lesser important priority for gna: it is easy to get a
www host already, unlike development tools.
I really think that a CGI www host should only happen on a 4th server. We are
not exactly aware of the cost of SVN and Arch (which one we do not currently
plainly support - or support) and I think we should not make fast move,
especially to fullfil non-important needs.
(I still can CGI an non-important need because : this is not hard to find such
host ; in most case PHP is used to serve static page, with is just costly in
resources)
-------------------------------------------------------
Date: Fri 05/14/04 at 18:19 By: Vincent Caron <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: Vincent Caron <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: Vincent Caron <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: Mathieu Roy <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/
