Re: duplicate popularity-contest ID
On Tue, Aug 06, 2019 at 02:01:16PM -0400, Sam Hartman wrote:
> >>>>> "Bill" == Bill Allombert <ballombe@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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: