Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Granular DHCP Sync - Support for Static Leases Only #487

Open
Cycledudebcn opened this issue Jan 19, 2025 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@Cycledudebcn
Copy link

Is your feature request related to a problem? Please describe.

Feature Request: Granular DHCP Sync - Support for Static Leases Only

Context

Following up on #29 regarding DHCP sync control, there's a need for more granular control over DHCP synchronization. While we can currently exclude DHCP sync entirely using exclude: ["dhcp"], this prevents syncing of static leases which are crucial for high-availability setups.

Feature Request

Add support for selective DHCP synchronization, specifically allowing static lease sync while keeping other DHCP settings independent between instances.

Use Case

In a high-availability setup:

  • Primary AdGuard Home instance runs the DHCP server
  • Secondary instance acts as a failover
  • Static DHCP leases need to stay synchronized between instances
  • DHCP server should remain disabled on secondary until needed
  • Current workaround (excluding all DHCP sync) prevents keeping static leases in sync

Proposed Implementation

Add granular control over DHCP sync components. For example:

sync:
  dhcp:
    sync_leases_only: true  # New option to sync only static leases
    # OR
    include:
      - static_leases
    exclude:
      - server_config
      - interface_settings

Alternative syntax could be:

sync:
  include:
    - dhcp.static_leases
  exclude:
    - dhcp.server_enabled
    - dhcp.server_config

Benefits

  1. Maintains static lease consistency across instances
  2. Prevents unintended DHCP server activation
  3. Supports proper failover scenarios
  4. Reduces need for external sync solutions

Technical Considerations

  1. AdGuard Home API already separates static leases in its endpoint structure (/control/dhcp/static_leases)
  2. Could potentially leverage this existing separation in the sync tool
  3. Minimal impact on existing functionality

Alternative Solutions Considered

  1. External sync script just for static leases (more complex to maintain)
  2. Manual lease management (error-prone and time-consuming)
  3. Full DHCP sync with post-sync disable (race conditions, complexity)

Related Issues

Describe the solution you'd like*

/config.yaml
...
sync:
dhcp:
sync_leases_only: true # Simple, single option to sync only static leases

This a preferred approach since:

  1. It's simple and explicit in its purpose
  2. It doesn't require complex nested configuration
  3. It's clear what it does from the name alone
  4. It's a single toggle rather than managing multiple includes/excludes

Describe alternatives you've considered

No response

Anything else?

No response

@Cycledudebcn Cycledudebcn added the enhancement New feature or request label Jan 19, 2025
@bakito
Copy link
Owner

bakito commented Jan 19, 2025

Hi @Cycledudebcn

Thank you for your request.

What config do you use?
Adguardhome-sync does not provide any 'exclude' functionality. Hence it the config exclude: ["dhcp"] has no effect for the application.

Dhcp behaviour is condifured via feature flags, where you can toggle server config separately from static leases.

# Configure sync features; by default all features are enabled.
features:
  dhcp:
    serverConfig: true
    staticLeases: true

@Cycledudebcn
Copy link
Author

Oh! I see.. thanks for the clarification! I was completely off with the 'exclude' approach.
The feature flags are exactly what I need - will test this right away! 👍
much appreciated!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants