Currently the incus-agent expects to receive connections over vsock and to be able to similarly connect to the host over vsock (for /dev/incus API). We have limited support to connect over HTTPS as a fallback mechanism but that only really works when run on an Incus-managed network where we can predict the IP address of the instance.
At FuturFusion, most of our customers seem to mostly care about the agent running for reporting of IP configuration as well as OS information. The other features like file transfers, command execution and to an extent, the extra resource information are often disabled by policy anyway.
As we're working with pretty old platforms (see #3195), vsock is often unavailable and even HTTPS could be a challenge due to those systems usually not having general network connectivity (they're EOL and very much unpatched).
The one thing that works quite reliably is access to the virtio serial device, so the idea is to extend incus-agent to have a fallback mode where when vsock isn't detected, it will start sending its state struct (OS, IP, ...) as JSON serialized data through the serial port alongside its usual heartbeat.
Incus can then pick that up and hold it in memory (with a reasonable size limit to avoid potential abuses).
Then when the state information is requested from Incus, that data can be used as a substitute for the agent API call.
Currently the incus-agent expects to receive connections over vsock and to be able to similarly connect to the host over vsock (for /dev/incus API). We have limited support to connect over HTTPS as a fallback mechanism but that only really works when run on an Incus-managed network where we can predict the IP address of the instance.
At FuturFusion, most of our customers seem to mostly care about the agent running for reporting of IP configuration as well as OS information. The other features like file transfers, command execution and to an extent, the extra resource information are often disabled by policy anyway.
As we're working with pretty old platforms (see #3195), vsock is often unavailable and even HTTPS could be a challenge due to those systems usually not having general network connectivity (they're EOL and very much unpatched).
The one thing that works quite reliably is access to the virtio serial device, so the idea is to extend incus-agent to have a fallback mode where when vsock isn't detected, it will start sending its state struct (OS, IP, ...) as JSON serialized data through the serial port alongside its usual heartbeat.
Incus can then pick that up and hold it in memory (with a reasonable size limit to avoid potential abuses).
Then when the state information is requested from Incus, that data can be used as a substitute for the agent API call.