Beneath my desk is a web server hosting private copies of published sites and sites under development.
Until recently, it ran Apache/PHP/MySQL on Windows 2000. That machine died, and I decided this was an opportunity to pursue my interest in Linux.
I chose the server edition of Ubuntu for the replacement machine because I had been impressed with the desktop version running on another computer. The server project would be a good way to improve my Linux knowledge.
Installation went well, save for one fault.
My 'new' server is actually a 200MHz AMD-K6 system from the early nineties, sporting 256Mb RAM and a 20Gb hard disk. Although no match for a lot of modern Windows software, I can't bear to ditch a functioning computer when it'll still do a job.
I am pleased to report that it is remarkably slick and snappy in its new role.
The old non-Intel processor was misidentified by Feisty Fawn's installer, so I ended up with a version of the kernel that crashed during boot-up.
That was fixed by re-running the installer from CD, selecting the repair option, then later opting to execute a shell on the hard disk (not the other shell choice, which is to run within the installer environment). From there, I was able to install a usable kernel:
sudo apt-get install linux-386
Next, I configured the machine for remote access over my LAN. The server has no monitor or mouse, and the keyboard is tucked away. I use PuTTY to gain terminal access from Windows systems on my network and ssh from the other Linux box.
After installing the lightweight Xfce desktop, I can also open a remote graphical desktop from my other Ubuntu system:
ssh -Y ppp.qqq.rrr.sss sudo startxfce4
This starts Xfce with root privilges on the server, whose IP address is ppp.qqq.rrr.sss (replace with the actual numbers). Although I am controlling the server, the user interface is presented on the computer I am sitting at. See this link (and also use Google) for more information on using your Linux desktop remotely over an ssh connection.
For me, this is a neater, better-performing and more satisfying option than VNC, marvellous though that program is and one I use daily in other contexts.
Following other routine configurations and customisations, I had my web sites working again, save for a tiny snag.
One site makes heavy use of the GD Graphics Library, GDlib, to enable PHP scripts to manipulate graphics. And one of those manipulations involves rotating images.
I got an error saying the imagerotate() function wasn't available. Investigations revealed that the function is only present in a special version of GD bundled with PHP, not the generic one that can be added as an external library.
The PHP supplied with Ubuntu is compiled without the bundled GDlib. This, apparently, is due to security concerns. If you want GD for PHP, the easy way is with:
apt-get install php5-gd
Only, that's the generic version without imagerotate() and other enhancements peculiar to the one offered by Zend, the company behind PHP.
Having the highest possible level of security does not concern me with a private development server hidden from the outside world. But I do need it to match the capabilities of my hosting company's version.
None of the workarounds I found on the net were satisfactory, so I was left with one choice other than revert to Windows...
Let me say here that this guide is not definitive and I am not promoting myself as the Internet PHP compile doctor.
Far from it. I am a Linux learner but I managed to muddle though. I hope my experience helps you muddle through quicker than I did. If you have any questions, your favourite search engine is a FAR more useful resource than my email address.
Proceed with root privileges. Rather than typing sudo all over the place, open a new copy of the shell as root: sudo bash or sudo -s.
Download the .tar.gz PHP source code from www.php.net/downloads.php. Unzip and un-tar it with:
tar -zxvf name_of_file
This should give you a new directory full of PHP source files. Change into it from the command line. Remember that in bash, pressing [Tab] in a partially complete directory name will fill in the rest automatically if what you have already typed leaves only one possible name.
Before you compile, you have to select configuration options. This is done by running ./configure with a list of command line arguments longer than your leg. The arguments specify the features that will be compiled in.
Bundled GD support is one of the options, and for this '--with-gd' is the required parameter.
Didn't think it would be that easy, did you? Well stop smiling, because it isn't. Not by a long way.
You must specify an army of options to get a fully functional PHP installation. Otherwise, the limited defaults are likely to leave your compiled PHP short of many features you take for granted.
Settle in, this will take a while.
The full range of possible command line arguments can be seen with:
./configure --help | more
or better still:
./configure --help > configopts.txt
nano configopts.txt
This produces an extensive listing that fills many sheets of paper.
Skim it, but then leave it for now. You don't need to understand it all. Refer to the relevant parts later when the related items give trouble.
Luckily, there's a cunning way to avoid taking a PhD in PHP compilation.
Make a web page with PHP's phpinfo() function and put it on a working server. That page will output a lot of information, one item of which is the ./configure parameters used to compile PHP.
Paste them into a text editor. You can study and tinker with them, and copy the latest version to the command line. Keep older versions in case something you delete later turns out to be needed.
You are likely to find that some options don't suit your set-up or requirements, but it's a good starting point.
Now run your initial ./configure command. You will, I promise, perform this many times. Each run will fail with an error message that has to be addressed before the next try. I spent hours in this phase, and it felt like a long dark tunnel.
Sources of errors are mostly:
Lack of development files: many of the modules you want compiled in with PHP might already be present on your machine. However, the executable code is not enough. Compilation requires that certain source files be available. These are usually supplied in a more extensive version of the module than the purely executable stuff you may already have.
The solution is to Google the error message to find the name of the development version of the package, or try to discover its name using:
apt-cache search xxxxx
where xxxxx is a portion of the package name taken from the error message. This should bring up a list of available and likely-looking versions of the packages to install.
If too many packages are returned, try to filter the output with:
apt-cache search xxxxx | grep yyyyy
Here, yyyyy is another fragment of text that you have identified as being related. For example, it might simply be dev.
The naming convention is to add 'dev' or 'devel' or perhaps 'development' to the base name. With the full name found, install the package:
apt-get install xxxxxxxxxxxxxx
You will probably find at the start that your system doesn't have all the up-to-date development tools. Once again, you have to look at the error messages, use a search engine, and install the required stuff. I am sorry I didn't keep a list, but it wasn't hard to work out what was needed and everything is readily available through apt-get. Read Required software in the INSTALL file, which you should look through before you start anyway.
Incorrect paths for options: Look at the parameters you have, and you may find that the purpose of several of them is to say where the development files are located. If you pulled these commands off another server, the paths may not match the ones on your system.
You need to find where the files live and adjust the paths to suit. Sometimes, there is a usually correct default, and the error message might go away if you don't specify a path. Try that first, then if it doesn't work enter the actual location.
Options that don't work whatever you do: I had a few of these. I forget what. My note taking fell apart when so much time had been chewed up that I was panicking over the need to get on with other urgent things.
One error was killed by upgrading from Feisty Fawn to Gutsy Gibbon, released at the very moment when I thought I'd be forced to give up.
In desperation, I deleted or disabled other intractable parameters and so far haven't encountered any adverse consequences. Your mileage may vary, as may mine in a future development project that needs the omitted features.
For the record, this is what phpinfo() reports I ended up with:
./configure '--prefix=/usr' '--enable-bcmath' '--with-curl' '--enable-exif' '--enable-fastcgi' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/lib' '--with-xpm-dir=/usr/X11R6' '--with-gettext' '--with-iconv' '--with-imap=/usr/local/imap-2004g' '--enable-mbstring' '--enable-mbregex' '--with-mcrypt' '--with-mhash' '--enable-magic-quotes' '--with-mysqli' '--with-mysql' '--enable-discard-path' '--with-pear' '--enable-sockets' '--with-ttf' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/include/freetype2/freetype' '--with-zlib' '--with-kerberos' '--with-imap-ssl' '--with-apxs2=/usr/bin/apxs2' '--without-sqlite'
This was the first version that compiled and gave all the features my PHP scripts use. I'd had more than enough by then, so I won't worry about it further until a missing feature forces me to.
Once ./configure finishes a successful run, you can perform the compilation with:
make
This takes a long time, but was much less troublesome getting the configuration to work. Check back occasionally and deal with any errors, usually by examining and changing the configuration parameters.
If you need to recompile, first do a make clean.
I also had segmentation faults at random places, but I think these were due to an overheating CPU. This old PC has always run well and quietly without a CPU fan. The extended and heavy compilation process probably pushed it too hard for a bare heatsink.
It shouldn't take much effort to get compilation to succeed, and once done you can test it with the extensive suite of about 3000 tests is included. Run those to confirm that the compilation was successful:
make test
This is the easy bit:
apache2ctl stop
make install
apache2ctl start
And that should be that. Access your phpinfo() page to make sure it is working and all the modules you need are there. In the case of GDlib, you looking for the following line in the 'gd' section:
GD version bundled (2.0.34 compatible)
The word 'bundled' is the important bit.
I am not much of a drinker, but I confess to downing a large sherry at this point.