All-In-One Configuration Tools

As I mentioned previously, I run many sites on my web server. Yesterday I decided to clean up some sites that their owners had neglected or not used. One such site was running Apache Tomcat Java Server, which I did not care to leave running.

Now I, like many users of commercial hosting plans, pay for cPanel/WHM which includes a myriad of options/configurations/settings to do almost everything on the server. Back in 2007, I had used the cPanel Addon to install Tomcat. It was an incredibly easy “1-click Install”. I never checked, but I just assumed it worked. Similarly I thought it would be just as easy to uninstall Tomcat. I clicked “Uninstall” and all went well and I didn’t see any immediate problems. Or so I thought …

Last night the Apache Webserver failed. I did not realize till this morning (6 hours later). After some digging I found that it was because Apache could not find some Tomcat/Java module. So much for a proper uninstall. I did not have time to debug the issue, so what did I do? I simply re-installed Tomcat. I just could not afford any more downtime! … I know, I know: Shame on me!

This incident is like many commonly seen in the Linux world: An all-in-one graphical configuration tool can do wonders, but somewhere due to interaction between components it can causes all sorts of unforeseen problems. The root problem here is that it is incredibly difficult to know all the intricacies and nuances for administrating multiple software systems. Add to that the occasional need to manually edit config files, and you create an unmanageable mess.

Do you remember linuxconf? … Back in the day (pre-2002) Red Hat included a configuration tool called linuxconf which could manage multiple system options using a variety of graphical and non-graphical interfaces. While this worked wonders for novices performing simple tasks (mounting disk partitions, adding users, setting network addresses), it caused all sorts of issues for more complex services (web server, mail server, samba). Unfortunately at that time, there were very few complete comprehensive tools for configuring complex servers. Users who got burned using linuxconf, eventually learned that the only guaranteed way to setup things was to read man pages and documentation, and then editing config files manually.

Redhat did eventually abandon linuxconf with RH8.0. And while many users did complain, ultimately it was a smart decision. Software projects cannot be held accountable if some 3rd-party tool mangled their config files. Even more importantly, how can someone be certain the tool made the change they requested without looking at the config output? You can’t.

Sadly even though I expected cPanel to do its job (considering it is not free), I should have been more careful on a live production server. While I’m not saying that every single “all-in-one” tool is a failure, I am saying that trusting any tool without validation is a very poor choice.

The VPS Search

After using shared hosting services on Linux servers for the past few years, I was thinking about experimenting with a VPS (virtual private servers). Currently shared hosting services are highly competitive. If you shop around you can find great deals to host a simple website most with a comprehensive feature set. However these are all very limited. My basis for a VPS was to acquire a server that had room to grow but yet more manageable and more affordable than a dedicated server. These were some of my considerations.

There are VPS solutions as cheap as $30/month for a fairly basic setup. By basic I’ve seen: 5GB disk space, 100GB transfer bandwidth and CPanel service. However availability and/or reliability of the cheaper service tend to make them a poorer choice. Through my research I found that a fairly typical price was between $40-60/month. And some competitive features were 7-10GB disk, with 100-150GB. Even then, the typical “step-up” options were almost doubled features with a price of $100/month. Logically this doesn’t seem very practical as you can obtain some dedicated servers for $100 or even do a co-location server for less. Hence my target was $50/month.

The more I read, the more I realized that reliability is a serious concern with VPS’s. Apparently many people have experienced considerable downtime or hard to diagnose problems. My guess would be poor technical support as it is very easy to misconfigure or corrupt a virtualized operating system. I came to accept that some VPS providers may have more downtime compared to shared hosting providers. Again this is only preliminary research.

Many providers do offer some sort of monitoring service (either free or extra charge). These can vary from simple ping commands from an external server at timed intervals. Or significantly more complex tools, however they all seem to imply that monitoring is in your best interest.

Almost all VPS providers will use some distribution of Linux. Technically, it could be another form of Unix (or even Windows with “Remote Desktop”). Additionaly most will have a preference to a Redhat variation (Redhat 9.0, Fedora Core, CentOS, RHEL). The benefit here is that I can duplicate a great deal of testing at home before I deploy a complex setup on the VPS.

Virtuozzo (the VPS management software in Linux) relies on some tweaking done to the virtuallized booting kernel in VPS. Hence when I saw Fedora Core 2 available, I blindly assumed it used a 2.6 based kernel, when in fact it was a 2.4 variant. On other VPS’s running CentOS, I’ve seen similar characteristics. — The bottom line is that it is beneficial to have a more up to date distribution even if you really shouldn’t modify it too heavily (i.e. Redhat 9.0 is almost 3 years old).

Software on the distributions will be fairly typical to any Linux: apache, database, mail, etc. However for management there are some options such as CPanel or Plesk or even perhaps a service specific option. If you want to save money (between $7-20/month) you can forgo the specialized options and even elect Webmin. However I doubt that it is nicely geared to be helpful for webhosting on a VPS or for running multiple shared websites.

This is final most significant factor. Depending on the partitioning of the VPS on the host machine, the VPS may or may not be able to grow. Example: If a 100GB disk layout was cut up in to 10 separate 10GB partitions and 1 user required an upgrade, this would not be possible!. They would have to buy a new VPS or transfer to another physical host. Hence it is very important that you understand your growth. Keep in mind that 1GB of disk space already goes to the Linux installed. Basic upgrades like software packages and bandwidth may be available, but physical resources may be fixed upon setup. Know these facts in advance.

Getting a VPS took me a little more time than I expected, but the research was much less than when I learned shared hosting in 2002. I plan to be up and running with my selection in the next few days.

From what Rob mentioned from his VPS experience, selection was probably the easy part!

PHP4 RPMs for Fedora Core 4

EDIT (Dec 19, 2005):
I have written a formal guide on PHP4 on FC4.

As a followup to my previous post about PHP4 on FC4, I decided to abandon PHP5 altogether. I spent some time to try and get the PHP4 src.rpm from FC3 to compile correctly in FC4. As it turned out neither the GCC4 nor the GCC3.2 included in FC4 would compile everything properly. So I decided to try GCC3.4 (which I installed from source long ago when first tweaking with FC4).

Anyways it worked. I have 15 RPM files which I don’t think I will upload unless someone really cares for them. I’ve only done this in the process of seeing if there is an advantage in using my own compiled RPM’s as opposed to using the FC3 RPM’s. Right now I don’t think that there is.

Recommended Method:
In the end if you force uninstall all PHP5 RPM files in FC4, and then you install the FC3 PHP4 RPM’s, it does work.

[root]# rpm -e php-imap php-ldap php-mysql php-pear php

Install any PHP4 RPM you want from Fedora Core 3 Updates. Make sure to install the php and php-pear RPM files together.

Virtual Private Servers

One of Linux’s many strength’s is its highly suitable web hosting options. Primarily Apache web server on Linux with various open source applications can provide cheap solutions for hosting needs.

The most commonly used hosting option is Virtual Hosting through Apache. With a simple setup, hundreds of unique websites can be run with 1 single server machine. For about $100 (US) a year, you can get a good set of features from most providers. However, most providers limit your options (minimal email, limited databases, no Java App Server, etc.).

Until recently, the next best solution was Dedicated Hosting. This requires rental or ownship of a specific server machine and managing it yourself. Multiple virtual websites can be hosted and depending on the hardware it can have other services as well. However the cost is significantly higher. Most providers change at least $50 per month for basic hardware/features and it is fairly typical to see prices of $100-200 (plus fees) per month for competitive features.

The technology has been around for quite some time, but Virtual Private Servers (VPS) are recently becoming more popular. This is the process of running multiple instances of Linux and Apache on the same machine. Every VPS on the machine gets a percentage of CPU, disk space, etc. Then each VPS can then host whatever they want without the need to maintain server hardware. When they need to be rebooted, the whole machine is not rebooting bringing down other VPS’s on the same machine – more of software reset than hardware reboot. Software such as Virtuozzo is becoming a popular product from many providers. You can find hosting plans offering VPS from $20-40 per month.

Once I hear some good reliable reviews on VPS services I plan to migrate to that option. I’d welcome any comments on how well these services work.

PHP4 on Fedora Core 4

EDIT (Dec 19, 2005):
I have written a formal guide on PHP4 on FC4.

One of my biggest difficulties with using Fedora Core 4 was that it packages PHP5 with the Apache webserver. Any experienced person should know that Fedora Core is probably a terrible Linux Distribution to be using for a large scale Web Server on the Public Internet. However, it may be sufficient for home or Intranet usage.

What I like to do is, I mirror my public main site mjm wired on my home Linux computer. This was very easy with FC1 – FC3, however PHP5 broke several things in my PHP code. I tried fixing most of them, but it wasn’t worth the effort since my current hosting provider is still on PHP v4.3.10. Anyways, I tried meddling with the PHP4 RPM in FC3 – that was no good. Then I tried recompiling the source RPM for FC3 (src.rpm), but that caused too many compiler errors and with over 60 lines of configure options to compile I couldn’t figure out all the dependancies and flags to satisfy the compile. I had some problems with some XML libraries.

In the end I just compiled the tar.bz2 with some minimal settings. I set the install directory to use /opt/php4 so as not to disturb PHP5. It properly installs the PHP4 Apache Module in the correct location. Then I had to edit /etc/httpd/conf.d/php.conf to disable PHP5 and enable PHP4. So now Apache2 on FC4 runs PHP4 correctly for me. I know there is some way to run them in parallel with controlling certain directories and controlling certain Types (.php, .php4, .php5), but I don’t require this at the moment.

I might write a formal process on this later when I get the time. However, I do think that there MUST be a better way to do this, I am open to suggestion or tips.