amazon-ssm-agent: Add dynamically-linked agent binaries

[koooosh]

Issue number: #19

Closes #19

Description of changes:

Making the following modifications to the amazon-ssm-agent package:

• amazon-ssm-agent.spec
  • Changing the base packages to vendor dynamically-linked agent binaries patched to have a configurable dependency on bash
  • Adding plugin subpackages which vendor the original statically-linked agent binaries
• 0001-agent-Add-config-to-make-shell-optional.patch
  • This is a patch for the SSM agent that adds a new config called UseShell which is a boolean set to false by default. If this config is false, then bash is not used when running commands -- instead using exec. If true, it uses bash like the default Agent.
• amazon-ssm-agent.json
  • This is the custom config for the SSM agent with the new UseShell setting along with defaults installed in %{_cross_factorydir}%{_cross_sysconfdir}. Depending on whether they want to use bash, downstream users can opt to take this config by adding a tmpfiles.d for that target or create and install their own config.
• amazon-ssm-agent.service
  • This is the systemd service for the SSM agent. It is similar to the default Agent service besides changes to the binary path and the RestartSec lowered from 90 to 5. Journal logs show no unexpected behavior as a result of this reduction in time.

Also updating the ecs-agent.spec in the ecs-agent package to use the new ssm-agent-plugin subpackage.

Testing done:

• Launched an aws-dev variant instance with the amazon-ssm-agent package added and host-containers disabled.

  • When it is built with UseShell set to false, running a command with a bash script fails:

    "status": "Failed",
    ...
    "output": "\n----------ERROR-------\nfailed to run commands: fork/exec #!/usr/bin/bash: no such file or directory",
    

    While other commands still succeed. Example running apiclient get os:

    "status": "Success",
    ...
    "output": "{\n  \"os\": {\n    \"arch\": \"x86_64\",\n    \"build_id\": \"62833938-dirty\",\n    \"pretty_name\": \"Bottlerocket OS 1.21.0 (aws-dev)\",\n    \"variant_id\": \"aws-dev\",\n    \"version_id\": \"1.21.0\"\n  }\n}\n",
    

  • When it is built with UseShell set to true, the bash script runs successfully as expected.

• Regarding the subpackaging of the statically-linked binaries, I launched an aws-ecs-1 variant instance with the amazon-ssm-agent-plugin package added and verified it is able to join a cluster + ECS exec also works.

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.

[arnaldo2792]

As mentioned, no need to include a default config file.

[bcressey]

As mentioned, no need to include a default config file.

Why not? Does this config file effectively end up just listing what would be the defaults?

[koooosh]

My reason for including the custom config amazon-ssm-agent.json and the tmpfiles.d to install it was to make it as easy as possible for downstream users to change this config (and our new setting UseShell) as necessary.

But I also understand the case that we do not want to include this in the core-kit itself. I'm fine with either approach.

[arnaldo2792]

As mentioned, no need to include a default config file.

Why not? Does this config file effectively end up just listing what would be the defaults?

My reasoning was that it wouldn't be possible for downstreams to override this configuration if we provide it through the package, right? RPM will complain if the downstreams provide the same file twice (unless you know a magic trick in RPM to prevent that). What I thought was that we could provide the factory file, with reasonable defaults, and let downstreams decide whether they want to use it with a tmpfiles.d file. If they want to provide their own, they can provide their own factory and their own tmpfiles.d conf file so that they copy the correct file.

[koooosh]

My reasoning was that it wouldn't be possible for downstreams to override this configuration if we provide it through the package, right?

This config file amazon-ssm-agent.json is essentially the default configs + our new config for UseShell. So if downstreams want override, they can modify this file (or provide their own amazon-ssm-agent.json).

What I thought was that we could provide the factory file

Can you clarify what you mean by "factory file"?

[koooosh]

Discussed with @arnaldo2792 offline. We are keeping amazon-ssm-agent.json in %{_cross_factorydir}%{_cross_sysconfdir}. Customers can opt to take this config by adding a tmpfiles.d for that target or create/install their own config.

[koooosh]

New commit makes the following major changes:

• Removes amazon-ssm-agent-tmpfiles.conf
• Installs agent binaries directly to /usr/bin/ instead of its own directory
• Updates ecs-agent-spec to use agent-plugin package which has the previous static binaries