jira
JIRA standalone, MySQL and Apache 2
As mentioned in my last post, I grabbed a free personal license for JIRA Enterprise today. Here’s what I did in order to install it on my server:
- I downloaded the tar.gz package and unpacked it in my folder of choice
- I symlinked “jira” to “atlassian-jira-enterprise-3.13.1-standalone” for convenience
- I changed Tomcat’s conf/server.xml in order to avoid conflicts with JBoss instances:
<Connector port="28080" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" useBodyEncodingForURI="true" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" />
8080 would have been the default port.
- I “chown”ed the entire JIRA installation to a dedicated user
- I started up JIRA for a first test.
So far so good. At this point, JIRA was running on HSQLDB which is not really useful for production. Thus, the next step was a database switchover to MySQL. For this, I followed the instructions on the “Connecting JIRA to MySQL” page. Yes, it’s really that easy. :-) One thing to bear in mind though: in order to download a MySQL connector, I first had to visit the download website in order to pick a mirror, and then grab the direct link and feed it to wget.
Okay so now I had a running JIRA with MySQL behind it. I’ll skip the JIRA first run setup process, which is very much self-explaining.
Being a fan of Apache2 as the front door HTTP server, I now wanted to make JIRA accessible over one of my domains. I followed the “Integrating with Apache” tutorial and ran into some problems because I had a mix of Virtual Host configuration and mod_rewrite in place. Luck for me: I discovered that the rest of the domain was pretty much out of use, so I simply kicked out the rewrite magic. NOTE: above tutorial does not mention that mod_proxy does nothing as long as there are no protocol handlers loaded. Hence, it makes sense to load mod_proxy_http in addition to mod_proxy ;-) This requires simply one more symlink in mods_enabled, you’ll be able to figure it out if you read the tutorial.
If anyone asks: why mod_proxy instead of mod_jk? Simple: proxying keeps the entire hassle regarding static resources (CSS etc.) away from you. I was way too lazy to research mod_jk and static resource providing, so I decided to use mod_proxy.
As to the Virtual Host problem I had: simply put the Proxy directives into the configuration of the targeted VHost, e.g. like this:
NameVirtualHost 12.34.56.78:80
<VirtualHost 12.34.56.78:80>
# [... settings snipped ...]
# JIRA STUFF
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /jira http://localhost:28080/jira
ProxyPassReverse /jira http://localhost:28080/jira
ServerAdmin webmaster@mysite
# END JIRA STUFF
</VirtualHost>Then there were two last things to do:
- Update the server.xml as stated in the “Integrating with Apache” tutorial
- Update iptables rules in order to close port 28080 to the outside world.
Having finished all setup and administration tasks, I’m now proudly running JIRA on my server. Thanks very much to Atlassian for the generous licensing model!
JIRA for personal use
In order to do some issue tracking for personal purposes (household, money etc.) I grabbed a personal license for JIRA Enterprise today. It comes as a standalone bundle with Tomcat included. I’ll describe my setup steps right here – preliminary summary: painless installation and ++ proxying through Apache 2 made my day!
JIRA and Greenhopper
Via the Atlassian Developer blog, I found a blog post by Kieran Shaw today. In his post, he describes the “Agile Velocity Tracking” plugin for JIRA. A nice plugin in my opinion.
I’m happy to see Kieran Shaw reanimating development on a JIRA plugin that had already appeared to be dead, which is a really nice contribution. His blog post is also a good tutorial on basic JIRA configuration (custom fields, custom issue types etc.) and on sprint planning using JIRA.
One sentence at the end of his post caught my attention though:
Some might ask why use this over the traditional card wall that is often used in agile projects. Card walls are the simple and low tech solution, but they are not available over the web, they are not searchable, filterable, commentable or reportable without manual work from someone.
This is partially correct. In fact at my employer, we started using agile methods by working on a traditional “Postit” card board. Some weeks later, we decided to extend JIRA using the Greenhopper plugin, which gives you a virtual card board where you can drag issues around, get nice charts, including a velocity report. This is where the card board becomes available over the web. If you like it a little more complex, feature-rich, and eye-candy-loaded, you might try this one as well :-)