Linux administrators can choose from numerous HTTP servers, database servers, programming languages, and administrative tools for creating web servers on Linux. Among the most prevalent, however, is the so- called LAMP (Linux/Apache/MySQL/PHP) configuration. LAMP is great way to run a web site: It's fast, reliable, efficient, and flexible. It can also, however, be daunting to set up and manage for those not intimately familiar with Linux configurations. Just installing the pieces of the LAMP puzzle involves anything from a few RPMs (if you do it from binaries) to multiple source builds (if you prefer to roll your own). Configuration often consists of editing text-based files and restarting daemons -- not a problem if you're a Linux wiz, but intimidating if you are not. Perhaps most difficult is getting secure (SSL-based) web hosting to work, a task that can try the patience of anyone who is not a cryptography guru.

A number of companies have taken on the task of automating the task of building and managing Linux web servers, among them NuSphere Corporation with their "NuSphere MySQL" product. NuSphere claims the installation process works on Windows 95/98/NT4/2000, Solaris 2.6 and 2.7, and Red Hat Linux 6.2 and 7.0. It turns out that it also works on Caldera eDesktop 2.4, though with a few caveats as you will see later. To make a long story short, NuSphere is an extremely easy way to build a fairly comprehensive Apache server with all the bells and whistles.

Up until now, I had always built Apache, MySQL, and PHP from source tarballs. This isn't too difficult except that there are some odd interactions between Apache and PHP (you have to ./configure Apache, then build PHP through, then build Apache). With NuSphere there are four ways to install, and three of them don't involve building from source. You can run NuSphere's installation program locally, you can run it remotely using a web browser, or you can install the components manually from the provided RPMs. Last, but not least, you get the source tarballs on the CDROM and so you can install that way.

I did several installations in various configurations on my Caldera system, which is close to Red Hat and is RPM-based. The only method that would not work for me was the one that seemed most straightforward: running the installation program locally. There were several dialog windows that simply showed blank white backgrounds, and the main sequence of installation just hung and had to be killed. This was probably due to a GTK or other widget library being either too new or too old, though it was hard to say which since no error messages were generated.

On the other hand, the remaining three installation methods worked quite well even though Caldera isn't officially supported by NuSphere. Source is source, so I won't belabor the tarball option further here. Installing from the generic RPMs worked correctly except that the startup and shutdown scripts weren't copied or linked into /usr/local/bin (a matter easily corrected with some judicious "ln -s" commands). The other problem with the generic RPMs was that they attempted to create files under the login name of "dmcmahon", presumably one of the company's engineers. RPM handles the non-existence of this login gracefully by defaulting to root, but it's something the folks at NuSphere should fix.

The most interesting approach is the remote install, and this is a real power tool for distant servers! You need to get the installation files onto the target machine (the remote), though it doesn't matter much how you do this. On the remote machine, with no X DISPLAY variable set, running the "setup" script from the installation directory brings a prompt to start a browser on the local server (the controller) and point it at port 4001 on the target. From within the browser window, CGI-like forms are used to control the installation and testing process. This worked flawlessly for me, and within minutes the system was ready for use. After a successful installation, the main NuSphere screen is visible if a browser connects to the local machine, and menu items offer links to the other functions depending on what has been installed and what has not.

All of the major applications on the NuSphere media are Open Source software, so what this company brings to the table isn't so much code as it is integration. In some areas, I found this to be quite beneficial while in other areas I remain skeptical. For example, the company's literature says, "...rather than scattering installed components across your disks in multiple directories, the NuSphere MySQL installation puts everything under one common root directory." They certainly do what they say (it defaults to /usr/local/nusphere), but I question the value of this when most standard installations would create only a few new directories, and those beneath /usr/local. Does it really matter that /usr/local/apache is replaced by /usr/local/nusphere/apache? In fact, as integral as Perl is to the operation of many system utilities, I'm not certain that I want it to live in /usr/local/nusphere/perl. This is just an opinion, of course.

Next: Smooth integration, decent documentation. »