Slashdot Mirror

← Back to Stories (view on slashdot.org)

How to Build, Install, Secure & Optimize PHP

Posted by Hemos on from the getting-it-all-installed dept.

geekmedia writes "Open Network Architecture has an excellent article up entitled "How to Build, Install, Secure & Optimize PHP.""

19 comments

  1. The right tool for the job by Anonymous+Coward++1 · · Score: 0, Offtopic

    I'll admit, I mostly use perl. For what sort of jobs is php the best tool? Comparisons of php/mod-perl?

    --
    Karma: Bad (mostly affected by being such an asshole)
    1. Re:The right tool for the job by DrSkwid · · Score: 5, Interesting

      I've been doing PHP development for nigh 6 years I think [since just after v4 was released]

      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.

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    2. Re:The right tool for the job by ooglek · · Score: 3, Interesting

      I think PHP is great, better than perl, for web-based programming. Perl is nice and powerful and all, but PHP was written AFAIK for web applications. It supports good, Perl-based RE string parsing, an file open function which supports URLs, and best of all, many of the functions that deal with HTML, databases and the web specifically are built-in. Such as "htmlentities()" which changes a string to an HTML entities (& -> &).

      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.

      --
      TossableDigits.com: Temporary Phone Numb
  2. mod_php security reduces functionality by DrSkwid · · Score: 3, Interesting

    I prefer to use PHP in cgi mode and use SUXEC in Apache for virtual hosting.

    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.

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    1. Re:mod_php security reduces functionality by vano2001 · · Score: 2, Interesting

      I still have to find *how* does one get secure user accessible (r/w/x) cgi-bin's per virtual host. Everybody seems to do it without any problems but it looks to me as if you simply cannot limit CGI acccess (r/w/x) to be only inside the user dir. The only methods I have tought are using XFS fs's ACL and security patches such as grsecurity and others...but even these are a pain. Having suexec and a user accessible cgi-bin won't help much when the user executes a binary doing "cat /etc/passwd".

    2. Re:mod_php security reduces functionality by Electrum · · Score: 1

      I still have to find *how* does one get secure user accessible (r/w/x) cgi-bin's per virtual host.

      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.

  3. security by Hard_Code · · Score: 4, Insightful

    PHP (or anything for that matter) in non-suexec/CGI mode will not be secure for multiple users until the Apache perchild MPM actually works and is officially supported by PHP. This sandboxing of users has long been necessary.

    --

    It's 10 PM. Do you know if you're un-American?
    1. Re:security by illusion_2K · · Score: 1

      As someone who's considering deploying PHP in a multiuser environment and holding off for security concerns, I'm curious to know when you think this will happen.

  4. Where I stopped reading... by vbweenie · · Score: 5, Informative

    From the article:

    It seems that PHP will certainly replace other language ( sic) like Perl or CGI for web services in the future. This is due to its simplicity of use and many developers known (sic) about this and has (sic)already developed software that run with PHP on a web server. When you need to add some popular web service to your web server, you will inevitably find that PHP is required and that you need to install it with Apache.

    Three things:

    1. Didn't anyone edit this?
    2. Does the author know what "web services" are? It doesn't sound it...
    3. No, I don't think PHP will "certainly" replace Perl or CGI for web applications; AxKit is one good reason why not, and Perl::Mason is another. And CGI isn't a language.

    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...

    --
    Experience is a hard school, but fools will learn no other.
    1. Re:Where I stopped reading... by DrSkwid · · Score: 1

      I managed to actually skip reading the words and skimmed over the content to see what general principles were being introduced.

      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

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  5. Where was the optimization and the warnings? by Ryquir · · Score: 5, Informative

    Read through the article and quite frankly this was a sad attempt which should never have gotten beyound the editor stage. First off, since when did IMAP-DEVEL become a required library? Since when did half those libraries become required?

    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.

  6. Re:the acronym itself by Anonymous Coward · · Score: 0

    Shows what you know. PHP is an initialism. Acronyms are pronounced as regular words; examples: NATO, RADAR, SCUBA. Please borrow a clue before trolling.

  7. PHP is Personal Home Page by DrSkwid · · Score: 1

    which eventually became too cutesy.

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    1. Re:PHP is Personal Home Page by Anonymous Coward · · Score: 0

      In other words, managers started wondering about it's robusticity.

  8. suexec doesn't cover your whole ass by DrSkwid · · Score: 1

    you are right, of course.

    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 /www to be chmod nn0 the built in permission testing will take care of that. Hopefully there are no pitfalls in that direction.

    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.

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter