(codedeploy) invalid package name causing yum failures for CentOS 8 and presumably RHEL 8

[GregThoen]

The Issue

We have been using an older version of the CDK (1.84.0, I believe), and want to now upgrade to the latest, but the roadblock we've hit is that the UserData script CDK creates for autoscaling groups using codedeploy has changed and is now causing failures that keep instances from launching.

The fixes for issues #13654 and #13755, while apparently working for Amazon linux, break it for CentOS 8 (and presumably RHEL 8, off which CentOS 8 is based). The only mainstream yum repository I'm aware of for CentOS/RHEL that contains the aws cli is the EPEL (Extra Packages for Enterprise Linux) repository. When this repository is being used (set up as documented at https://aws.amazon.com/premiumsupport/knowledge-center/ec2-enable-epel/), the name of the aws cli package is awscli, not aws-cli.

# yum install aws-cli
Last metadata expiration check: 0:13:59 ago on Fri 24 Sep 2021 02:33:09 PM MDT.
No match for argument: aws-cli
Error: Unable to find a match: aws-cli
# echo $?
1
# yum install awscli
Last metadata expiration check: 0:16:24 ago on Fri 24 Sep 2021 02:33:09 PM MDT.
Package awscli-1.18.156-1.el8.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!
# echo $?
0

Environment

• CDK CLI Version: 1.124.0

Other information

In the past, since we're using a CentOS AMI we've set up, we actually installed the AWS CLI tools the way Amazon recommends (https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2-linux.html or https://docs.aws.amazon.com/cli/latest/userguide/install-linux.html), which is downloading the package directly from AWS and installing it, rather than using non-Amazon-created packages in a non-AWS package repository. The UserData script generated by the version of CDK we've been using (1.84.0) also would try to do a "yum install awscli" similar to what 1.124.0 does (but obviously awscli instead of aws-cli), and even though we hadn't configured our instances to use the EPEL repository (so this yum command failed), it didn't matter because (a) the script didn't do a "set -e" (like the current one does) so it ignored this error and (b) since the AMI we're using for the autoscaling group instances already has the CLI tools installed (by us manually as recommended by Amazon), the rest of the script (which needed the aws cli tools to download and then install the codedeploy agent) works fine.

For what it's worth, here are some obvious ways of fixing this:

1. Do a "yum list awscli" command to determine whether the package called "awscli" exists in the repo, and if so, use that name, otherwise use aws-cli -- rather than just assuming it's always aws-cli if yum is being used. The "yum list" command will exit with a 0-value if the package exists and 1 if it doesn't.
2. Do "set +e" before the yum command(s) to install the AWS CLI, then "set -e" after it (before trying to download and install the codedeploy agent). I understand the use of "set -e" in the script, as if there's a problem installing the code deploy agent, you wouldn't want the instance to launch into the autoscaling group, as it's not configured correctly. However, it seems to me that the entire point of the UserData script for this is to make sure the codedeploy agent and its dependencies are installed properly. So, having a failure of the ruby installation or a failure of the download & install of the codedeploy agent cause the script to fail makes sense to me. But the AWS CLI installation is just a means to an end (being able to use "aws s3 cp" to download the codedeploy agent), but how the AWS CLI gets there (or if it was already there, like we've been doing the last year or two) doesn't really matter. Hope that makes sense.

Thanks,
Greg

[skinny85]

Thanks for opening the issue @GregThoen. I agree with all of your points. It seems that actually always installing the AWS CLI might not be a great idea - perhaps we should first run a which aws, and see if that returns a non-zero exit? Because if returns 0 (like in your case, where your AMI already contains it), we should probably just skip installing the AWS CLI package altogether.

To unblock your migration to a newer CDK, you can turn off the automatic CodeDeploy agent installing with the installAgent property set to false, and then add your own UserData on the AutoScalingGroup with the addUserData() method.

Thanks,
Adam

[GregThoen]

Yeah - I think that will work too. In particular, it should work for us, since we have it installed in the AMI already. I think in general, for other people, though, one of the two things I mentioned might end up being better, so that it can work with RHEL & CentOS when not already installed -- just a suggestion. :)

[skinny85]

Yep, agreed - after which aws returns non-zero, we should do a yum list awscli to establish whether the package is called awscli, or aws-cli.

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.