How to update the internal state of the nginx module executable?

Question

Suppose I want to write a nginx module that blocks clients by IP. To do this, at the initialization stage, I read a file with IP addresses that I should block (blacklist) and save it in the context of the module.

Now I want to update the blacklist without restarting nginx. One possible solution is to add a handler to a specific location. for example, if uri "/block/1.2.3.4" is requested, my handler adds the ip address 1.2.3.4 to the blacklist.

However, nginx runs several workers as separate processes, so only one specific worker is updated.

What is the general solution to such problems?

Answer 1

If you can move the blacklist outside the context of the module, perhaps to a system file, a KV or SHM repository, which allows each process to talk to the central source blacklist. I believe that shmat () and futex will do the job, and the overhead will be negligible.

Answer 2

But nginx does not require a reboot (or downtime) to change the configuration!

Cm:

• http://nginx.org/en/docs/control.html#reconfiguration

In order for nginx to re-read the configuration file, a HUP signal must be sent to the main process. The master process first checks the accuracy of the syntax, then tries to apply the new configuration, that is, open the log files and new sockets for listening. If this fails, it discards the changes and continues to work with the old configuration. If this succeeds, it starts new workflows and sends messages to old workflows asking them to close them gracefully. Old workflows close sockets and continue to serve old customers. After serving all customers, the old workflows are completed.

As an administrator, I would expect all modules to be monitored in this way as well.

(Of course, if you need a lot of configuration changes very often, another solution might be more appropriate.)

---

You are giving an explicit example of IP blocking. Are you sure that a new module is required to complete the task? It would seem that a combination of the following standard directives might already be sufficient:

• http://nginx.org/r/deny && & && & http://nginx.org/r/allow
• http://nginx.org/r/geo
• http://nginx.org/r/map
• http://nginx.org/r/if && & && & http://nginx.org/r/return

---