emHTTP port control, default port and SSL

[NAS]

The days where emHTTP is the only web server in unRAID are long gone. Really emHTTP, since it is a control interface and not a general network user interface, should be on an oddball high port and not 80. We should also use self signed SSL by default.

 

Since nont of this is hard it would be nice to get this into v6.0 so it becomes the new norm.

[itimpi]

The days where emHTTP is the only web server in unRAID are long gone. Really emHTTP, since it is a control interface and not a general network user interface, should be on an oddball high port and not 80.

I disagree.  For most people the GUI is the only web server running on unRAID so defaulting it to port 80 makes sense as the average user then does not need to specify the port.    For those knowledgeable enough to run another web server it is trivial to move emHTTP to another port by editing the 'go' file to specify the port in the command that launches emHTTP.

[NAS]

The days where emHTTP is the only web server in unRAID are long gone. Really emHTTP, since it is a control interface and not a general network user interface, should be on an oddball high port and not 80.

I disagree.  For most people the GUI is the only web server running on unRAID so defaulting it to port 80 makes sense as the average user then does not need to specify the port.    For those knowledgeable enough to run another web server it is trivial to move emHTTP to another port by editing the 'go' file to specify the port in the command that launches emHTTP.

 

I disagree. v6 will have skill less addons in the form of dockers most of which currently have web interfaces. These apps should be what users see not the admin level control GUI which should be moved away from what anyone will find by default. This is in fact what most serious devices do that present multiple services like we plan to. I would suggest ssl on port 8443 by default.

 

Modifying the go file manually should be discouraged and is not for general consumption although I agree it is easy it would be a kludge.

 

Edit: I suppose its a difference in philosophy. My point is that there will be more consumers of web services post v6 that are general users (i.e. family etc) than there will be admins. If a general user is told that say a subsonic server is on http://server:1234 they should not be presented with the admin interface to the server if they omit the port by mistake or intentionally. On the other hand the admin will be far less likely to make this mistake and even if they do the consequences are zero.

[itimpi]

I think we will have to agree to disagree on this!

 

When using dockers (which I expect will NOT actually be the majority of users) if the dockers have web management pages then each docker needs to use a different port.  This means that an unRAID set up like this will have multiple 'management pages' - one for each docker to be managed.  I still think therefore that the default for the GUI should be unRAID itself - not an arbitrary docker that the admin user selected to be on port 80.  If you want end-users to access the web pages associated with particular docker containers why not set them up shortcuts with the required port already preset.

 

Moving away from http to https for admin would not be unreasonable.  However even this would fool some users who are increasingly getting used to entering web pages without the leading http:/https: part as most modern browsers auto-fill in the http: part if missing.

 

One solution that might meet both needs is a way to have a front page  on port 80 that provides links to the other services that are available on this particular unRAID system.  It might be possible to get most of these links auto-generated when adding docker containers if the dockerman plugin is clever enough.

[NAS]

I think we will have to agree to disagree on this!

 

When using dockers (which I expect will NOT actually be the majority of users)

I can see why this request would seem pointless given this assumption. I still think I am right based on the popularity of addons on every off the shelf app but I suppose time will tell.

 

 

Moving away from http to https for admin would not be unreasonable.  However even this would fool some users who are increasingly getting used to entering web pages without the leading http:/https: part as most modern browsers auto-fill in the http: part if missing.

Yeah I am sure we could educate users its not rocket science.

 

One solution that might meet both needs is a way to have a front page  on port 80 that provides links to the other services that are available on this particular unRAID system.  It might be possible to get most of these links auto-generated when adding docker containers if the dockerman plugin is clever enough.

It is interesting you suggest this as I was thinking the same thing. Its not a trivial solution as it requires some interaction with docker config but with something as simple as nginx reverse proxy you could stop users having to remember ports at all and everything would be http(s)://server/. From a non skilled user point of view this would be a big boost and you could then inherit a single ssl cert and the security features of nginx for all web based GUIs and add a second level of access security to the emHTTP. Also form a port scan only one port would be open as all the other ports would be loopback only.

 

[WeeboTech]

One solution that might meet both needs is a way to have a front page  on port 80 that provides links to the other services that are available on this particular unRAID system.  It might be possible to get most of these links auto-generated when adding docker containers if the dockerman plugin is clever enough.

It is interesting you suggest this as I was thinking the same thing. Its not a trivial solution as it requires some interaction with docker config but with something as simple as nginx reverse proxy you could stop users having to remember ports at all and everything would be http(s)://server/. From a non skilled user point of view this would be a big boost and you could then inherit a single ssl cert and the security features of nginx for all web based GUIs and add a second level of access security to the emHTTP. Also form a port scan only one port would be open as all the other ports would be loopback only.

 

This is a great idea. I do this for some of our internal administrative servers.

The base http server on port 80 will redirect to the other ports, urls and sometimes other hosts.

I also do something with https 1.1 and hostnames to do the redirection automatically.

 

This way multiple hostnames accessing the same host, get redirected to the respective urls/ports.

[Zuhkov]

One solution that might meet both needs is a way to have a front page  on port 80 that provides links to the other services that are available on this particular unRAID system.  It might be possible to get most of these links auto-generated when adding docker containers if the dockerman plugin is clever enough.

It is interesting you suggest this as I was thinking the same thing. Its not a trivial solution as it requires some interaction with docker config but with something as simple as nginx reverse proxy you could stop users having to remember ports at all and everything would be http(s)://server/. From a non skilled user point of view this would be a big boost and you could then inherit a single ssl cert and the security features of nginx for all web based GUIs and add a second level of access security to the emHTTP. Also form a port scan only one port would be open as all the other ports would be loopback only.

 

This is a great idea. I do this for some of our internal administrative servers.

The base http server on port 80 will redirect to the other ports, urls and sometimes other hosts.

I also do something with https 1.1 and hostnames to do the redirection automatically.

 

This way multiple hostnames accessing the same host, get redirected to the respective urls/ports.

 

Was just going to suggest this and I agree that it's an excellent idea. I use Nginx both as a reverse proxy and for SSL termination for everything I serve out of my home network (except Plex for the moment). It allows me to setup things like Perfect Forward Secrecy once and then slap that in front of all my applications. Very convenient and inexpensive additional layer of security. I never need to remember what port a service is on. For the paranoid, there could even be the option to add Naxsi, a fairly simple (though still immature) WAF for Nginx. The trick is in keeping the configuration of it all simple enough for the users, but I'd be willing to bet on the ingenuity of this community.

[JonathanM]

I currently use dmacias' Apache plugin to do exactly what you are talking about with nginx. I have a password protected https://tower link that goes to a static table of contents page with the contents of the links opening in a frame. It took me a few minutes to set up, but it's not that complex, and could be generated on the fly, with easy customization. I expose that specific URL with port forwarding, and I have a world accessible password protected SSL link to all my various services, sick, sab, couch, subsonic, phpvirtualbox, minecraft, etc.

 

All this is on currently available plugins, but I don't use dockers yet.

[NAS]

...

This way multiple hostnames accessing the same host, get redirected to the respective urls/ports.

 

That is a nice tweak and potentially gives us a very user friendly way to do this. So something like http:/tower/ and http://tower-admin/

 

[Zuhkov]

That is a nice tweak and potentially gives us a very user friendly way to do this. So something like http:/tower/ and http://tower-admin/

 

I would think you want something that would allow the most straightforward addition of SSL by retaining a common hostname or domain root. If you are using a single domain cert (self-signed or 3rd party), then you could do https://tower/admin and https://tower/unifi with one passing through to emhttp and the other going to a unifi docker. Alternatively with a wildcard cert, you could have https://admin.tower and https://unifi.tower. I find that a little cleaner, but the DNS configuration is potentially a little more complicated. Would be nice to be able to configure internal (limited/private subnets) vs. external visibility on a per service/application basis.

[NAS]

So there are a few ideas in here that potentially get us somewhere that is acceptable by both the "hide admin form users" and "show admin to users" camps.

 

I didnt however expect there to be so many variations  or push back so there's no way this is happening for v6 and as such will leave open for later discussion.

[Fireball3]

This seems a good opportunity to place my wish once again:

I'd like to see an unprotected unRAID starting page that will show basic (content maybe configurable) stats of the array. It's pretty cumbersome to always log in just to check the status of unRAID.

Perhaps one day there will be an android-app or a windows widget to have this information at hand without even opening the browser (provisioning for an appropriate interface)?