Question

Being a Windows developer I’m currently working on my own project using LAMP. I understand what I need to know of PHP and MySQL, but Linux looks huge and it’s not clear where to start and what is enough given my goals. And my goals are to grasp general concepts, being able to deploy the project to a hosting provider and to be able to monitor the site’s performance in order to spot problems, load issues, etc.

I know, the best solution is to get a Linux administrator to do that, but before I can do that I need to do it myself.

Answer 1

80% of your problems will be permissions. Windows does them differently; if you login as root (or with root-like privs) you can bypass permissions. Apache can’t and won’t.

• Learn how to properly set ownership of files and directories. Any Unix book will cover this: be sure to actually understand it — it’s not Windows security spelled differently — it’s a different model for security.

Of the remaining problems, 80% will be PATH issues. PHP doesn’t have as big a PATH issue as Java and Python, but they all use a PATH setting to find components and libraries. You’ll get those wrong regularly. Windows has a PATH, but it also has a registry, making things either super easy or super secret. Unix keeps no secrets.

• Learn what environment variables PHP and MySQL use. Be sure you know where and how they get set. Apache runs in it’s own peculiar environment, and it has commands to provide runtime environment settings via mod_php. Write short echo $PATH shell scripts to reveal what’s going on.

Of the remaining problems, 80% will be database related. After sorting out database permissions, you’ll still have to get connected, and the ‘named pipe’ vs. ‘localhost’ stuff will be wrong in obscure, confusing ways. MySQL is very forgiving, but you’ll make some mistakes here.

• Try each alternative connection, know how they work. Don’t pick one because it’s Windows-like, or ‘simpler’. Actually exercise each one. How you pass usernames and passwords from web app to database server is important, also. Apache runs as ‘nobody’ — and you don’t want to give them default access to anything. Your app should make an intentional connection to the database without using defaults.

Of the remaining problems, 80% will be Apache configs. Apache is really simple, but has a million options. There’s four ways to do everything, and you’ll always try two that don’t work at all, and settle for the third which will be icky. The fourth, which is much simpler, will never occur to you.

• Read a LOT about Apache configuration. The httpd.apache.org site has lots of information. Strive for simplicity. Copy existing examples and use them. Don’t make up requirements or desired implementations based on IIS experience or Windows desktop experience. Copy something that works.

Of the remaining problems, 80% will be application use of the file system. If you try to open, read or write local files, you’ll find that (a) permissions aren’t correct on the directory you’re trying to use [see above] and (b) the Unix file paths are different. Not a lot different, but enough different that something will break in an obscure way.

• Every programming book in Unix/Linux book covers this. It’s not a lot different from Windows, just enough different to trip you up the first time. Write ‘hello world’-like PHP pages to spike the simplest possible version of uploads or downloads just to be sure you have all the pieces and parts in place. Then fix your full app to do it correctly.

Of the remaining problems, 80% will be subprocess creation. Windows does this differently. One of the most important things in Unix is to remember that your subprocess is your child and you must actually wait for it to finish so the OS can clean up. If you think of a subprocess as a parallel ‘fire-and-forget’ thing, you’ll have zombie processes and be forced to do periodic reboots.

• Write very simple PHP pages to spike subprocess management. The golden rule is to manage your children and clean up after them. Then fix your full app to do it correctly.

The remaining problems will be trivial application logic, but because of the platform differences, you’ll blame Unix before you track down the bug in the PHP application.

• Get your unit tests and your logging squared away so you can debug effectively.