Update docs for RHEL 10, make cert docs evergreen. #1909
Conversation
prmerger-automator
bot
requested review from
msaenzbosupport,
divargas-msft,
pagienge and
AmandaAZ
|
@sdherr : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. @navpreetkaur1098 |
|
Learn Build status updates of commit 6ab4b64: ✅ Validation status: passed
For more details, please refer to the build report. |
PRMerger Results
|
|
I do not know if the tabbed view works properly as a child of a list item, and don't know how to check. However otherwise this is ready. |
|
#sign-off |
There was a problem hiding this comment.
We can add validations to catch early input errors (for example, if $VERSION_ID is not in the expected format or if MAJOR_VERSION is empty):
if [ -z "$MAJOR_VERSION" ]; then
echo "Could not determine major version. Please check /etc/os-release."
exit 1
fi
Line 265: sudo yum --config temporary-rhui.config install rhui-azure-${OFFERING}
Line 271: yum repolist all
We might replace yum with dnf
Line 165 and 166:
GPG_KEY_SUFFIX=$(if [ $MAJOR_VERSION -eq "10" ]; then echo "-2025"; fi)
GPG_KEY="https://packages.microsoft.com/keys/microsoft${GPG_KEY_SUFFIX}.asc"
If we, Microsoft changes the filename to microsoft-2026.asc etc.., we might validate if GPG key URL is reachable? or we can just trust it wont change.
Set GPG key based on RHEL major version
if [ "$MAJOR_VERSION" -eq "10" ]; then
GPG_KEY="https://packages.microsoft.com/keys/microsoft-2025.asc"
else
GPG_KEY="https://packages.microsoft.com/keys/microsoft.asc"
fi
Optional: validate that the GPG key URL is reachable
if ! curl -s --head "$GPG_KEY" | grep -q "200 OK"; then
echo " Error: Unable to fetch GPG key from:"
echo " $GPG_KEY"
echo "Please verify the key location at:"
echo " https://packages.microsoft.com/keys/"
exit 1
fi
The other two documents have minor changes to add RHEL 10 under support type, which is fine.
|
Learn Build status updates of commit 5c7db54: ✅ Validation status: passed
For more details, please refer to the build report. |
PRMerger Results
|
|
@msaenzbosupport I have added the verification of MAJOR_VERSION and GPG_KEY as you suggested. We should not call As for You can trust that the GPG_KEY urls will never change. Millions of clients around the globe reference these values. We may at some point at additional keys that maybe RHEL 11 might use, but the key that RHEL 10 uses is constant, as is the URL it's available at. |
|
Thanks for the updates. The changes regarding MAJOR_VERSION and GPG_KEY look good to me. Regarding the yum vs dnf point, I understand that yum is a symlink to dnf on RHEL 8 and above. However, since we're explicitly targeting RHEL 8+ in this context, I believe it's better to use dnf to align with current method It helps reinforce the modern usage pattern for these systems. On the last point about the GPG key URLs, I agree with your reasoning and that makes perfect sense. Please give me until Monday to approve this. I have an internal meeting scheduled to discuss the proposed changes, as we want to ensure the new process remains simple and easy to understand for end customers. Our priority on the support side is to avoid confusion and ensure clarity for those who follow these instructions. |
@msaenzbosupport Are we? The current docs do still contain RHEL 7 instructions in several places. I'm not sure what our support agreements look like, but Red Hat still supports RHEL 7 with an ELS add-on until 2028. Okay, well I've added another commit changing |
|
@sdherr You're right, RHEL 7 is still supported under ELS until 2028, and I agree it's important to consider that context. My suggestion to use dnf was mainly based on simplifying the instructions for RHEL 8+ and helping customers align with current tooling. Thanks for switching it to dnf. Let’s hold off on finalizing that for now — I’ve got an internal meeting on Monday to go over the proposed changes. We want to make sure the updated flow is still clear and straightforward for customers. It’s possible that the new approach could create some confusion on the support side, and we’d like to avoid that. |
|
As we discussed this PR will be closed. |
@msaenzbosupport Thanks for the information. The PR is closed. |
The intent here is to update docs for RHEL 10. This should be merged along with this PR that updates
rhui-check.pyto work properly on RHEL 10.Along the way I noticed that there was a massive amount of unnecessary duplication in the "Solution 3: Install the EUS, non-EUS, or SAP/E4S RHUI package" section. I have de-duplicated it. The resulting instructions are evergreen and universal, and don't need to be updated when new RHEL 10 offerings are made available (non-Base offerings are not yet published), or other offerings go EOL.