It was always troubled me that /etc/init.d/adblock status gives no response if adblock.global.adb_enabled='0' (as below - the boldness is my highlight):
root@sr-router:~# /etc/init.d/adblock status
::: adblock runtime information
adblock_status : enabled
adblock_version : 3.4.0
overall_domains : 19024 (normal mode)
fetch_utility : wget (built-in)
dns_backend : kresd (/etc/kresd)
last_rundate : 05.01.2018 18:18:07
system_release : Turris Omnia, OpenWrt omnia 15.05/3.9.1
root@sr-router:~# uci set adblock.global.adb_enabled=‘0’
root@sr-router:~# /etc/init.d/adblock status
root@sr-router:~# uci set adblock.global.adb_enabled=‘1’
root@sr-router:~# /etc/init.d/adblock status
::: adblock runtime information
adblock_status : disabled
adblock_version : 3.4.0
overall_domains : 0 (normal mode)
fetch_utility :
dns_backend : kresd (/etc/kresd)
last_rundate : 05.01.2018 18:22:34
system_release : Turris Omnia, OpenWrt omnia 15.05/3.9.1
I have seen many people (including myself) get stuck because this behaviour is a little counter-intuitive (you ask a question, and get no response). I accept the adblock service itself may be disabled, but the init.d wrapper is enabled/disabled by a different means (i.e. in rc.d), and certainly not by the configuration files in \etc\config.
I know there is a log entry (adblock is currently disabled, please set adb_enabled to '1' to use this service), but couldn’t there be a console message (and for adblock.sh too)?
For that matter, what exactly does adblock_status : disabled mean? Doesn’t it actually mean inactive? Or is the behaviour above caused by the bug you’ve fixed in 3.4.1 - my system is now stuck on start adblock processing (reload)?
This is commonly used by so called community builders/builds, which add the adblock package though disabled by default. If you would like to disable adblock temporary, use the suspend/resume functionality.
Yes.
In adblock 3.4.1 I’ve fixed the status handling, even the ‘disabled’ state will be printed correctly. In the previous adblock release there was a ‘status’ race condition whenever the adblock process was running in parallel.
Adblock 3.4.1 is now in trunk and the ready to run packages will be available probably tomorrow.
For the record IMHO " /etc/init.d/adblock status" should always say something. Silence is simply disconcerting and suggests something is broken. Sort of like asking someone what time it is and getting a blank stare for a reply ;-).
Sounds reasonable. It’s already implemented in the LuCI-frontend of current adblock 3.4.1 - the missing command line output will be added in forthcoming adblock 3.4.2.
Have another question. I installed adblock 3.4.0 at the end of last year and recently I upgraded to 3.4.1. Everything works fine, the configuration is consistent, services work, but the Omnia rolled back to 3.4.0 one day later. in the Localrepo both versions are in it, is that the reason? where can I prevent it from rolling back?
uci set adblock.disconnect.enabled=‘0’
uci set adblock.hphosts.enabled=‘1’
for IDX in cn de id nl pl ro ru; do
uci del adblock.reg_${IDX}
done
uci set adblock.global.adb_dns=‘kresd’
uci set adblock.global.adb_fetchutil=‘wget’
uci set adblock.global.adb_trigger=‘timed’
uci set adblock.global.adb_enabled=‘1’
uci commit
Yes - I see your changes are 100% as per my adblock.global section.
For those who are not sure why @didbot is using a .conf file and I am using uci command - they are two different ways of achieving the same thing. The UCI is is a core part of OpenWrt/LEDE and is one way of making changes to the configuration files in /etc/config (another is to edit the files directly).
I like to use uci command simple because they scriptable.
When the Omnia’s official package repository eventually contains a recent-enough version of adblock, it will include the appropriate version of adblock.conf.
Everything was created and I made the entry in the user.lua.
But made the mistake and deleted from the localrepo-auto the previous versions, for whatever reason.
What surprised me too, why I get a message by mail the updater has an unknown error?
Did he want to roll back to 3.4.0 and could not it because the packages no longer exist in localrepo-auto?
How can I get the localrepo-auto up-to-date?
localrepo list gives me this output:
Since the Updater does not have the previous two versions in localrepo-auto, how can I remove them from the list?
About which entry or which file I can clear this list, it all works well on version 3.4.3-1
usage: localrepo [-h] [--path PATH] {list,add,rm,get,clean,check} ...
Local opkg repository management script.
optional arguments:
-h, --help show this help message and exit
--path PATH Path to repository (usable if we are working out of
root). In default path /usr/share/updater/localrepo is
used.
Operation:
{list,add,rm,get,clean,check}
list List all packages in repository
add Add packages to repository
rm Add packages to repository
get Copy package from repository to current working
directory.
clean Clean unused packages (not installed ones) from
repository.
check Check repository index and related files and
optionally fix inconsistencies.
Did you try the check command? That would be my first guess. Maybe rm could work - not sure how the checks for actual files are configured there…
Just noticed typo in rm command description. Maybe @cynerd already knows about it…
Well I don’t. Thank you for reporting it. It’s kind of funny typo.
Anyway I accept that it is not documented but you have to use underscore to specify version (it’s same format as package naming uses). So for example something like this localrepo rm --repo auto adblock_3.4.1-1. Also if you specify it without version it should remove all packages of that version from given repository. Also note that if you don’t specify repository that you are working just with user repository.
As last thing just small note. There is known bug with this syntax and because of that it’s subject to change. Reference: Sign in · GitLab
