unifios-utilities
unifios-utilities copied to clipboard
Re-apply periodically; or after UI changes settings
The problem
I do configurations with udm-utilities changing some network configurations. They apply at boot, which is great. But after a while I discover my settings are (partially) reverted, I suppose that it was some change I made in the UI that caused them to be overwritten.
I suppose that this is a more or less generic problem that people using udm-utilities might face.
Possible solutions
I wonder if it would be within scope to have some generic mechanism to either
- Put an entry in crontab that would execute the same scripts we define for boot, if we so desire
- Detect changes (to files?) and re-apply.
I know that I can probably solve my own problem (by using the boot script to set up my cron job, or some file watcher), what I am asking here, or perhaps suggesting, is that it might be cool to do something generic that enhances udm-utilities in this direction.
Does anyone else feel this could be useful?
sure, you gotta monitor it writing the firewall state file and then run the commands. Could use python in the unifi-os container to do this.
I'm afraid I don't know Python, haven't learned it yet. I'll leave this as a suggestion for the project, in case anyone finds the time and is motivated to do it. Thanks!
@pgorod - I had this issue as well after making changes to traffic-control manually (specifically, removing smart queue functionality for downloads only and keeping upload queues in place).
Applying those settings in an on-boot.d script occur before the Network application is loaded and once it loads, it re-provisions the changes from the config, therefore modifying in on-boot.d is not effective. I got around this by creating a cron job to re-apply the settings every 5 minutes (you could choose whatever frequency works for you) and I added a script at https://github.com/telnetdoogie/udm-utilities/blob/patch-1/on-boot-script/examples/udm-files/on_boot.d/25-add-cron-jobs (pull request into master pending) to update cron on each startup, so the cron job is persistent.
For me, I chose every 5 minutes because 1) the change is operationally insignificant, that is; no downtime occurs as a result and 2) the change is lost anytime anything in the Network UI is updated. So at most I'm 5 minutes away from the change being re-applied.
There might be a better way to make the change more permanent but this works really well for me for the time being.