I wanted to get this. We'll call it option A:
[User]-----HTTPS over Internet----->[Single Login Proxy]----HTTP------>[Web Applications At Home]
It is also trivial then to set up this (Option B) since it only requires the removal of some configuration (comment out the A-only sections labeled in the config files) and then configuring each individual application with a password:
[User]-----HTTPS over Internet----->[No Login Proxy]----HTTP------>[Web Applications At Home]
<VirtualHost *:80> ServerName www.mywwwdomain.com Redirect permanent / https://www.mywwwdomain.com/ </VirtualHost> <VirtualHost _default_:443> ServerName www.mywwwdomain.com SSLEngine on SSLProxyEngine On RequestHeader set Front-End-Https "On" ProxyPreserveHost On RewriteEngine on CacheDisable * SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL SSLCertificateFile /local/path/to/certfile.cert SSLCertificateKeyFile /local/path/to/certkey.key ProxyRequests Off ProxyPreserveHost off DocumentRoot /var/www <Directory /> ############ OPTION A ONLY################## AuthType Basic AuthName "My Homebrew Gateway" AuthUserFile /etc/apache2/passwords Require user your_login(s)_go_here ############# END OPTION A ONLY############# SSLRequireSSL SSLRequire %{HTTP_HOST} eq "www.mywwwdomain.com" SSLOptions +FakeBasicAuth +StrictRequire SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128 ErrorDocument 403 https://www.mywwwdomain.com Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> ############ OPTION A ONLY################## AuthType Basic AuthName "My Homebrew Gateway" AuthUserFile /etc/apache2/passwords Require user your_login(s)_go_here ############# END OPTION A ONLY############# SSLRequireSSL SSLRequire %{HTTP_HOST} eq "www.mywwwdomain.com" SSLOptions +FakeBasicAuth +StrictRequire SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128 ErrorDocument 403 https://www.mywwwdomain.com Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all </Directory> <Location /sab> ProxyPass http://localhost:8080 ProxyPassReverse http://localhost:8080 </Location> <Location /couchpotato/> ProxyPass http://localhost:8084/couchpotato/ ProxyPassReverse http://localhost:8084/couchpotato/ </Location> <Location /subsonic> ProxyPass http://localhost:4040/subsonic ProxyPassReverse http://localhost:4040/subsonic </Location> <Location /sickbeard/> ProxyPass http://localhost:8081/sickbeard/ ProxyPassReverse http://localhost:8081/sickbeard/ </Location> <Location /manage> ProxyPass http://localhost:32400/manage/ ProxyPassReverse http://localhost:32400/manage/ </Location> RewriteEngine on RewriteOptions inherit </VirtualHost>Then set your /etc/apache2/httpd.conf file up like the following:
ServerName www.mywwwdomain.com <Proxy *> Order deny,allow Allow from all ############ Option A Only ################### AuthType Basic AuthName "My Homebrew Gateway" AuthUserFile /etc/apache2/passwords Require user your_login(s)_go_here ############ End Option A Only ################# SSLRequireSSL SSLRequire %{HTTP_HOST} eq "www.mywwwdomain.com" SSLOptions +FakeBasicAuth +StrictRequire SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128 ErrorDocument 403 https://www.mywwwdomain.com </Proxy>
After you have these files in place remove /etc/apache2/sites-enabled/000-default and from within /etc/apache2/sites-enabled run ln -s ../sites-available/proxy to make a softlink to the proxy site configuration file we just made.
To review the files we just made:
The "option A only" sections deal with basic auth using passwords. In order to have passwords you will also need to create a password file containing your login/password info using the htpasswd command. In the example provided, the passwords are stored in /etc/apache2/passwords and you could set this up with htpasswd -c /etc/apache2/passwords your_login. It will then prompt you for the password. If you want to enforce use hashed passwords there is an htpasswd option for that. Basic auth is perfectly secure when used behind SSL encryption as is anything tunneled through an encrypted protocol. So if anyone tells you different, punch them in the groin and scream like a rabid hyena.
The SSL options ensure https is enforced at specific locations and in general. The httpd.conf file generally applies these settings, but I wanted to be super-sure that we are getting SSL on the auth in a few places where it didn't happen with the httpd.conf alone.
You should replace www.mywwwdomain.com with your actual internet-accessible domain. Also, you should replace the your_login(s)_go_here with your actual login names as set up in your htpasswd created file. There is a "Require group" directive if you want to use that instead.
In the location sections, the references to localhost are because these different applications are all hosted on various ports of the same machine that is acting as the reverse proxy. If you have your apps on a different machine in your local network, replace localhost with the local static ip address (e.g. 192.168.0.x) for that server.
The location sections set domain subdirectories that proxy to the port numbers transparently. The reason for doing this instead of something like sickbeard.mywwwdomain.com is because the cheap SSL certs are only licensed to www.mywwwdomain.com and can't do wildcards to match each subdomain. If you want to drop hundreds of dollars a year on a wildcard cert, knock yourself out. The method I used lets one cert work for unlimited applications. Check that your own port numbers are used in the configuration. Most of mine are probably not the defaults for these apps.
Lastly, we also set up a redirect here so that traffic coming to mywwwdomain.com will get sent to https://www.mywwdomain.com. From there they may be asked to login (if using option A) and then sent to the landing page. Also, it is important to know that each subdomain also requires authentication on the proxy if you go straight to them instead of the main landing page which we will make later, but once you are logged in it will not ask again until your browser is restarted. This Option A authentication is really neat if you are only accessing things on the web, but it can hinder any third party applications you might want to use. If using webapp-specific phone apps for instance, they will not understand the auth popup. In those cases, omit or comment out the option a authentication and just turn on passwords on each individual app. The proxy will still handle SSL for everything so you don't need it on each individual webapp.
None of this is going to work yet. And we don't want it to yet. First we need to do some app configuration. Here is the rundown:
Sickbeard will need extra configuration. Stop sickbeard from running. If you have a service setup for it this is as easy as service sickbeard stop. Then edit sickbeard's config.ini file and set web_root = /sickbeard with no quotes. Then start sickbeard back up again.
Sab is already ready.
Couchpotato (V2) needs extra configuration. If you are not using V2, you are on your own. It is what I used and I am not going to muck with an older version for your benefit. Go to settings, check advanced, in general enter "couchpotato" in the Url Base field. Then restart it.
Subsonic requires additional configuration as well. Turn subsonic off service subsonic stop. Open up /usr/bin/subsonic (it is a script not a bin file) and set "SUBSONIC_CONTEXT_PATH=/subsonic". Turn subsonic back on service subsonic start. Note that you can't get rid of the login on subsonic.
You might not care about these last two since the above are the big four, but in case you do they are in there. Of course, comment out any of the location sections in your proxy configuration file for apps you aren't using.
Plex will work out of the box with the configuration I gave you and it using its default port.
EXtplorer is a web-based file manager. If you have it configured, it will work with a proxy out of the box. As far as deploying it though, if you don't already have it setup, DO NOT USE THE DEBIAN PACKAGE FOR IT!!!! Don't do it!! It will mess up apache and steel port 80 from it, and there is no documentation on how to configure or use the packaged form of it at this point. Download the normal zip file for it, and follow this guy's guide. Chmod the whole extplorer unzipped directory with 777 recursively chmod -R 777 extplorer and then chmod the .htusers.php file with the devil's number (666) like he said. Also ensure you jack up the upload size and post size to something you can live with. When you are done with his guide, go and softlink your /extplorer directory from within /var/www using ln -s /path/to/extplorer extplorer. When you log into it with admin/admin the first time (after we fire up apache) you will also want to change the root directory to something more useful like /mnt or /media (or / if you are bold) depending on what you want to see.
Finally, you need to fire apache up service apache2 restart. When you do this, you will see some errors about modules or something telling you to go to the error log /var/logs/apache/error.log. You will need to use a2enmod to load the modules you need enabled. When you run it, it will give you a list of what you can turn on. Turn on the ones it is bitching about and then try to restart apache again. Eventually it will stop bitching and everything will work if you get the right modules turned on. You will also probably need to configure the apache init script to restart on reboot with update-rc.d apache2 enable.
Finishing Touches:
We already set up a webroot so you can alter the html files in there and make your own custom landing page at /var/www/index.html. I highly recommend this instead of having to remember all your subdirectories as your setup grows. My landing page looks like this:
It is just a bunch of logos (stored in /var/www) linked with relative paths to the various apps. So use an href="/sickbeard/" as the link for example.
Final thoughts:
If Jerry Springer can have them, so can I. A nice improvement would be to allow you to access this on your local network without having your traffic redirected to the authentication/ssl domain when you type your.local.proxy.ip/appname/. It really shouldn't be hard to configure, but I sunk so much time into this I really don't want to mess with it at the moment. My simple workaround is to add local links to your landing page that use your.local.proxy.ip:app_specific_portnum to access each thing and you will need to append the directory in addition to the port number for some of them. Here are the ones I needed for my specific port setup 8081/sickbeard, 4040/subsonic, 32400/manage (plex). The rest worked already. You won't have to authenticate when using these local addresses, but they aren't accessible to the outside world this way since you are only forwarding ports 80 and 443. Extplorer is running in apache, so it cannot be worked around like this. That is fine for me at home since my server serves up files with NFS/SMB locally and that is a much more integrated solution for your local systems anyway.
Also, I spared you the hassle of setting up SSL on each individual app. Not that it is difficult for most of those that can do it, but couchpotato (for example) cannot and it is nice to get zero-configuration SSL on each app you add down the road especially when the app didn't even offer it.
Subsonic is very painful to setup with SSL directly because it uses utterly retarded java keystores that require converting your ssl cert into a pkcs12 type and then running it through some retarded java keystore importer app with a load of retarded flags and retarded options to generate a retarded file that retarded java can retardedly accept. Then you have to stick options in /usr/bin/subsonic to tell it about that file and how to access it.
Lastly, I expect some smart ass to say, "Hey, Mr. Sheez. I noticed that the auth pops up before my browser says it is encrypted https." Really punk? Does it? No, not really. Your browser might make it look like the authentication is going to happen in plain text. However, intercept your traffic like a grown-ass man and you'll see that nothing is being sent in non-encrypted http. If it is, I'll eat my hat. If not, you'll eat my hat.
Do let me know if anything legitimately needs correction or updating. If you need clarification on anything I covered, then let me know in the comments. Don't ask me some random apache question about an unrelated setup because you are too lazy to look it up. I am not an apache guru in general. I figured all this out through sheer force of will and shared it out of some twisted sense of altruism toward the reddit usenet community. Anyway, have fun with this info mateys.