I'm looking for a way for make the system invoke my custom command after each uci commit (including commits issued by luci). Couldn't find a way to do it.
Is there an already implemented way to achieve this?
If not, a good idea would be to have a ubus event for uci commit - then I'd be able to wait for in a loop in a bash script and invoke the my command.
My end goal is to push a backup of all the configuration files to an external server on every change - so I also looked into things like alternative uci backends, but that seems to be too heavy of a solution for the task this simple.
I'm pretty sure any alterations/wrapping of the uci executable are not going to help, and neither they are really the architecturally correct way of doing what I need. This is because I technically want the system to react to the the commit event itself, and not merely the invocation on uci commit binary. My current research of the source of uci/ubus suggests that the actual commit event can be issued by means other than invoking the uci executable.
To be more specific, all that uci binary does is it invokes libuci internally (uci_commit for commit), and any other code can do that too.
This is why what you're suggesting is not going to work at all, as it only wraps around one way of doing the commit, but I want to capture all of them.
After more research of the uci source code, it seems there is currently no way of doing what I need.
So, I'd like to discuss possible additions to the uci to enable dispatching events for other parts of the system to subscribe to.
I agree that something like rsync is probably a robust and efficient approach. You might make it more sophisticated by checking modification times with find and/or additionally triggering with events.
The inotify functionality may also be valuable to explore. As I understand it, it can trigger events on file changes. I don't know if it is available as a drop-and-go addition to an OpenWrt install, nor if it can easily be configured to handle additions of new files to subdirectories.
The problem is losing the changes that happen between the backups.
The situation is there may be nothing happening for months, and then something happends that immediately breaks the system, in which case we'd want to catch both states before and after the uci commit. Ideally we'd want to have a hook to run a command before commit, as well as after commit, but capturing stuff aonly after the commit works for me too at this point.
I'll have to check if doing the rsync frequent enough to tho what I need is feasible.
Not an easy problem if you're capturing the information off-device. "Joe" changes the LAN address from 192.168.0.22 and "derps" to 188.8.131.52 instead of 192.168.0.23. Poof, no way to connect to the remote. It might even be that a config file was edited and the device comes up with "bad" config. Or "Bob" decides unwisely to run opkg upgrade and TLS connectivity dies.
There's one more point, which is uci commit only overwrites previous persistent configuration, it doesn't require to apply it, or you can apply changes without saving them.
So it's possible to reproduce the situation when service runtime configuration differs from UCI runtime configuration, and UCI runtime configuration differs from UCI persistent configuration.
Yeah, for this case my the goal is to capture the persisted configs, kind of.
Maybe for the broader use cases it'd be best to alter libuci in a way that it does the proper audit + state backups, but for me just capturing commits would be good enough.