Skip to content

Deployment Scenarios

Kaleb Fenley edited this page Jul 29, 2026 · 1 revision

Deployment Scenarios

EZ-Kea figures out what to manage at startup, before serving a single request. DHCPv4 and DHCPv6 are resolved independently, so a host running only kea-dhcp4 lands in LIVE mode for v4 and DEMO mode for v6 — the two are never collapsed into one shared answer.

How discovery works

In order, stopping at the first match:

  1. Saved UI settings win. If a settings file exists (ez-kea-settings.json in your data directory), EZ-Kea uses the paths recorded there. The mode is then LIVE unless the configured path looks like a sandbox (data/kea).
  2. A running daemon. EZ-Kea scans /proc for a process whose name or argv[0] matches kea-dhcp4 / kea-dhcp6, then reads the config path from the -c / --config argument on its command line. If the daemon was started without an explicit -c, EZ-Kea assumes the packaged default (/etc/kea/kea-dhcp4.conf). → LIVE
  3. A standard config file on disk, even with nothing running. Checks /etc/kea/kea-dhcp4.conf then /usr/local/etc/kea/kea-dhcp4.conf (and the v6 equivalents), plus any path already set via environment variable. → LIVE
  4. Nothing found. Falls back to a sandbox under ./data/, creating a config skeleton if needed. → DEMO

The mode is displayed as a badge in the navbar on every page.

Scenario 1: Kea is already running

The intended path. Install EZ-Kea anywhere on the same host and start it — it finds the daemons, binds to the exact config files they were launched with, and comes up in LIVE mode. Nothing to configure.

Scenario 2: Kea is installed but stopped

Discovery finds the config at its standard location and binds to it. You can edit configuration normally; applying changes will try to reload a daemon that isn't running, which fails harmlessly — start Kea and the config is already where it expects.

Scenario 3: No Kea at all

EZ-Kea creates ./data/ with a config skeleton and runs in DEMO mode. Useful for evaluating the UI, modelling a network before building it, or developing against EZ-Kea itself.

Changes are written to the sandbox only. Nothing touches a real DHCP server.

Scenario 4: Kea in a non-standard location

If your config lives somewhere discovery doesn't check, either set DHCP_CONFIG_FILE / DHCP6_CONFIG_FILE in the environment, or point EZ-Kea at it in the UI under Global Settings → Application Settings. UI settings persist to ez-kea-settings.json and take priority over discovery on every subsequent start (rule 1 above).

Scenario 5: Kea in Docker

Supported, with extra settings for the container's filesystem namespace and reload mechanism. See Installation.

Pinning EZ-Kea to a specific config

Discovery re-runs on every start, which is usually what you want — but not always. If a real /etc/kea/kea-dhcp4.conf might appear on a host where you want EZ-Kea to stay on a sandbox, pin it explicitly:

SETTINGS_FILE=/srv/ez-kea/data/ez-kea-settings.json
DHCP_CONFIG_FILE=/srv/ez-kea/data/kea-dhcp4.conf
DHCP6_CONFIG_FILE=/srv/ez-kea/data/kea-dhcp6.conf

Environment variables take priority over saved settings, and both take priority over process discovery.

Clone this wiki locally