So in the process of adapting my project to fully support OpenWrt, I'm looking into creating an init script for it. Currently the project uses cron jobs for both autoupdate and persistence across reboots. Basically the persistence part adds a table in nftables, loads (ip) sets from compressed backup, adds/inserts nftables chains and rules and verifies that everything is good.
So I'm thinking that I could simply replace the @reboot cron job (which doesn't work with Busybox cron) with a procd script which would do the same thing (it just needs to call one of my scripts which does all the rest) and then exit.
Since I've never created an init script before, I'm wondering if there is something else I'd need to think about in this context? Except at reboot, is there a condition where the firewall gets reset and my init script would need to monitor this? Is there any benefit in also implementing autoupdate launching through it (instead of a cron job)?
The init script should be simple enough to do based on an existing example from your router.
If you want it to survive a firewall restart, you need to add triggers. You could trigger it off the firewall config changing or off an interface reloading. It depends on what your package does/needs.
Probably surviving firewall restart would be a good idea. Will firewall restart necessarily activate this trigger procd_add_reload_trigger firewall?
The project basically does geoip blocking implemented via firewall rules. It contains several scripts, including an install script, a fetch script, an apply script which loads fetched ip lists into nftables sets and creates firewall rules based on user-specified parameters, a backup-restore script (which creates a compressed backup of nftables sets or restores them from backup), a run script which is called from cron jobs and in turn calls the fetch, apply and backup-restore scripts to implement persistence and autoupdate. And a manage script which provides an easy interface for the user to check geoip blocking state and change settings after installation. All user interface is currently working via a terminal.
For a typical use case in a router, my code selectively applies firewall rules to WAN interfaces. So probably monitoring WAN interfaces state should also be useful (I already have some code which auto-detects network interfaces which belong to the WAN zone and confirms them with the user, so I could as well utilize these for adding triggers, I think).
I’m not sure, but I suspect it doesn’t fire on a plain firewall restart.
However in the firewall config you can also put “include” files which will be run every time it restarts.
You can either include nftables scripts or a shell script that does all your setup.
@lantis1008 or anyone who knows the answer:
are the includes run at boot as well? if so then perhaps I don't even need an init script at all but rather implement persistence via the includes (which will call my "run" script)? any flaw with this approach?
The firewall runs at boot so the includes should be picked up as part of that.
Probably good to double check the behaviour but that’s my understanding.
Thinking about this some more, there is a flaw, which is if someone resets the firewall completely then my project stays installed but inactive. So I suppose I'll make a simple init script which will simply make sure that the firewall include exists.
