Archive for April, 2011

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:

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

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:


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

ignoreregex =


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

1 Comment

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 =
  when numbervalue = 1 then '1'
  when numbervalue = 2 then '2'
  when numbervalue = 3 then '3'
  else stringvalue
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.

Leave a comment