Tomcat: Configuring Access Logging

Posted on by
Reply

This is third in my series of posts detailing my efforts to stand up a Tomcat/ACF10 development environment next to my existing Apache/JRun/ACF9 stack. For background, see the first post in the series.

Access logging in Tomcat is fairly straightforward to set up, and the official docs are very understandable. The default configuration installed with ACF10 includes an entry for access logging in ./cfusion/runtime/conf/server.xml. Toward the bottom of the file, find the <Host> element and its child access log <Valve> element.

<Host name="localhost" ... >
   <Valve
      className="org.apache.catalina.valves.AccessLogValve"
      directory="/tmp"
      prefix="access-"
      suffix=".log"
      pattern="common"
      rotatable="true"
      fileDateFormat="yyyy-MM-dd"
   />
   ...
</Host>

Most of what’s shown there is easy to understand. A couple of items are worth touching on:

  • the pattern attribute specifies what gets logged for each request; as noted in the docs “common” and “combined” are short-cuts for standard sequences of commonly-used field
  • the fileDatePattern attribute is used to specify the naming mask for the log file; it also specifies the frequency at which the log files are rotated if the logs are specified as being rotatable. Where this mask goes to the day level, access logs will be specified each day.
  • I’ve temporarily set up the access logs to be created in the /tmp folder just for convenience as I work through configuring; I will change this to have the logs created in a more standard (and more secure) location as I get closer to wrapping this up.

Configure your logs as needed, restart the server, bounce a couple requests off it, and verify that the access logs are present and functional.

Tomcat: Disabling Directory Listings

Posted on by
Reply

This is the second in a series of posts detailing my efforts to stand up a Tomcat/ACF10 development environment next to my existing Apache/JRun/ACF9 stack. For background, see the first post in the series.

I will focus my initial configuration efforts on some basics for securing the Tomcat/ACF10 stack, addressing things I know the security scanning services on our network look specifically for. I will start with disabling directory listings provided by default when a browser requests a URL for a directory without a default document. In this post (and all future posts in the series, unless I specifically indicate otherwise), I will use paths based upon my installation of ACF10 in the default location on Mac OS X systems. By default ACF10 is installed in /Applications/ColdFusion10; you can translate as needed for your installation.

To disable directory listings, find the <servlet> element within file ./cfusion/runtime/conf/web.xml. Within that element, find (or insert) an <init-param> element with a child <param-name> element with a value of listings. Set the <param-value> element to false.

<servlet>
   <servlet-name>default</servlet-name>
   <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
   ...
   <init-param>
      <param-name>listings</param-name>
      <param-value>false</param-value>
   </init-param>
   ...
</servlet>

Restart the server, and we can check this one off our list.

Exploring Tomcat and ColdFusion 10

Posted on by
Reply

With the recent availability of a pre-release version of Adobe’s ColdFusion 10 CFML engine, I am going to be doing a bit of comparative exploring to see how this upcoming version lines up against the current 9.01 version. My intent is to install and configure ACF10 on one or more of my development systems in a manner where it can run alongside the currently-installed ACF9 so that I can get a feel, in particular, for any performance differences between these two versions and to ensure that when ACF10 is officially available, any compatibility issues with our CFML-based applications have been addressed.

My current development systems are Mac OS X and Linux boxes, running ACF 9.01 under Apache’s Web server. I will install ACF10 in a stand-alone mode in order to be able to run both servers concurrently. In this mode, ACF10 will be running with the bundled Apache Tomcat server for use as both its application server (replacing the JRun application server historically used with ACF) and as its Web server.

The first portion of this effort, then, will focus on getting ACF10 and Tomcat configured to function as needed in my development environment. With that in mind, I will be exploring the following Tomcat-related configuration needs and blogging about them (as well as anything else of interest I stumble into) in the coming days:

You can see that list is a mix of security-related settings and configuration settings related to how our application folders are structured (and the desire to run these applications through both the new Tomcat/ACF10 stack and the old Apache/JRun/ACF9 stack).

In terms of structure, all of the applications reside in a folder outside of the Apache webroot, and are found via a set of aliases. The folder structure below that top-level folder is set up as follows (with their corresponding application URL’s listed in parens):

  • appGroup1
    • common
    • app1a (http://localhost/app1a/)
    • app1b (http://localhost/appab/)
    • app1c (http://localhost/app1c/)
  • appGroup2
    • common
    • app2a (http://localhost/app2a/)
    • app2b (http://localhost/app2b/)
    • …
    • app2n (http://localhost/app2n/)
  • app3 (http://localhost/app3/)
  • shared

Within each of the application groups “appGroup1″ and “appGroup2″, the “common” folder contains assets shared by the applications in the corresponding group; this folder is aliased into each of the individual applications within the group to appear as if it were nested below the application folder (e.g., http://localhost/app1a/common, http://localhost/app1b/common). All of the applications reference the “shared” folder as a root level folder “/shared” (i.e., as http://localhost/shared).

Further, most of the applications have a default document that relies on SSI to function properly as part of the applications’ respective authentication and security framework. I also do all of testing and prototyping in a folder immediately off of my home folder; I will need to have that folder served by Tomcat/ACF10 just as it is currently under the other stack.

Finally, a caveat: I am a complete noob when it comes to Tomcat, so I will be learning as I go. I am almost certainly going to find sub-optimal ways to make portions of the work. If you see such mis-steps and have recommendations for other and/or better ways, please point them out in the comments on each post.

We have our work cut out for us. Stay tuned.

Up early…

Posted on by
Reply

Up early this morning to get Ian up early (never an easy feat, and sometimes not all that pleasant) to get him to the airport. He’s headed back to Norman and school today, leaving a noticeable hole here at home. It has been wonderful having him home for the break between semesters and for the Christmas holidays.

We’re definitely seeing that as Li gets older, she misses him more each time he leaves, which makes these transition days as and after he departs even harder for all of us.

The Linux Merry-Go-Round Has Stopped

Posted on by
Reply

… or at least slowed so much that to those riding it, it appears to have stopped.

Since the time I jumped into the Linux waters for some of my computers at home and at work, I’ve done a significant amount of hopping between distributions. In the beginning, many of those jumps were simply out of curiosity to see what the different distros were bringing to the table and to get a better feel for the extent to which they easily supported my hardware. After the first couple years, the hopping took on a different purpose and became a bit more intermittent: I was looking for a distro that worked for me, not just on my hardware but for me personally (as well as for those who also used those same computers). I have a stack of CDs and DVDs of distros that I have tried to varying extents; that stack is approaching 8 inches in height (and it clearly doesn’t include all of the distros I’ve tried via bootable USB sticks or as a VM over the past couple years).

Arch Linux logoSo it is a bit of a shift, in many ways, for me to realize the merry-go-round has slowed, possibly stopped. I think I’ve found it. I’ve been running Arch Linux on my Asus netbook for  several months and it fits well: very good support for the hardware and for me personally. It has the packages I want, and I love the rolling release model that keeps packages current continuously as software projects release both major and minor updates (something that always bothered me to the point of kludging work-arounds in other distributions). Over the Christmas break, I moved my older Gateway desktop to Arch, as well. That is still a work in progress, as I am wrestling with a couple of items there but I have a fairly high degree of confidence I will resolve those. (And that’s a very different box with a very different usage profile than my netbook in terms of how I use it and how frequently.)

For now, I’m happy and don’t foresee any hopping in the near future. I absolutely do not miss the periodic upgrade-or-reinstall dance from the other distros I’ve primarily used in the past (Mint and Ubuntu being the two distros I spend the majority of the past 5 years living in/with). I like the pace at which new software versions, once release, make their way through the package management process. The package manager itself does everything I need it to in a very straightforward manner (even in situations where I’ve had to ignore updates to things like video drivers for my desktop’s antiquated graphics adapter). The software I want to use is present. The resulting systems, particularly given their older and/or low-end hardware, are stable and are far more responsive under Arch than any of the other distros I’ve had installed on them. The distro has an active and supportive community, along with a very usable and useful wiki.

Arch probably isn’t for everyone, but it works for me. (And it is the underlying aspect of this — having the availability of a broad spectrum of variations on a given OS, each with different strengths and philosophies to choose from — that makes me truly appreciate Linux, but that’s possibly the topic of a future ramble.)

Discuss.