[stork-users] Fresh Stork 2.2.0 does not discover fresh Kea DHCP 3.0.0 instalation

[Slawek Figiel]

Hello Corby!

Stork indeed requires the Kea Control Agent to be able to monitor Kea 
daemons. We are implementing support for CA-less installations. You can 
track the progress in: 
https://gitlab.isc.org/isc-projects/stork/-/issues/1835 .

The configuration of the Kea Control Agent is described in Kea ARM in 
this section: 
https://kea.readthedocs.io/en/kea-3.0.0/arm/agent.html#configuration

You can find some examples of working and Stork compatible 
configurations in the Stork demo files. For example: 
https://gitlab.isc.org/isc-projects/stork/-/blob/master/docker/config/agent-kea/kea-ctrl-agent.conf?ref_type=heads

I'm looking forward for your feedback of using Stork.

Best regards,
Slawek Figiel

On 7/22/25 8:19 PM, Corby Stephens wrote:
> Let's just say I've gotten really good at installing Kea, Stork Server 
> and Agent, even getting them talking to Postgresql. 🙂 What is missing 
> is instructions on kea-ctrl-agent and how to configure it in this 
> context. Can someone give me the basic, bare-bones version I can easily 
> get the stork agent and server talking on the same machine? What I need 
> now is the kea-ctrl-agent basics.
> 
> I need to get this working in stages, not straight to the end result. I 
> need a proof of concept first. And yeah, I do see it is meant ultimately 
> for a larger scale. In my case, the end goal will be a simple main and 
> HA backup for a rural ISP of five /22 IP blocks.
> 
> Thanks for your help BTW.
> 
> 
> *Corby Stephens, Fiber Network Administrator* | *ACCESS* Anacortes Fiber 
> Internet | P.O. Box 547 | 904 Sixth Street | Anacortes, WA  98221
> 
> Office:  360.588.8362 | Cell:  360.873.3770 | corbys at anacorteswa. 
> <mailto:corbys at anacorteswa.>gov | www.anacorteswa.gov/fiber <http:// 
> www.anacorteswa.gov/fiber>
> 
> ------------------------------------------------------------------------
> *From:* Stork-users <stork-users-bounces at lists.isc.org> on behalf of 
> Kevin P. Fleming <lists.stork-users at kevin.km6g.us>
> *Sent:* Tuesday, July 22, 2025 11:07 AM
> *To:* stork-users at lists.isc.org <stork-users at lists.isc.org>
> *Subject:* Re: [stork-users] Fresh Stork 2.2.0 does not discover fresh 
> Kea DHCP 3.0.0 instalation
> 
> ******    This email is from outside the City of Anacortes network.  
> Please use caution when clicking on links, opening attachments, or 
> replying.   ******
> 
> On Tue, Jul 22, 2025, at 13:57, Corby Stephens wrote:
>> The section heading is misleading. In my case I was not upgrading to 
>> Kea 3, it was my starting point, so I saw no reason to read that. 
>> Also, the ARM docs do not mention a need to the Control Agent in 
>> either Kea or Stork.
>>
>> That being said, having never configured the Control Agent, what is 
>> the proper configuration when hosting Kea and Stork on the same server 
>> (basic, getting started, get them talking, no SSL yet level)? Again, 
>> I'm brand new to Kea, Stork, this whole ecosystem. The docs need to be 
>> written at that level. My main DHCP experience is Microsoft based so 
>> I'm not new to DHCP itself, but this is a very different platform in 
>> terms of setup/configuration.
> 
> You're absolutely right... even the Stork 'quick start guide' just 
> assumes that you already know you need the Kea Control Agent installed: 
> https://kb.isc.org/docs/stork-quickstart-guide#installing-the-stork- 
> agent <https://kb.isc.org/docs/stork-quickstart-guide#installing-the- 
> stork-agent>
> 
> Pay attention also to that guide's warnings about installing the Stork 
> Server and the Stork Agent on the same machine; the default 
> configuration of those two services will conflict with each other and 
> one will have to be changed.
> 
> If your goal is to provide DHCPv4 service with Kea and monitor it with 
> Stork, then you'll need to install the Kea DHCPv4 server and the Kea 
> Control Agent, and you'll also need to install the Stork Server and the 
> Stork Agent. In case it wasn't clear, these tools are generally intended 
> for large (not single server) deployments where some of the pieces run 
> on different machines, which is why there are so many pieces!
> 
>