Running JDK6 on FreeNAS 0.7rc1 rev4735

I had a good experience a few months ago when I re-purposed an old and inexpensive Dell PE400SC server as a network attached storage device running FreeNAS. That system has been a joy to work with, and has served to introduce me to my first experiences with iSCSI mounts from my Windows 7 box.

The underpinnings of FreeNAS are FreeBSD:

freenas:~# uname -a

FreeBSD freenas 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1

...as uname explains. Fortunately, FreeBSD is a system that I've gotten to appreciate and know for several years now. So it was just a matter of time before I started looking for what else this machine could do for me. Sure a few small utilities like screen, autossh, and gawk are nice to have, but my bigger interest lies in java applications, so I really wanted a JDK to support that.

So here are the steps I had to navigate to get the Diablo JDK into FreeNAS. I must say, the FreeNAS documentation site seemed kind of hit and miss for some of this information.

Fetch the java binary


I found this was easier done from Firefox from my Win7 box and saved back to the NAS, in part, because the URL redirects to a POST-only form. Grab the file from:

http://www.freebsdfoundation.org/cgi-bin/download?download=diablo-jdk-freebsd7.i386.1.6.0.07.02.tbz


Make pkg_add happy

There seems to be some confusion about what version of FreeBSD this was built with. Try this:

setenv PACKAGESITE ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.4-release/


Attempt Diablo install

Try to install the java binary, but beware it may balk.

pkg_add -v diablo-jdk-freebsd7.i386.1.6.0.07.02.tbz

If it does complain, you may need to do a series of individual fetches with pkg_add:

pkg_add -r x11/xtrans-1.0.4

etc., for every complaint. Then retry the diablo install. In the end, I was rewarded with this:

freenas:~# java -version
java version "1.6.0_07"
Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
Diablo Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode)

...and a working javac!

Jetty 6.1.x hardening

By day, I am a web developer using Java. At work I'm forced to used RAD 6.0, Websphere and JDK 1.4. But on my own time, I favor Jetty for its light weight and ease of use.

Every time I update Jetty, I eventually get around to repeating the same configurations. This entry documents what I've found to be useful towards setting up a production-ready instance of jetty that has limited risk exposure.


Remove sample webapps

Delete all files under webapps\** - also, enable jetty-plus web apps at the same time (all my apps tend to use jndi and connection pools)

Disable default favico

Change etc/jetty.xml to stop serving the default favicon - find DefaultHandler add this serveIcon false setting:

<New id="DefaultHandler" class="org.mortbay.jetty.handler.DefaultHandler">
<Set name="serveIcon">false</Set>
</New>


Conceal server name/version header

Put this under server elements in both jetty.xml and jetty-plus.xml:

<Configure id="Server" class="org.mortbay.jetty.Server">
<Set name="sendServerVersion">false
...


Configure a default/ROOT webapp

Inside this webapp, use Jetty's error code range mappings to do something like this:

<get name="errorHandler">
<call name="addErrorPage">
<arg type="int">300</arg>
<arg type="int">599</arg>
<arg type="String">/WEB-INF/ERROR/generic.jsp</arg>
</call>
</get>

Change the default session cookie name

Normally, J2EE containers send a JSESSIONID cookie in the first request. But why even expose the fact that you're running a servlet container in the first place? Customize this cookie's name using the following in web.xml:

<context-param>
<param-name>org.mortbay.jetty.servlet.SessionCookie</param-name>
<param-value>XSESSIONID</param-value>
</context-param>
<context-param>
<param-name>org.mortbay.jetty.servlet.SessionURL</param-name>
<param-value>none</param-value>
</context-param>

That second setting disables URL session cookies.

The remainder of these notes addresses configuration items that have nothing to do with hardening - these are just convenient reminders to myself.

Add datasources

Under the Configure element for org.mortbay.jetty.Server, add resource definitions as needed.

Here is one example of a datasource with a pool defined using Apache DBCP (put all jars in etc/lib/ext):

<New id="TESTDB" class="org.mortbay.jetty.plus.naming.Resource">
<Arg></Arg>
<Arg>jdbc/TESTDB</Arg>
<Arg>
<New class="org.apache.commons.dbcp.BasicDataSource">
<Set name="driverClassName">com.ibm.db2.jcc.DB2Driver</Set>
<Set name="url">jdbc:db2://example.com:50000/TESTDB</Set>
<Set name="username">user</Set>
<Set name="password">pass</Set>
</New>
</Arg>
</New>


Add MIME mappings for required content types

Add the MIME mappings you'll need to etc/webdefault.xml - a few I have used are:

<mime-mapping>
<extension>jad</extension>
<mime-type>text/vnd.sun.j2me.app-descriptor</mime-type>
</mime-mapping>

<mime-mapping>
<extension>cod</extension>
<mime-type>application/vnd.rim.cod</mime-type>
</mime-mapping>

<!-- also add maps for ogg, others, etc. -->


Replace the DefaultHandler with a custom class

The default handler automatically lists all contexts configured for the webapp, which is not something you typically want in a production environment.



What other customizations would you recommend for locking Jetty down at initial setup?

Using recursion with grep on windows

I've hit this problem before, but never figured it out, so it has bugged me for a while now. But finally, here is the answer.

Having recently started on support for a new project at work, I wanted to get a sense of who had worked on this code base over the past decade or so of its existence. Being a fan of GNU tools for Windows my mind immediately goes to grep, but it didn't work the way I intuitively thought that it should. I wanted to do this from my project directory:

   grep --recursive @author *.java

...and then I figured a quick awk script could roll up counts by name for me. That last argument of *.java however needs be either a list of non-wildcarded filenames or a simple *

  grep --recursive --include="*.java" @author *

Thanks to the poster of this message for helping me find the answer.