Releases: yubiuser/pihole_adlist_tool
2.3.0
PR #19 adds the new option -r which will analyse blacklist regex as well. It first creates a list of all visited domains (from pihole-FTL.db) and then checks each domain against all regex. Output is a table with all regex blacklist and the number of visited domains that would have been been blocked by this regex.
Note Depending on the amount of visited domains, the number of regex entries and the hardware/CPU this calculation needs some time (were talking about minutes!). This is also the reason users need to enable regex analysis manually and they are off by default.
Note 2 The Pi-hole's regex engine can do some very fancy stuff (e.g. blocking based on the query type). The internal test (pihole-FTL regex-test) can not test for all those rules as it only takes the domain into consideration. There might be more edge cases that are not covered by this test. Therefor, the number of covered domains by some regex might be understimated.
2.2.0
2.1.0
2.0.0
This is a breaking change
Pi-hole FTL v5.5 and newer are required now! This Pi-hole version contained important security updated. The adlist tool benefits from enforcing this version by removing a lot of if...then...
code. Additionally, we use Pi-hole's build-in sqlite3 shell from now on. (PR #13)
1.4.0
- Add an option to enable only the minimal number of adlists that cover all domains that would have been blocked (Thanks to @Ghalid). Previously some domains would have been missed if users choose enabling only adlists with unique domains. PR #8 solves #5
- calculate adlists_ids with unique domains only if users chose "enable only adlist with unique domains" (c7f8ddd)
1.3.1
- Fix type. Thanks to @techie2000 (#7)
- After the final selection which adlist should be/kept enabled, calculate how many domains from gravity_strip are still enabled in gravity. This is useful in case users select to enable all adlist initally, but return to their previous adlist configuration which might not contain all domains that could have been blocked (or choose to enable only adlists with covered unique domains). This is a inital step to solve #5 (409be37)
- add
info
table to the temp database to store pre-calculated information (a01b56c) - display a warning and option to run gravity if a mismatch between enables adlists and data in gravity is detected (8dab718)
1.3.0
Added handling of CNAME info (see #3 for details)
Cave: If you request to analyze queries before you've upgraded to pihole FTL v5.2, the number of domains and hits reported by pihole as being blocked (gravity+deep CNAME) will be much higher than the calculation based on your current adlist configuration. Reason is, that previously a CNAME blocked query got the same status (blocked during CNAME inspection) but without the additional_info which domain has actually been blocked. Counting the number of queries with that status is therefore higher as the number of queries with additonal_info (which is needed for calculation)
1.2.5
1.2.4.
1.2.3
- Prints timestamp warning before giving the opportunity to enable all adlists. Prevents an edge case where current adlist configuration won't be restore because requested query is after last query in the database (script will exit) but user had choosen to enable all adlists before c812875
- Use pihole-like output style 3146e23
- Print selected configuration options on script start 3146e23
- Generally be more verbose 3146e23