Friday, December 31, 2010

Where, oh where, is that configuration set?

Did I say last time that the most difficult thing about transitioning to Linux systems was figuring out how to get basic system information? I did? Well, let me change that. I will now say one of the biggest challenges is determining where to find configuration information pertaining to programs you want to run on Linux. There are 101 different places to stick things, and while this is undoubtedly one of the features that makes Linux so appealing to do-it-yourselfers, it makes it a little challenging for those of us who like order.

I'm working through Apache and Tomcat 6 again. I've found that there's no better way to get some of this stuff under my hat than to do it over and over again until I pretty much don't need to look at a guide or notes or anything like that. Really, I want to obtain a very deep understanding of the technology and not just be able to type in commands that someone else provided. I really want to know the why of what I'm doing in addition to the how. But I digress.

So, I'm working through Apache and reading through their documentation as I go along to better explain some of the directives available and the inner architecture of the service. I got to the point of where we can use Tomcat to serve up Java applications. Since the Tomcat container exists as its own app, you have to use a plug-in to get Apache to talk to it. For this you install mod_jk, which Apache uses to talk to Tomcat using the AJP13 protocol. When you install mod_jk, it creates a file called In all of the setups we have in-house, is located in /etc/apache2. My install had no such file, which led me to believe that maybe I hadn't installed the module properly because it's supposed to be created by default. I checked and sure enough jk.load existed in /etc/apache2/mods-enabled, indicating that the installation was successful, so I went off to discover why this file was missing.

I found that is by default actually created in /etc/libapache2-mod-jk; whoever configured these systems moved that file to /etc/apache2. I checked and there is indeed a file in the default location as well, but it's not being used because the line that points to the file, the jKWorkersFile directive, dictates what file is used anyway. More interesting news is that some of the properties I have previously seen outlined in apache2.conf or httpd.conf, such as the directive that actually loads this module and other directives that control logging, can be defined pretty much anywhere. Some installations have this set up in the jk.load file, others have it set up apache2.conf, others in ports.conf, others in httpd.conf...skies the limit. As long as its an include in the main configuration file, you could put it in a file named peanutbutterjellytime if you wanted.

What this means to me is that it creates a slightly sharper learning curve because not only does one need to understand the concepts, one also has to be a detective to find where the configuration files and commands are even located in the system. I have two servers here running the same combination of applications, and they don't even match in that regard. My desire for standardization is fighting with the flexibility of Linux.

No comments:

Post a Comment