technically you could just backup the entire /opt/AdGuardHome folder and subfolders and redeploy it back to a new router. As long as you also re-run the script to move dnsmasq etc.
Personally i'd just reuse the script to reinstall from clean OpenWrt install and then port any yaml settings from your backup.
My reasoning for this is basically it doesn't take long to re-setup from scratch and AGH is evolving fairly rapidly. They have stated that config changes will come when they refactor certain modules (eg the DHCP settings etc)
It is far better to start with a clean install and debug or copy your tweaks to it, than to copy what was working but may be out of date from an old backup. (I've been bitten by this with yaml version changes in the past)
The yaml file and maybe the stats database are the only really "key" files in terms of data. Filters and the program itself can be redownloaded. Its your config setup that will be personal to you and also any statistics/querylogs you wish to keep. Everything else is replaceable really.
@mercygroundabyss, that part in your tutorial still goes 192.168.1.1:5353, but in the rest of the tutorial you say 127.0.0.1:5353, the part that contains 192.168.1.1:5353 is wrong? I always get confused on this part, sometimes I don't know if the correct thing is to add 127.0.0.1:5353 or 192.168.1.1:5353.
@mercygroundabyss Yes, it is possible the opkg version to not start on boot due to race conditions which certain network setups. Short of changing the start value, there isn't an easy fix because it is quite variable.
The consideration is AdGuardHome devs have made the start value equal to when /etc/rc.local is called, that's right at the end the boot process, which isn't ideal.
The issue is these network race conditions aren't always going to happen, it's down to individual setups. I'm wondering if the opkg version should allow you to configure a custom START value in it's config, as currently it will get wiped on any sysupgrade.
I'm not sure the solution is to just increase the START value to 95, as it's way too late in the boot process for something as critical as DNS.
The workaround I found is implementing a custom init script that runs before AdGuardHome to make sure other network conditions are available before it tries to start.
We could bump the start value a bit, as perhaps 21 is a little too early for all network related areas to be completed, but I wouldn't go as far as increasing to 95.
However one consideration is changing the bind_host/bind_hosts value from 0.0.0.0 could lead to this issue, if you set a specific address that's not available.
There is possibly an argument to leave the bind values as default to any available address, because the firewall rules should prevent access outside of the LAN. Likewise dnsmasq also defaults to all network addresses by default to bind to.
As long as your router is 192.168.1.1 then both will work.
I was using 127.0.0.1 (the local loopback) for statistics tracking for ptr requests. I should redo the image really. local loopback basically says look it up yourself but use internal instead of external ip.
its an on or off selection in the ui. I'm dubious about having it on by default. things are SUPPOSE to expire from your cache to stop it filling up with rubbish. Visit one site and never go back? it will still be permacached with that on.
However... they arent very clear what it actually does. It appears if the option is checked then AGH will reply with the expired DNS entry but a very short TTL and will query the upstream and replace the expired cache version.
I guess a better answer from them as to what it really is doing behind the scenes would be better.
What you can do is change the OVERALL DNS cache size by editing the value below.
But opportunistic mode is an on off tick only.
Have you seen this other alternative to PiHole and AdGuard Home?
I've just accidentally found it and it looks very similar to AGH. On the +side, it includes a builtin DHCP server that may work as expected... On a possible -side, I haven't seen any mention to per client settings, which would be a no, no for me. (I haven't tried it yet, just found it...)
In short what i've found out is that AdGuard DNS is a mix of their own hosted DNS service and AdGuard Home. Sort of a middle ground but less configurable.
it should in theory also be deployable like AGH, but given some of the chatter i've seen, I will be sticking to AGH.
If you're already using AGH, I don't think you'll find anything worthwhile in the DNS Beta. You can't add an arbitrary list, you can't share a single config between multiple devices and have them identified separately, you can't use your own identifier string in DoT/DoQ subdomain or DoH path to add specific filtering and device identification, you can't even disable logging.
Right now the DNS Beta is more geared toward those who can't be bothered to set up AGH.
I still must get around to a new install of AGH and try dhcp but without being able to have upstream IPv6 its not really a proper test and thus i wouldn't be able to give it a proper shakedown before doing recommendations to the thread
Just installed it to a spare RPi4, now trying to make sense of it.
On the subject of a possible missing per client settings, I just found out it may support this feature by means of additional "Apps" you can deploy to your Techinitium instance. I have just added three Apps to my test installation.
After installing and testing the alternative adblocker I mentioned above, I found it to be an intelligently designed application, with a lot of potential to grow. I'm currently using it as the DNS server for my own private workstation and it's been able to block everything AdGuardHome blocks. The main feature I find it lacks and is present in AdGuardBlock is the ability to very easily block Services (see below), without the need to manage a list of individual domains. I will keep following it with interest as it's developer seem to be actively enhancing it.
uninstall and reinstall with their script.... oooorrrr... stop AGH. copy the stable binary over the top the existing one and restart.
I'm curious however. The stable is quite far behind edge and i know re-writing DNS entries was broken in stable. It is fixed in edge. While edge builds traditionally in software tend to break things. I've not had AGH edge builds fail on me (yet).
Is there any particular reason you want to switch back?
curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v
Dont get me wrong. The stable branch is ok, but fixes get deployed faster to the edge builds and they have patched a fair bit of stuff recently.
the dns rewrite issue popped up recently as i know it was previously working as i'd been using it. So its been working, got broken, and got fixed again. ( I hadn't noticed because i switched back to using ip addresses but a friend who uses names for his ARR stack was "urm. why doesn't this work?")
Here when I try to install adguardhome now I always get this error: starting AdGuard Home installation script
2022/06/16 11:43:34 [info] service: control action: install
6/16/2022 11:43:34 [fatal] service: executing action "install": Failed to install AdGuard Home service: command "update-rc.d" failed: exec: "update-rc.d": executable file not found in $PATH:
cannot install AdGuardHome as a service
It is looking for something to run but not finding it. the $PATH is where it search for executables.
We need to narrow down exactly what it is that AGH is searching for and ensure it is installed on OpenWrt to fix it, or we need to file a bug on AGH issues page for them to fix the error.
