SageTV Web + SSL + Reverse Proxy (Any interest?) (unRAID only)

[stuckless]

I've done this a couple times, now, where I'm using the "Let's Encyrpt" docker app (in unRAID), and it gets a free, and valid, ssl certificate for my server, and then I'm using it's configuration to reverse proxy my SageTV server.

The process is fairly simple, but not sure if anyone is interested in doing the same. I can try to find some time to document the steps, if there's interest.

I'm using duckdns to get a free "dyn dns" host that points to my home home router, and Let's encrypt, can work with those types of dynamic dns setups. The end result is that when I now go to my home server I get the "green" ssl secure enabled icon in the browser, since the certificates are valid.

EDIT: Here's a guide on using unRAID's Let's Encrypt containter and reverse proxying SageTV

https://github.com/stuckless/sagetv-...verse_Proxy.md

[alfi33]

Great timing! I already use the LetsEncrypt Docker to get to Home Assistant running in a Docker and today I just started experimenting with it with Sage.

How are you doing username/password? Are you using the htpasswd password config in nginx or just the Sage web interface username/password (or something else)?

I think my preference would probably be to just use the htpasswd password config in nginx (and not have a password on the Sage web interface when accessed from my LAN) but I haven't found a way to remove password protection from the Sage web interface.

[KarylFStein]

Originally Posted by stuckless

I've done this a couple times, now, where I'm using the "Let's Encyrpt" docker app (in unRAID), and it gets a free, and valid, ssl certificate for my server, and then I'm using it's configuration to reverse proxy my SageTV server.

The process is fairly simple, but not sure if anyone is interested in doing the same. I can try to find some time to document the steps, if there's interest.

I'm using duckdns to get a free "dyn dns" host that points to my home home router, and Let's encrypt, can work with those types of dynamic dns setups. The end result is that when I now go to my home server I get the "green" ssl secure enabled icon in the browser, since the certificates are valid.

+100 YES! I think that it's important to have SSL even on the LAN and anything that makes it easy and recommended for people is good. This should be the default method for any communication including the mini client and sagex. If you don't believe me go to DEF CON and see how long it takes for your login to show up on the Wall of Sheep! That is maybe an extreme environment, but it shows what is possible in the real world.

I've used SSL in Jetty for years on my own dime, (and earlier with my own CA), but once Let's Encrypt came out I've been using it. I actually tried the Nginx/Let's Encrypt Docker this weekend as I am looking at moving to unRAID, but it was just not for me. While the Docker allows for subdomains I have multiple domains AND Nginx is one of the few things that I want fail-over for meaning Pacemaker/Heartbeat with a virtual IP which I do not see any way to do in an unRAID/Docker setup. So, Nginx along with dnsmasq and OpenVPN are in VMs.

(Note that the future 6.4 release of unRAID is supposed to have an overhaul of the HTTP GUI which supports SSL.)

Originally Posted by alfi33

Great timing! I already use the LetsEncrypt Docker to get to Home Assistant running in a Docker and today I just started experimenting with it with Sage.

How are you doing username/password? Are you using the htpasswd password config in nginx or just the Sage web interface username/password (or something else)?

I think my preference would probably be to just use the htpasswd password config in nginx (and not have a password on the Sage web interface when accessed from my LAN) but I haven't found a way to remove password protection from the Sage web interface.

Note that Nginx allows you to pass basic authentication so you could put a rule in that does it for you if on the LAN and otherwise requires a login, (which could be an Nginx one with fail2ban protection). Personally I use SSL even on my LAN, but Let's Encrypt it makes it more of a pain to do certificates and keep them current if you do not have a way to automatically update them. Plus browsers like Chrome are flagging certificates with a lifetime of over a certain time period as unsafe even if you trust the CA. My next test is to use Nginx + Let's Encrypt as an SSL termination point for everything and have it connect on the back-end over SSL ignoring certificate lifetimes.

[wayner]

Yes, please document.

[wayner]

Originally Posted by KarylFStein

... I think that it's important to have SSL even on the LAN...

Why is this?

[stuckless]

OK... this week I'll try to write up a simple guide on the steps that I used to set this up. There were some pitfalls that I hit along the way, so, I think having it documented would be good.

Originally Posted by alfi33

How are you doing username/password? Are you using the htpasswd password config in nginx or just the Sage web interface username/password (or something else)?

Currently, because I wanted to test it out, I'm using the .htpasswd method and the sagetv authentication (so it prompts twice). Since I can't remove the authentication from Sage, I'll likely just configure the sagetv paths in nginx to not use authentication and simply rely on the built in authentication in sagetv.

I currently working on a complete overhaul of the web server in sagetv... been doing so for many months (a few hours here and there), and I'll definitely look at being able to disable the auth requirements on the web server. Personally, I'd rather let nginx do it, and like you, only require it when you coming from the internet, over ssl.

Originally Posted by KarylFStein

+100 YES! I think that it's important to have SSL even on the LAN and anything that makes it easy and recommended for people is good. This should be the default method for any communication including the mini client and sagex. If you don't believe me go to DEF CON and see how long it takes for your login to show up on the Wall of Sheep! That is maybe an extreme environment, but it shows what is possible in the real world.

I've used SSL in Jetty for years on my own dime, (and earlier with my own CA), but once Let's Encrypt came out I've been using it. I actually tried the Nginx/Let's Encrypt Docker this weekend as I am looking at moving to unRAID, but it was just not for me. While the Docker allows for subdomains I have multiple domains AND Nginx is one of the few things that I want fail-over for meaning Pacemaker/Heartbeat with a virtual IP which I do not see any way to do in an unRAID/Docker setup. So, Nginx along with dnsmasq and OpenVPN are in VMs.

(Note that the future 6.4 release of unRAID is supposed to have an overhaul of the HTTP GUI which supports SSL.)



Note that Nginx allows you to pass basic authentication so you could put a rule in that does it for you if on the LAN and otherwise requires a login, (which could be an Nginx one with fail2ban protection). Personally I use SSL even on my LAN, but Let's Encrypt it makes it more of a pain to do certificates and keep them current if you do not have a way to automatically update them. Plus browsers like Chrome are flagging certificates with a lifetime of over a certain time period as unsafe even if you trust the CA. My next test is to use Nginx + Let's Encrypt as an SSL termination point for everything and have it connect on the back-end over SSL ignoring certificate lifetimes.

BTW, I think the MiniClient uses encryption by default (it's not "ssl" since it doesn't run over http sockets), but, the miniclient does have encryption. Now, whether or not it's being used, is another story... I haven't verified it, but I did encryption in the code, even when I was doing the Android MiniClient.

I do think the "Let's Encrypt" container is good for 90% of people with minimal requirements. I first used it for my brother's business. I had setup an unRAID server for him, then we wanted FTP access for clients, so I setup CrushFTP, and then he complained that the "SSL" was unsafe, so I set up Let's Encrypt... I really love the versatility of unRAID (but that's another post/story).

After setting it up for him, I decided to do it for myself. I have zero experience with nginx, but I figured it out. Once you figure out the reverse proxy stuff, which is just a couple of lines of configuration, it becomes easy to repeat that for other paths on your network.

I'm not much of an IT person and I hate spending time maintaining stuff... so the "Let's Encrypt" container fits the bill perfectly for me.

I'll try to write up the details steps for this in the new few days.

[KarylFStein]

Originally Posted by wayner

Why is this?

My background is security. We're a paranoid bunch of folks :).

Originally Posted by stuckless

Currently, because I wanted to test it out, I'm using the .htpasswd method and the sagetv authentication (so it prompts twice). Since I can't remove the authentication from Sage, I'll likely just configure the sagetv paths in nginx to not use authentication and simply rely on the built in authentication in sagetv.

Nginx can be configured to handle HTTP basic authentication, (see http://shairosenfeld.blogspot.com/search?q=nginx), or I imagine (not tried) you can just put it in the URL string e.g. http://user:pass@IP:port.

The Nginx Docker for unRAID also includes fail2ban.

[stuckless]

Originally Posted by KarylFStein

My background is security. We're a paranoid bunch of folks .



Nginx can be configured to handle HTTP basic authentication, (see http://shairosenfeld.blogspot.com/search?q=nginx), or I imagine (not tried) you can just put it in the URL string e.g. http://userass@IPort.

The Nginx Docker for unRAID also includes fail2ban.

I see... I could set the Authorization header in the proxy config, something like this..

proxy_set_header Authorization "Basic a2luZzppc25ha2Vk";

That's clever.

[wayner]

I am trying to get Reverse Proxying working on Apache to allow me access to my SageTV server(s) and other web content over a regular connection on port 80. This should allow me to access these sites even when a network (like your work network, etc) blocks most/all ports other than 80.

I am able to get through to the home page but I appear to be having problems getting the menus for the SageTV web UI to show up and accessing child pages and I think this has something to do with relative paths.

What I want to do is something like this - when you go to htt://myserver/sage1 it would redirect you to 192.168.1.99:7070 and then it would also redirect all relative paths, such as htt://myserver/sage1/sage/RecordingSchedule to 192.168.1.99:7070/sage/RecordingSchedule. (Note I left out the p in htt so it doesn't create automatic links.)

Does anyone know how to do this? Do I have to put in ProxyPass and ReverseProxyPass for all relative paths like /sage, etc?

[Taddeusz]

I had this trouble with Nginx. I had to point the virtual path /sage directly to Jetty's /sage path. Not the root path of my SageTV's Jetty. The reason is that many of the paths in the SageTV UI are static, not relative, and there's nothing we can do about that.

[wayner]

Ok, I have it working better with the following in my config.

ProxyPass /sage1 http://192.168.1.99:7070
ProxyPassReverse /sage1 http://192.168.1.99:7070

ProxyPass /sage http://192.168.1.99:7070/sage
ProxyPassReverse /sage http://192.168.1.99:7070/sage

ProxyPass /sage1/sage http://192.168.1.99:7070/sage
ProxyPassReverse /sage1/sage http://192.168.1.99:7070/sage

The problem is that I can't do this to allow access to multiple sage servers since the second set of commands will send all references to /sage to my 192.168.1.99 server.

[stuckless]

Here's a quick guide... Hopefully it's thorough enough for people to follow.

https://github.com/stuckless/sagetv-...verse_Proxy.md

[wayner]

Thanks Sean - that's awesome.

One question - as a slight change to your methodology is there a risk in just setting your Sage web page to not require a user and password? Won't nginx stop anyone from outside your LAN - and I don't really care about authentication if the web access is coming from inside my LAN. Or am I missing something?

In addition, there is a driver for my Control4 HA system for Sage but it only works if you have no user/pass set for Sage.

I was also able to set this up to be able to access two Sage servers on my LAN with the following in my config file:

	location ^~ /sage {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.99:7070/sage;
	}
	location ^~ /sage2 {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.92:8080/sage;
	}

[stuckless]

Originally Posted by wayner

Thanks Sean - that's awesome.

One question - as a slight change to your methodology is there a risk in just setting your Sage web page to not require a user and password? Won't nginx stop anyone from outside your LAN - and I don't really care about authentication if the web access is coming from inside my LAN. Or am I missing something?

In addition, there is a driver for my Control4 HA system for Sage but it only works if you have no user/pass set for Sage.

I was also able to set this up to be able to access two Sage servers on my LAN with the following in my config file:

	location ^~ /sage {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.99:7070/sage;
	}
	location ^~ /sage2 {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.92:8080/sage;
	}

To be honest... I'm not aware that you can tell Jetty to NOT require authenication in the setup that exists in SageTV today. If you could, then, sure, you can turn it off, if you are OK with people on the local network having full access (personally, I'd be ok with that). Connections from the internet will still require a username and password.

Also, you can reverse proxy the unRAID admin UI in the same manner, if you did want to expose it. I haven't done that myself... but I'm considering it... especially since the only time SageTV dies on my is when I travel, and using the unRAID UI I can easily restart it

[KarylFStein]

You can also add location rules so Nginx will not prompt for a password on the LAN. I haven't done this, but I think you could do something like add the following to the location block, (using your own LAN subnet range of course):

   satisfy any;
   allow 192.168.1.0/24;
   allow 127.0.0.1;
   deny all;

[wayner]

You may be right - I tried to put in a blank user and password in the Sage UI and it didn't seem to work.

I have OpenVPN running on my router so that is how I would access my machine while travelling as my system is like yours - it only goes down when I am travelling. You might want to try that - you seem to have an Asus router and the Merlin firmware for Asus has OpenVPN server. Or you can run OpenVPN server in a docker

How would you do the config for nginx to reverse proxy other dockers that don't use a /dockername folder? For example, my Unifi controller docker just runs at 192.168.1.99:8443. How would I do the mapping for that?

[stuckless]

Originally Posted by wayner

You may be right - I tried to put in a blank user and password in the Sage UI and it didn't seem to work.

I have OpenVPN running on my router so that is how I would access my machine while travelling as my system is like yours - it only goes down when I am travelling. You might want to try that - you seem to have an Asus router and the Merlin firmware for Asus has OpenVPN server. Or you can run OpenVPN server in a docker

How would you do the config for nginx to reverse proxy other dockers that don't use a /dockername folder? For example, my Unifi controller docker just runs at 192.168.1.99:8443. How would I do the mapping for that?

I would think (and I haven't verified this)... but you could simply do something like...

location ^~ /unifi {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.1.92:8443/;
	}

ie, this is similar to how you mapped /sage2/ to route to /sage/

[wayner]

That doesn't appear to work, but I will play around with it again tonight.

I was able to get it working properly for my rutorrent docker but I had to change the rutorrent/nginx config so that rutorrent is now located at http://tower:7777/rutorrent rather than http://tower:7777. It looks like this reverse proxying doesn't work as well when you want to hit the root path, or at least it takes a little more configuring if it does.

Similary I was able to get my Plex docker to work as a reverse proxy but I had to use the rather generic path of web as in http://tower:32400/web

And my sage2 doesn't totally work. Some of the links seem to be absolute so they still go to /sage as was mentioned by Taddeusz. So it is kind of weird that you can think you are looking at the WebUI for Server2 but when you click on a link you are actually operating on a file on Server1.

For example if I go to https://tower/sage2 it still takes me to Server1. But if I use https://tower/sage2/Home then I get to Server2. But some of the links at that page, such as the link for Upcoming recordings and all of the links for the menu bar, still map back to /sage. But other links, like the link for the UI Context under Currently Watching, or the detailed info for shows that are currently recorded or that are soon to be recorded, map to Sage2.

This reverse proxying is very useful for being able to access web sites where you can only hit basic ports like 443 or 80, but it seems like you are still much better off running VPN if you can. But you often can't do that - like when you are at work.

I wonder if all of this stuff will work better in the IPv6 world where every device has an "external" IP address and you can use port 80 or 443 for everything, you don't have to jerk around with using all of these different ports for different applications.

With unRAID it would be nice if you could create virtual IPs for every docker (isn't that what you do in a VM?) rather than having to map a couple of ports for every docker and you hope that you don't use the same port for multiple dockers, especially since not all of the ports you have used show up in that list when you are setting up a new docker.

[stuckless]

Originally Posted by wayner

That doesn't appear to work, but I will play around with it again tonight.

I was able to get it working properly for my rutorrent docker but I had to change the rutorrent/nginx config so that rutorrent is now located at http://tower:7777/rutorrent rather than http://tower:7777. It looks like this reverse proxying doesn't work as well when you want to hit the root path, or at least it takes a little more configuring if it does.

Similary I was able to get my Plex docker to work as a reverse proxy but I had to use the rather generic path of web as in http://tower:32400/web

And my sage2 doesn't totally work. Some of the links seem to be absolute so they still go to /sage as was mentioned by Taddeusz. So it is kind of weird that you can think you are looking at the WebUI for Server2 but when you click on a link you are actually operating on a file on Server1.

For example if I go to https://tower/sage2 it still takes me to Server1. But if I use https://tower/sage2/Home then I get to Server2. But some of the links at that page, such as the link for Upcoming recordings and all of the links for the menu bar, still map back to /sage. But other links, like the link for the UI Context under Currently Watching, or the detailed info for shows that are currently recorded or that are soon to be recorded, map to Sage2.

This reverse proxying is very useful for being able to access web sites where you can only hit basic ports like 443 or 80, but it seems like you are still much better off running VPN if you can. But you often can't do that - like when you are at work.

I wonder if all of this stuff will work better in the IPv6 world where every device has an "external" IP address and you can use port 80 or 443 for everything, you don't have to jerk around with using all of these different ports for different applications.

I would look at the sub_filter part of this stackoverflow answer... I think that's the key to having the response rewriten to account for the fact that the Jetty server does fully paths in the URLs. (You just need to know the actual hostort that the response is sending, and rewrite it...

https://stackoverflow.com/a/32543398/614231

With unRAID it would be nice if you could create virtual IPs for every docker (isn't that what you do in a VM?) rather than having to map a couple of ports for every docker and you hope that you don't use the same port for multiple dockers, especially since not all of the ports you have used show up in that list when you are setting up a new docker.

Docker is meant to be a very lightweight container, so, it's shares lots of resources with the host. I think if you need more conrtol over networking, etc, you might need a heavyweight container, like a VM.

That being said, you can likely create multiple docker virtual interfaces... but not sure you can do that on the unraid environment... it tries to shield your pretty well from most docker things.

[KarylFStein]

Originally Posted by wayner

That doesn't appear to work, but I will play around with it again tonight.

I was able to get it working properly for my rutorrent docker but I had to change the rutorrent/nginx config so that rutorrent is now located at http://tower:7777/rutorrent rather than http://tower:7777. It looks like this reverse proxying doesn't work as well when you want to hit the root path, or at least it takes a little more configuring if it does.

Similary I was able to get my Plex docker to work as a reverse proxy but I had to use the rather generic path of web as in http://tower:32400/web

And my sage2 doesn't totally work. Some of the links seem to be absolute so they still go to /sage as was mentioned by Taddeusz. So it is kind of weird that you can think you are looking at the WebUI for Server2 but when you click on a link you are actually operating on a file on Server1.

For example if I go to https://tower/sage2 it still takes me to Server1. But if I use https://tower/sage2/Home then I get to Server2. But some of the links at that page, such as the link for Upcoming recordings and all of the links for the menu bar, still map back to /sage. But other links, like the link for the UI Context under Currently Watching, or the detailed info for shows that are currently recorded or that are soon to be recorded, map to Sage2.

This reverse proxying is very useful for being able to access web sites where you can only hit basic ports like 443 or 80, but it seems like you are still much better off running VPN if you can. But you often can't do that - like when you are at work.

I wonder if all of this stuff will work better in the IPv6 world where every device has an "external" IP address and you can use port 80 or 443 for everything, you don't have to jerk around with using all of these different ports for different applications.

With unRAID it would be nice if you could create virtual IPs for every docker (isn't that what you do in a VM?) rather than having to map a couple of ports for every docker and you hope that you don't use the same port for multiple dockers, especially since not all of the ports you have used show up in that list when you are setting up a new docker.

I don't have a lot of time with Nginx under my belt and not somewhere I can test, but I think you want something like "location /unifi/ {" (trailing slash). If you also have a trailing slash on your proxy_pass line I believe it will strip /unifi/ from the URL string.

I haven't played with Sage web through Nginx yet, but in the past I've used rewrite rules in IIS to change the URL strings in responses. I'd be surprised if Nginx doesn't have something similar.

You might want to look at the Pipework docker for assigning a VIP to a docker container. Note that I haven't used this yet either. I'm still very early on in figuring out how to migrate all my configurations/capabilities to unRAID and the best way to do that...