Error 500 after upgrading Confluence to 5.2.x

Background

After we upgraded our Confluence instance from 5.1.5 to 5.2.5 we got surprised when trying to access the newly upgraded instance.

Instead of being greeted with the login screen, the webpage showed an Error 500 and Confluence wasn’t accessible at all.

Analysis

As usual the first step when running into problems with Confluence is to take a look at the Confluence log. This showed reoccurring errors like the following:

Searching the web pointed out a quite close issue described for the Support Tools Plugin (STP) “Upgrading to 3.5.20 results in a java.lang.AbstractMethodError”.

Support Tools Plugin is a bundled plugin in Confluence which provide some useful utilities for administrators like an automated log file scanner (which reports issues on a daily basis to admins) or a quick way to create support tickets.

The one issue with that report was that it was marked as resolved and was reported to having been occurred with version 3.5.20 of the plugin (while we were running 3.5.28). So did we really run into the same issue or was it simply a completely different problem we were facing?

Solution

After getting in touch with Lauretha Rura from Atlassian support and Deividi Luvison (who was assigned the Support Tools issue), Deividi confirmed that the compatible version number for STP versions > 3.5.20 was set incorrectly. While version 3.5.20 correctly stated it is compatible with Confluence >= 5.3 the following versions (including the one we use (3.5.28)) suggested they were compatible with Confluence >= 4.3. That’s how we ended up with that incompatible version of STP getting installed.

While this didn’t seem to be a problem with Confluence <= 5.1.5 with 5.2.5 it refused to work at all.

After having reported this to Deividi the incorrectly set compatibility versions of STP for Confluence were fixed, so that other users will no longer run into this problem.

Workaround

In case you are suffering the problem, the easiest way is to uninstall your current (incompatible) version of STP and install the latest compatible one (for Confluence 5.1.5 this would be STP 3.5.10 for instance) and perform the upgrade to Confleucen 5.2.x afterwards.

Alternatively, you can also directly upgrade to Confluence > 5.3 in which case the issue should not surface as well.

Removing spam comments in JIRA

Introduction

The company I’m working for I’m administrating a JIRA instance which is being used as an internal bugtracker.

Lately we’ve opened-up JIRA to the public and use it as a platform for part of our product.

There’s unfortunately one problem with that: Being a rather small company (with less than 20 employees) we develop our product for a large number of customers who only pay for the product once (no reoccurring costs). The cost is also quite low (around 10-50 Euro) if you compare this to the prices of larger products. If I had to guess, I’d assume we have a customer base which goes into the hundreds of thousands of users.

Compare this to other companies and you get a slight idea why we can not afford an unlimited JIRA license (which, at the time of writing this, would cost us $24,000 plus $12,000 every year, while our current 25 user license only costs $1,200 plus $600 per maintenance renewal).

Since the unlimited user license is out of question for us, we allowed anonymous access to our JIRA instance for some of the projects. That allows our user base to create and comment on issues directly in our bugtracker.

Unfortunately, allowing anonymous access in JIRA has one bad side effect: It also opens up the bugtracker to spammers, since it no-longer requires you to log-in before adding comments or creating issues.

For several months this worked out until a few days ago, when some spambot detected our instance and started created spam comments (around 1,500 the first day and another 5,000 the other day).

JIRA is really a great tool IMHO but understandably the product’s and company’s focus is directed towards larger companies. That’s also most likely the reason why there is almost no built-in protection against spam. Presumably most customers do not use the anonymous access and rather buy the unlimited license so that their users simply create their own accounts, while requests for improvements for anonymous spam protection have been on record for years already (see: JIRA issue 10236 and JIRA issue 8000).

But what do you do if you want to allow anonymous access and run into the situation of a spambot having created a shitload of comments on your instance? Deleting >5,000 comments manually is certainly not an option (that’s roughly 10,000 mouse-clicks to get rid of all the entries 🙂 ).

My first idea was obviously to alter the JIRA DB entries directly, but that certainly is not supported and bares a certain risk of breaking things, if you don’t know all the details of the DB structure.

Fortunately, I discovered a post from Henning Tietgens. Based on his post I was able to adjust his  provided script to get rid of all the comments in just a few hours work.

How to bulk remove comments in JIRA?

(The following instructions were tested on JIRA 6.0.8. They might however also work for any later (or even earlier) version of JIRA).

Make sure you have a backup of your JIRA instance to be on the safe side in-case anything goes wrong with the script. While the description worked for me, it was only tested on a single instance and I can’t give any warranty at all.

  1. In the JIRA instance go to the Add-Ons Manager (CogIcon -> Addons -> Find New Add-Ons) or use the following link: http://[yourJIRAInstanceURL]/plugins/servlet/upm/marketplace
  2. In the search box enter “Script Runner”. This should bring-up the “ScriptRunner for JIRA Standard Edition” as the first entry. Click on Install to install the add-on
  3. On the admin panel you’d now see a new section (on the Add-Ons tab) called Script Runner. Click on Script Console.
  4. On this screen select Groovy as the Script engine, copy/paste the script provided below into the script frame, adjust the issueKey to the one which contains the spam comments, replace “Foo Bar Comment” with some entry in the spammer’s comment and click on Run Now.

Voila. That’s it. All comments containing the phrase you specified above in the given issue should be gone.

Following is also the script (updated 08/19/15) I ran on our instance to clean-up all the spammers comments (based on the URLs the spambot entered in the comments).

Bare in mind to double-check the URLs before running it against your instance. Since spambots tend to use also just completely normal URLs (so to hide which URLs they actually want to spam), it’s quite possible that in your case the script would remove absolutely fine comments as well.