[release] collect /etc/machine-id from RHEL

[vwalek]

[release] collect /etc/machine-id from RHEL

Drafting a PR to pull the /etc/machine-id from the rhel.

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname email@example.com?
• Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo yum install -y dnf-plugins-core on RHEL 8
• sudo dnf install -y dnf-plugins-core on Fedora
• dnf copr enable packit/sosreport-sos-3426
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[pmoravec]

Thanks for the contribution. The CI failure is some infra issue.

We already collect /var/lib/dbus/machine-id in https://github.com/sosreport/sos/blob/main/sos/report/plugins/dbus.py#L23 and the file is (usually? always?) a symlink to /etc/machine-id. We should not collect the same file by multiple plugins and dbus and the symlink seems more appropriate.

What is the use case where either /var/lib/dbus/machine-id -> /etc/machine-id does not exist, or dbus plugin is not called?

[arif-ali]

Ubuntu has the same file, so and /var/lib/dbus/machine-id is symbolically linked to /etc/machine-id

[vwalek]

@pmoravec yeah, from my last sosreport from microshift, it is not collected. Let me check the dbus plugin and see why it was not collected. Just question, if it is collected - does the sosreport keep the /etc/machine-id link?

update:

Probably because of this

# ls /var/lib/dbus
ls: cannot access '/var/lib/dbus': No such file or directory

# ls -l /etc/machine-id 
-rw-r--r--. 1 root root 33 May 27  2023 /etc/machine-id

# cat /etc/redhat-release 
Red Hat Enterprise Linux release 9.2 (Plow)

[pmoravec]

Yes, we do collect targets of symbolic links, even recursively.

Since /var/lib/dbus/ (always? usually?) contains just symlink to /etc/machine-id, it makes more sense to collect the /etc/machine-id target as a safeguard still in dbus plugin, for cases like this.

How (im)probable it is a system has /var/lib/dbus deleted? If it is a sole user error, it would be questionable if sos should have a safeguard for that (which costs some tiny but extra time in every execution). If it is a legitimate system deployment, sos should respect it and collect the file directly, on the other hand.

[vwalek]

How (im)probable it is a system has /var/lib/dbus deleted? If it is a sole user error, it would be questionable if sos should have a safeguard for that (which costs some tiny but extra time in every execution). If it is a legitimate system deployment, sos should respect it and collect the file directly, on the other hand.

Actually, I've checked couple of my RHEL systems and they do miss the /var/lib/dbus directory. So I don't think this is user error. What do you think @pmoravec ?

[pmoravec]

Indeed, some RHEL9 (new installs?) dont have that directory while some older (upgrade from RHEL9.0?) does have it.

So sos report should collect explicitly /etc/machine-id and ideally both.

Since the dbus one is symlink to the etc one, both files should be collected by one plugin (ideally, though the argument behind "multiple plugins cant collect same file" does not fully fit here).

I think release plugin isnt a good fit as the machine-id is some UUID from boot time, nothing about the OS release, no?

We can collect both in dbus for legacy reasons - or since it is related / set during initial boot, maybe collect (both?) in boot plugin?

Either dbus or boot plugin for both sounds good to me.

Any opinion, @arif-ali and @TurboTurtle ?

[arif-ali]

On a freshly installed latest version we have both files (please ignore the hostname, that was a typo when I created the VM ;))

ubuntu@xenial01:~$ lsb_release -c
No LSB modules are available.
Codename:	mantic
ubuntu@xenial01:~$ ls -lh  /etc/machine-id 
-r--r--r-- 1 root root 33 Dec 14 18:09 /etc/machine-id
ubuntu@xenial01:~$ ls -lh /var/lib/dbus
total 0
lrwxrwxrwx 1 root root 15 Dec 14 18:09 machine-id -> /etc/machine-id

I would be on the side, where we collect both then, for historical reasons. based on my experience, the contents of the file stays the same. Based on my experience, it is a randomly generated id at install time, and doesn't change. So, imo, it should stay in dbus, and add the new location there as well