Fellow adblockers, adblock-lean v0.7.1 is now available.
This is a small bugfix/maintenance release with following changes:
Fix ANSI colors contained in message passed to report_success() in custom script (if defined)
Fix ANSI colors contained in some logged messages
pick_opt(): fix options sometimes not printed
Create $ABL_CONF_STAGING_DIR in parse_config() rather than in load_config() - fixes direct calls to parse_config() from the luci app
Implement check_func(), use check_func() when checking for functions
Document API for calling report_update()
Full Changelog: https://github.com/lynxthecat/adblock-lean/compare/v0.7.0...v0.7.1
Users can update to this version, as usual, via the command
It is asking a question, expecting you to input y or n. For some reason, the prompt is sometimes not printed. I thought that I fixed that with this latest update but maybe not. Will look into this again.
Turns out that one of the commits (specifically this one) broke prompt printing when output is redirected. I reverted that change and re-released v0.7.1. Thank you for letting us know.
Is it possible to update adblock lean and start it automatically? The idea is to have a switch such as "service adblock-lean update -y" which proceeds to accept any recommended config updates and also starts the service after execution, instead of prompting the user interactively. The background here is that I use luci-app-commands to simplify interaction with the router, which does not allow user input during execution, and depend on ssh only as needed. Adblock updates are suggested when it finds a new version, but a simple non-interactive update method would help, to avoid ssh-ing to specifically say "yes" to starting the service. Sample below
Fellow adblockers, adblock-lean v0.7.2 is now available.
This is a fairly large release which mainly implements improvements to the self-update mechanism:
Rather than writing the version string into each of the installed files, only write it into the main file
Rather than checking libraries by comparing version strings, create a file with md5sums of all installed files and check against that.
This is both more robust and allows to minimize the number of flash writes when updating adblock-lean scripts as only the main script will be re-written unconditionally and other scripts will be only re-written when they actually change.
Implement local API query caching which works around GitHub limits on consecutive API queries - this helps when testing various adblock-lean versions in rapid succession.
Support a new update channel: branch=<gh_branch>
Additional changes:
Implement support for additional compression utils: GNU gzip, pigz, zstd (thank you @justops1337 for the feature request) - this also changes some config options
Support the -y option to auto-approve all suggested changes during adblock-lean version updates (thank you @openwrter for the feature request). Note that this option will work when updating from v0.7.2 to the next release but not when updating from v0.7.1.
The blocklist size of the preset 'small' now exceeds 6100 KB, so this needs another revision in the default config I believe. Blocklist update worked after I revised this option.
I realize the issues this can cause in terms of RAM usage, but I guess letting the user also configure this limit as part of the setup wizard can be helpful, with the right warnings in place. Or potentially the option to exclude the tif feeds, if the limit exceeds the sane defaults.
Thank you for reporting this. Unfortunately, I don't think that increasing the default limit makes sense for the 'small' preset as it's intended for 128MiB devices and on some of them this would increase the chances of getting OOMs (out-of-memory errors). So IMO the necessary solution is to remove the Hagezi tif.mini list from that preset. Users who own a 128MiB device which has enough memory to spare will still be able to add that URL and increase the value of max_blocklist_file_size_KB.
We have to balance this with setup simplicity and with code simplicity as well. IMO most users, especially first-time users, wouldn't know which values to set for min and max limits, and this would make the initial setup much less straightforward. Experienced users, on the other hand, can easily edit the config file to their liking. From the code simplicity standpoint, implementing complex dialogs in shell is quite cumbersome. So I wouldn't go there.
Edit: turns out that the medium preset is also overflowing. I submitted a PR which addresses both issues.
I think it is safe to say that the internet keeps growing and we are quite a long time away from it shrinking (unless some nuclear war happens or an asteroid impact or similar). [/offtopic]
As discussed above, the small and medium presets in adblock-lean are currently broken because of a significant increase of entries count in some Hagezi lists, which now makes adblock-lean reject the final blocklist because it's larger than the presets allow. This is now fixed in the master branch (along with some minor'ish bugs) and we will soon issue a release incorporating these changes.
In the meantime, I also implemented an idea I've had for a long time, which is to accept short list identifiers for Hagezi and oisd lists and automatically translate them to URLs. So, for example, this:
Fellow adblockers, adblock-lean v0.7.3 is now available.
This is mainly a bugfix/maintenance release, but it also introduces a new feature: support for short list identifiers instead of URLs for Hagezi and oisd lists. This README section has more details about this feature. adblock-lean continues to support fetching lists from download URLs but when generating a new config via the service adblock-lean gen_config or service adblock_lean setup commands, short list identifiers will be used instead of URLs.
Presets small and medium default URLs were adjusted to account for some Hagezi lists increasing in size and causing adblock-lean to reject the final blocklist (thank you @openwrter for reporting the issue)
Fix color highlighting for warnings and errors (thank you @justops1337 for reporting the issue)
Fix regression introduced in v0.7.2 with calls to Busybox applets not issued correctly on some systems (thank you GitHub users lazyzyf and VoQZHD for reporting the issue and @d687r02j8g for testing)
New feature: support short list identifiers for Hagezi and oisd lists (thank you @d687r02j8g for testing)
README updates
NOTE that because of config incompatibility, downgrade from v0.7.3 to earlier adblock-lean versions is not supported by the update command. The abl-install.sh script can still downgrade to earlier versions but it will remove current config when downgrading (a backup copy will be made).
Hi all, we're nearing the release of the next adblock-lean version which implements support for adblocking on multiple dnsmasq instances, some other improvements and minor bugfixes. The code has been merged into our 'master' branch and we've done initial testing. Would be nice if more people tested the code before we make a new release. If you want to help with testing:
service adblock-lean update -v snapshot
If you are using multiple dnsmasq instances and would like to adblock on all or some of them, use this command after update:
service adblock-lean select_dnsmasq_instances
If someone here is already using adblock-lean with multiple dnsmasq instances via custom addnmount entries in /etc/config/dhcp, please remove your custom modifications before updating.
If later you want to go back to current adblock-lean release:
I upgraded to 24.10.2 yesterday using LuCI's Attended Sysupgrade with the “keep settings” option.
When I run: service adblock-lean status
the output was adblock-lean service is disabled.
Is it expected?
I run: /etc/init.d/adblock-lean enable
and got:
Enabling the adblock-lean service.
Updating cron job for adblock-lean.
cron_schedule is set to 'disable' in config.
Removing cron job for adblock-lean.
I’m wondering — should I run the setup script? sh /etc/init.d/adblock-lean setup
Appreciate any pointers. Trying to make sure adblock-lean stays ON.
Did you preserve the adblock-lean config file when doing the sysupgrade?
The service is in a disabled state immediately after sysupgrade, this is expected.
Anyway, if you do not have anything special in your config, you can run the setup command, choose to create a new config when asked, then everything will be reset to defaults, including cron job.
