Adblock-lean: set up adblock using dnsmasq blocklist

Community Builds, Projects & Packages
1889

Fellow adblockers, adblock-lean v0.7.4 is now available.

Main changes in this release:

  • New feature: support adblocking on multiple dnsmasq instances (the service adblock-lean select_dnsmasq_instances command now allows to pick multiple instances) - thank you @languagegame for requesting this feature and testing, thank you @d687r02j8g, @spence for testing
  • Bugfix: files .abl-extract_blocklist, abl-conf-script not removed when adblock-lean is paused
  • Improve config-related logic and config parsing efficiency
  • Improve error handling
  • Various minor optimizations
  • README updates

Full Changelog: https://github.com/lynxthecat/adblock-lean/compare/v0.7.3...v0.7.4

Users can update to this version, as usual, via the command

service adblock-lean update

Users who temporarily changed the update channel of adblock-lean can use the command

service adblock-lean update -v release

to switch back to the release update channel.

New users can install adblock-lean by following the instructions in the adblock-lean GitHub repository.

Enjoy!

5 Likes
1890

@antonk Is it expected that the update will reset the compression algorithm to gzip?

image
image950×265 7.19 KB

The *.gz is a valid extension only for gzip/pigz, but in case zstd is used, the configuration is not valid, and it was removed during the upgrade. If the compression is manually changed to zstd, the following warning is printed, but the "setup" option does not provide the ability to configure them.

image
image1015×137 5.1 KB

Are there any other options instead of manually adding them in the dhcp config file and enabling it in the "adblock-lean" configuration file?

image

1891

Nope. The compression algorithm shouldn't get reset. I'll try to reproduce the issue.

The way it is designed to work:

  1. you change the compression utility
  2. you run service adblock-lean setup and type in e to keep your config
  3. the addnmount entries are updated automatically

Does this not work for you?

1892

@antonk - same for me

Perform following automatic changes? (y|n)
1. Migrate config entries
2. Remove unexpected entries from the config
y|n: y

Old config file was saved as /tmp/adblock-lean_config.old.
This will overwrite existing config. Proceed? (y|n)
y|n: y

Saving new config file to '/etc/adblock-lean/config'.

Checking dnsmasq instances.

Detected missing addnmount entries in /etc/config/dhcp for paths: /var/run/adblock-lean/abl-blocklist.gz

Create missing addnmount entries automatically? (y|n)
y|n: y
Deleting addnmount entry for '/bin/busybox' for dnsmasq instance 0.
Creating dnsmasq addnmount entries for dnsmasq instance 0.
adblock-lean has been updated to version '0.7.4'.

Start adblock-lean now? (y|n)
y|n: y
1893

This is expected. Support for multiple dnsmasq instances required to change the path at which the blocklist is stored - was ${dnsmasq_conf_dir}/abl-blocklist.[gz|zst], now /var/run/adblock-lean/abl-blocklist.[gz|zst]. So addnmount entries need to be changed during this update.

1 Like
1894

I can not reproduce the issue. Tested update from v0.7.3 to v0.7.4 with compression utility set to zstd and this did not reset the compression utility in adblock-lean settings. This does remove all previous addnmount entries and then creates new entries because this is the simple way to manage them, however correct entries were created.

Downloading adblock-lean, version '0.7.4' (update channel: 'release').
...
Checking dnsmasq instances.

Detected missing addnmount entries in /etc/config/dhcp for paths: /var/run/adblock-lean/abl-blocklist.zst

Create missing addnmount entries automatically? (y|n)
y|n: y
Deleting addnmount entry for '/usr/bin/zstd' for dnsmasq instance 0.
Deleting addnmount entry for '/bin/busybox' for dnsmasq instance 0.
Creating dnsmasq addnmount entries for dnsmasq instance 0.
adblock-lean has been updated to version '0.7.4'.
...

# cat /etc/adblock-lean/config | grep compression_util=
compression_util="zstd"

# cat /etc/config/dhcp | grep zst
        list addnmount '/usr/bin/zstd'
        list addnmount '/var/run/adblock-lean/abl-blocklist.zst'
1895

Strange, but after reverting to version '0.7.3', I've not managed to reproduce the issue above. Thanks for your time.

1 Like
1896

Update from SNAPSHOT to adblock-lean, version '0.7.4' (update channel: 'release') worked fine on my R4S.

service adblock-lean update -v release 
root@R4S-wrt:~# service adblock-lean update -v release

Downloading adblock-lean, version '0.7.4' (update channel: 'release').

Installing new files...
File '/usr/lib/adblock-lean/abl-lib.sh' did not change - not updating.
File '/usr/lib/adblock-lean/abl-process.sh' did not change - not updating.
Warning: File '/etc/init.d/adblock-lean' was manually modified - overwriting.
Saved a backup copy of manually modified file to /tmp/abl_old_modified_files/adblock-lean
Copying file '/etc/init.d/adblock-lean'.

adblock-lean has been updated to version '0.7.4'.

Start adblock-lean now? (y|n)
y|n: y

Starting adblock-lean, version 0.7.4.
...
Checking for adblock-lean updates.
The locally installed adblock-lean is the latest version.
root@R4S-wrt:~#
2 Likes
1897

Updated from 7.3 to 7.4 — all went smoothly. I just chose 'y' three or four times to let the setup adjust automatically. Thanks!

While I was at it, I switched the list links to the short versions:

blocklist_urls="hagezi:pro hagezi:tif oisd:nsfw hagezi:native.xiaomi hagezi:native.winoffice"

I noticed that OISD has four lists. Would oisd:big be beneficial for my setup, or would it overlap with hagezi:pro and tif?

What lists do folks here recommend — or am I good with what I have?

Cheers!

1 Like
1898

Hi all, adblock-lean v0.7.4 has a minor regression which causes an error to be printed when running the setup command and choosing to create new config. I just released v0.7.4.1 - a hotfix for this issue.

@Seb I just checked: your list selection currently has 965,315 entries (after deduplication). When adding oisd:big, the final blocklist has 1,021,030 entries. Which adds ~56,000 entries, out of ~200,000 entries which are included in oisd:big. So ~144,000 entries in that list are duplicated in other lists. Generally oisd is considered good and solid, so as long as your device can handle the extra entries, I don't see why not include them.

2 Likes
1899

Yes @Seb and adblock-lean originally used the OISD lists by default, but over time it became evident that the Hagezi lists were benefitting from maintenance by a true perfectionist - just checkout the GitHub page here: https://github.com/hagezi/dns-blocklists (much like our very own @antonk that is now most actively developing adblock-lean) and furthermore formulated in such a way as to facilitate flexibility by picking and choosing from a large number of carefully curated lists. Whereas on a couple of occasions we (myself and @Wizballs) spotted a couple of bad entries in OISD leading to connectivity issues - rare, but still there, which prompted all the validation checking in adblock-lean, I don't think we've encountered the same degree of issues in respect of the Hagezi lists.

I think the Hagezi lists are a safer bet for default lists and the set-and-forget approach, and I think I'd personally err on just using more of the Hagezi lists rather than adding in the OISD list(s), but there could be merit in mixing and matching from the perspective of catching more baddies. This is a little difficult to quantify for me because with Hagezi I find pretty much all adverts gone on all the sites I look at.

From my perspective Hagezi and @antonk make for a very powerful combination - both perfectionists and enthusiasts, and I like to think this, combined with the core pattern @Wizballs and I established for adblock-lean - make it the best 'set and forget' choice for all OpenWrt users. It's no-nonsense and 'just works'. One can forget all about it and it just does it's thing in the background. All efficiency. No bloat and very limited reports of issues and breakage.

4 Likes
1900

Hi @antonk and @Lynx
Thank you both for helpful replies and taking time to respond to me.

I’m truly grateful for the effort and thoughtfulness behind adblock-lean. Compared to adblock, it’s faster, leaner, clearer in execution and error reporting, and overall a joy to use. Its set-and-forget reliability—clean terminal output, coloured status messages, seamless upgrades—feels like adblocking done right. Huge thanks to everyone contributing to this project—your work is appreciated more than you know.

I originally included oisd:nsfw for family safety, and only today added oisd:big to expand coverage (ads, phishing, malware, tracking, etc.).

However, if the Hagezi lists already cover those categories—particularly adult content—I’m open to dropping OISD entirely for a more coherent, efficient setup.

My current config:

blocklist_urls="
hagezi:pro 
hagezi:tif 
oisd:big 
oisd:nsfw 
hagezi:native.xiaomi 
hagezi:native.winoffice
"

Device: Linksys MR8300 (ipq40xx)
Memory still well within the comfort zone: 152 MiB RAM used / 495 MiB total, applying ~1.2M entries in 1m40s.

Also, as I am at it. The hagezi and oisd lists seem smaller than they were a few months ago, and I think I can revisit those parameters, that I set before:

min_good_line_count="260000"
max_file_part_size_KB="20000"
max_blocklist_file_size_KB="30000"
boot_start_delay_s="100"

What would be the recommended values for those?

Once again. Thanks for everything, guys.

2 Likes
1901

Thank you for the kind words - very nice to hear them.

Note that the important figure is entries count after deduplication. If you are using the lists you mentioned above, including oisd:big, then currently that figure is ~1,020,000. Entries count in Hagezi lists tends to fluctuate a lot, and it's not rare to see the combination of hagezi:pro + hagezi:tif get to 1.2M entries. So I would take 1.2M as the rough estimate so you don't have to adjust the values again anytime soon.

adblock-lean includes an algorithm which calculates recommended values for presets based on expected entries count. The calculated values have some headroom which allows for ~20% size fluctuations upwards. Here is the slightly simplified version which can work as a standalone script. You can save it as a file on any Linux machine and use it to calculate recommended values.

#!/bin/sh

# Calculate recommended values for adblock-lean options based on target entries count
# This is a slightly simplified algorithm which assumes that 2 or more lists are used
# usage: sh calc_values.sh <target_entries_count>

reasonable_round()
{
	eval "input=\"\${${1}}\""
	input="${input#"${input%%[!0]*}"}"
	: "${input:=0}"
	case "${input}" in
		*[!0-9]*) printf '%s\n' "Error: invalid input '${input}'." >&2; return 1 ;;
		?|??) return 0 ;;
		????????????*) printf '%s\n' "Error: input '${input}' too large." >&2; return 1 ;;
		*)
			factor=$(( 10**(${#input}-2) ))
			eval "${1}=$(( (input/factor) * factor ))"
	esac
	:
}

final_entry_size_B=20 # assumption
source_entry_size_B=20 # assumption for raw domains format. dnsmasq source format not used by default

tgt_entries_cnt=$1

min_good_line_count=$((tgt_entries_cnt*10/35))
max_blocklist_file_size_KB=$(( (tgt_entries_cnt*125/100*final_entry_size_B)/1024 ))
max_file_part_size_KB=$(( (tgt_entries_cnt*103/100*source_entry_size_B)/1024 ))

reasonable_round min_good_line_count &&
reasonable_round max_blocklist_file_size_KB &&
reasonable_round max_file_part_size_KB || exit 1

printf '%s\n%s\n%s\n%s\n' "Recommended values:" "min_good_line_count: $min_good_line_count" "max_blocklist_file_size_KB: $max_blocklist_file_size_KB" \
	"max_file_part_size_KB: $max_file_part_size_KB"

For 1M entries, this algorithm produces following results:

min_good_line_count: 280000
max_blocklist_file_size_KB: 24000
max_file_part_size_KB: 20000

For 1.2M entries, following results are produced:

min_good_line_count: 340000
max_blocklist_file_size_KB: 29000
max_file_part_size_KB: 24000

As to boot start delay, it has nothing to do with entries count. 100s is a reasonable figure.

1 Like