JIRA with Apache2 and SSL

Responding to a question from AAC. This worked well for me using Ubuntu 10.04 LTS.

sudo aptitude -y install apache2 apache2-mpm-worker libapache2-mod-proxy-html libapache2-mod-jk
sudo a2enmod ssl proxy_ajp rewrite
sudo vi /etc/apache2/mods-enabled/jk.conf

JkWorkersFile /etc/apache2/workers.properties

sudo vi /etc/apache2/sites-available/jira

NameVirtualHost <ipaddress>:443
<VirtualHost <ipaddress>:443>
        ServerAdmin webmaster@localhost
        ServerName <FQDN>
        SSLEngine On
 
        SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
        SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
 
        JkMount / jira
        JkMount /* jira
 
        JkLogLevel info
        JkLogFile /var/log/apache2/jira_jk.log
 
</VirtualHost>

sudo vi /etc/apache2/workers.properties

worker.list=jira
 
worker.jira.host=localhost
worker.jira.port=8006
worker.jira.type=ajp13

sudo vi /etc/apache2/sites-available/default and add to the bottom:

RewriteEngine   on
RewriteCond     %{SERVER_PORT} ^80$
RewriteRule     ^(.*)$ https://%{SERVER_NAME}$1 [L,R]

sudo vi /opt/jira/conf/server.xml

<Connector port="8006"
    enableLookups="false" protocol="AJP/1.3" minSpareThreads="5" maxThreads="256" URIEncoding="UTF-8" />

sudo a2ensite jira
sudo /etc/init.d/apache2 restart

Get public IP from Linux CLI

Quick way to find your public IP address from a Linux command prompt:

wget -O - -q icanhazip.com

Setup Fail2Ban for JIRA and Confluence

While this article is a good starting point, I thought it was worth documenting some more details on configure Fail2Ban for these applications.

To begin, install Fail2Ban:

sudo aptitude install fail2ban

Ensure that your application is logging access attempts. I have Apache in front of both standalone applications:

LogLevel warn
ErrorLog /var/log/apache2/jira-error.log
CustomLog /var/log/apache2/jira-access.log combined

Next, update the /etc/fail2ban/jail.local file:

[confluence]
enabled  = true
filter   = confluence
action   = iptables-allports[name=Confluence, protocol=all]
           sendmail-whois[name=Confluence, dest=root, sender=fail2ban]
logpath = /var/log/apache2/confluence-access.*
maxretry = 5
bantime = 300


[jira]
enabled  = true
filter   = jira
action   = iptables-allports[name=JIRA, protocol=all]
           sendmail-whois[name=JIRA, dest=root, sender=fail2ban]
logpath = /var/log/apache2/jira-access.*
maxretry = 5
bantime = 300

You’ll see I decided to ban the offending IP from all ports, not just port accessed. After 5 failed attempts at logging in, the IP is banned for 5 minutes.

Now, setup a filter file for each application:

/etc/fail2ban/filter.d/jira

[Definition]
failregex = <HOST>.*"GET /login.jsp
            <HOST>.*"POST /rest/gadget/1.0/login

ignoreregex =

/etc/fail2ban/filter.d/confluence

[Definition]
failregex = <HOST>.*"GET /login.action
            <HOST>.*"POST /dologin.action

ignoreregex =

Finally, restart Apache and Fail2Ban:

sudo /etc/init.d/apache restart && sudo /etc/init.d/fail2ban restart

Fix Fail2Ban on Ubuntu 10.04 LTS

I wrongly assume Fail2Ban was working just fine. I recently audited it’s logs and found very little in the way of banning. I tried to get banned from another host via ssh, but that failed:

2011-04-11 12:32:02,098 fail2ban.actions.action: ERROR iptables -n -L INPUT | grep -q fail2ban-ssh-iptables returned 100
2011-04-11 12:32:02,099 fail2ban.actions.action: ERROR Invariant check failed. Trying to restore a sane environment

Luckily, someone else posted a solution to this on serverfault.

def __processCmd(self, cmd, showRet = True):
beautifier = Beautifier()
for c in cmd:
time.sleep(0.1) ## Added per http://serverfault.com/questions/84569/fail2ban-error-gentoo
beautifier.setInputCmd(c)

JIRA: Change Custom Field Type

I created a custom field for a project with a custom field type of Number. It quickly became evident that this should have been a Text Field instead. Unfortunately, you can’t change this in JIRA (at least not without some convoluted custom field configuration scheming).

Direct SQL access to the rescue!

First, stop JIRA before access the database directly:

--This will change the field type to text
UPDATE customfield set customfieldtypekey = 'com.atlassian.jira.plugin.system.customfieldtypes:textfield',
customfieldsearcherkey = 'com.atlassian.jira.plugin.system.customfieldtypes:textsearcher'
where cfname = '<customfield_name>';
--Find all the possible values that need to be changed
select distinct numbervalue from customfieldvalue where customfield = (select id from customfield where cfname = '<customfield_name>');
--each of these values will be included in the case statement
update customfieldvalue SET stringvalue =
case
  when numbervalue = 1 then '1'
  when numbervalue = 2 then '2'
  when numbervalue = 3 then '3'
  else stringvalue
end
where customfield = (select id from customfield where cfname = '<customfield_name>');
--Now, remove the number values that were copied to string values
UPDATE customfieldvalue set numbervalue = null where customfield = (select id from customfield where cfname = '<customfield_name>');

Now, you can start JIRA and check that everything went as planned. Once you’ve confirmed the changes, you should reindex JIRA.

JIRA: Auto ReIndex

It can be helpful to schedule a reindex of issues after hours (likely when you are asleep!). Here is the shell script that can make that happen:

#!/bin/sh
### SETTINGS ###
USERNAME=<admin_username>
PASSWORD=<password>
DASHBOARD_PAGE_URL=http://<JIRA_URL>/secure/Dashboard.jspa
INDEX_PAGE_URL=http://<JIRA_URL>/secure/admin/jira/IndexReIndex.jspa
COOKIE_FILE_LOCATION=jiracoookie
### COMMANDS ###
curl -u $USERNAME:$PASSWORD --cookie-jar $COOKIE_FILE_LOCATION --output /dev/null $DASHBOARD_PAGE_URL
curl --cookie $COOKIE_FILE_LOCATION --header "X-Atlassian-Token: no-check" -d "indexPathOption=DEFAULT" -d "Re-Index=Re-Index" -d "indexPath=" --output /dev/null $INDEX_PAGE_URL
rm $COOKIE_FILE_LOCATION

JIRA: Add watchers at issue creation

After struggling with this feature request from users for quite some time, I have a way now to add a list of watchers to an issue automatically at creation.

The secret here is (1) you need to add a scripted post function to the creation step in your workflow (so this may mean seperate workflows for individual projects) and (2) you need the Script Runner plugin.

Add the following groovy script somewhere in your CATALINA_BASE and call it in your workflow.

import com.atlassian.jira.ComponentManager

def componentManager = ComponentManager.getInstance()
def watcherManager = componentManager.getWatcherManager()
def userManager = componentManager.getUserUtil()

def watchUsers = {usernames ->
   usernames.each {
         def user = userManager.getUser(it)
         watcherManager.startWatching(user, issue.getGenericValue())
      }
}

   def users = ["comma", "separated", "usernames"]
   watchUsers(users)

Special thanks to Brian LeGros for help on this too!

Ubuntu 10.04 LTS x64 Desktop on XenServer 5.6

http://forums.citrix.com/thread.jspa?threadID=266677&tstart=0

This is just a quick quide for those wanting to install Ubuntu 10.04 LTS Desktop x64 on XenServer 5.6. Note that the points given will only work with XenServer 5.6 as pygrub of previous versions do not know how to read grub2.

1. Create a VM in XenCenter. I used Windows 2008 R2 x64 as a template.
2. Install Ubuntu 10.04 in any way you like. Just remember that when you get to choosing your partitions that you select EXT3 for your /boot partition because pygrub does not support the EXT4 file system yet. All the other partitions can be made EXT4.
3. Install SSH SERVER just in case something goes wrong so that you can still access your VM once it is installed.
4. The console for the DomU in PV mode is HVC0. You will need to tell getty to this. Copy the existing tty1.conf and edit it to replace “tty1” with “hvc0”.

sudo cp /etc/init/tty1.conf /etc/init/hvc0.conf
sudo nano -w /etc/init/hvc0.conf

5. Shutdown the VM
6. Retrieve the UUID for the VM by using : xe vm-list
7. Retireve the UUID for the VBD disk by using xe vm-disk-list uuid=xxxxxxxxxxxxxxxx
8. Clear out the HVM boot policy by using xe vm-param-set uuid=xxxxxxxxx HVM-boot-policy=
9. Set the PV bootloader to pygrub by using xe vm-param-set uuid=xxxxxxx PV-bootloader=pygrub
10. Set the VBD disk to bootable by using xe vbd-param-set uuid= bootable=true
11. Start the VM and login. If your console appears to hang, try connecting to the VM using SSH. If you missed step 4 the console will appear to hang. However it is actually not displaying the login prompt on hvc0
12. Mount the xs-tools.iso and install the Linux guest utilities.
13. Unmount the xs-tools.iso before restarting the VM.

You will have to setup VNC such that the guest console works. This is discussed in other forums and is therefore not repeated here.

Try http://community.citrix.com/display/ocb/2008/07/02/Installing+Ubuntu+on+XenServer

iPad Models

Why would any sensible person get the non-3G version of the iPad? Honestly, Apple and, by extension, AT&T got this right by offering a 3G device capable of full Internet browsing and without a contract. If you don’t have a laptop now, this is a perfect device for typically browsing, email, documents, photos, and even eBooks. You can turn the 3G on/off at will–on a monthly basis.

Startup Script for JIRA in CentOS

#!/bin/sh -e
# chkconfig: 2345 90 10
# description: JIRA

# Define some variables
# Name of app ( JIRA, Confluence, etc )
APP=JIRA
# Name of the user to run as
USER=jira
# Location of application's bin directory
BIN=/opt/atlassian/jira-4/bin

case "$1" in
# Start command
start)
echo "Starting $APP "
su -s /bin/sh $USER -c $BIN/startup.sh
;;
# Stop command
stop)
echo "Stopping $APP"
su -s /bin/sh $USER -c $BIN/shutdown.sh
echo "$APP stopped successfully "
;;
# Restart command
restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
;;
esac

exit 0