Converting Hardcoded Pathnames

The next step on my adventure with Pericles is to convert all of the hard-coded pathnames from F:\Web to /var/www (as well as any other hardcoded paths I find.) I've been pretty careful not to use hard-coded names in unnecessary places, putting most of them in simple configuration include files and so forth, because I knew from the beginning that this day would come.

I typed grep and it turns out that I have a convenient version of Turbo grep (comes with any Insprise/Borland product of the last decade), but GNU grep should work just as well. The syntax for turbo grep that I'm using is:

grep -di "f:" *.ph*>hardcoded

I'm using *.ph* because I am searching all *.php and *.ph files. I typically use *.ph for include files instead of *.inc, the -di means search subdirectories and ignore case, and I keep my data and web files on the F: drive. I'm redirecting the output to a file named hardcoded so that I can use it as a checklist. I'll do the same thing again but, like this:

grep -di "c:" *.ph*>>hardcoded

To get all references to anything on the C: drive (I know I refer to an executable font conversion tool from one place, for example.) and the double angle brackets mean to append the result to my previous file instead of overwriting.

Now that I have my checklist, here's the plan:

I want to convert all the code while still on the Windows box to support Linux based on a single configuration change. I will make an include file with one function in it that takes any path given as a parameter and if it starts with /var/www, to convert it back to F:/Web. This will allow Linux to be the native language with a "patch" for Windows support. This should have been part of my plan from day 1 (two years ago), but it didn't occur to me. The idea is that I can replace this function with an "identity" function such as: function linpath($a) { return $a; } in order to use raw Linux paths instead of Windows.

I will also do similar adaptations on a situational basis as I run into any F: or C: references that can't be solved with the above include file.

I anticipate some difficulties with file permissions since Apache on Linux is more secure than Apache on windows. My main resolution to this will be to consolidate the affected items that need to be accessed into consistent areas that the Apache process has access to read. If I have any chroot issues, I can overcome them with the use of mount --bind as explained in my article on setting up FTP.

This path translation will probably be the most tedious task in the Pericles project. I'll report back when I have finished.

4:18 P.M. - Upon more deliberate consideration, I have determined to abandon this undertaking and instead to change the paths manually. Why? There only seems to be about one per website, with an odd exception here or there. The trouble crops up when deciding exactly how to include the file with the path mapping function without using a path for itself. Furthermore, even if I install it into the default includes path, it seems silly to include a file only to help correctly include another file. May as well just change them when the time comes.

Configuring PHP

I'm now trying to get PHP working on Pericles.

The first thing I should point out, is that I started by doing a vanilla LAMP install from the Ubuntu Server disc. This means I already had Apache2 and PHP5 installed "out of the package", but they aren't configured adequately for my needs.

I dropped a simple file in /var/www that would echo the output of phpinfo() so that I could compare it with my existing WAMP server's setup.

If you don't have Apache working yet...

You can use php5-cli (install this with Synaptic) as an alternative to view the phpinfo() at a shell prompt:

php
<?php echo phpinfo(); ?>
(Press CTRL+D)

A plain text rendering of phpinfo() will appear, which you can scroll back to view in your console buffer.

Here are the major differences that I need to adjust:

magic_quotes_gpc needs to be turned off. It's a stupid thing, blast them for making it default to on. post_max_size and upload_max_filesize need to be increased, because I have people uploading large megapixel images through http forms. 2M doesn't quite cut it any more these days. The gd module needs to be enabled. The zip module, or a substitute for it, needs to be enabled (I use this to automatically unpack files uploaded to a designated FTP account for daily processing.) I notice a few other differences, but I think they're minor. If I run into problems with them later, I'll follow up with details on how to fix them.

I discovered that by installing the php5-gd package with Synaptic, and then restarting Apache I gained gd2 support. That was easy. To restart Apache:

sudo apache2 -k graceful

This does a graceful restart (it won't force any connections to close that are still opened). I realize this is a new box, so there won't be any connections hanging open anyway, but it is good to get into this habit early on.

I reloaded the phpinfo() test file, and there is now a section for gd which says version: 2.0 or higher, and everything looks enabled (freetype, t1lib, gif, jpg, png, wbmp)

I think the zip module I was using was part of pecl. I know pecl is similar to pear, and now that I think about it, I know I'll need pear support too, so if it hasn't already been done, php5-cli and php-pear should now be installed with Synaptic. The reason we need to install php5-cli is because pear is a command-line utility, and requires the command-line version of PHP in order to run. Don't worry: php5-cli and libapache2-mod-php5 peacefully coexist. I opened a shell, typed pear, and there it is!

On a whim, I typed pecl, and it also runs. It looks like pear and pecl come as a pair (no pun intended).

Back to Synaptic, we need to install php5-dev because we will need a tool called phpize in order to complete the next step. php5-dev has several dependencies that it will automatically install.

Now, the magic command:

sudo pecl install zip

When its finished, it will say: You should add "extension=zip.so" to php.ini

cd /etc/php5/apache2
sudo editor php.ini

Do what it says. Add the line extension=zip.so at the very end of the file, because that's where the automatically added extensions (mysql, mysqli, gd) ended up. You may want to also add the same line into the /etc/php5/cli/php.ini so that you have zip support when you use php for shell scripting.

Save your changes and:

sudo apache2 -k graceful

If you look at the phpinfo() output again, you'll now see the zip section near the bottom. This is
really easy.

While we're editing these two ini files, lets search for and change the following lines to these new values:

memory_limit = 16M
post_max_size = 16M
magic_quotes_gpc = Off
upload_max_filesize = 10M

Remember to set these for both /etc/php5/apache2/php.ini and /etc/php5/cli/php.ini

Another tool I sometimes use (if I need to programatically submit a post):

sudo pear install HTTP_Request

Well, I think that's everything I use. Restart apache2 one last time and see if it all works.