Building RPM files of Atlassian software - the hard way

Posted on Sat 27 May 2017 in how-to

This article will tell you a little story of mine about building .rpm-files. Not the Red Hat Package Manager itself, the file format.

After switching from Debian derivates, especially Ubuntu, to CentOS Ive figured out that at some point I'll have to build my own packages. In the meantime there have been some struggles with Bugs as well as the different kind of system management Red Hat delivers to it's users. By now I'm using Fedora and are quiet happy with the less stable, but relately current state of the packages.

After adjusting the and building collectd and understanding the .deb-file format it was clear to me that building an .rpm-file must be easy. I was wrong.

Why packaging Atlassian software as rpm files?

Manual installation is a time consuming task. Using the installer is also somehow manual and it doesn't copy all the settings that have been made within an installation directory. This includes the Java parameters, ports to listen on and file permissions.


First of all rpmbuild and all it's dependencies must be installed. It's as simple as 'dnf install rpmbuild'. After that the tricky part starts. .rpm-files are being creeated by using .spec-file. It describes what kind of package you want to build, which version it consists of, what's the source and how to build it. It's basically a bloated Makefile.

To understand the structure and requirements you should read the Creating RPM Packages with Fedora page on the Fedora wiki.

Let's break it down:

  • Install rpmbuild
  • Read the wiki
  • Carry on with a feeling like wtf?
  • Take a look at other spec files. Maybe the ones for nginx or time
  • Calm down and give it a try!

Atlassian distribution and first steps

Atlassian provides it's software products as Windows installers, zip and tar.gz archives as well as Linux installers. As you may notice there are no packages for Debian or Red Hat derivates available and Atlassian won't provide those in near future.

The tar.gz archives consist of a single directory. It contains (for most of the products) a Tomcat with an extracted webapp:

    ┌ root@reparo /root
    └ # ls -al /opt/confluence/
    total 12
    drwxr-xr-x 11 root       root        132 May 27 20:59 ./
    drwxr-xr-x  4 root       root         42 May 27 20:59 ../
    drwxr-xr-x  2 root       root       4096 May 27 20:59 bin/
    drwxrwxr-x  3 confluence confluence  200 May 27 20:59 conf/
    drwxr-xr-x 26 root       root       4096 May 27 20:59 confluence/
    drwxr-xr-x  2 root       root       4096 May 27 20:59 lib/
    drwxrwxr-x  2 confluence confluence    6 May 27 20:27 logs/
    drwxr-xr-x  4 root       root         37 May 27 20:59 synchrony-proxy/
    drwxrwxr-x  2 confluence confluence    6 May 27 20:27 temp/
    drwxr-xr-x  2 root       root          6 May 27 20:27 webapps/
    drwxrwxr-x  2 confluence confluence    6 May 27 20:27 work/

Basically the packaging process should be to unpack the tar.gz and repack as rpm. Maybe it would be a good idea to create users to run the software and so on. Don't you think?

The documentation fail

I've started with some .spec-file I've found on the Atlassian bugtracker. Which led me to an issue when building. The bootstrap.jar led to an error when being repacked. Wait what? A .jar-file is being repacked? Why would you do that?

After I took a closer look at the .spec file I've found a setting problably referring to my issue: %define __jar_repack %{nil} A quick Google search showed quite some results in forums and on mailings lists, but no documentation about why it is there and what it does.

Also I couldn't find any Bug report referring to my issue, but lots of threads discussing it. It seemed like the option is simply ignored.

As of now I still don't know why this option is on by default and what caused this bug, but it has been fixed with the version of rppmbuild that's being shipped by Fedora in the repositories for Fedora 25.

Writing the spec files

After installing Fedora 25 and building some Java app I've started creating my own .spec files for the Atlassian products, which can be found on GitHub. There was a lot of reading an testing involved and I won't dive into all the details as it's nearly midnight. ;)

As you can see in the .spec-file for Confluence it consists of a few sections.


Think of %define lines like variables. Simply use them for recurring string and so on. The version of a software, a user with which it runs and so on. Everything can be put in a %define statement.


There are a few metadata attributes every spec file needs. For example:

    Summary:    Atlassian Confluence
    Name:       atlassian-confluence
    Version:    %{confluence_version}
    BuildArch:  noarch
    Release:    %{confluence_release}

prep, build, install, clean

These 3 sections are the part where rpmbuild does something on your machine. It will, in case of the Atlassian applications, first unpack the tar.gz archive (setup), it won't build anything as we just repack the archive as rpm and finally it will create additional folders and files, remove obsolete files and so on in the install section. After finishing everything it will remove the remporary folder for building, the buildroot.

pre, files, post

The pre and files sections contain information about what to do when installing the rpm. In this case creating a group and user in the pre section and after that modyfying file attributes to make sure the applications user owns all the folders that are required.

After all of this in the post section the systemd daemon is being reloaded to make sure the service can started.

Automating the process

Within the repo you'll find a file called which will download and build the rpm files to automate the process.

To do so the repo is cloned to $HOME/rpmbuild, which is the default folder for rpmbuild to look for the source code and additional files which may be included. After that the download is started and a build process is being triggered.

At the end it will print the locations of the rpm files.

You can show the help like this:

curl -fsSL | sh -h

To build rpm files for all products simply run the script with -a:

curl -fsSL | sh -a