What you want is name-based virtual hosts. Because you're likely to get lots of bad advice on how to structure this, I suggest the following as being a nice and clear (perhaps slightly duplicated) way of doing this.
But before I begin, I would say: where does Crowd fit into this picture (Crowd being the SSO piece that joins Jira and Confluence together fairly nicely). In our deployment, we have jira.example.com/jira, jira.example.com/confluence, and the same for /crowd, and /servicedesk, and whatever next comes along. You may want to consider how you solution will grow (I'm not saying that your solution is bad, or even worse than ours, but it is something to bear in mind).
Okay, to the configuration. You need to tell Apache that you're using name-based virtual hosting on HTTP and HTTPS.
# Look in /etc/httpd/conf/httpd.conf
Presumably you have mod_ssl installed, and mod_proxy_ajp to reverse-proxy back to the tomcat servlets providing you with Jira / Confluence etc.
Hopefully you're familiar with setting up mod_ssl, so you've got your certificates etc. I haven't experience with SNI (and if you're still using RHEL5, that's not really an option, but you didn't say which version of RHEL you are using), so I'll assume you have a SAN certificate with names like:
- jira.example.com (or rather jira.foservices.corp, but I'm going to use example.com going forward)
- crowd.example.com (you didn't say if you're using that...)
If you're using RHEL5 or RHEL6, you'll want to
service httpd stop; edit /etc/sysconfig/httpd and enable the worker MPM (uncomment the HTTPD line), which will give you better scalability; then
service httpd start. RHEL7 uses httpd 2.4 by default and has the newer event MPM, I believe, which would be better than either of the previous.
Edit /etc/httpd/conf/httpd.conf and comment out any modules (LoadModule ...) that are not needed. If you don't know, do a few at a time and use
apachectl configtest to you test your config, as the default config will require a number of them.
While you're there, I would recommend enabling KeepAlives; a very good performance boost.
I'm doing to put all of those virtual hosts in /etc/httpd/conf.d/sites.conf. I hope you'll appreciate that there is some apparent duplication, but by separating each name/service into a different VirtualHost stanza adds a great amount of clarity.
I'll start with the basic structure showing all the sites (jira and confluence), and then flesh out the virtual host for jira (the other will be fairly similar).
Okay, so that's pretty high-level; let's have a closer look at the jira virtual-hosts. First, I define a virtual host for HTTP access that just redirects to HTTPS.
Redirect 301 / https://jira.example.com/
The HTTPS site is where all the action is:
SSLProtocol all -SSLv2 -SSLv3
# The following could be tigher...
# If using a SAN certificate, the following would be the same for crowd
ErrorLog ... # don't forget log rotation
# Enough boilerplate, down to Jira specifics. Check which ports are
# used for each or jira/confluence etc. The command (as root or as
# the account running the apps) may be helpful. You want the AJP port;
# not the HTTP port.
# 'lsof -Pni | grep LISTEN | grep java'
# Speed boost
AddOutputFilterByType DEFLATE text/html text/plain text/xml
ProxyPass / ajp://127.0.0.1:8009/jira
ProxyPassReverse / ajp://127.0.0.1:8009/jira
TIP: One thing to think about: what do you want to happen if people go to, say http://foauslxapp05.foservices.corp/ (the default site), or to the server's IP address directly? I suggest you respond with either a 404 (not found) or a 403 (forbidden). Here's a fragment for you to integrate as homework. Use
httpd -S to get a very useful summary of which sites are defined in your current configuration (not running-config, but config files as they currently are), and note that order matters (another reason why I put it all in conf.d/sites.conf, rather than conf.d/jira.conf and conf.d/confluence.conf etc.
RewriteRule ^ - [R=404,L]
I suggest you do a similar thing for the default https site in conf.d/ssl.conf
If hope you've found this post useful and informative.