Add symlink to latest version for amazon-ssm-agent

[koooosh]

Issue: #3988

v2

Description of changes:
Making the following modifications to the amazon-ssm-agent package:

• Creating a latest symlink so that downstream users can easily pick up the most recent agent version

Reason for revision: As per offline discussion with @arnaldo2792 and @bcressey, we are removing the dynamically-linked agent binaries for now since it currently comes with an explicit dependency on bash. We want to make this bash dependency optional so they will be re-added in a later patch.

Testing done:

For the aws-ecs variants, verified instance is able to join a cluster and ECS Exec succeeds.

Verified symlink exists in the correct location:

[root@admin]# sudo sheltie
bash-5.1# ls /usr/libexec/amazon-ssm-agent/bin/
3.3.418.0  latest

v1

Description of changes:
Making the following modifications to the amazon-ssm-agent package:

• Changing the base package to vendor dynamically-linked agent binaries
• Adding this dynamically-linked agent to the aws-dev variant
• Adding a subpackage which vendors statically-linked agent binaries
• Creating a latest symlink so that downstream users can easily pick up the most recent agent version
• Adding this statically-linked agent to all aws-ecs variants

Testing done:

For the aws-dev variant, verified that SSM can be used to connect to the instance. Also, SSM send-command succeeds.

For the aws-ecs variants, verified instance is able to join a cluster and ECS Exec succeeds.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[larvacea]

Looks good to me.

[larvacea]

I think that we could get away with a lower value if this became a concern. I am absolutely fine with 90 seconds until we learn otherwise.

[KCSesh]

Yeah this also appears to be their default (confirmed myself) which I think is a good starting point!

[KCSesh]

LGTM!

[arnaldo2792]

nit: ideally, the commit that modified the aws-dev variant should include the changes to the Cargo.lock file that add the SSM agent.

[bcressey]

What's this about? I don't like this change. bash is only for the *-dev variants; it's not allowed as a package dependency.

What I'm not seeing here that I expected to see based on previous discussions is a patch so SSM agent doesn't need bash to execute commands. Ideally that would be some sort of environment or config-driven toggle, and the default would be to not require bash (because it's not present on production variants).

[koooosh]

When testing, I checked this and saw that bash is present in the aws-dev variant only and NOT present in the ecs variants:

I enabled admin container and disabled control container before SSHing into the instances.

## aws-dev variant instance
 
[ec2-user@admin]$ sudo sheltie
bash-5.1# find /usr/bin -name "bash" 
/usr/bin/bash
bash-5.1# 
 
## ecs variant instance
 
[ec2-user@admin]$ sudo sheltie
bash-5.1# find /usr/bin -name "bash"
bash-5.1# 

Regarding the SSM agent patch to remove bash dependency, that task is still in the works. An initial effort to do that was unsuccessful, so we need more time to complete that. @arnaldo2792 can provide you with more details on this.

[bcressey]

This logic doesn't make sense to me. A properly initiated reboot should cause systemd to transition to shutdown.target which will cause this service to stop (because of default dependencies).

I'm OK with the special treatment for the 194 exit code, but the delay isn't good. It means if the agent crashes for whatever reason it will take 90 seconds to come back up, which is an eternity if SSM is the only mechanism for managing the node.

[koooosh]

I'm fine with lowering the restart time, but we would be altering the default SSM agent configuration. Are we okay with this? If so, what restart time do you recommend?

[bcressey]

I'm fine with lowering the restart time, but we would be altering the default SSM agent configuration. Are we okay with this? If so, what restart time do you recommend?

I don't have a specific recommendation, just the feedback that 90 seconds is too long. You can look at other RestartSec values in packages/*/*.service to get a sense of the acceptable ranges.

Whatever value you pick, you should back up with data along the lines of "I inspected the ssm agent source code and I'm confident this is fine because ..." or "I tested the script-initiated reboot path in Bottlerocket, inspected the system journal, and confirmed that no unexpected restarts were triggered even with a lower restart time."

[bcressey]

You need to remove the ecs-agent.spec dependency on amazon-ssm-agent, or else you will automatically install that package on all ECS variants.

You should replace that dependency with the plugin dependency, so that ecs-agent takes care of its own requirements and variants don't have to specify them.

[koooosh]

Please see updated description under v2 for recent changes

[bcressey]

ecs-agent already requires amazon-ssm-agent so I don't understand the purpose of this change. It seems to just involve renaming subpackages with amazon-ssm-agent in the current form.