This is a brief document on a basic tomcat installation for a redhat based system, including configuration of the server.xml and context.xml files.
To start with, we have Depot objects as:
to allow actually version our configuration so that if a dependency such as an RPM is required it can be tied to a specific configuration (e.g. RabbitMQ Installation requires some RPMs not in our default kickstart).
Note, we always assume we're installing into "/apps" but this could as easily be configured with a property, eg "TARGET.APPS_DIR". We prefer to NOT have local variables but variables on the server to allow for reuse of packages and jobs, or you'll end up with 30 jobs with minor differences for the same installation.
- Create a blank BLPackage "tomcat v7.0.33 Install"
- Next, you'll need a server with an existing user/group or call system commands to add the users. We don't bother anymore with BL Assets - we just call the system commands so we don't even have to find a server with the user accounts/groups/etc.
- Create basic directories, such as /data/logs (again, we imported this from a live browse, but we've had better luck with external commands like "mkdir /data/logs"
- Import a tar.gz as a custom software install to bladelogic. Then, add that software install to this BLPackage. NOTE: We softlink everything so that source files can be updated and have their changes reflected in packages. This allows us to include for example a logging.properties file and have it be changed without having to delete and add it back to a BLPackage.
- Add a "directory softlink" for /apps/tomcat to /apps/apache-tomcat-7.0.33. This allows us to use a standard configuration handling without caring what version of tomcat is installed later on.
- We're using right now the configuration files for jmxremote configuration to allow remote management. These users and passwords are a standard CONFIGKEY entry:
- NOTE: you'll need this file to exist someplace first. We've moved away from this to using template files that can be parsed and take parameters to bypass this need, as well as to allow 1-N users and permissions based on property dictionary settings.
- We clean up the old directories (We overload the standard configurations in our config file, more on that momentarily. We add an external command to do "rm -rf /apps/tomcat/webapps" and rm -rf /apps/tomcat/logs"
- We add a log rotate file. Contents are standard logrotate config - here's a sample below:
9. We use chown -R tomcat:web /apps/tomcat* as an external command.
10. We soft link and include an init script to start tomcat. See $CATALINA_HOME/bin/daemon.sh for an example.
11. Finally, we do some additional cleanup in order to get things more "correct". Below is what our final package looks like.
More details to come here, but we have a set of bash shell scripts that build a server.xml template and context.xml template and create the different pieces from property dictionary values associated with a targetted server.
Attached is a sample script we call to set the server.xml. We call this with a BLPackage external command that does:
cp -f /apps/tomcat/conf/server.xml /apps/tomcat/conf/server.xml.bak
bash /var/tmp/configure_server_xml.sh "??TARGET.APPLICATION.Tomcat Environment Definitions??" "??TARGET.APPLICATION.Tomcat Resource Definitions??" > /apps/tomcat/conf/server.xml
We execute something very similar for the context.xml and setenv.sh files. At the same time, we upload files for various JDBC connections. In the end, we have a BLPackage like the below. This is the only way we've found to dynamically create entries in a server.xml or other files: