How to Build, Install, Secure & Optimize PHP 19
geekmedia writes "Open Network Architecture has an excellent article up entitled "How to Build, Install, Secure & Optimize PHP.""
This discussion has been archived.
No new comments can be posted.
How to Build, Install, Secure & Optimize PHP
Related Links Top of the: day, week, month.
"How to make a million dollars: First, get a million dollars." -- Steve Martin
Re:The right tool for the job (Score:5, Interesting)
php is oft derided for "mixing data & presentation" because in the Learn php in 24 hours style books you get examples like
<?php
if ($something) {
?>
<html> etc
<?php
} else {
?>
<html> otc....
<?php
}
?>
which is really bad style.
if you look through my [modern] code you would see something more like this simplistic example
<?
require_once 'html.class';
requre_once 'database.class';
class page extends html {
function add_links(&$db) {
foreach($db->get_links() as $url=>$txt) {
$this->add_href($url, $txt);
}
}
}
$p = new page();
$db = new database('website');
$p->add_links($db);
echo $p->get();
?>
which would generate a valid html page.
Of course I've got the advantage of building up by database & html class over time but that's what re-usuable code is all about 8)
the thing that stands PHP apart from Perl is that the focus has been on Web development rather than a general purpose language [although recently development has added more command line functionality]. To this end the common things needed for web development are built into the distribution. Database access, IMAP access, treating http:// as a stream, etc.etc.
To non-programmers PHP is the sort of thing that is easy to pick up, I know this from the people I have met that use it. All the examples around have generally been about generating web pages. Perl source code is legendary for it's obscurity. PHP keeps things simple.
It's not a perfect beast. Passing by reference can be awkward, requiring extra non-anonymous variables, and the ugly face of backward comaptibility has meant that keywords & built-ins are inconsistent in name and parameter order.
(
In particular the original array manipulating functions are called stuff like count() whereas if that was introduced today it would be called array_count().
parameter order is a subtle source of confusion
consider
strpos ("abcdef", "d")
give me the position of "d" in "abcdef"
and
explode(" ", "hello world")
split "hello world" using " "
the subject of the function is reversed
not a big deal but it often means a quick trip to the manual to find out which one it is this time.
)
If I was suggesting a programming language to learn programming PHP would not be it, Python or C or Limbo would be my suggestions there.
Re:The right tool for the job (Score:3, Interesting)
Almost all the popular databases are supported (granted they are either dynamically loaded or compiled in). MySQL, Postgres, Sybase, Oracle, ODBC and others.
Honestly, outside of the web applications, I don't see PHP as a strong language. But I do find PHP's speed and simplicity to be a strong point, and the fact that I can tune it and play with it so as to scale well makes me even happier about it. Plus, if well written, it's pretty secure. At least I've never had any problems with it being any more or less insecure than well-written Perl.
mod_php security reduces functionality (Score:4, Interesting)
I get mod_perl to read the config data in from a database when Apache starts up.
Our Apache setup (for multiple machines) is then automated with a few HTML forms.
It also give us the advantage of reducing insecurity with other cgi based programs.
not perfect performance wise but I think the tradeoff is acceptable.
Re:mod_php security reduces functionality (Score:2, Interesting)
suexec doesn't cover your whole ass (Score:2)
Not only is it necessary to tighten up the Web Server's security but your whole system has to be configured with that premise in mind.
CGI here ends up running as $USER:www (you need to have ALL the web users in www so that non-cgi files & directories can be read by the server.)
I will be honest and confess that I've not finished experimenting with the possibilities. I was hoping that by setting ALL files outside of
maybe I'd be better going with OpenBSD's chroot'd & jailed Apache [I'm running on FreeBSD atm.]
anyhow I was also going to see if I could make a bin directory for each user so that they can only execute the files in that directory
Naturally I have no actual non-staff users with a login on the web server so I've got quite a licence to do whatever I feel is necessary, mis-guided or otherwise 8)
I only work there one day a week and they would rather me get other stuff done first.
Re:mod_php security reduces functionality (Score:2)
We do this using Zeus. Each customer gets his/her own virtual server. Each virtual server is configured to run CGI scripts under a specific uid/gid (that of the customer's account). It works nicely and is very easy to setup.
security (Score:5, Insightful)
Re:security (Score:2)
Where I stopped reading... (Score:5, Informative)
From the article:
Three things:
Note that I use, and like, PHP and have no axe to grind against the language or its enthusiasts. But this kind of vague, misinformed fluff doesn't give me a lot of confidence in the rest of the article...
Re:Where I stopped reading... (Score:2)
That particular paragraph just made me laugh.
What a loser.
All that compiling and shuffling files around is markedly different from my experience.
PHP is inevitable, resistance is futile
no-one mention that PHP runs just fine on IIS
PHP is Personal Home Page (Score:2)
Where was the optimization and the warnings? (Score:5, Informative)
I guess what ticks me off most is what is not mentioned. How many times does the PHP list have to explain to people that Apache2 DOES NOT work well with PHP. This is a a topic the php support/users lists rehash constantly.
While some users have been successful in migrating to PHP and Apache2 it is not an easy process by far. One clear issue is that the more 3rd party libraries you include the greater the chances of failure between PHP and Apache2 due to threadsafe issues in 3rd party libraries within PHP. PHP has made clear that this incompatibility is likely to be a long time in the fixing as every library used with PHP needs to be threadsafe. Given that the article asks users to install lots of 3rd party libraries I can't wait to see the list of problems this article creates.