[Feature Request] - report installed version in /etc/amazon-linux-release

[daniejstriata]

Is your feature request related to a problem? Please describe. Can the installed version details not update the /etc/amazon-linux-release or /etc/os-release files as well?

cat /etc/amazon-linux-release
Amazon Linux release 2023 (Amazon Linux)

could become

cat /etc/amazon-linux-release
Amazon Linux release 2023 (Amazon Linux)
2023.3.20231218

Describe the solution you'd like I find the team members not used to the AL2023 release cycle, to be unsure what version is installed and active.

Describe alternatives you've considered Rather than running yum info or rpm -qa on system-release can the version not be in a plain text file that can be read?

[elsaco]

BUILD_ID can be set in os-release:

       BUILD_ID=
           A string uniquely identifying the system image originally used as the installation base. In most cases,
           VERSION_ID or IMAGE_ID+IMAGE_VERSION are updated when the entire system image is replaced during an
           update.  BUILD_ID may be used in distributions where the original installation image version is important:
           VERSION_ID would change during incremental system updates, but BUILD_ID would not. This field is optional.

           Examples: "BUILD_ID="2013-03-20.3"", "BUILD_ID=201303203".

Run man os-release to see all available options. Hopefully the devs will hear you!

[daniejstriata]

@elsaco Agreed. That will work perfectly.

[stewartsmith]

I agree that this would be good to have. No ETA, but something like this should not be hard to implement, and I can't immediately think of any concerns around compatibility.

[stewartsmith]

Okay... so this gets "interesting".

From the os-release spec we have:

VERSION= A string identifying the operating system version, excluding any OS name information, possibly including a release code name, and suitable for presentation to the user. This field is optional. Examples: "VERSION=17", "VERSION="17 (Beefy Miracle)"".

This is currently 2023 on Amazon Linux 2023, which makes some amount of sense. This could probably be changed safely, and it only would make me slightly nervous about doing that.

VERSIONID= A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, ".", "" and "-") identifying the operating system version, excluding any OS name information or release code name, and suitable for processing by scripts or usage in generated filenames. This field is optional. Examples: "VERSION_ID=17", "VERSION_ID=11.04".

We have this as 2023 today. Since the definition hints at the use case of various scripts, this seems to have a higher chance of breaking things if we change it.

VERSIONCODENAME= A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "" and "-") identifying the operating system release code name, excluding any OS name information or release version, and suitable for processing by scripts or usage in generated filenames. This field is optional and may not be implemented on all systems. Examples: "VERSION_CODENAME=buster", "VERSION_CODENAME=xenial".

We don't set this :)

BUILD_ID= A string uniquely identifying the system image originally used as the installation base. In most cases, VERSION_ID or IMAGE_ID+IMAGE_VERSION are updated when the entire system image is replaced during an update. BUILD_ID may be used in distributions where the original installation image version is important: VERSION_ID would change during incremental system updates, but BUILD_ID would not. This field is optional. Examples: "BUILD_ID="2013-03-20.3"", "BUILD_ID=201303203".

This would be most akin to something in our /etc/image-id... which would be plausible to use, although there's likely a chicken-and-egg problem here in generating os-release and image-id.. but it may be okay (but I'd have to check image building tooling)

IMAGEID= A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "" and "-"), identifying a specific image of the operating system. This is supposed to be used for environments where OS images are prepared, built, shipped and updated as comprehensive, consistent OS images. This field is optional and may not be implemented on all systems, in particularly not on those that are not managed via images but put together and updated from individual packages and on the local system. Examples: "IMAGE_ID=vendorx-cashier-system", "IMAGE_ID=netbook-image".

Amusingly enough, this is probably good for the container image and not really anything else. Since we don't currently have per-image-type system-release, it's probably not relevant to add.

IMAGEVERSION= A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, ".", "" and "-") identifying the OS image version. This is supposed to be used together with IMAGE_ID described above, to discern different versions of the same image. Examples: "IMAGE_VERSION=33", "IMAGE_VERSION=47.1rc1".

Same as IMAGE_ID I think.

---

So where does that leave us?

Well... there's also the CPE_NAME field!

Which, in os-release is defined as:

CPE_NAME= A CPE name for the operating system, in URI binding syntax, following the Common Platform Enumeration Specification as proposed by the NIST. This field is optional. Example: "CPE_NAME="cpe:/o:fedoraproject:fedora:17""

While you can go and read the NIST spec for it, it boils down to this:

cpe::::::::::::

We currently set CPE_NAME to:cpe:2.3:o:amazon:amazon_linux:2023. That is CPE version 2.3 (cpe:2.3, identifying an Operating System (o), from the vendor amazon, the product amazon_linux, version 2023.

Since we don't currently populate the update field, and it's explicitly designed to contain:

Values for this attribute SHOULD be vendor-specific alphanumeric strings characterizing the particular update, service pack, or point release of the product

it looks like the ideal candidate for inserting a well defined machine readable thing in /etc/os-release for the full version string, without breaking any existing tooling.

[daniejstriata]

Are you suggesting something like: CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023:3.20231218" or CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023:2023.3.20231218" or CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023.3.20231218" The first option seems the correct one to me.

[stewartsmith]

IIRC from my experimental build it was the middle one, using the field for the full version string.

I'll check though - and discuss with some folk internally who have spent more time with CPE than I have.

[stewartsmith]

Update: the (slightly paraphrased) response was "I swear we had a doc from way back at the start of designing how we would implement deterministic updates through versioned repositories where we said we would do exactly this. What do you mean we don't?"

So... this'll almost certainly come in with AL2023.4 :)

[daniejstriata]

@stewartsmith This is partly being addressed but the system-release rpm does not currently overwrite/update the os-release file. It creates a new/usr/lib/os-release.rpmnew instead.

-rw-r--r--. 1 root root 338 Feb 21 12:09 /usr/lib/os-release
-rw-r--r--. 1 root root 530 Mar 26 22:53 /usr/lib/os-release.rpmnew

[stewartsmith]

Hrmmm..... that would only happen if you have modified the file

[daniejstriata]

I don't update the file at /usr/lib/os-release. I'll check when I update some of my hosts with the previous release.

[daniejstriata]

On this host the os-release file was not overwritten: What's happening kinda makes sense as the old file will be different to the new one.

[ozbenh]

rpm normally only does this if the previous file has been user-modified ...

[daniejstriata]

It's not a file I change. Let's see what the hosts do with the next release.

[daniejstriata]

I updated a couple of hosts. The os-release file is updating correctly.