<div dir="auto">Hello and happy New Year,<div dir="auto"><br></div><div dir="auto">I tried to solve this by adding percent-specifiers as query parameters to the Path= property of the sysupdate definition though to my dismay I had to find out that they are discarded by the sd-import logic. Removing this restriction could solve this problem as one could easily send machine id, os version and similar information to the server.</div><div dir="auto"><br></div><div dir="auto">This would in general enable fine grained control over which updates a devices sees. Also see <a href="https://lists.freedesktop.org/archives/systemd-devel/2024-January/049889.html">https://lists.freedesktop.org/archives/systemd-devel/2024-January/049889.html</a> for a case where this is desirable.</div><div dir="auto"><br></div><div dir="auto">Kind regards, Nils</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 20, 2023, 19:04 Nils Kattenbeck <<a href="mailto:nilskemail@gmail.com" target="_blank" rel="noreferrer">nilskemail@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey everyone,<br>
<br>
does sysupdate currently support any way to slowly roll out updates<br>
where the server providing the files can be in control? This would be<br>
used to slowly make a new version available and have it at e.g. 1%<br>
adoption for a day to monitor regressions before increasing the<br>
coverage. I was unable to find any information about it in the<br>
documentation.<br>
<br>
Currently it seems like I would have to implement a different service<br>
which calls the sysupdate binary (or uses dbus once #28134 has landed)<br>
and then decides based on some other information.<br>
<br>
One idea I had would be that systemd-pull could send the machine-id<br>
based on which the server could then decide to provide the newer file<br>
(e.g. last two chars == "00" would roll it out to ~1/255). Though I am<br>
not sure if sd-pull is supposed to be "anonymous", i.e. do not provide<br>
this identifying information. Another drawback of this would be that<br>
stateless systems which reboot often get a new machine-id each boot,<br>
thus having an increased chance to get the newer version.<br>
<br>
Does anything like this already exist or is planned? Or should that be<br>
done by different applications on the client side?<br>
I also remember there being a discussion about plugging in different<br>
sd-pull like implementations/backends[1] to support delta updates,<br>
other transports, or TLS client authentication. This could at least be<br>
adapted to support my idea to send the machine-id as an HTTP header<br>
(e.g. X-MACHINE-ID).<br>
<br>
Greetings, Nils<br>
<br>
[1] <a href="https://lists.freedesktop.org/archives/systemd-devel/2023-February/048856.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/archives/systemd-devel/2023-February/048856.html</a><br>
</blockquote></div>