Hack, hack, hack!
Time stands still for no man, although I have to say the last few months have been pretty draggy. I have continued in my search for the perfect Linux and Apache combination, and there is still a version to test... for, like climbing mountains, there is always another ridge beyond the one you are on: the kernel versions just keep coming.
The following is a digest, of sorts, through a bunch of kernels and product releases that I have tried, with comments on the compile and runtime behavior. I once collected train locomotive numbers now I seem to be collecting kernel version numbers. Oddly, I got MySQL running once and have no interest in trying to see if I can destroy all my living database files.
The base systems I have tried installing to are single processor Pentium II and Athlon based systems with between 256Mb and 512Mb of RAM, one has SCSI drives, the rest IDE. I also have one dual processor Xeon system that has hardware RAID and 1Gb RAM, running RH9.
There are far better than I that have written reams of web pages on building the kernels, see the HOWTO's or other sources for better in-depth detail. I have got my builds down to the following steps:
Normally the Lilo.conf edit involves adding 4 or 5 lines to the file, something like:
image=/boot/vmlinuz-2.5.1 label=linux2_5_1 read-only root=/dev/hda6I don't change the default boot version till I have reboot at least once and shown that the new version works. These instructions work for all the 2.4.x and 2.5.x versions, I'm less certain they work for 2.2.x versions (make bzImage needed???).
I have run into some problems but they tended to be of my own making. I was getting errors with SCSI_IOCTL_FC_TARGET_ADDRESS and SCSI_IOCTL_FC_TDR; turns out I should either be using, or be configured to use, the Compaq SCSI Smart RAID adapter. If like me you don't have one of the near $1000 cards, then you will need to revisit your config and remove the SCSI device entry for this (and other devices?)
The selection of module or inbuilt is a tough one. There are many things that can build as modules and the system works just fine, on the other hand some items, like IDE or SCSI drivers tend to be better built in, especially if they are for the primary boot device.
Eventually typing make becomes boring, but the segmentation faults never cease to come up with new and wonderful excuses. One of the Linux boxes here refuses to function properly. The others are just fine. Go figure. I suppose I could uninstall EVERYTHING and then re-install, but this smacks too much of the Microsoft way of doing things. I will battle on. [Sounds of 'hero! hero!' from the crowds]
NEWS JUST IN... I installed the latest glibc rpm's and surprise, surprise no more seg faults in building the Kernel.
Always leave yourself an exit! NEVER replace the old Lilo entries until you are absolutely certain you will not need a kernel - i.e., never delete a lilo entry, buy a bigger monitor if you run out of space on the startup screen!
If you install the wrong network driver eth0 will not start. If you install the wrong video driver X will not start properly, but you should still get text VGA screens. Both of these are fixed by reconfiguring the config and rebuilding.
SMP. This is an ugly one. If you build with Symmetric Multi-Processing enabled then I have found no way to back out, the only thing I have been able to do is delete the source and start again. I get errors in the compile that say smp_processor_cnt (or similar) is being used but has not been defined. If you have SMP and multiple processors then good, if you don't, it is worth unsetting this and selecting the necessary APCI interfaces (they seem to be interlinked somewhere deep down, probably because SMP systems have different power control structures).
In running my system I get a message that says "Spurious 8259A interrupt : IRQ7". I have not been able to find where this comes from. There are references to it in several places in newsgroups, and some people say they have solutions (generally involving avoidance of SMP mode) but I have not been able to stop this one. I normally get just one incidence now, but it is still not quite right.
As of RedHat 8.0 the standard boot loader is Grub. Problem is that if you change the default to Lilo there are some odd problems. In building new kernels on RH 8.0, I keep getting a Grub library error that seems to destroy the install. I have not found a way around this yet. In RH 9.0 I get a "grubby" error, but the build finishes successfully.
Running xconfig or menuconfig is a bit intimidating at first. Thinking that you can destroy hardware does not help alleviate those concerns, however, the dangers to your machine are more likely to come from a bogus X setup than anything you can do in a kernel config. Kernels tend either to work or panic. A kernel panic is just another way of saying your system crashed. As long as you left yourself with a lilo default entry that left the last good kernel then you should be just fine, just reboot and select the good kernel.
I tend to find the most important entries in menuconfig (or xconfig) are in "Processor Type and Features", "SCSI Support", and "Network Device Support."
This was the second kernel I downloaded, an earlier 2.1 kernel never got used, this one is a gzipped tar file of almost 27Mb's, a fun download. The important thing to remember in doing the kernel compiles is not to change things too much. A good starting point is to get the config file that a previous kernel was built with (You may have to install the Kernel Source RPM to do this - it should be in /usr/src/linux-2.4.2 or similar.) Copy the config file from (/usr/src/linux-2.4.2/configs) to the new kernel directory. Run the config programs (xconfig or menuconfig), select your config file, then select the things you want to build into the kernel. Note that to make the kernel smaller you can build the items as modules (where allowed), but care must be exercised to make sure that critical features (such as IDE support if using IDE drives) are built in if you want some level of performance.
I was able to trash my initial configurations with ease. Make sure that you are including all that the system has been set up with (ie., is USB installed even if your not using it?).
This version was much more reliable than the version that came with Redhat initially.
There are a few people that think I am disturbed, crazy even. They might be right. This next kernel came out in October and I decided that I needed to download it and check it to see if it offered anything. Given the security frenzy we have at this time, being up on your OS version is not such a bad thing.
The download (source again, as I don't trust the patches, and having made changes to just about every release to get them to compile, I know the patches will not apply correctly) is another 27MB. I tar'ed it to the usual /usr/src locations. I copied over one of the 2.4.6 config files and compiled.
I modified the lilo.conf to add the new OS, and rebooted. Everything worked OK. This, too proved to be a good version. However, no sooner than you can say "buggy," another kernel is on the way!
Into the breach once more, dear friends... After a relatively short life 2.3.12 is replaced by 13. Is this unlucky, who knows. This fixes a few security issues that have seemingly been around a time.
The download (source yet again) is another 27MB. I tar'ed it to the usual /usr/src locations. I copied over one of the 2.4.6 config files and compiled.
I ran just two problems:
The errors in the SCSI code for the Compaq adapter seem not to have been altered since last we did this. I suppose I could have altered the config to see if I could eliminate the module these appear in. But that seems like work.
SCSI_IOCTL_FC_TARGET_ADDRESS and SCSI_IOCTL_FC_TDR seem to be undefined. I commented out the case statements these were used in, in the cpqfcTSinit.c module.
Sure enough, if you look hard enough when you're doing the config (xconfig or menuconfig) you will find in the SCSI section that there is an option to not include the offending Compaq SCSI modules. While I was there I cleaned out a bunch of useless stuff from my compiles. This became self defeating when I managed to install the kernel on a machine that infact had an Adaptec SCSI adapter. This machine needed a kernel compiled with the SCSI included in the kernel, and the adapter modules included too.
With this compile I also changed to using the Athlon machine architecture, I wanted to see if it was faster, smaller, etc. Well it seems to be running OK, it is a tiny bit smaller as an executable kernel, but not so that you would notice much. It is fast.
As is customary I modified the lilo.conf adding the new OS, and rebooted. Everything seems OK. I would like to say that I will give it a try, but 12 was replaced so fast, I hadn't had time to move it from this test server to the real server, before 13 came out. Let's see if 13 has more staying power.
One aside here, after creating a new kernel you will notice that you have two updated files in the /etc directory. These are issues.net and issues. These are text files, they say the same thing; something like
Wonder Linux 8.7 (Mannheim Release). Kernel 2.4.13 on an i686
I find it is useful to change these files to something less interesting, something like "Linux" or the machines name. This says anything anyone needs to know about the system. The issue and issue.net are used when a tool like logon or telnet connects to your machine, this is where the identification string comes from. To permanently change these files (they are regenerated at each boot up, edit /etc/rc.local. You will notice three 'echo' commands near the end of the script, comment out the lower two of the three, and put in one of your own, something like:
echo "Linux : A Brave New World" >> /etc/issue;
I have been playing around with the 2.5.x kernels for a while, but I decided that I also wanted a good solid production kernel, this is the kernel of the moment. I think that the 2.4.x kernels are now officially in maintenace mode, this means that there will be few changes. As usual I got the code from a mirror site, configred it and compiled. It installed with no major problems. I did have one issue, its something I have been battling with for a time: shutdown and the configuration options needed to make it automatic. I have been back and forth on this problem, some kernels I got it to work others didn't. This time I was going to beat it! I succeeded in configuring it all (see above) and it's now the default kernel.
Just keeping up with the version numbers here. With 2.4.19 due out soon, I took the opportunity to upgrade to 2.4.18 then patched in 2.4.19-rc3. It seems stable.
'Cause my RH9 systems still need attention, I still build the occasional more current kernels. The 2.4 kernels have become very stable. There are few surprises nowadays. Once you get a build configuration you can pretty much stick with it. The latest kernel (2.4.32) compiled well. I have had a little annoying proble with 2.4.31 where it seems to cause zcat, and couple of other apps to core dump, which may be a library incompatibilty sliding in, I will just have to keep an eye on things.
Sometimes it's not so good to jump in too quickly. This Kernel is the first of the new generation of Linux kernels. It brings a whole raft of goodies to the party, not one of which I can name, but heck when your collecting Kernels what's the difference! This kernel was not that good. Firstly, you need to get the -pre1 patch or you'll turn your hard drive into a Frisbee. With the patch installed, the compile was done from a scratch. I decided on a uni-processor setup and a fairly simple configuration (this was not going on a 'production' server so it didn't matter too much). The compile was not smooth. There were a couple of little things that I needed to tweak, but then it all built and installed. Running it was a surprise. This first version of 2.5 was a dog! Bow-wow! It was sloooowwww! I didn't stick with it too much and decided to go back to the old 2.4.13 install and wait.
The wait wasn't too long. By mid-december 2001 the new 2.5.1 kernel was released. This proved to be a mighty success. It compiled cleanly and ran right away. It is fast, at least as fast as previous 2.4 releases (a relief) and so far has not exploded on me.
It has been sometime since I tried a 2.5 kernel, last I looked 2.5.66 had been released. With such a high minor version number, I would suspect that you might be able to observe a nicely maturing kernel.
The test releases of the 2.6.0 kernel are out there. Watch out it is a very different process to biuld this release and integrate it than for the prior 2.4 kernels. On Older RedHat bases it is a major effort to get all the tools in place; you have been warned. I have been able to get one of the test kernels working (-test4, I think) and have -test9 in the wings to try. Too early to tell how it runs. The configuration options are quite extensive, a 2.4 config will NOT work.
I have tried this release of the kernel with respect to Fedora Core 2, but have not been successful in configuring it and building it. I also have some issues with the stability of the entire 2.6 series of kernels. One of my servers is constantly in rebuild mode, while another server running Fedora C2 has run fine for months %-|
The system I am trying to create is a web server. So it needs web server software. RedHat 7.1 actually comes with a recent copy of Apache (1.3.19), however to allow it to make use of PHP, and PHP in turn to make use of MySQL, you need to install the Source RPM's. At this stage I found out that PHP is now a major version up and MySQL has continued it's relentless pursuit toward numeric nirvana. Therefore, I decided to download all the latest packages. I started with Apache.
Build it and they will come
Apache is pretty easy to construct. Choose the things you want it to do (pretty much everything) and let it fly. There are some "curiosities": namely that you will likely want to construct the system using one of the pre-defined directory layouts, and you will need to enable a tool called apxs.
The layout you select is a matter of personal choice. I like the setup RedHat uses, so I have tended to remain with it. But other layouts are perfectly viable. Check out the options by looking at the file config.layout
One minor issue I ran into revolved around removing the pre-existing Apache install. This was necessary because there are libraries the new version does not seem to like. Of course when this removal is complete the old conf/modules and conf/log links in /etc/httpd are gone, and need recreating.
Note that unlike the RedHat version this new version uses apachectl to start and stop the service. If you uninstalled the old version of Apache, then even the /etc/rc.d/init.d/apache service script is gone. To get Apache to start when the machine is boot, you will need to recreate the service script.
Download Apache from Apache.org.
If we play the 'spot the difference' game I will lose here. I really can't tell 1.3.20 from 1.3.22. The both run reliably.
There has recently been a security release, so I downloaded and built this for the main site. It built and runs fine with no problems.
I got greedy. I decided to try and install Apache 2, the up coming new boy on the web server block. It's a new architecture geared to more scalability (like we need that here at the Mansion), performance (could always do with a little more Oomph), and expandability (more goodies). It's currently only in Beta, this means it may or may not work - it's more likely to work than an Alpha release, but less likely to work than a shipping product.
I knew the risks, but I wanted to get a march on the world, so I downloaded it. I read the documentation (such as it is), and got to compiling again.
The system compiled easily with simple default settings. It even ran, and there was a definite hint of greater speed. But that first compile did not include all the support needed to use PHP. So it was back to the drawing board. I also wanted it to compile, like the 1.3 version, to go in the RedHat directory structure.
And that's where the problems started.
At the moment I have been able to get it to compile and locate files to some of the places, but keep getting errors as it tries to copy files to places that don't exist, or are incorrectly specified in the Make files. I will persist and see what I can glean from the various make files and configuration definition files.
./configure \ "--with-layout=RedHat" \ "--enable-shared=max" \ "--enable-rule=SHARED_CORE" \ "--enable-info" \ "--disable-userdir" \ "--enable-so" \ "--enable-vhost-alias" \ "--enable-cgi" \ "--enable-ssl" \ "--enable-usertrack" \ "--enable-unique-id" \ "$@"
Also note that Apache 2 will install into a directory called /usr/local/apache2, not /etc/httpd.
Download Apache 2 from Apache.org.
This is the latest official Beta of the new Apache server. It was released at the end of November. It is a pretty much fully working release. After some fiddling, I found some of my earlier configuration settings didn't work with this version, I was able to get it to build and install. It runs smoothly. I then set about trying to integrate PHP. Ouch. This still does not seem to work with the DSO, or AXPS, interface. However I did manage to compile PHP for CGI and get it to work that way. It seems to be reasonably fast in this mode. I want to do a bit more fiddling before I put it on my main web server. Call me 'chicken!'
This is the official release of the new Apache 2 server. It appeared in early April 2002, it is stated that this is a production release. I was able to install and run this rapidly. I made a goof in that I mis-edited the make file and ended up creating a server that ran but was missing most of it's modules. I was corrected by those at apache.org.
See below for comments on integrating PHP with this release.
This is a security update, but includes lots of little fixes. I have built it and continue to test it with PHP but have so far refused to put it into production because I don't like the way PHP interfaces with it (cgi). This version built fine and seems stable enough on its own.
See below for comments on integrating PHP with this release.
Building and installing Apache has become somewhat routine. This release is another security release, and has some bug fixes. It builds and installs with no fuss or muss. I have now been running 2.0 versions for about 18 months, none have been problematic, and all have been reliable. If you are still in 1.3 land, think about the upgrade. Compiling and installing alone are worth the effort. Recent improvements in the http.conf syntax mean there are few changes needed with respect to moving over a VirtualHosts section.
See below for comments on integrating PHP with this release.
Continued routine in terms of build and install. This release is another security release.
See below for comments on integrating PHP with this release.
Even though this is a whole new version of Apache, the compile and build is identical to prior versions, so I found no issues. I did compile with a different prefix so that I could run two Apache servers side by side, but otherwise it looks ok. This page is being dished to you by Apache 2.2.0!
There is almost nothing involved in the install of MySQL. I have stuck to the Binary distributions. This means that I download the rpm version and just install it. The RPM installation process does everything that is needed to build the database environment and put all the scripts in the correct places. Setup of the database is left to you the viewer.
One aspect to this RPM install is that the executables are not placed in a directory of your choosing, they go into the /usr/bin directory. There is also a directory created as /usr/share/mysql, containing some test scripts and the language packs.
Download MySQL from MySQL.com.
Again, I stuck to the Binary distributions from the MySQL.com website. This means that I download the rpm version (and all the associated library and client RPM's too) and just install it (rpm -Uhvv *). The RPM installation process does everything that is needed to build the database environment and put all the scripts in the correct places. Setup of the database is left to you the viewer. Be aware that there are a couple of scripts that you need to run to upgrade either 3.x.x or 4.0.x versions to 4.1.x, these alter the columns in the tables of the mysql instance. These modifications are a big step on the way to v5.0, so look at them and get used to them!
One file you will need to keep tabs on is mysql_config which resides in /usr/bin and is needed in compiling in PHP mysqli libraries.
Last night MySQL released 4.1.7 as the first primary release version of the 4.1 version of MySQL.
Again, sounding like a broken record, I've stuck to the Binary distributions from the MySQL.com website for all the 5.0 releases. I have been downloading 5 or 6 RPM's for Linux and a large zip file distribution for Windows. I don't like the windows installer distribution as it has to be uninstalled and that can cause it's own issues with keeping critical files. As with earlier versions rpm -Uhv *.rpm the rpm's in Linux, or expand the zip file to a directory with the name of the distribution for Windows. I have a my.cnf in /etc and C:\Windows directories, that I have kept for each version of MySQL 5.0. There have been a couple of minor changes but nothing dramatic. Though those minor changes did stop the server starting. I keep my data in a separate directory tree that is not part of the MySQL distribution directory. This really simplifies changing versions. Changing from v4.1 to 5.0 I had to run the various scripts that come with the distribution. It is essential that these scripts are run. They change the structure of most of the mysql databases tables, adding many columns.
While the 5.0 branch is still in Beta, I have found no problems with recent releases. With the exception of this server, which runs an older MySQL version, all the other servers here are running 5.0.
Integration to PHP has not been a problem, nor has using the adminstrative and development tools (MySQL Adminstrator and MySQL Query Browser). If you try to use the older MySQL Control Center with MySQL 5.0 things generally still work, but every so often you get odd table errors that must mean CC is not expecting to get some data it has recieved.
MySQL 5.0, PHP 5.x and the new MySQLi interface were made for each other.
In the last month MySQL has gone 'gold' with the official release of MySQL 5. It came out initially as version 5.0.15, but quietly was replaced by version 5.0.16 (as of about Dec 1st 2005). There is one big, fundamental change in the distribution that I don't like - gone are the Linux x86 rpms. Their place is now taken by a single binary download. There are problems here though. I thnk the MySQL people had so many issues launching version 5, with people coming from older versions (v3.23 and v4.0), that the only versions now available are initial install versions. This means that the update files you need are gone. And you need the update files. Even coming from the prior beta release (5.0.12) you have to run a script that seems to merge the Host and Db tables (in the administrative mysql database). Without this script being run, you will get errors about "user XXXX can't logon to localhost". The script you are looking for is "mysql_prepare_privilege_tables_for_5.sql". If coming from older version 5 beta or alpha releases you will also need to run "mysql_fix_privilege_tables.sql". Run this second script first... when I tell you where to find it. Remember, to run these scripts you need to ignore errors :
mysql -u XXXX -p -D mysql -f < scriptfile.nameWhere to get the scripts? If you download the windows non-installer version (5.0.16) and expand it, you will find in there a scripts directory. It has all the necessary scripts. Copy the two scripts mentioned above to your linux install tree and run them.
To get this straight: On linux...
PHP is a script engine providing similar functionality to Microsoft's ASP (Active Server Pages). It provides the ability to create dynamic web pages with content that can respond to user input. It's a fairly easy language to learn. It runs well in Linux, it's free, and it runs fast. 'Nuff said?
There is not much to set up for PHP. I set it up to be an independent or Dynamic module, this requires having to find the apxs module created in the Apache build. I found apxs in /usr/sbin/apxs, though your experience will vary with your apache layout or directory configuration. The next thing is that I wanted to use the MySQL database.
It took me by surprise. I had previously done this with a much older copy of MySQL and not run into this issue, but now I found that MySQL's install had not put in place files that PHP needed. This required some snooping around, until I found that you need to install the MySQL-devel-3.23.39-1.i386.rpm. This establishes a /usr/include/mysql directory with a bunch of header files.
The last thing to do with Apache to get PHP working is to edit the httpd.conf file. Deep down you will find a line that contains the text "And for PHP 4.x, use" Under this are two commented out lines. like below:
#AddType application/x-httpd-php .php #AddType application/x-httpd-php-source .phpsRemove the asterisk from the start of each line, save the file, then restart Apache.
In your html directory used as Apaches DocumentRoot, add a file that is called test.php
and contains the single line...
Download PHP from PHP.net.
The 4.1.0 version of PHP came out in early December 2001. It is a minor bug fix release. It does have some performance improvements if you are <hushed tones>running windows</hushed tones>.
I have set it up on the main production server, though for some reason - to be determined - it refuses to run there. I need to do more work on that.
We are rapidly getting to the day that we have a Linux 2.5.x kernel, with an Apache 2.0.x web server and PHP 5(?) engine. Maybe by March of 2002 we will get there.
It was with this version of PHP that I managed to compile a CGI version that runs in Apache 2.0. I had seen various people say that this is the only way to do it. To make this version you need to compile with a slightly different config setup:
./configure --with-mysql=/usr --enable-force-cgi-redirectThis should give you a new version that is a standalone executable (and can operate much like Perl, running scripts from the command prompt). You need to edit the httpd.conf file in Apache 2.0 to send the files to this cgi engine:
Action php-script /cgi-bin/php AddHandler php-script .phpThis should also work in earlier versions of Apache, but as they allow DSO modules it's not much use. The CGI version should show marked deterioration in performance as the hit count goes up.
The 4.1.1 is a bug fix version of 4.1.0, that came out in late December 2001. It is suggested that folks use this instead of 4.1.0. I downloaded it and compiled. I ran into some of the same problems as I did with 4.1.0, in that I kept getting a "NOT_FOUND" error in the sapi modules. Eventually I found a reference to this deep in some news group. It seems to have been a change that crept in after 4.0.6, it means that you have to do some odd things to get PHP to compile as a DSO module to run under Apache (on Linux - not tried it on Windoze). [The prior version (4.1.0) is working because I compiled it as CGI for testing on Apache 2.] This error occurs because some of the code is created dynamically by the configure process, it needs to be able to find paths to some apache include files, and can only do it by first pointing at apache, unfortunately you can't both point at apache and do an apxs call. Here is what I did to get this to compile for Apache 1.3.20:
Do a "./configure --with-apache=/path/to/my/apache", follow this with a "make" then delete the files stub.lo & stub.o in the php root directory and then all the .lo files in the main directory.
DO NOT do a make clean...
Now, do a "./configure --with-apxs=/path/to/my/apxs", follow with a "make" and "make install". This should compile and create the libphp4.so in the correct Apache runtime directories.You will need to restart Apache. Check with the usual phpinfo() call.
The build configurations for Apache 2.x and PHP 4.x are as follows:
Build Apache 2.0 as defined above Then...
The configure I have been using looks like this. It allows the PHP to find Apache2 and includes MySQL built into the PHP engine (for better or worse). I enable the trans-sid so I don't have to type all those session items.
./configure --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-inline-optimization --enable-trans-sid
Make sure your httpd.conf has the LoadModule and AddType commands
LoadModule php4_module modules/libphp4.so AddType application/x-httpd-php .php .htm
The PHP.INI should be in /usr/local/lib. If you edit it is worth making sure occasionally that the version in the new PHP build is compatible with the last version you had (copy settings to a new version and see if things get better.)
I have to say that over the last few years my PHP make file has become far more sturdy, there are days I wish I knew what was in it! However, it is useful sometimes to see these things and how people have meddled with them to create their setups. So here is the current make file:
./configure --prefix=/usr/local/apache2 --exec-prefix=/usr/local/apache2 --with-apxs2=/usr/local/apache2/bin/apxs --enable-force-cgi-redirect --disable-debug --disable-rpath --enable-inline-optimization --with-openssl --with-xml --with-zlib --with-layout=PHP --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --enable-trans-sid --with-pear=/usr/share/apache2/pear --with-mysql=shared,/usr/local/mysql-5.0.16 --with-mysqli=/usr/local/mysql-5.0.16/bin/mysql_config --with-soap --with-gd --with-jpeg-dir=/usr/local/lib/ --with-png-dir=/usr/lib --with-zlib-dir=/usr/lib/
There are no line breaks in the real file, its all on one line, but looks too messy for a web page. The critical things are that it hooks up to Apache 2.0 (actually 2.2), creates the mysql and mysqli libraries for MySql 5.0.x, builds in GD to do some graphics - along with jpeg and png libraries, and allows some xml stuff. A bit bigger than I started with!
I downloaded, compiled and deployed 4.1.2. It works fine. I then decided that I wanted to try the new Apache 2 server (2.0.35). PHP has for a long time had some support for Apache 2 principally in support of its --with-apxs2 label. However, it never really worked well. I was able to get 4.1.1 to compile for Apache 2 only as a CGI module, not as a DSO. I tried 4.1.2 and had even less success (I failed to build 4.1.2 as either CGI or DSO to Apache 2). When I noticed that the boys and girls at PHP had released a beta to 4.2 I started the downloads again. The first 2 downloads did nothing for me, but the most recent Release Candidate (PHP 4.2.0 RC4 [15 april 2002]) was a whole new experience.
I had to do some house cleaning. I noticed that I had a stray apxs lying around which I replaced by the Apache 2 version. I was then able to compile PHP as a DSO. They are saying this is a Beta test release (or worse - an Experimental release). So far, I have seen no issues. I will not be going to production with this combination, not just yet, but the day is certainly closer.
This is intended as a security vulnerability fix release, but it is also the first of the 4.2 releases I have put on the production server. I compiled this two different ways, the first was to load to an Apache 2.0 web server, the second to an Apache 1.3 server, which is the production version this page is dished up from.
I was caught out on the production machine by the fact that I was upgrading from a PHP 4.0 version, so the security stuff has changed. The application also has a slight difference in it as to where the PHP.INI is found. I normally have this in the /etc directory, but with this version it has to be changed to /usr/local/lib. Thankfully, I did RTFM, and found the change and got the system working with out being embarrased on some News Group.
I still don't like the cgi version that works with Apache 2, and until I can get the DSO version working I will resist upgrading the main server to the Apache 2/PHP 4.2 combination.
This is another feature and security vulnerability fix release. I compiled this two different ways, the first was to load to an Apache 2.0 web server, the second as the CLI version. I have been using PHP as a scripting engine for a while - at which it is very able. We are closing in on PHP 5, so I guess there will be few addition 4.3 releases.
Whoop-de-do a new version you say. Well this is THE NEW version of PHP, including much more of an Object Oriented language engine, and numerous changes. Is it worth it? Ask me in 6 months. I have it installed and I am moving code on to it.
The build process has not fundementally changed, though the install process is a little more
involved. Some of this is due to my interest in using the new mysqli interface to the MySQL database.
To test both interfaces and use the latest version of MySQL I decided to use the MySQL client libraries
- not sure they include MySQL libraries in PHP anymore. This involves including two settings in the
configuration of PHP, needing both a
BUGS! It seems that version 5 is a bit buggy. I tripped over one in the handling of dates and time through the
strtotime() function. This seems to have been a problem since 5.0 was launched. To get around it, and create a
frankenstein monster, I did the following:
All new, updated version with an improved object model and other sundry changes, it is less of a step up from 5.0 to 5.1 than it was for the 4.x to 5.0 transition. The new code compiled using the same make files as the last php version (5.0.3), and while it points to Apache 2.2.0, and uses MySQL 5.0.16 it has proven so far to be very stable.
|AM © 2002 -|