Lackhead.org

Whew! I spent a looooong time today futzing around trying to get Confluence to work with SSL and mod_proxy, and after hours combing the Internet for hope, I did stumble upon a few blog comments here and there, which stitched together provided me with the pretty simple solution I was looking for. Granted, I’m pretty new to both Confluence and Tomcat, so perhaps that hindered me. But I also couldn’t find anything succinct out there that talked about my situation, hence, this posting.

Here’s my situation- I have an Apache server that hosts a number of virtual hosts, including SSL and non-SSL sites. I had recently purchased Confluence to provide wiki services for me, my son, and perhaps a few others. I wanted to tuck Confluence behind Apache, and read up on Confluence’s web site about how to use mod_proxy to get Apache to front-end Confluence. This turned out to be very simple, and in a matter of minutes I had Confluence up and running. For those of you who might be interested in doing this, here is a brief overview of the process:

1. Add a virtual host to apache, either named or by IP, with the following configuration:

       # This is just passing a proxy to a localhost server
       ProxyRequests Off
       ProxyPreserveHost On
   
       <Proxy *>
            Order deny,allow
            Allow from all
       </Proxy>
   
       ProxyPass / http://localhost:8080/<whatever-space-you-have-confluence-in>
       ProxyPassReverse / http://localhost:8080/<whatever-space-you-have-confluence-in>
   
       <Location />
           Order allow,deny
           Allow from all
       </Location>
   

2. Configure Confluence to only listen on to localhost, which is as easy as adding a line to the Connector stanza in the server.xml file that reads address="127.0.0.1".

Really, that’s it. This way, Tomcat is not listening on any port that the outside world can see, which means only a service running on that box (apache) can talk to it.

This was all fine and dandy, but I really wanted to get this working over HTTPS so that I could rest a bit easier knowing that my information would be traversing the wild and dangerous Internet encrypted (authentication-related information and everything else). So, the rough idea was that my browser would open up an SSL connection with apache over port 443, and it would proxy to Tomcat via localhost, the later of which didn’t need to be encrypted because it was confined to my box and wouldn’t come in contact with the Internet.

Reading up on this turned up a dearth of good information. Or, at least a nice general summary of what to do. Here’s what I wound up doing:

1. Change your Apache virtual host to use SSL. For me, that meant carving out another virtual network interface on my box and assigning it its own IP address. Once that’s done, you can add Listen directives to get apache to listen on the particular IP:port you are looking for:

   Listen xxx.xxx.xxx.xxx:443
   

   Once that’s done, you can add the SSL directives to your VirtualHost. This is what my configuration wound up looking like (I removed superfluous entries like logging, etc.):

    <VirtualHost xxx.xxx.xxx.xxx:443>
       ServerAdmin <youradminemailaddress>
       ServerName <yourservername>           
   
       # SSL Setup
       SSLEngine On
       # Allow out medium or high key lengths
       SSLCipherSuite HIGH:MEDIUM
       # Here I am allowing SSLv3 and TLSv1, I am NOT allowing the old SSLv2.
       SSLProtocol all -SSLv2
       # Server Certificate:
       SSLCertificateFile /path/to/public_cert.pem
       # Server Private Key:
       SSLCertificateKeyFile /path/to/private_key.pem
       # Server Certificate Chain:
       SSLCertificateChainFile /path/to/ca_cert.pem
       # Certificate Authority (CA):
       SSLCACertificateFile /path/to/ca_cert.pem
   
       # This is just passing a proxy to a localhost server
       ProxyRequests Off
       ProxyPreserveHost On
   
       <Proxy *>
            Order deny,allow
            Allow from all
       </Proxy>
   
       ProxyPass / http://localhost:8080/
       ProxyPassReverse / http://localhost:8080/
   
       <Location />
           Order allow,deny
           Allow from all
       </Location>
   
   </VirtualHost>
   

   This really isn’t any big change from before, just SSL-izing it as you would any host.

2. Now, I also had to make a change to the server.xml that added more options to the Connector stanza. This is what that whole stanza wound up looking like:

          <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080" minProcessors="5"
                      maxProcessors="75"
                      proxyPort="443" scheme="https" proxyName="wiki.lackhead.org"
                      address="127.0.0.1"
                      enableLookups="false" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="20000"
                      useURIValidationHack="false" URIEncoding="UTF-8"/>
   

   The important line is the one with the proxy information. This tells Tomcat to believe that all incoming requests into your server on port 443, even though hopping through the proxy changes that information.

   Given what I traipsed up on the Internet, I had various pieces of this and spent a lot of time trying to figure out what was going on when I would hit the URL, it would connect with the server, but nothing would ever come back. Not really rocket science, but without all the pieces it just wasn’t working. Now it is.

   -c

A little while I finally bought a big-boy fridge for my house, after getting by with a mini fridge I got when I first moved into my fridge-less house. Lil’ whitey, as he came to be known, moved on to a more austere use, that of a beer fridge. So far I have one new brown ale on tap, and my hopes are to get a second brew going when the fabled Mr. X and I get back from Zion in a few days.

Yay for beer!

-c

FYI, I have an updated version of my French Verb Summary, with a couple of typo fixes and a new section on pronoun ordering, including compound tenses and dual-verb constructions. You can find it as a link at the right, or you can grab the PDF version or the Open Office version directly.

-c

This is more of a note for myself, and for the net as the error that I keep running into is not documented all that well online. Well, at least, when I search for Error 51: Unable to communicate with the VPN subsystem most of the links that I come across say just restart the VPN subsystem and life returns. This does not fix the problem I get with this error, which comes usually after a OS update.

The fix for me is to completely uninstall the Cisco VPN application, which is actually a command-line activity. All you have to do is run /usr/local/bin/vpn_uninstall as root (sudo). This does the full uninstall, and then you can re-install the application and life should return. If you just update the software in place, the error does not go away.

So there, at least I know I can find out what to do next time I have to jump through this hoop.

-c

What you see here is a contraption I put together with a little post-dinner tinkering. I swear there is nothing you can’t accomplish with $10 at Lowe’s and some zip ties. My previous sparge arm was a pre-bought POS that fell a far cry from serviceable. My hope is that this one does a bit better and I’m not forced into building a rotating copper doohickey thing-a-ma-bob, despite how much fun that sounds. I’d rather just get on with the brew.

Speaking of, I have Squatter’s Hop Rising waiting for me! On with the show then.

-c