Is using an Apache proxy the only way to get JIRA + Confluence in the same host?

[Rolando]

As per title, is setting up Apache as the reverse proxy for JIRA + Confluence (as per here) the only way to get both running on the same host?

The reason I'm asking is our Timesheet gadget doesn't like it when SSL is terminated on apache, as its internal API fails to communicate.

The only other way i can think it may be setup is with either sevice running on different interfaces!

How have people here setuyp JIRA + Confluence on the same box?

Cheers

[Rolando]

Thanks Andy + Jamie,

i've got it running behind apache at the moment with the mydomain.com/jira + mydomain.com/conf type setup. all seems to work fine, apart from when I enable SSL. I like the flexibility that Apache gives me.

I think i'm going to have to consider our usage of the timesheet plugin :( even though its one we make a lot of use of.

[JamieA]

Apache or nginx or similar...

There are a lot of advantages to setting up Apache. Of course, you get rid of the ugly port numbers, but also you can hold connections at apache until tomcat is ready for them.

Also, you can do cool things like url rewriting, for instance I rewrite the avatar urls so we get a common set of avatars across all the tools, without people having to set them up. And you can redirect to a nice status page when jira is down.

If I was you I'd work out your issues with apache rather than look for alternatives just yet.

[Andy Brook [Plugin People]]

You can run both on one box without apache if you're happy to use ports (or as you say use separate IP addresses!), but thats probably overkill and not the best configuration.

The benefit apache/other gives you is that it provides a seamless frontdoor, not to mention a common point for SSL termination. There are two ways to configure apache, either VirtualNamesHosts (jira.myco.net/confl.myco.net) or a single host with suffixes (myco.net/jira, myco.net/confl).

With SSL certs, you can have only CName as the as the SSL transport is established before the http session, hence, SSL validates the server you are connecting to, hence the VirtualNamedHosts configuration will only be valid for one host (jira.myco.net) - unless you have a wildcard SSL Cert (*.myco.net).

I think figuring out the Gadget SSL issue is the best course of action.

Ive always used apache fronting apps, in both VirtualNamesHosts and single host with suffixes.