On 3/6/26 10:06, Uwe Jasper wrote:
After the recent Stork update my Stork agent can no longer work with the
Kea control agent to read the DHCP server state. Every time I restart
the Kea DHCP4 service it recreates the socket with the default
permissions and Stork fails. When I manually update the permissions on
run/kea/kea4-ctrl-socket to 660 everything works again, but only till
the next restart.
I have been seeing similar in my own environment.
From what I've seen, this does not involve the Kea Control Agent
(KCA). Rather, what's happening is, the Stork agent is trying to
connect to the Kea daemon's own control socket. (This is the "direct
API" mechanism, bypassing the KCA, new in Kea 3.0 and Stork 2.4.) The
Stork agent then hits the socket permission problem you noted.
I'm still working through the permutations to determine exact
scenarios and workarounds.
I don't know yet if there's a way to force the Stork agent to use the
KCA and not try the Unix domain socket.
Another thing that occurs to me as a workaround is to have the
systemd unit which starts the Stork agent do a ExecStartPost with chmod
to fix-up the socket permissions each time. Again, haven't tested this yet.
I'll follow-up here with the GitHub Issue once I get the particulars
nailed down.
-- Ben
--
Any opinions expressed in this message are those of the author alone.
All information is provided without warranty of any kind.
--
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.
[email protected]
