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?
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:
exec $PRGDIR/catalina.sh run $@
exec authbind --deep $PRGDIR/catalina.sh run $@
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:
<rule> <name>Http Check</name> <condition type="scheme" operator="equal">^http$</condition> <from>^/(.*)</from> <to type="permanent-redirect" last="true">https://jira.company.com/$1</to> </rule>
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.
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.
(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 $@"
$sucmd -m $JIRA_USER -c "$PRGDIR/startup.sh $@"
I would put it before $PRGDIR/startup.sh, in the quotes. Like this:
"authbind --deep $PRGDIR/catalina.sh run $@"
But, I wouldn't actually do this. I would instead run start-jira.sh with authbind --deep in front of this. Otherwise you're going to make this edit every single upgrade. If you're kicking off start-jira.sh using an init.d script, then put authbind --deep there.
Also, you would make that change for every line that could execute Jira, not just the one I altered. This holds true for editing start-jira.sh or init.d script.
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
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:
<Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="80" protocol="HTTP/1.1" redirectPort="8443" useBodyEncodingForURI="true"/>
For further details, the following links could be useful to understand a little bit about that:
Also, perhaps you should raise a new support ticket for an advanced assistance.
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.
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
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:
Redirect permanent / https://jira.company.com:8443
Redirect permanent / https://jira.company.com:8443
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.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot