On Di, 02.01.24 14:40, Nils Kattenbeck (nilskem...@gmail.com) wrote: > > > does sysupdate currently support any way to slowly roll out updates > > > where the server providing the files can be in control? [...] > > > > This is currently not available, no. > > > > The idea so far was always that the server is dumb, and the client > > picks the release it wants. > > I feel like it would be more flexible to have the client mostly > handling transferring and applying the data and any additional logic > should be handled by either the server or secondary applications which > call into sysupdate (or its future dbus API).
Well, our idea was really that you can use a bog standard static http server to serve this stuff and get as much of the feature set as you could possibly get. > > I have thought about this usecase a while back, and my thinking was > > that such a staged update logic should be driven by the machine > > ID. i.e. we should teach sysupdate a simple logic that allows pattern > > matching of new versions based on some arithmetic of the machine > > ID. More specifically, include some value in the URL pattern that > > indicates the percentage of hosts that shall update to this > > release. Then, each client takes its machine ID, treats it as an > > integer and calculates modulo 100 of it or so, and then checks if the > > resulting value is below the intended percentage, and if so it > > updates, otherwise it doesn't. > > > > (or something like that, the above is probably not ideal, since it > > would mean it's always the same hosts that try a new release first, > > and it probably should be evened out across the set of clients). > > Any logic based on the machine ID would also have the problem I > mentioned below that the ratios would be skewed for stateless devices > which cannot persist their machine id to disk. > > One would at least be able to override it with something persistent > like a MAC address though this could be exposed as some argument or > environment variable which a secondary application could set before > calling sysupdate. Yeah, we have something similar with the seed logic of repart already (by default repart derives partition uuids to create from the machine ID but you can also specify a seed explicitly), I see no problem with adding the same to sysupdate. That should be trivial and just adopt a scheme we already introduced at one more place. I am fully on board with that. I'd also be fine with a kernel cmdline option or so which allows fine-tuning where PID 1 takes the machine ID from if it generates a new one. Right now it takes the SMBIOS ID when running in a VM, and has a similar mechanism for containers. We could probably add something to optionally tell it to pull the ID to use from smbios/dt even on physical systems, or even from the TPM. (I am not sure how far the MAC thing would work. AFAIK on a lot of embedded systems the MAC is expected to be randomly generated by software, hence would not be useful as an identifier here. Also, it's directly publically visible, which makes it too easily guessable. And there's the raciness issue: usually device drivers for such auxiliary hardware are loaded relatively late, and we want the machine ID relatively early.) > > > I also remember there being a discussion about plugging in different > > > sd-pull like implementations/backends[1] to support delta updates, > > > other transports, or TLS client authentication. This could at least be > > > adapted to support my idea to send the machine-id as an HTTP header > > > (e.g. X-MACHINE-ID). > > > > If we can avoid it, I'd always adopt a logic whether identifying info > > doesn't have to be sent to the server. After all the logic should be > > generic and applicable in scenarios where the client should get > > anonymity as much as it wants. > > If the client automatically applies updates the server could always > deliver an image which exposes information by e.g. simply updating the > Path= to include %m somewhere in it. > Though I agree that always sending such information in headers would > not be optimal. > > I also found out that sd-import drops query parameters from the URL. I guess we could change this. if a query parameter is explicitly specified I see no reason to unconditionally drop it. > If this were not the case my use case would already be possible by > embedding the machine ID as part of the query. > This would also make it possible to opt in to sending the information. > > The problem I think is that there are two user groups of sysupdate > with different requirements. > On one hand we have end user distributions with A/B style updates > where the distribution only has limited to no interest over precise > control of updates and user devices and the users wish for anonymity. > On the other hand though are enterprises which deploy sysupdate for > (I)IoT devices. In these case devices commonly have to be registered > anyhow, and the enterprise controls how updates are rolled out etc. In > these cases anonymity is not necessary and instead customers often pay > the enterprise to perform all the management on their behalf. I think adding some concept for this would be entirely fine, but this really should be opt-in. Happy to review a patch for this. I think in the longer run we need to hook this up with remote attestation though, i.e. instead of just including the machine ID, include a quote from the TPM about PCR 15 (which includes a measurement of the machine ID), signed by some suitable local TPM key. That would make it a bit harder for clients that were hacked to play games with you, and report incorrect machine IDs. Lennart -- Lennart Poettering, Berlin
