1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

nginx ("web server" on TomatoRAF) reverse proxy configuration

Discussion in 'Tomato Firmware' started by OFFBEAT, Jan 28, 2014.


    OFFBEAT Reformed Router Member

    I'm happy Tomato RAF includes nginx server as I intend to use it as a REVERSE PROXY for hosting multiple domains across multiple different servers.

    The "Web Server" module within Tomato RAF has a "custom configuration" textbox that simply concatenates my custom settings at the end of the "default" configuration. However, the "default" directives, rules and settings on /tmp/etc/nginx/nginx.conf cause conflicts w/ my intended use.

    I am interested in writing my own "nginx.conf" from beginning to end without my changes being overwritten by any process. I also need the changes to be reboot persistent.

    So far I've been unlucky to locate such settings within NVRAM.

    Any ideas?

    OFFBEAT Reformed Router Member

    After further testing, it looks like custom changes are saved OK. The issue seems to be that upon router reboot (either SSH "reboot" or TomatoGUI "Reboot.." link), the nginx.conf is recreated from <???> into /tmp/etc/nginx/nginx.conf.

    OFFBEAT Reformed Router Member

    Upon further research of the sources, it appears "Tomato-RAF/release/src/router/rc/nginx.c" is the culprit that hardcodes "nginx.conf" and overwrites previous custom nginx.conf upon system reboot(s).

    So the workaround I see would be to disable "Web Server" to start automatically (therefore bypassing recreating the hardcoded config parameters) and instead generate the entire custom nginx.conf configuration within "Administration > Scripts > WAN Up". Followed by starting the service. Additionally set a cron to check whether nginx process is running, should for whatever reason the process die.

    Any ideas?
  4. koitsu

    koitsu Network Guru Member

    Search Google for "Tomato setfile2nvram" and read. You would want nvram setfile2nvram /etc/nginx.conf followed by nvram commit and only once.

    Keep in mind use of this feature, depending on how big your nginx.conf file, may exhaust your NVRAM space. You've been warned.

    Otherwise, make a short script (stored preferably on a USB stick) that gets run + overwrites the file (/etc is a symlink to tmp/etc which is RAM, hence lost on reboot -- now you understand how this works/why it is the way it is) with the contents you want + restarts nginx using service nginx restart.

    You DO NOT want this script placed in WAN Up. I repeat: you do not. This should go into either Init or Firewall. And you may need to use a while loop with sleep 1 + pidof to wait until nginx is launched/running so that you can restart it.

    Honestly, custom nginx.conf modifications should probably get their own GUI field (similar to dnsmasq.conf and others). But that's not my decision; just an idea.
    OFFBEAT likes this.

    OFFBEAT Reformed Router Member

    koitsu, seems like logical to have nginx.conf stored in it's own GUI field. i submitted a github proposal to have that considered by Vic.

    I was hoping to avoid using a USB drive. Incorporating nginx was the main reason I chose TomatoRAF rather than using Entware on any other Tomato build.

    It doesn't appear that service nginx stop/start/restart is correct. Is there a way to lookup what available services are registered? The usual service --status-all doesn't work on these systems.
  6. koitsu

    koitsu Network Guru Member

    service on Tomato is not accomplished/done the same way on standard Linux distros due to embedded environment concerns. The way it works I describe elsewhere. There is no "registering" of services, and I had forgotten that it doesn't iterate over the process list, so no, I may be wrong: service may not the right way to go about restarting nginx, but I'd ask Vic to be sure. Otherwise you just need to use pidof and start it manually if it isn't running (you can get the arguments by looking at an existing running version, ex. ps | grep nginx).
  7. twentyninehairs

    twentyninehairs Network Newbie Member

    This doesn't appear to be an issue any longer with shibby's AIO builds because the configs are built into the web GUI. However I would just like to fully understand why koitsu emphasizes NOT putting the config script in the WAN Up box--if he is also saying that the server also needs restarted???

    I use the script config boxes for a lot of different things & I was just wanting to understand why that is an issue???
  8. koitsu

    koitsu Network Guru Member

    WAN Up can happen at any time the WAN link goes down or back up (and even more common if using PPPoE). Thus, every time the WAN comes up, the script would get run. There's no point in doing that (copying the config file, etc.) every time the WAN link comes up -- there's no config file change you'd need that would "key off" of anything involving a change in WAN IP address or anything like that. (If there is, then yes, WAN Up would be the place to put it, but it's unlikely).

    Basically, one-time things need to go into Init (only run once when router comes up, before any network links), firewall rules go into Firewall (those can be run again at any time too, but usually are flushed first and the ones in Script/Firewall are done afterward), and WAN Up happens when the WAN link comes up (but this may happen multiple times depending on your setup, e.g. your link is up, but then someone reboots your cable modem, once it comes back, WAN UP gets run again, etc.).

    The reason I advocate not putting things in WAN Up unless they need to be is that people often write scripts that just "blindly append things", like throwing iptables rules or "echo foo >> /some/file" in there. Every time WAN Up gets run those commands will happen, which means you'll have iptables rules that get appended to over and over and over (i.e. grow and exhaust), files that get appended to (grow and exhaust), etc..

    I would suggest looking at how nginx binds to interfaces to see if it does an INADDR_ANY (chances are it does) to a specific port -- if so, then there is absolutely no reason for it to go into WAN Up, because nginx doesn't need to know anything about your WAN IP or anything else that might change. It's just a one-time deal. Start the daemon + let it run. :)
  9. twentyninehairs

    twentyninehairs Network Newbie Member

    That makes a lot of sense. Thanks for helping me think that through!

Share This Page