Rockstor behind reverse-proxy (nginx)

Hi Everyone.

Not sure this is a Rockstor-thing per se but figured I’d ask.

I’ve installed the SWAG docker container and rebound the Rockstor UI to a non-standard SSL port. I can reach the UI and it works fine by using the IP address and it works just fine when “exposed” to the Internet (which is why I’m going with SWAG.)

SWAG is just a nginx instance listening on 80/443 and handles LetsEncrypt and includes fail2ban. For me, it’s a two-for and a good fit. It also functions as a reverse-proxy and has several canned configs for various apps (such as portainer, for example.) For Rockstor I’ll need to create a custom one which I did for Nodered but I’m getting nowhere fast.

SWAG does have a requirement that services need to be on the same docker network, obviously Rockstor is not but I can reach the UI but things are broken display-wise making it pretty much unusable. I looked at nginx.conf for Rockstor, there’s nothing I would call out of the ordinary there so I figure I’m missing something obvious.

I got portainer, and nodered working just peachy along with emby and transmission. But for the life of me I cannot figure out how to proxy the UI.

Has anyone managed to do this with nginx?

1 Like

Well just an update. Got quite a bit further but unfortunately it seems that Rockstor doesn’t seem to support a base URL(?) so proxying it requires me to map /static and /socket.io from the reverse proxy as fqdn/static and fqdn/socket.io rather than fqdn/nas/static and fqdn/nas/socket.io and I also had to reduce my security posture in SWAG (A+ on SSLLabs, B+ on Mozilla Observatory) in order to get far enough to see the 404’s causing the problem due to mapping in reverse-proxy.

Seems like a lot of work and somewhat outside my skillset (and hours of reading various web resources, trial & error, etc already put into it) when in reality, I probably shouldn’t expose Rockstor’s web interface anyways and just live with the fact I need to be on the LAN to in order to access it.

That being said, I’ll probably keep mucking with it :slight_smile: as I think if I spent time in Rockstor’s nginx conf and re-configure it accordingly (and hope it’s not clobbered by changes in the UI or make backups) I may get this to work.

Unfortunately I’m going to have to call this one. Going through src/templates I see a lot of hard-coded relative and absolute pathing and hard-coded https:// as well. The base_url is defined by what appears to be ip:port versus an URL such as /rockstor and there’s too many changes required.

I realize this was probably the original intent to be the only web service on the machine Rockstor was installed on so LAN-only access is perfectly fine and in the long-run, safer.

1 Like