adblock-lean
adblock-lean copied to clipboard
lynxthecat
Improve update availability monitoring
report_update_available()
{
mailbody="${1}"
mailsend -port 587 -smtp smtp-relay.brevo.com -auth -f [email protected] -t [email protected] -user [email protected] -pass PASSWORD -sub "Adblock-lean update is available" -M "${mailbody}"
}
As discussed on the openWRT forum. A third trigger for a custom script, to send an email for example, when an update is available.
@friendly-bits we also discussed setting up a function to check for the existence of an update. So that could be implemented in, say, a cron job that went like service adblock-lean check_for_updates && service adblock-lean update -a where the -a was an automated update. Not sure what the best way here is.
@vJoseph what's your preference here in terms of e-mail vs something like the above?
@friendly-bits we also discussed setting up a function to check for the existence of an update. So that could be implemented in, say, a cron job that went like
service adblock-lean check_for_updates && service adblock-lean update -awhere the-awas an automated update. Not sure what the best way here is.@vJoseph what's your preference here in terms of e-mail vs something like the above?
Auto-Updates would definitely work for the set it and forget it description of ABL. I wouldn't necessarily need the email notification at that point.
As @friendly-bits has pointed out though, some people may prefer to scan through changes before updating so maybe a copy of the change log / notes could be emailed whenever an update becomes available so that the user can then decide to go update manually, without having to check their system's log for updates, to preserve the set it and forget it feel but as an alternative option to auto updates.
a cron job
Is there really a need for another cron job? To me this only makes sense if the lists update cron job doesn't exist. So I'm trying to imagine why would someone want to have no regular list updates but have regular version update checks and if this is a realistic scenario, and if it is then should we care. If it's not really needed then it is much easier to implement just another call to user-defined function on exit and that's it. Otherwise we need to implement handling of another cron job, so checking the cron service, handling fault conditions with the cron service, checking if the job already exists, ideally checking that the actual job matches what's set in config, if not then removing the job, creating a new job, handling errors etc. All of this is doable (and IIRC we are doing all that for the lists update cron job) but I'm not sure it's necessary here.
check_for_updates && service adblock-lean update -a
I'm not comfortable with the idea of having any code which automously writes to flash on embedded devices, without any user confirmation. If it's a one-off like during initial setup, directly sanctioned by the user, then no problem. But having this run periodically is just too risky. This is just from the perspective of flash wear. From the perspective of version updates, this doesn't make sense to me either. The only justification for automatic updates (which I can think of) is security (I.e. we find a vulnerability in adblock-lean and we issue an update which fixes it). This is not negligible but security is not the only consideration. There is also functionality, for example. Can we actually guarantee that the new version doesn't have a serious bug which breaks functionality in some environments? I think almost no software can, and definitely not adblock-lean where at best, we are able to get 4 or 5 people to do any testing before release (including ourselves).
So in short, I really don't like the idea of autonomous version updates.
Sending a notification about an update being available is a perfectly fine idea though.
@friendly-bits just saw the abl update. thank you for implementing the update notification function.
Thank you to the whole abl team for the great program, it works great and checks all my boxes