The latest guild-deploy.sh doesn't install the epel repo for rhel 9 and there is a bad condition statement

[rob-grokism]

For RHEL 9 the EPEL Repo doesn't seem to get installed

Description : Add epel repository when needed

: $1 = DISTRO

: $2 = Epel repository VERSION_ID

: $3 = pkg_opts for repo install

The ${1} here is associated with the environment variable DISTRO=$(grep -i ^NAME= /etc/os-release | cut -d= -f 2) there doesn't seem to be any condition under which the if statement has a value of Fedora...the value that the DISTRO variable is assigned is always returned as NAME="Red Hat Enterprise Linux" From the /etc/os-release file

add_epel_repository() {
if [[ "${1}" =~ Fedora ]]; then return; fi
echo -e "\n Enabling epel repository..."
! grep -q ^epel <<< "$(yum repolist)" && $sudo yum ${3} install https://dl.fedoraproject.org/pub/epel/epel-release-latest-"${2}".noarch.rpm > /dev/null
}

You can derive the ${1} "fedora" from the OS_ID environment variable. This would allow the epel release to get installed.

The other issue is that this condition (from a newly downloaded guild-deploy.sh script) is that the condition for RHEL 9 is never met so it always puts you in the rhel 8 track and tries to enable code-readybuilder 8 for rhel 9...This needs to be an && because there are 2 conditions that need to be met...both the distro of Redhat and the Version ID

219 elif [[ "${DISTRO}" =~ "Red Hat" ]] || [[ "${VERSION_ID}" =~ "8" ]]; then
220 pkg_list="${pkg_list} --enablerepo=codeready-builder-for-rhel-8-x86_64-rpms libusbx ncurses-compat-libs pkgconf-pkg-config"
221 elif [[ "${DISTRO}" =~ "Red Hat" ]] || [[ "${VERSION_ID}" =~ "9" ]]; then
222 pkg_list="${pkg_list} --enablerepo=codeready-builder-for-rhel-9-x86_64-rpms libusbx ncurses-compat-libs pkgconf-pkg-config"

change this then to elif [[ "${DISTRO}" =~ "Red Hat" ]] && [[ "${VERSION_ID}" =~ "8" ]]; then
elif [[ "${DISTRO}" =~ "Red Hat" ]] && [[ "${VERSION_ID}" =~ "9" ]]; then

BTW...thank you for working on the code-ready-builder requests for rhel 9...if the epel repository is enabled that part of the script works just fine.
Regards,
Rob Phillips
St. Paul MN
[email protected]

[rdlrt]

Thank you for raising the issue. RHEL variants are indeed one of the less tested (in real world) variants and might have some leaks, it is always good when community reports any issues/findings back.

The ${1} here is associated with the environment variable DISTRO=$(grep -i ^NAME= /etc/os-release | cut -d= -f 2) there doesn't seem to be any condition under which the if statement has a value of Fedora...the value that the DISTRO variable is assigned is always returned as NAME="Red Hat Enterprise Linux" From the /etc/os-release file.

Isnt this the expected result? If DISTRO had a match against RegEx Fedora then the command executed would have been return (without any actions). Let me know if this is not what you expect.

if [[ "${1}" =~ Fedora ]]; then return; fi  

The other issue is that this condition (from a newly downloaded guild-deploy.sh script) is that the condition for RHEL 9 is never met so it always puts you in the rhel 8 track and tries to enable code-readybuilder 8 for rhel 9

I agree this is an undesired result, I'd imagine we should simply convert lines 219-222 to below:

      elif [[ "${DISTRO}" =~ "Red Hat" ]]; then
        pkg_list="${pkg_list} --enablerepo=codeready-builder-for-rhel-${VERSION_ID}-x86_64-rpms libusbx ncurses-compat-libs pkgconf-pkg-config"

Let me know the results for first part , if you still end up with not having epel - that part might need some more checks.

Will also tag @TrevorBenson as he also uses (if I remember correctly) RHEL variants.

[TrevorBenson]

I'll take a look and run tests for both a RHEL 9 and Rocky 9 full builds.

[rob-grokism]

ok...I see what you mean about the add_epel_repository() function...if it is anything other than "Fedora" it will attempt to install the epel repo...I was trying to figure out why the epel repository wasn't getting installed and enabled by the time the codeready-builder for rhel 9 was installed. Install was failing telling me that the there is no such repo as codeready builder. This is because the epel repository wasn't there. As soon as I enable the epel repository by hand, then the codeready builder stuff works as expected. I will test the script as is except for the "&&" exclusive ands that need to be added. I will let you know how it works.

[TrevorBenson]

ok...I see what you mean about the add_epel_repository() function...if it is anything other than "Fedora" it will attempt to install the epel repo...I was trying to figure out why the epel repository wasn't getting installed and enabled by the time the codeready-builder for rhel 9 was installed. Install was failing telling me that the there is no such repo as codeready builder. This is because the epel repository wasn't there. As soon as I enable the epel repository by hand, then the codeready builder stuff works as expected. I will test the script as is except for the "&&" exclusive ands that need to be added. I will let you know how it works.

Yep, its the || instead of && on line https://github.com/cardano-community/guild-operators/blame/alpha/scripts/cnode-helper-scripts/guild-deploy.sh#L219 which leads to the check for VERSION_ID matching 9 (Line 221) being unreachable (but should also be && and is currently ||).

FWIW the variable definitions all look good to me:

+ OS_ID='"fedora"'
+ [[ -z "fedora" ]]
++ grep -i '^NAME=' /etc/os-release
++ cut -d= -f 2
+ DISTRO='"Red Hat Enterprise Linux"'
++ grep -i '^version_id=' /etc/os-release
++ cut -d= -f 2
++ tr -d '"'
++ cut -d. -f 1
+ VERSION_ID=9

The branch is opened with the fix, but my developer subscription expired recently so waiting for re-registration to complete to kick off the testing. If you want to try out the branch you can use ./guild-deploy.sh -b rhel-9-crb-repo [...] ([...] being whatever additional flags). I'll open a PR for review as soon as I can confirm repositories enable and packages install as expected.

[rob-grokism]

I will test and give you an update. Regards, Rob

…

On Wed, Nov 15, 2023 at 12:38 PM illuminatus ***@***.***> wrote: ok...I see what you mean about the add_epel_repository() function...if it is anything other than "Fedora" it will attempt to install the epel repo...I was trying to figure out why the epel repository wasn't getting installed and enabled by the time the codeready-builder for rhel 9 was installed. Install was failing telling me that the there is no such repo as codeready builder. This is because the epel repository wasn't there. As soon as I enable the epel repository by hand, then the codeready builder stuff works as expected. I will test the script as is except for the "&&" exclusive ands that need to be added. I will let you know how it works. Yep, its the || instead of && on line https://github.com/cardano-community/guild-operators/blame/alpha/scripts/cnode-helper-scripts/guild-deploy.sh#L219 which leads to the check for *VERSION_ID* matching 9 (Line 221 <https://github.com/cardano-community/guild-operators/blame/alpha/scripts/cnode-helper-scripts/guild-deploy.sh#L219>) being unreachable. FWIW the variable definitions all look good to me: + OS_ID='"fedora"' + [[ -z "fedora" ]] ++ grep -i '^NAME=' /etc/os-release ++ cut -d= -f 2 + DISTRO='"Red Hat Enterprise Linux"' ++ grep -i '^version_id=' /etc/os-release ++ cut -d= -f 2 ++ tr -d '"' ++ cut -d. -f 1 + VERSION_ID=9 The branch is opened with the fix, but my developer subscription expired recently so waiting for re-registration to complete to kick off the testing. If you want to try out the branch you can use ./guild-deploy.sh -b rhel-9-crb-repo [...] ([..] being whatever additional flags). I'll open a PR for review as soon as I can confirm repositories enable and packages install as expected. — Reply to this email directly, view it on GitHub <#1701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASO7EKU5RECI3I5YNP2Z22TYEUD2RAVCNFSM6AAAAAA7HUC4ZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJTGA3DIOBUHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[TrevorBenson]

I will test and give you an update. Regards, Rob

@rob-grokism I tested and it seemed good. I've opened a PR (#1703), which will also close this issue once merged. If you find any problem please don't hesitate to respond. I will postpone merging the PR, even after review approvals, until a response confirming this resolved your issue is received.

Thanks

[rdlrt]

Sorry - went ahead with the merge, didnt make sense to wait as the changes fully made sense - if there's more, we can always create another one 🙂