That is mostly accurate. Stork manages Kea via the API, so without the hooks that provide such, Stork won't be able to manage the system either.
Thank you, Darren Ankney On Fri, Apr 12, 2024 at 10:53 AM Dan Geist <d...@polter.net> wrote: > > The way I read (the admittedly slightly confusing set of pages) is that both > MySQL and PostgreSQL are supported as configuration backends in the latest > stable open source version, but the hooks to do certain things (like per-host > lease reservations, bulk-lease-query and API-based configuration of the DB > backend) are only available with the paid support. Anything you want to do > with those db backends to replicate/distribute/manage are probably workable, > as are 3rd part db HA solutions (there are a few whitepapers out there on > people doing KEA with PostGres HA, etc. Obviously, you'll have to implement > that part on your own without paid support. > > The Stork project might give you some extra flexibility but I believe it > manages KEA instances natively via API/memfile config and is not compatible > with the Db backends. > > ISC folks, is this accurate? > > Dan > > ----- On Apr 12, 2024, at 8:09 AM, Udo Rader udo.ra...@bestsolution.at wrote: > > > Hi, > > > > even after searching the list archives and the docs, I am not really sure > > what > > the migration path for our existing ISC DHCP server could look like. > > > > Currently we are using ISC DHCP in three different places (data centers). > > They > > all consume their configuration (subnets, static host entries, DHCP options, > > ...) from an OpenLDAP server, which is replicated to the different data > > centers. > > > > Every data center has its own base DN in LDAP, eg > > > > dhcpd.conf in data center1: > > [...] > > ldap-base-dn "ou=DC1,ou=DHCP,dc=example,dc=com"; > > [...] > > > > dhcpd.conf in data center 2: > > [...] > > ldap-base-dn "ou=DC2,ou=DHCP,dc=example,dc=com"; > > [...] > > > > dhcpd.conf in data center 3: > > [...] > > ldap-base-dn "ou=DC3,ou=DHCP,dc=example,dc=com"; > > [...] > > > > Leases are stored locally and they are irrelevant for migration. > > > > I understand that KEA does not support LDAP as a backend and so I would be > > willing to migrate the existing configuration to something else, but even > > after > > reading the docs, I fail to fully understand what my options are. > > > > My best guess so far is that I could replace LDAP by either MySQL or > > Postgres, > > configure database replication and have the various local KEA instances > > connect > > to the replicated local database instances. Is that correct? > > > > And if so, am I right to assume that for this to work, I need the "Kea > > Configuration Backend" (which requires a support subscription)? > > > > Thanks for any insights. > > > > Udo > > ________________________________ > > > > Udo Rader, MSc, MBA, Head Unicorn Wrangler > > BestSolution.at EDV Systemhaus GmbH > > Salurner Straße 15, 6020 Innsbruck, Austria > > https://www.BestSolution.at > > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > [BestSolution] > > -- > > ISC funds the development of this software with paid support subscriptions. > > Contact us at https://www.isc.org/contact/ for more information. > > > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > > > Kea-users mailing list > > Kea-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/kea-users > > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > Kea-users mailing list > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
