Errands run, kids in bed, and Krull On Demand. Finally, sometime to put some thoughts down about building the Alfresco Appliance.

Some of what I write here refers back to when I original put together, the first version of the appliance. Some is from revisiting it for this release.

Choosing a distribution

I started playing with building an appliance right about the time that Ubuntu announced their Jeos distribution. I have a strong preference for openSUSE and would have liked to have built the appliance on it. (LimeJEOS answers my concerns, and I am excited to give it a spin. Just a few more things to move off my plate before I can devote time to it.) I tried several different distributions: Fedora, openSUSE, Ubuntu, Puppy Linux, Zen Walk. I liked some, was optimistic about others, and disappointed and frustrated with a couple.

What I wanted was a distribution that provided me a small lightweight base, and gives me the ability to add just the packages I needed to run my application. Most of these came in close to what I wanted, but due to dependencies, grew to be much larger than I wanted. Some didn’t even provide me with a nice clean way to get the applications I was dependent on. Those I dropped immediately. Those with decent package mangers got pluses. I wanted to be to keep base packages up to date.

This brings us to Ubuntu Jeos (Just Enough OS). It gave me the size, the packages, and the manager that met my base criteria for a distribution.

Getting Started

While the base install is already fairly small, there still are many packages that I was going to need and not need. This takes some time, but go through the installed packages and identify what you aren’t and are going to need. Make a list and develop a script to remove the ones you don’t need. Another to add the ones you need. You may like to have some of the packages around while developing your appliance, but when you go to deliver it they may add more weight than what you would like, or give tools that just aren’t need by your appliance, or your end users. Keep them installed until you are sure they aren’t needed any more. My list includes: man pages, wireless-tools, sound packages, laptop packages, different editors, hardware utilities, etc. Your list will vary. Sometimes you may want to force remove dependent packages if you know their functionality is not needed. Don’t be afraid to take them out.

I know my list is not perfect, but over time it will improve. Some of this will come with trial and error. Don’t expect to get it right the first time.

Once I narrowed the package list, I started to add my dependent packages. Some of these could require you to re-add removed packages. That is why I suggest leaving packages installed until you have all your dependencies installed.

One of the cornerstones of an appliance is zero configuration. You want people to be able to just deploy the appliance, start it and use the appliance. In the case of Alfresco, it needs Tomcat to be started at boot time. For this I needed an init script. (Mine can be found here.) I use the init script to start Tomcat, start needed services, and perform runtime configurations.

Alfresco is a web-based application, so I need a way to provide the URL needed by users to access the application. For an appliance this can be changed from install to install. There are several ways to handle this, eventual, you will want to have a static address or use Dynamic DNS to update IP to name mappings. My appliances is primarily for evaluation. It is not really ideal to play with DNS or static IPs. I have kept the implementation simple, I’ve created a script that updates the /etc/issue file with runtime URL. (The script I use is here.) The major issue I faced was when the script was to be run. I placed the script in /etc/network/if-up.d. I fully expected it to be run when the interface came up. The script did run when I manually ran ifup. But it didn’t run in every case, especially the most import, at boot time. I tried several different things to work through this. I added a reference to the script into /etc/network/interfaces using the post-up directive. (in openSUSE, you would add a POST_UP_SCRIPT=”” to the interface file in /etc/sysconfig/network and put the script in /etc/sysconfig/network/scripts). This added a bit more power, but did quite fix my problem. I finally narrowed it down to udev. The interface was being brought up by udev, but when /etc/init.d/networking is run, it runs ifup with a -a option (all interfaces marked auto). The problem with this is if the interface is already up, the associated scripts won’t be run. I haven’t found an appropriate fix for this yet. (Any ideas?) So I just disabled the udev rule for the network interfaces . rPath has a good solution for this, they change /etc/issue file in an init script. I like this idea, but didn’t want to write another init script or pollute my existing alfresco init script with this.

Plans for the Future

One of the things that I want to do is provide some Alfresco branding to the appliance. I also want to create some more production ready appliances that use MySQL and point at an external virtual drive to store content and the indexes.

What is Missing

One of the big things that is missing in a management interface for the appliance. rPath provides a very nice extensible web-based administrative interface. It is extensible both for function and branding. But it is rPath specific. I’d like to see an open source cross distro solution. One that was not only extensible but adds CIM based management features. This would make it easy to administer the CIM instrumented applications on the appliance, but also could allow it to be managed externally, but CIM enabled management tools. This would allow the appliance to play nicely in the data center. This is something that Xen is working toward.

---