nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira on port 80/443 using AUTHBIND

Kelly Schoenhofen

I'd like to run Jira on port 80/443 on Ubuntu Linux and not use apache2 mod_proxy for two reasons:

1) gzip compression is ruined by mod_proxy

2) I have a possibly erroneous belief that you also have to give apache2 your ssl cert as well, and it was difficult enough to get Jira to use a csr cert (I'm apparently forced to use a pkcs12 cert directly, rather than in the jre keystore).

I installed AUTHBIND, configured AUTHBIND for the "jira" user on both 80 & 443, but there's no /etc/default/TOMCAT6 config file to edit and enable AUTHBIND=yes. Some guides say to launch java with "authbind --deep" in front of it, but I'm not even sure where to set that.

Rather than resolving the detailed issues I'm having above, perhaps what's the _best_ way to run Jira on 80 & 443?

Accepted answers

Kelly Schoenhofen

Third answer, and this should be the final and most-correct one. Authbind works well on Ubuntu 12.04 LTS & Jira, but it took a couple extra steps that wasn't clear originally, specifically the --deep option and disabling IPv6.

Here's the process to get Jira working on port 80 and/or port 443, not running as root/sudo, on Ubuntu 12.04 LTS.

1) If you have anything using port 80/443 already, you'll have to remove it. In my prior hack I used apache2 to do some redirects for user browsers (from 80 to 8080, 443 to 8443); you might as well uninstall apache2 completely now. (i.e. sudo apt-get --purge remove apache2.2-common)

2) install authbind (i.e. sudo apt-get install authbind)

3) Bind your ports to your dedicated Jira user with touch, chown and chmod. Here's port 80:

sudo touch /etc/authbind/byport/80
sudo chown jira /etc/authbind/byport/80
sudo chmod 755 /etc/authbind/byport/80

Repeat as needed for other ports like 443.

4) Disable ipv6 in Jira/Tomcat - this was not clear to me for quite while; I glossed over that authbind does not currently support IPv6, and I didn't realize ipv6 was the primary protocol in Tomcat when it's enabled on your nic. (i.e. add CATALINA_OPTS="-Djava.net.preferIPv4Stack=true" in the setenv.sh in your jira/bin folder)

5) Don't forget to change your /jira/conf/server.xml to port 80 and/or port 443 instead of 8080 & 8443 respectively. To use Jira/Tomcat's basic http to https redirection, make sure your 80 block contains redirectPort="443" in it. If your users use http against anything but the exact url your SSL cert is for, they will get an ssl warning about a certificate mismatch.

November 2013 Edit: Rewriting step #6 to not edit the bin/start-jira.sh - it's just too much trouble to re-do this change every single Jira/Bamboo/Stash/Fisheye-Crucible/Confluence upgrade.

6) Configure Jira to launch it with authbind --deep( so child spawns are covered).

While you can edit the start-jira.sh script from:

to:

you will end up redoing this edit every upgrade of every Atlassian product.

The simplest method is to just use authbind --deep in your init.d startup script, or on the command line if you're launching that way. So something like this:

jira@jiraserver:/opt/atlassian/jira/bin$ authbind --deep ./start-jira.sh

works just fine. This is also excellent for validating your work when you are setting this up.

Bonus 7) If you want to get extra fancy, so users get redirected from whatever http address they try your Jira instance with (say http://jira when it should be http://jira.company.com) to the correct, FQDN using https (so no ssl cert mismatch warnings), add the following rule to the /jira/WEB-INF/urlrewrite.xml instead of redirectPort="443" in the server.xml:

&lt;rule&gt;
	    &lt;name&gt;Http Check&lt;/name&gt;
		&lt;condition type="scheme" operator="equal"&gt;^http$&lt;/condition&gt;
		&lt;from&gt;^/(.*)&lt;/from&gt;
		&lt;to type="permanent-redirect" last="true"&gt;https://jira.company.com/$1&lt;/to&gt;
	&lt;/rule&gt;

and then remove the redirectPort="443" from your server.xml.

For brevity, I glossed over alot of bits that hopefully are trivial. Hopefully this helps other people get Jira (or any other product) working on ports below 1024, and not run with sudo/root.

-Kelly Schoenhofen

All comments

PauloP

Hi Kelly

Since the application server is a Tomcat, you should use its configuration files and settings to enable por 80 and 443 (SSL) for JIRA. This configuration file is server.xml and the configuration for port 80 will be something like this:

For further details, the following links could be useful to understand a little bit about that:

https://confluence.atlassian.com/display/JIRA/Changing+JIRA%27s+TCP+Ports

http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Standard_Implementation

Also, perhaps you should raise a new support ticket for an advanced assistance.

Cheers,

Paulo Renato

Kelly Schoenhofen

Sorry, I thought we were on the same page. I'm running Jira on a Linux server of recent vintage, and you cannot bind to ports below 1024 unless you're root/su. I don't want to run Jira as root, as that is a worst practice and very much recommended against by Atlassian. If you know a good way to let Jira use port 80 and port 443, I would like to know.

Currently I've given up on this and I'm using a simple redirect in apache2 to accomplish my goal - that normal users don't need to remember the port, they can just go to http://jira.company.com.

Here's my httpd.conf I have right now:

ServerName jira.company.com

DocumentRoot /home/jira

Redirect permanent / https://jira.company.com:8443

</VirtualHost>

ServerName jira.company.com

DocumentRoot /home/jira

Redirect permanent / https://jira.company.com:8443

SSLEngine on

SSLCertificateFile /home/jira/jira.crt

SSLCertificateKeyFile /home/jira/jira.key

</VirtualHost>

This allows users to type in jira.company.com and they get seamlessly redirected to https://jira.company.com:8443. Not the greatest solution, but if Jira can't easily use ports below 1024, that's the best I came up with.

I intend on keeping Jira up to date so I'm going to down-vote any solution that involves alot of editing of Jira's internals. I also would like to use gzip compression, so mod_proxy is a less-desirable solution. I thought AUTHBIND had promise, but I can't get it working with Jira.

-Kelly

Nic Brough -Adaptavist-

I'm not sure that it will work for Jira, but I've seen "setcap" used to access privileged ports with non-root users.

You could try rinetd to redirect incoming port 80 to 8123 or whatever

Your firewall could be persuaded to remap as well, but I'm not going to claim any knowledge of iptables

I also have a feeling (don't quote me though), that you could do what I think Apache does - it doesn't run as root or with sudo either, but listens on 80 - I think it uses "setuid", which gives it root as it starts up, and then discards it.

Most of my clients simply use Apache though.

Kelly Schoenhofen

I hadn't heard of setcap before - I looked into it, it looked promising, so I did the following:

sudo setcap cap_net_bind_service=+ep /opt/atlassian/jira/jre/bin/java

(I believe it's Jira's java binary that needs the access, since it's the binary that is actually running).

It took the change, but Jira would no longer start; this was logged in the catalina.out file:

/opt/atlassian/jira/jre//bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Poking around some more, it was a rights issue. The user "jira" could no longer execute /jira/jre/bin/java. sudo could, jira by itself could not. I fixed the issue with:

chown -hR jira bin/

in the jira/jre folder. Jira could now run java, but we're back to permission denied for any port below 1024. If I do:

sudo getcap /opt/atlassian/jira/jre/bin/java

it shows the cap_net_bind_service+ep now gone.

So, we're back to square one, unless someone can showme where I went wrong with setcap.

I am going to mark this as answered on my original reply, with the apache redirect (not mod_proxy). So users start at jira.company.com but their browser switches to jira.company.com:8080. If you use mod_proxy, you lose gzip compression. We have enough WAN users that I don't want to lose gzip compression.

A hardware device like an F5 BigIP would be an alternative, but I don't have the budget to get an F5 for Jira.

Kelly Schoenhofen

Here's the process to get Jira working on port 80 and/or port 443, not running as root/sudo, on Ubuntu 12.04 LTS.

2) install authbind (i.e. sudo apt-get install authbind)

3) Bind your ports to your dedicated Jira user with touch, chown and chmod. Here's port 80:

sudo touch /etc/authbind/byport/80
sudo chown jira /etc/authbind/byport/80
sudo chmod 755 /etc/authbind/byport/80

Repeat as needed for other ports like 443.

November 2013 Edit: Rewriting step #6 to not edit the bin/start-jira.sh - it's just too much trouble to re-do this change every single Jira/Bamboo/Stash/Fisheye-Crucible/Confluence upgrade.

6) Configure Jira to launch it with authbind --deep( so child spawns are covered).

While you can edit the start-jira.sh script from:

to:

you will end up redoing this edit every upgrade of every Atlassian product.

The simplest method is to just use authbind --deep in your init.d startup script, or on the command line if you're launching that way. So something like this:

jira@jiraserver:/opt/atlassian/jira/bin$ authbind --deep ./start-jira.sh

works just fine. This is also excellent for validating your work when you are setting this up.

&lt;rule&gt;
	    &lt;name&gt;Http Check&lt;/name&gt;
		&lt;condition type="scheme" operator="equal"&gt;^http$&lt;/condition&gt;
		&lt;from&gt;^/(.*)&lt;/from&gt;
		&lt;to type="permanent-redirect" last="true"&gt;https://jira.company.com/$1&lt;/to&gt;
	&lt;/rule&gt;

and then remove the redirectPort="443" from your server.xml.

For brevity, I glossed over alot of bits that hopefully are trivial. Hopefully this helps other people get Jira (or any other product) working on ports below 1024, and not run with sudo/root.

-Kelly Schoenhofen

nkaravias

Use iptables to redirect 80 to 8080 and 443 to 8443. It's not the most elegant tactic but if you're only hosting Jira on the box you should be fine.

/sbin/iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8443
/sbin/iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Aren Cambre

Has any of this changed with JIRA 6.1 and Ubuntu 13.10? I followed steps 1-6 exactly, and Tomcat is not even listening on ports 80 or 443 per gufw.

Kelly Schoenhofen

I don't think so; I am using 13.10 on some non-production servers but I can't say for certain 13.10 didn't break authbind. But I would highly doubt it did. Did this ever work for you, or are you starting off on 13.10?

Just go after one of the ports (say port 80) and ignore the redirect rule at the end. I need to edit my original post - after doing this for 9 months and going through many-many upgrades of Jira, Bamboo, Fisheye/Crucible and Confluence, all using authbind so we can use port 80/443, I moved the "authbind --deep" from the starting script in the application's bin folder to the init.d startup script, or I remember to do it from the command line. Otherwise, if you edit the startup script in bin (like I say to do in #6) you have to re-do the edit every single product upgrade.

So if you have a clean start-jira.sh, you should be able do to "authbind --deep ./start-jira.sh" and Jira will run on port 80 without launching as root or sudo.

Let me know how this goes, this normally takes 2 minutes to setup and works flawlessly. I'm not sure where your setup is snagging, but I'm sure we can fix it quickly.

Aren Cambre

(Weird, to reply to your comment, I have to hit Comment on your original answer.)

Figured it out. The problem is that the execution of start-jira.sh does not encounter the lines you recommend editing in #6 (starting at line 29). I noticed this being displayed back when I run that script: executing using dedicated user: jira

That comes from line 43.

Running authbind --deep ./start-jira.sh does work.

Starting at line 50 is this:

if [ "$PRGRUNMODE" == "true" ] ; then

$sucmd -m $JIRA_USER -c "$PRGDIR/catalina.sh run $@"

else

$sucmd -m $JIRA_USER -c "$PRGDIR/startup.sh $@"

Is it safe to put authbind --deep before $sucmd?

Richard Kiefer

Thanks Kelly for your detailed analysis. I also ran into issues with setcap. Wish I had found your answer half an hour ago.

With Jira 7.9.0 using setcap does not work because the start- and stop-scripts do no longer work as they suddenly report that there was a wrong java version. Revoking the setcap (setcap -r path/to/bin) resolves this again.

But even working around this version check would unveil further issues, as Kelly pointed out. So I give up with setcap.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

authentication

tomcat

ssl