new update is coming out
Shouldn't affect anyone who's installed the Edge version which I detailed. However if you want to only use stable versions then 107 should be fine to use.
opkg AGH now updated to 107. This build is useable and now you can just opkg install and use openwrt's build.
Please note this does NOT install into /opt but into /var so there are differances to using the AGH install script that i detail in my updated install post and instructions in this thread.
Wondering what the thoughts are around avoiding non standard ports for the web if?
Why not bind another LAN IP address to your router, so you can run AdGuard Home from a separate IP address with port 80/443? This means LuCI and the AdGuard Home web interface can co-exist, without having to change the ports. You can still bind DNS to 192.168.1.1 providing you've moved dnsmasq.
SSL wise, I'm able to use ACME and share the same SSL certificate across LuCI and AdGuard Home, I do have a wildcard *.internal.domain.com certificate though to make this easier, however with SAN requests, you don't have to use a wildcard, just specify the hostnames required in the certificate and then you can point the private key, cert path etc in AdGuard Home to the location on the OpenWrt filesystem.
I went for the simple route and just punted AGH web interface to 8080. Its not ideal but it is a workable solution as ideally we want luci as the primary web interface. The aim was to simplify things and integrate without replacing, while making it easily accessible for users without such a technical background.
A better one is what was discussed on the PR. Using a reverse proxy like Traefik or even nginx (which is supported by luci and AGH) https://github.com/AdguardTeam/AdGuardHome/wiki/FAQ#nginx
There was also a luci app for agh but its 2yrs out of date and seems abandoned. https://github.com/rufengsuixing/luci-app-adguardhome
Ah, reverse proxy is a good shout. Admittedly the binding of an additional IP while not exactly difficult would be hard to script, given the LAN range could be anything, you could in theory check this with UCI variables but it is more complicated and not as straight forward. That's what I do though, have AdGuard Home on it's own IP for the web interface, so I don't have to worry about non standard ports. I'm probably a bit of purist when it comes to random non standard ports on things when you don't need to.
I'm going to test the reverse proxy now actually, I already use nginx with LuCI.
Part of my reasoning for not going too complex is that AGH's DHCP is... rather simple and still awaiting some changes to bring it more inline with the far more powerful OpenWrt implementation.
Small changes and avoid breaking stuff. I deliberately aimed to avoid major changes to avoid breaking peoples installations. Break DNS and bad things happen.
Interesting experiment I had a look at. Since the 0.106.3 and 0.107.0 release the binary size (using ARMv7 as the sample) has grown a fair bit, in OpenWrt land this is more of an issue than other platforms for directly storing in flash/overlay which is what the opkg package will do. While there is exroot and persistent storage via USB etc which would be recommended, I did wonder if the binary can be compressed without breaking it.
Throwing the 0.107.0 ARMv7 release through upx, it compressed it down to 10 MB, down from 32.1 MB (original binary from GitHub) which is a 68% reduction. It runs on OpenWrt fine, there doesn't seem to any major issues, but I'm sure they'll likely be performance trade offs, possibly with startup time and maybe some calls within.
It did make me wonder though, if the binary continues to increase at such a rate without compression or optimisation during the build source phase, it's going to be very impractical for most routers to even have the opkg package install potentially.
I did raise a discussion on the AdGuard Home GitHub for comments.
I don't know if the build from source does any compression or optimises the release builds, I'm not really that experienced with Go related software. I'm going to run the compressed binary on my own router and see if there's any major issues though, 68% compression from the original is pretty good though.
Edit: The AdGuard team seem to think this is specific to 0.107.0: https://github.com/AdguardTeam/AdGuardHome/issues/4025
1 Like
can i add my ipv6 to bind host?
You have already.
::1 is short form for your .1 address in ipv6 space.
127.0.0.1 is localhost.
::1 is ipv6 host
192.168.1.1 is ipv4 host.
::1 not localhost ip6 ?
correct. it is.
I have a question, can i use AGH and ipset at the same time because when i redirect port 53 to agh it break my ipset rule ( example i use mwan3 ipset for some websites go through vpn, use AGH -> ipset not work or i use firewall to block some websites with ipset, it stop working when use AGH ). I can use vpn-policy-routing for it but i want use only mwan3. Tks.
try use the latest edge build they fixed some ipset errors in it.
2 Likes
What issue with ipset are you having? If you were previously using dnsmasq + ipset, you will need to migrate your ipset policies to AGH when used as the primary DNS resolver.
AGH has a different syntax for ipset policies. I wrote an example of how you create policies on the wiki, as it's not that clear from the official AdGuard Home wiki (or at least I didn't find it that clear).
I use mwan3 too and ipset is working fine based on my testing. I have several ipset routing rules in my mwan3 config which are working as expected, after migrating to AGH. I have confirmed the lookup of a domain in an ipset policy will get added to the referenced chain like dnsmasq.
Providing you have ipset policies configured in AGH, there should be no changes required in terms of mwan3, given AGH is not responsible for the policy based routing side.
I would setup a test ipset policy in AGH, confirm a lookup through AGH adds the IP address of the domain to the policy and then check your ipset rules in mwan3.
1 Like
Not sure if this is the best place to provide wiki feedback, but regarding the Debugging section. It might be worth noting that the init script (at least of the opkg package) bridge AGH stdout/stderr to syslog, so you can query for errors via
# logread -e AdGuardHome
1 Like
Noted and wiki updated. Thanks.
Looks like the AdGuard team have snuck in two stable releases since 0.107.0. There is now a 0.107.1 and 0.107.2. I've personally hit a bug that's fixed in the latest stable, I'll send a PR to update the opkg package to 0.107.2, seems to fix a few areas which some users might hit.
That's pretty much why i just use the edge builds. While stable builds are preferable, i do feel that AGH is definitely more agile/reactionary with builds.
As of yet i've not encountered any showstoppers with edge builds, but it does have its risks.
The development cycle currently seems very agile and rapid, but stable is always going to be preferred or a good idea, as eventually a stable release would need to be in master to then backport down to 21.02 or whatever the latest release branch is.
Maybe after the 1.0.0 milestone, releases may settle down a bit, but I'm happy to PR new stable releases, in conjunction with maintainers. It's easy enough to get alerts when new releases happen and I've got an OpenWrt buildroot setup to compile test packages.
1 Like