On Tue, Aug 06, 2019 at 02:01:16PM -0400, Sam Hartman wrote: > >>>>> "Bill" == Bill Allombert <ballo...@debian.org> writes: > > Bill> This is potentially an excellent idea! > > Bill> Does not /etc/machine-id suffer of exactly the same issue as > Bill> /etc/popularity-contest.conf ? > > A lot more procedures for cloning images know that they need to generate > new /etc/machine-ids. > > It's one of those things you tend to realize fairly quickly that you > need to fix up in cloned images. > Interactions with machined, systemd journal, and a few other things tend > to make it obvious.
However there some points in "man machine-id" which are rather problematic for popularity-contest: Optionally, for stateless systems, it is generated during runtime at early boot if it is found to be empty. Unless such system has very high uptime, it is much preferable for stateless systems with identical images to report with the same popcon ID rather than generate identical ghost submissions with each boots (which stays active for 20 days). The machine-id may also be set, for example when network booting, by setting the systemd.machine_id= kernel command line parameter or passing the option --machine-id= to systemd. A machine-id may not be set to all zeros. It seems machine-id is too linked to the boot process to be usable by popcon. When a machine is booted with systemd(1) the ID of the machine will be established. If systemd.machine_id= or --machine-id= options (see first section) are specified, this value will be used. Otherwise, the value in /etc/machine-id will be used. If this file is empty or missing, systemd will attempt to use the D-Bus machine ID from /var/lib/dbus/machine-id, the value of the kernel command line option container_uuid, the KVM DMI product_uuid (on KVM systems), and finally a randomly generated UUID. Again this would generate ghost submissions. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
