Sync all DHCP settings, but do not enable it about adguardhome-sync HOT 21 CLOSED

Seems logical.

I wonder, @tapufd @bakito , why a should another instance even accept dhcpd-settings, when it is not enabled on that instance?
As it’s always a one-way sync/transfer.

from adguardhome-sync.

Currently there's only the option to sync or not sync DHCP Settings.

from adguardhome-sync.

If I disable the DHCP server on the REPLICA (how it should be as it is enabled on the ORIGIN), and a sync is done from ORIGIN to REPLICA, the DHCP server is again enabled on the REPLICA.
This should be avoided, as no 2 DHCP servers should be running on the same LAN.
That is why I would prefer an option to sync the DHCP settings, but not enable DHCP on the REPLICA.
I have a master-standby setup running, so if the ORIGIN (master) is having issues, I can activate the REPLICA (standby) one.

from adguardhome-sync.

If I disable the DHCP server on the REPLICA (how it should be as it is enabled on the ORIGIN), and a sync is done from ORIGIN to REPLICA, the DHCP server is again enabled on the REPLICA. This should be avoided, as no 2 DHCP servers should be running on the same LAN.

I think you are searching for some fail-over solution?

If not, maybe you can explain a bit clearly what the problem/scenario is you want to solve?

That is why I would prefer an option to sync the DHCP settings, but not enable DHCP on the REPLICA. I have a master-standby setup running, so if the ORIGIN (master) is having issues, I can activate the REPLICA (standby) one.

It's fine to run 2 DHCP servers.
Not an very usual setup, but certainly not forbidden.

However, DNS and DHCP in itself do not need fail-over that enables a replica when the origin fails.
DNS has its own way (as in: specify at least 2 DNS-addresses) and DHCPd uses Discovery/DORA-principle

Also: there is always (only) one origin and one (or more) AGH replica's.
It's a one-way sync; so even in the case (only) the replica becomes active, the origin=previous DHCPd will be in the dark anyway.

from adguardhome-sync.

I use keepalived to move a certain IP between an active-passive setup.
That IP has certain services linked to it:

• DNS (AdGuard Home)
• stunnel
• ...

If the active node goes down, that IP goes to the passive node and handles services there.
However DHCP (also provided by AGH) cannot be linked to that IP, and uses the local IP of the node.
So I have a script that is triggered by keepalived, that can enable/disable DHCP from AGH (via REST API) on the corresponding node.
But like I said, the sync of the DHCP settings overwrites my DHCP-enabled setting on the REPLICA.
Having 2 DHCPs on the same LAN is not recommended, as both can hand out the same ip-adresses to different devices on the LAN, as they are not aware of eachother.
This leads to duplicate IP situations.

from adguardhome-sync.

I use keepalived to move a certain IP between an active-passive setup. That IP has certain services linked to it:

• DNS (AdGuard Home)
• stunnel
• ...

If the active node goes down, that IP goes to the passive node and handles services there. However DHCP (also provided by AGH) cannot be linked to that IP, and uses the local IP of the node. So I have a script that is triggered by keepalived, that can enable/disable DHCP from AGH (via REST API) on the corresponding node. But like I said, the sync of the DHCP settings overwrites my DHCP-enabled setting on the REPLICA.

Very specific, also sounds somewhat unstable here to switch over an IP for (i think) core services.

As you are already using the API of AGH: cant you just use / enhance your script to en/disable dhcp on the replica / origin, as needed?

Or use a separate DHCP server, and/or specific ip-ranges per server

IMHO this is not an issue with or for adguard-sync.

from adguardhome-sync.

ok, np, will look for another solution then.

from adguardhome-sync.

ok, np, will look for another solution then.

Oh well, a PR implementing your issue might get accepted ;)
Or if @bakito sees a fit to implement

from adguardhome-sync.

@tapufd I could add a flag on the replica which defines the dhcp server REPLICA1_DHCPSERVERENABLED can you give it a try with the latest main image?

docker pull ghcr.io/bakito/adguardhome-sync:main

@bartclone Thank you for the support in this

from adguardhome-sync.

Cool, many thanks!
Will test it asap and give some feedback here...

from adguardhome-sync.

I just realize that I use the config file setup:

replica:
url: http://x.x.x.x
insecureSkipVerify: true
username: ***
password: ***
interfaceName: eth0

What you mention above is for the docker compose file, I assume?
How does this fit in my config file setup?
Just add "DHCPSERVERENABLED: false" under replica?
Thx!

from adguardhome-sync.

Its dhcpServerEnabled under replica.

from adguardhome-sync.

It works like a charm!
Many, many thanks for implementing this!

from adguardhome-sync.

Is there going to be a new release for this?
I'm using the linuxserver.io version of your docker-image, because it allows some fine-tuning like the timezone.
Expect that they will only release a new version of their image if you release a newer version.
But I could be wrong of course...

from adguardhome-sync.

Yes, there will be a new release

from adguardhome-sync.

released in https://github.com/bakito/adguardhome-sync/releases/tag/v0.4.13

from adguardhome-sync.

released in https://github.com/bakito/adguardhome-sync/releases/tag/v0.4.13

i'm trying to disable dhcp activation but i'm not able, can you please tell me where to add dhcpServerEnabled: false?
i've tried under replicas but got an error, under features does nothing

thanks in advance

from adguardhome-sync.

Please check the readme.

features:
  ...
  dhcp:
    serverConfig: true
    staticLeases: true

from adguardhome-sync.

dhcpServerEnabled: false

i did but im talking about the dhcpServerEnabled: false entry

from adguardhome-sync.

there's an example in the test files:

from adguardhome-sync.

from adguardhome-sync.