Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Sunday, April 10, 2011

KIS Me Kate - RPM Packaging KFS Part 1

The default packaging option from the Kuali Foundation is typically JAR or WAR packaging. These are my observations from modifying typically deployment of KFS at the University of Arizona, to using RPMs. This is fine for libraries and/or web applications. It is platform independent and follows the standards of software deployment. So

Why Repackage KFS?

There are shortcomings tow WAR and JAR packaging. WAR packaging was created with the intent that the application is actually WebSphere, Weblogic, JBOSS, etc..., and the WAR is actually a webapp that is deployed within. With that intent comes the concept that everything is contained within the WAR. What is lacking is:
  • There is no notion of pre/post processing at installation and deployment
  • There is no verification of dependencies or requisites.
  • There is no workflow for software installation
  • No maintenance over documentation vs. configuration files.
  • No platform-specific task hooks.
  • Upgrade software management and configuration management

All of these things may not make sense. For example, "No platform-specific task hooks". WAR is platform independent. Why would you want that, right? Well, that's just it. I think it's great that WAR is platform-independent. It let's you independently define your own packaging around it. Again, why would you want to do that? Double packaging? Let's approach each of these.

Pre/Post-Processing at Installation and Deployment

There may be some actual server information that the application needs to be configured at the point of installation and deployment. For example, server name database configuration, ssh key generation, certificate authority verification, ssl configuration, etc... These are normally configured manually by the system administrator manually after installing a WAR. What if this needs to be installed on several servers in a cloud? Some of this information can be automated. It does not require interaction or input from a user, so why do we require it to be done manually? That shouldn't be necessary.

Verification of Dependencies or Requisites

Sure, WAR files can contain all required libraries. There's no guarantee of this. Further, what if the server has a configuration that supercedes the WAR configuration. There's no way to know that either. Libraries aren't the only requisites that a WAR can have. You can ship with the BSF (Bean Scripting Framework), but that does you absolutely no good whatsoever if you have no native scripting languages installed on your server. What about the application server? The WAR doesn't come with that. Wouldn't it be nice if installing the application meant that even the appserver was installed with it and any software (libraries or not) it depends on? Yes it would, that's why proper software packaging starts to look pretty good.

Workflow for Software Installation

Like your development process, installation itself can have its own phases. A good installation infrastructure allows you to augment or even create and define your own phases. For example, pre/post-processing scripts (described earlier), patching, build, file installation, permission assignments, documentation handling, cleanup, etc...

Maintenance Over Documentation vs. Configuration Files

Documentation and Configuration files are very delicate items in your deployment. Any configuration deployed with the application is usually reference implementation. That is, it is typically replaced manually or at the first deployment. Upon upgrading, configuration files are not something you want to override. You typically want to back these up with each upgrade and identify changes in configuration formats between versions. For example, new configuration entries can be added to a configuration file with each version. Some may become obsolete. It is undesirable to keep these, but you typically do not want to sacrifice the rest of your configuration for this. Kuali software is not a stranger to this situation. Kuali Foundation projects have the concept of an "external" configuration directory that exists outside of the WAR. The purpose of this is to exclude sensitive information from the webapp itself like passwords, any uploaded financial information batch files, or even log files. Such information is kept out of reach for security purposes within the external configuration. The external configuration files will not likely change, so when deploying upgrades, these should remain unchanged.

Platform-specific Task Hooks

Trouble with WAR files is that their plaform independent. This is their greatest strength, but also a huge weakness. WAR files know nothing about the system your are deploying too, this is a hassle for system administrators because the software has to be treated separately from other installations. It is difficult to observe changes and possible security threats. For example, if there is an exploit in the version of bouncy castle that KFS uses, there is no way for a system administrator to know. Further, if installation can be simplified by using platform-specific knowledge about the installed system at installation time, this knowledge can be used to automate the process more. For example, knowing what software and what version is installed can help determine what arguments to pass to utilities at install time.

Upgrade Software Management and Configuration Management

Basically, this is software intelligence. Having metadata about your software before and after it's installed for dependency management (illustrated earlier), configuration file handling (illustrated earlier), bug reporting, vulnerability observing (illustrated earlier), etc... One huge use is when a system administrator needs to manage multiple software installations across several servers. Knowing what version, build number, and configurations are on servers should be as easy as checking the software database of that system. Each platform has one. If a webapp is packaged and installed using that system, the software database will know about it and be able to disseminate that information back to the system administrators. With further scripting and automation tools, system administrators can have much better control over the systems they maintain.

Why is Packaging Important to KFS?


KFS is victim to all of the above illustrated.
  • At the University of Arizona, there are application sanity and maintenance tasks that run before packaging and before package installation. Packaging is done on a system separate from installation because there are actually several installation systems. To provide a repeatable installation process, it was decided that if any were going to be on a remote system then all should. For security purposes I cannot go into much detail about what pre/post-processing the University of Arizona does, but I can say that I would expect just about any university to require it.
  • Since building, packaging, and installation happen on separate systems a workflow has to be maintained. Further, the software is not the only thing that is installed for some implementing institutions. Some may couple data or even database schema information to the software. Therefore, this information may be distributed and deployed with the software. It cannot happen all at once. If there is a problem anywhere during the installation, a fallover path must exist. Installation workflows help this work out.
  • KFS makes use of something called an "external" settings directory. This directory is created and populated with reference information at installation. However, this information is overwritten at each installation by default. It would be good to not have to do this each time. When dealing with configurations on several servers, it can be tedious and problematic to rebuild each time and reconfigure each time. Mistakes are made. It is best to just configure once, and then make modifications only when necessary.
  • I have noticed that some institutions like to give access to the shared files directory via setacls on RedHat and other linux systems. Such capabilities are not available by dropping in a war.
  • Currently KFS does not install all other required software with it. Also, there are no reports or observations on vulnerabilities of libraries distributed with KFS. When upgrading from one release to another, there is no verification of version or software compatibility.


How can KFS Further Benefit from Software Packaging?


I used RPM packaging of KFS at the University of Arizona. When I did, it greatly streamlined installation. System administrators were familiar already with RPM. They were adept with installing packages, handling logs and dependencies, and found it easy to modify and maintain configuration. We were able to integrate RPM building into our CI (continuous integration). Whenever a release was due, a new RPM was created. This RPM could then be manually or automatically installed by the package management system. RPM information could quickly be verified with

% rpm -qa | grep kuali
kuali-coeus-2.0-10
kuali-coeus-settings-dev-2.0-10
kuali-coeus-kittdb-2.0-10

or

% rpm -qi kuali-coeus-settings-dev-2.0-10
Name : kuali-coeus-settings-dev Relocations: (not relocatable)
Version : 2.0 Vendor: (none)
Release : 10 Build Date: Tue 28 Dec 2010 07:19:51 AM MST
Install Date: Tue 11 Jan 2011 01:23:25 AM MST Build Host: uaz-kr-a02.mosaic.arizona.edu
Group : System/Base Source RPM: kuali-coeus-2.0-10.src.rpm
Size : 200685086 License: EPL
Signature : (none)
Packager : leo [at] rsmart.com
Summary : External configuration settings for Kuali Coeus
Description :
Mosaic Kuali Coeus external configuration and settings. These files are located
in /home/tomcat/app

. With dependencies management, they are able to make sure that all the necessary tools exist in the system before the software is installed/updated. Database upgrades are streamlined and integrated into the installation process.

Package Repositories

I mentioned that UA has a package management repository. Right now, it is a crude CIFS share. It is possible through YUM to be more elegant with updates. I plan to in the future create my own YUM repository for managing Kuali software upgrades.

Another package management and build system is APT which uses DEB packages. A package maintainer can create a project on LaunchPad which is a portal for Ubuntu Package/Build management. These packages are then present on a package repository (PPA or Personal Package Archive) where a system administrator can then point a server to this PPA and gain updates to all the software on it. The software and repository are verified against a PGP (Pretty Good Privacy) key. See my launchpad. My goal is to eventually have a working packaged KFS distribution by Summer 2011.

Between YUM and APT, it is possible to get automatic updates and patches to your Kuali Software. This is one of the biggest reasons to use software packaging for KFS.

No comments:

Post a Comment