New Rust Xen guest tools

Andrew

@olivierlambert No IP record... Using Debian 11 with Management agent 1.0.0-proto-0.4.0. It's a non-standard interface setup with the IPv4/IPv6 assigned to the bridge interface. The agent does not report any addresses up to XO.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 32:a9:24:28:18:56 brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:31:46:59:66:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.33/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2000::5031:46ff:fe59:66a1/64 scope global dynamic mngtmpaddr
       valid_lft 2591833sec preferred_lft 604633sec
    inet6 fe80::5031:46ff:fe59:66a1/64 scope link
       valid_lft forever preferred_lft forever

olivierlambert

Likely because br0 isn't parsed. Pinging @yann and @TeddyAstie

yann

@olivierlambert yes, and that's a known issue. The protocol used to communicate with XAPI only allows to report info for VIFs (and SR/IOV, with support coming with in a PR). We can likely implement something by querying the status of bridge devices and listening to their changes like we do for the VIFs, and report those for the VIFs that are part of bridges - but it's a bit more than just "parsing br0" .

Opened https://gitlab.com/xen-project/xen-guest-agent/-/issues/24

flakpyro

With the release of Debian 13 apt now complains that the repo is not signed. Also Debain has changed to using .sources files for repos.

For example,, the new format would be:

Types: deb
URIs: https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64/
Suites: release/
Components: 
Signed-By: https://path/to/release.gpg
Trusted: yes

Maybe worth addding a release.gpg to the repo and updating documentation when configuring the repo on newer Debian / Ubuntu releases?

Example of the error when no key is present:

Ign:8 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 release/ InRelease
Hit:9 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 release/ Release
Ign:10 https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64 release/ Release.gpg
Fetched 176 kB in 1s (154 kB/s)
All packages are up to date.    
Notice: Missing Signed-By in the sources.list(5) entry for 'https://gitlab.com/api/v4/projects/xen-project%2Fxen-guest-agent/packages/generic/deb-amd64'

olivierlambert

@yann can you update the README accordingly?

yann

@olivierlambert updating the README will be quick enough... but if the sig is indeed mandatory we need to setup something for this first... and autosigning from a CI rather requires doing that on a trusted runner rather than on gitlab-provided ones, so that requires some provisioning and IT work first.

yann

@flakpyro the old format is still supported, and actually the [trusted=yes] in the old-style configuration shown in the release notes does work in my quick test with our own Debian 13 hub template.

David_5.1

One-line format should work fine with Trixie, but as the “new” deb822 format has been supported since Debian Jessie, it should be usable on most installs.

Jessie manpage for reference : https://manpages.debian.org/jessie/apt/sources.list.5.en.html#:~:text=rfc822

john.c

@yann Though the deb822 format allows for that file in sources format, to have the signing key tied to that file’s specified repositories. Very important as it ensures that the key is only used by that repository, unless otherwise specified. The old format typically tends to apply that key to all repositories. So even repositories which shouldn’t use it could, worse the key was trusted for all repositories by the client.

In the new format the repositories can have the specific key tied to them, on the client side as well as the server side.

yann

@john.c OK, that will be useful when the repo is signed, but for now I don't see what adverse effect it can have. Do I miss something?

Also we try to avoid breaking support for older OS versions, so we'll likely continue to advertise the old format for older versions of Debian.