[stork-users] Cannot get state of machine
Slawek Figiel
slawek at isc.org
Mon Feb 16 16:44:03 UTC 2026
Hi Bart!
Sorry for the delay. I was pretty busy recently.
> But, I changed the port in the webinterface to 8081 during the
troubleshooting and still it threw the error
Please, don't change the hostname and port using web UI. This feature is
planned to be reviewed because we are not sure if all corner cases are
handled properly. Instead, re-register your machine (run the Stork agent
"register" command or run it with the --server-url flag). Then, examine
the unathorized machine list to check if there is a new machine.
Please verify that the hostname (`--host`/`--agent-host`) and port
(`--port`/`--agent-port`) flags or corresponding environment variables
are okay. It means you can use them to establish connection from the
host with installed Stork server to the host with installed Stork agent.
If you use the register command, please carefully check that the
provided CLI flags are equal to the CLI flags/environment variables that
you provide to the Stork agent when you run it.
> The bug about not being able to delete machines is still there and
because they can't connect (because of neglecting to enter 8081 instead
of 8080 during the registration process), the log gets flooded with
reports about that. Fortunately the log is in a RAM-disk.
We are working on it. As a temporary solution, you can delete the
corresponding row in the "machine" table in the Stork database.
> Unfortunately I haven’t got it working on the system I want to use
Stork on. That system has since then been set up as a router, with a
nftables firewall with the default policies all on drop (the drop all,
except approach). From what I can tell (I temporarily enabled traffic
logging), communication between Agent and Stork goes through the
loopback interface, but I haven't been able to let nftables accept this
traffic. Tried allowing all traffic coming in and out of the loopback
interface, no luck, the registration process keeps cancelling because of
a timeout.
You should use the loopback/localhost address only if the Stork server
and Stork agent are installed on the same host. If these components are
separated, then the --host flag you provide in the Stork agent must be
an IP address or a hostname available on the server host.
Example configuration:
Assume you have a Stork server installed on the machine with hostname:
"server-computer". It should listens on 192.168.0.5 address and 8080
port. You should specify: STORK_REST_HOST=192.168.0.5 and
STORK_REST_PORT=8080. You can also listen on hostname:
STORK_REST_HOST=server-computer.
You also have a second machine with installed Stork agent. Its hostname
is "agent-computer". It should listens on 192.168.0.10 and 8888 port.
You decided to not use the register command, but allow Stork agent do it
internally. You should specify: STORK_AGENT_HOST=192.168.0.10,
STORK_AGENT_PORT=8888, STORK_AGENT_SERVER_URL=http://192.168.0.5:8080.
You can also listen on hostname: STORK_AGENT_HOST=agent-computer.
Remember that the server host must be able to establish connection to
the agent over 192.168.0.10:8888 (GRPC protocol) and the agent must be
able to establish connection to the server over 192.168.0.5:8080 address
(HTTP protocol).
If you was able to register agents, it means the server configuration
should be correct.
Regards,
Slawek Figiel
On 2/16/26 5:16 PM, bart at ravenslair.nl wrote:
> Uhm, pfSense? I ditched that back when .... pfSense Embedded 1.2.2 was current (2009?) and I ran into a crappy driver. After that I briefly went to IPFire, which still does not support IPv6 (my tutorial to get that working got deleted, still available in the webarchive though), to end up with Debian for like a decade or so now.
>
> A clean install of Stork sounds like a good idea, since that seems to be the only way to get rid of the undeletable machines.
>
> -----Oorspronkelijk bericht-----
> Van: Darren Ankney <darren.ankney at gmail.com>
> Verzonden: maandag 16 februari 2026 10:45
> Aan: bart at ravenslair.nl
> CC: stork-users at lists.isc.org
> Onderwerp: Re: [stork-users] Cannot get state of machine
>
> Hi Bart,
>
> I'm afraid I can offer no help with your pfsense issues. As far as the Stork Server is concerned, and deleting non-working machines, I would suggest (after solving all of the problems with the agents), removal of the stork server (including dropping it's database) and installing again. Then you can repeat the now working steps of registering the agents and wind up with only working agents listed there.
>
> Thank you,
> Darren Ankney
>
> On Sun, Feb 15, 2026 at 11:41 AM <bart at ravenslair.nl> wrote:
>>
>> Yes, it works, though only in the virtual machine I tested the fix in. Turned out I missed this bit of the quick start guide:
>> "Altered Stork Agent Port
>> If you had to alter the Stork Agent Port to 8081 due to cohabitation with the Stork Server, then you will have to specify the port number during the registration process as shown here: >>>> Enter port number that Stork Agent will listen on [8080]: 8081"
>> After redoing the registration and entering 8081 at the 3rd question, it works.
>>
>> The bug about not being able to delete machines is still there and because they can't connect (because of neglecting to enter 8081 instead of 8080 during the registration process), the log gets flooded with reports about that. Fortunately the log is in a RAM-disk.
>>
>> Unfortunately I haven’t got it working on the system I want to use Stork on. That system has since then been set up as a router, with a nftables firewall with the default policies all on drop (the drop all, except approach). From what I can tell (I temporarily enabled traffic logging), communication between Agent and Stork goes through the loopback interface, but I haven't been able to let nftables accept this traffic. Tried allowing all traffic coming in and out of the loopback interface, no luck, the registration process keeps cancelling because of a timeout.
>>
>>
>>
>> -----Oorspronkelijk bericht-----
>> Van: Stork-users <stork-users-bounces at lists.isc.org> Namens Darren
>> Ankney
>> Verzonden: zondag 15 februari 2026 14:20
>> Aan: stork-users at lists.isc.org
>> Onderwerp: Re: [stork-users] Cannot get state of machine
>>
>> Hi Bart,
>>
>> It is unclear to me where you are with regard to the original problem.
>> Is communication now working between the agent and server on 8081? To
>> find out if your stork-agent is indeed listening on 8081 as planned,
>> execute: `ss -tulnap | grep 8081` to see if anything is returned.
>> Example:
>>
>> $ ss -tulnap | grep 8081
>> tcp LISTEN 0 5 192.168.40.42:8081
>> 0.0.0.0:*
>>
>> Thank you,
>> Darren Ankney
>>
>> On Sat, Feb 14, 2026 at 3:16 AM <bart at ravenslair.nl> wrote:
>>>
>>> The unable to delete looks like
>>> https://gitlab.isc.org/isc-projects/stork/-/issues/1887
>>>
>>> Oh and "contains port 80801" should've been "contains port 8081", typo....
>>>
>>>
>>> -----Oorspronkelijk bericht-----
>>> Van: Stork-users <stork-users-bounces at lists.isc.org> Namens
>>> bart at ravenslair.nl
>>> Verzonden: zaterdag 14 februari 2026 09:06
>>> Aan: 'Darren Ankney' <darren.ankney at gmail.com>;
>>> stork-users at lists.isc.org
>>> Onderwerp: Re: [stork-users] Cannot get state of machine
>>>
>>> "During the registration of the stork-agent step, did you perhaps forget to specif 8081 in the dialogue?"
>>> ...... seriously, how could I have missed that, twice. That seems to be it, thanks!
>>>
>>> But, I changed the port in the webinterface to 8081 during the troubleshooting and still it threw the error, now that I entered the port in the dialog the location in the webinterface contains port 80801, which I had already tried entering there and it didn't solve the problem. That's weird, isn't it?
>>>
>>> Also, now there's a new problem: the not working machines cannot be deleted:
>>> Error deleting machine: Cannot delete machine 1 Error deleting machine: Cannot delete machine 2 This using the webinterface, now to look for the file they are stored in, guess I'll have to remove them that way.
>>>
>>>
>>> -----Oorspronkelijk bericht-----
>>> Van: Stork-users <stork-users-bounces at lists.isc.org> Namens Darren
>>> Ankney
>>> Verzonden: vrijdag 13 februari 2026 11:18
>>> Aan: stork-users at lists.isc.org
>>> Onderwerp: Re: [stork-users] Cannot get state of machine
>>>
>>> Hi Bart,
>>>
>>> This log message:
>>>
>>> stork-server[10579]: time="2026-02-08 14:11:35" level="warning"
>>> msg="failed to get state from agent PlrtzGlrb:8080: grpc manager is unable to make a call to the agent PlrtzGlrb:8080: rpc error: code = Unavailable desc = connection error: desc = \"transport:
>>> authentication handshake failed: tls: first record does not look like
>>> a TLS handshake\"" file=" statepuller.go:246 "
>>>
>>> Appears to show that the Stork server is trying to connect to the
>>> agent on port 8080 instead of 8081. During the registration of the
>>> stork-agent step, did you perhaps forget to specif 8081 in the
>>> dialogue? See:
>>> https://kb.isc.org/docs/stork-quickstart-guide#register-stork-agent1
>>> where it says:
>>>
>>>> Altered Stork Agent Port
>>>>
>>>> If you had to alter the Stork Agent Port to 8081 due to
>>>> cohabitation with the Stork Server, then you will have to specify
>>>> the port number during the registration process as shown here:
>>>> `>>>> Port number that Stork Agent will listen on [8080]: 8081`
>>>
>>> Thank you,
>>> Darren Ankney
>>>
>>> On Thu, Feb 12, 2026 at 3:44 AM <bart at ravenslair.nl> wrote:
>>>>
>>>> Hi Slawek,
>>>>
>>>> Yeah, that's what it looks like indeed, but what config exactly? I followed the quick start guide, but since that was written before Debian 13 was released, I am now wondering if there's more wrong with that guide than just a package not existing for Debian 13.
>>>>
>>>> "STORK_AGENT_PORT"
>>>> As stated by the guide: "Please note that if the Stork Server and Stork Agent are both on the same machine, that they both default to port 8080. The easiest thing to do is alter /etc/stork/agent.env uncommenting the STORK_AGENT_PORT directive and setting thusly: STORK_AGENT_PORT=8081. This way, the agent will listen on port 8081 and the server will listen on port 8080 as per default."
>>>> Did that.
>>>>
>>>> "STORK_AGENT_HOST"
>>>> This one is commented. But I have changed this value in the webinterface:
>>>> 2026-02-12 08:58:27 communication with Stork agent on machine [1] 127.0.0.1 to get state failed
>>>> 2026-02-12 08:58:14 communication with Stork agent on machine [1] 192.168.*.* to get state failed
>>>> 2026-02-12 08:52:33 communication with Stork agent on machine [1] debian13 to get state failed
>>>> This is the 2nd system, debian13 points to 127.0.0.1. Pinging to all 3 result in replies. Also tried uncommenting and setting that option, followed by systemctl restart isc-stork-agent, same result and to rule something else out I tried uncommenting STORK_AGENT_SKIP_TLS_CERT_VERIFICATION=true, since journalctl said something about TLS handshake, same error.
>>>>
>>>>
>>>> -----Oorspronkelijk bericht-----
>>>> Van: Slawek Figiel <slawek at isc.org>
>>>> Verzonden: woensdag 11 februari 2026 19:25
>>>> Aan: bart at ravenslair.nl; stork-users at lists.isc.org
>>>> Onderwerp: Re: [stork-users] Cannot get state of machine
>>>>
>>>> Hello!
>>>>
>>>> It looks like a misconfiguration problem to me. The Stork server cannot connect to the Stork agent.
>>>>
>>>> > "transport: authentication handshake failed: tls: first record
>>>> does not look like a TLS handshake
>>>>
>>>> But the Stork agent can connect to the Stork server because it successfully registered.
>>>>
>>>> In my opinion, the most likely issue is wrong STORK_AGENT_HOST or STORK_AGENT_PORT parameters. The server uses these values to establish a connection to the agent. If they are wrong, the server tries to connect to an incorrect or nonexistent host.
>>>>
>>>> Please verify these values provided in the Stork agent configuration or specified as CLI flags. Check (for example, using ping) that the Stork server machine can connect to the Stork agent machine using this hostname/IP address.
>>>>
>>>> I will wait for your feedback.
>>>>
>>>> Regards,
>>>> Slawek Figiel
>>>>
>>>>
>>>> On 2/11/26 7:18 PM, bart at ravenslair.nl wrote:
>>>>> Recently I followed https://kb.isc.org/docs/stork-quickstart-
>>>>> guide#debian-apt-compatible
>>>>> <https://kb.isc.org/docs/stork-quickstart-
>>>>> guide#debian-apt-compatible> to set up Stork on Debian 13, I ran
>>>>> into two things.
>>>>>
>>>>> The first thing I ran into has since been added under “Debian 13
>>>>> differences” after I reported a “command not found” to the
>>>>> customer service.
>>>>>
>>>>> The other thing is that I keep running into “The machine state
>>>>> was retrieved from the Stork server, but the server had problems
>>>>> communicating with the Stork agent on the machine: Cannot get
>>>>> state of machine”
>>>>>
>>>>> As far as I can tell everything that’s supposed to be running is
>>>>> running and I retried the guide on a(nother) Debian 13 install
>>>>> on a different system, only to run into the exact same thing.
>>>>>
>>>>> Since there’s no firewall active (yet) it can’t be that, so
>>>>> that’s one thing excluded. While settings things up I ran into
>>>>> the identical port issue, got Stork and the agent running on the
>>>>> same system. I changed the config as indicated by the guide
>>>>> under “Stork Server and Stork Agent cohabitating” after which I
>>>>> could register (and later
>>>>> re-register) the agent without problems. Journalctl shows this:
>>>>>
>>>>> kea-dhcp-ddns[5468]: INFO COMMAND_RECEIVED Received command 'config-get'
>>>>>
>>>>> kea-ctrl-agent[5805]: INFO CTRL_AGENT_COMMAND_FORWARDED command
>>>>> config- get successfully forwarded to the service d2 from remote
>>>>> address 127.0.0.1
>>>>>
>>>>> kea-dhcp4[5370]: INFO COMMAND_RECEIVED Received command 'config-get'
>>>>>
>>>>> kea-ctrl-agent[5805]: INFO CTRL_AGENT_COMMAND_FORWARDED command
>>>>> config- get successfully forwarded to the service dhcp4 from
>>>>> remote address
>>>>> 127.0.0.1
>>>>>
>>>>> kea-dhcp6[5569]: INFO COMMAND_RECEIVED Received command 'config-get'
>>>>>
>>>>> kea-ctrl-agent[5805]: INFO CTRL_AGENT_COMMAND_FORWARDED command
>>>>> config- get successfully forwarded to the service dhcp6 from
>>>>> remote address
>>>>> 127.0.0.1
>>>>>
>>>>> stork-server[10579]: time="2026-02-08 14:11:34" level="info"
>>>>> msg="Completed pulling DHCP status from Kea apps: 0/0 succeeded"
>>>>> file=" status.go:258 "
>>>>>
>>>>> stork-server[10579]: time="2026-02-08 14:11:35" level="warning"
>>>>> msg="rpc
>>>>> error: code = Unavailable desc = connection error: desc = \"transport:
>>>>> authentication handshake failed: tls: first record does not look like
>>>>> a TLS handshake\"" file=" manager.go:125 " agent="PlrtzGlrb:8080"
>>>>>
>>>>> stork-server[10579]: time="2026-02-08 14:11:35" level="warning"
>>>>> msg="Failed to get state from the Stork agent; the agent is still not
>>>>> responding" file=" grpcli.go:340 " agent="PlrtzGlrb:8080"
>>>>>
>>>>> stork-server[10579]: time="2026-02-08 14:11:35" level="warning"
>>>>> msg="failed to get state from agent PlrtzGlrb:8080: grpc manager
>>>>> is unable to make a call to the agent PlrtzGlrb:8080: rpc error:
>>>>> code = Unavailable desc = connection error: desc = \"transport:
>>>>> authentication handshake failed: tls: first record does not look like
>>>>> a TLS handshake\"" file=" statepuller.go:246 "
>>>>>
>>>>> stork-server[10579]: time="2026-02-08 14:11:35" level="info"
>>>>> msg="Completed pulling information from machines: 1/1 succeeded"
>>>>> file=" statepuller.go:73 "
>>>>>
>>>>> kea-ctrl-agent[5805]: INFO HTTP_CLIENT_REQUEST_AUTHORIZED
>>>>> received HTTP request authorized for 'kea-api'
>>>>>
>>>>> kea-ctrl-agent[5805]: INFO COMMAND_RECEIVED Received command 'version-get'
>>>>>
>>>>> kea-ctrl-agent[5805]: INFO CTRL_AGENT_COMMAND_RECEIVED command
>>>>> version- get received from remote address 127.0.0.1
>>>>>
>>>>> kea-ctrl-agent[5805]: INFO CTRL_AGENT_COMMAND_FORWARDED command
>>>>> version-get successfully forwarded to the service d2 from remote
>>>>> address
>>>>> 127.0.0.1
>>>>>
>>>>> kea-dhcp-ddns[5468]: INFO COMMAND_RECEIVED Received command 'version-get'
>>>>>
>>>>> kea-dhcp4[5370]: INFO COMMAND_RECEIVED Received command 'version-get'
>>>>>
>>>>> kea-ctrl-agent[5805]: INFO CTRL_AGENT_COMMAND_FORWARDED command
>>>>> version-get successfully forwarded to the service dhcp4 from
>>>>> remote address 127.0.0.1
>>>>>
>>>>> kea-dhcp6[5569]: INFO COMMAND_RECEIVED Received command 'version-get'
>>>>>
>>>>> kea-ctrl-agent[5805]: INFO CTRL_AGENT_COMMAND_FORWARDED command
>>>>> version-get successfully forwarded to the service dhcp6 from
>>>>> remote address 127.0.0.1
>>>>>
>>>>> Since I’m new with Kea DHCP Server and Stork (I’m used to ISC
>>>>> DHCP Server combined with Webmin), I wouldn’t be surprised if I
>>>>> missed a setting, though I would’ve expected that to be in the guide.
>>>>>
>>>>> Does anyone happen to know why Stork is throwing the error? As
>>>>> for journalctl, Google isn’t giving hits on the TLS handshake
>>>>> error from journalctl in combination with Stork.
>>>>>
>>>>>
>>>>
>>>> --
>>>> Stork-users mailing list
>>>> Stork-users at lists.isc.org
>>>> https://lists.isc.org/mailman/listinfo/stork-users
>>> --
>>> Stork-users mailing list
>>> Stork-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/stork-users
>>>
>>> --
>>> Stork-users mailing list
>>> Stork-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/stork-users
>>>
>> --
>> Stork-users mailing list
>> Stork-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/stork-users
>>
>
More information about the Stork-users
mailing list