Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix countme bucket calculation #1662

Merged
merged 2 commits into from
Jun 6, 2024
Merged

Fix countme bucket calculation #1662

merged 2 commits into from
Jun 6, 2024

Commits on May 9, 2024

  1. Fix up some comments in addCountmeFlag() 

    The buckets aren't really an array that's indexed in the code, they're
just sequential numbers for the URL flag.  Also clarify why we're using
"this window" instead of "the current position of the sliding window" in
the comments.
    @dmnks
    dmnks committed May 9, 2024
    Configuration menu
    Copy the full SHA
    a41a280 View commit details
    Browse the repository at this point in the history

  2. Fix countme bucket calculation 

    Actually use the system's installation time (if known) as the reference
point, instead of the first-ever countme event recorded for the given
repo.

This is what the dnf.conf(5) man page always said about the countme
option, the code just never lived up to that.

This makes bucket calculation more accurate:

1. System upgrades will no longer reset the bucket to 1 (this used to be
   the case due to a new persistdir being created whenever $releasever
   changed).

2. Systems that only reach out to the repos after an initial time period
   after being installed will no longer appear younger than they really
   are.

3. Prebuilt OS images that happen to include countme cookies created at
   build time will no longer cause all the instances spawned from those
   images (physical machines, VMs or containers) to appear older than
   they really are.

Use the machine-id(5) file's mtime to infer the installation time.  This
file is semantically tied to the system's lifetime since it's typically
populated at installation time or during the first boot by an installer
tool or init system, respectively, and remains unchanged.

The fact that it's a well-defined file with clear semantics ensures that
OS images won't accidentally include a prepopulated version of this file
with a timestamp corresponding to the image build, unlike our own cookie
files (see point 3 above).

In some cases, such as in OCI containers without an init system running,
the machine-id file may be missing or empty, even though the system is
still used long-term.  To cover those, keep the original, relative epoch
as a fallback method.  System upgrades aren't really a thing for such
systems so the above point 1 doesn't apply here.

Some containers, such as those created by toolbox(1), may also choose to
bind-mount the host's machine-id file, thus falling into the same bucket
as their host.  Conveniently, that's what we want, since the purpose of
such containers is to blend with the host as much as possible.

Fixes: rpm-software-management#1611
    @dmnks
    dmnks committed May 9, 2024
    Configuration menu
    Copy the full SHA
    a7ef279 View commit details
    Browse the repository at this point in the history