Amazon-ssm-agent: Ability to customise DefaultDocumentWorker

Created on 28 Nov 2017  路  12Comments  路  Source: aws/amazon-ssm-agent

Is it possible to customise the value for DefaultDocumentWorker on linux?

By default it appears to be hard coded to /usr/bin:
https://github.com/aws/amazon-ssm-agent/blob/e092980b261c432156f738dc1531666bf8277679/agent/appconfig/constants_unix.go#L79

We're trying to deploy on Container Linux based on this blog post. It's not a current supported OS, although the agent does work fine if we rebuild after changing that value. The reason it needs to be different is on Container Linux /usr is read only to allow for OS updates.

Most helpful comment

@c-knowles @jpadilla @jhmartin @hui-yang - I have release binaries on my fork which lets you set $SSM_DOCUMENT_WORKER_PATH at agent run-time:

https://github.com/opsgang/amazon-ssm-agent/

Effectively you can install the agent and ssm doc worker binaries anywhere on the filesystem.

You can download the built releases (these work on CoreOS amongst other linux amd4s) from here:
https://github.com/opsgang/amazon-ssm-agent/releases

I will be keeping this in-sync with the upstream - builds of the binaries are automated on a release.

Hope its of use ...

All 12 comments

we currently don't support customizing binary paths.

I have the same request for a different use case.
I simply compiled amazon-ssm-agent from source on an unsupported OS, and I had to move ssm-document-worker binary from build directory to /usr/bin, because the reference is hardcoded.

Do you support this use case?
If yes, the Readme should mention it https://github.com/aws/amazon-ssm-agent#building-and-running-from-source
If not, do you suggested always create a release package?

Same issue here; realizing CoreOS is not a supported OS but the hardcoding is unnecessarily strict.

Just ran into this as well. Any workarounds?

@jpadilla for what it's worth, we augmented the script from the blog post I linked above with this:

sed -i "s+/usr/bin/ssm-document-worker+$BIN_DIR/ssm-document-worker+g" agent/appconfig/constants_unix.go

That's not to say all agent actions work as the OS is still not supported, but at least now it runs and shell script can be executed and audited via SSM.

A custom build is certainly an option, but it is so much cleaner if it is a native configurable.

@c-knowles @jpadilla @jhmartin @hui-yang - I have release binaries on my fork which lets you set $SSM_DOCUMENT_WORKER_PATH at agent run-time:

https://github.com/opsgang/amazon-ssm-agent/

Effectively you can install the agent and ssm doc worker binaries anywhere on the filesystem.

You can download the built releases (these work on CoreOS amongst other linux amd4s) from here:
https://github.com/opsgang/amazon-ssm-agent/releases

I will be keeping this in-sync with the upstream - builds of the binaries are automated on a release.

Hope its of use ...

@jinal--shah I suggest submitting a PR here with that, if nothing else AWS then can't complain about the work necessary to enable it.

As of today, DefaultDocumentWorker is a var and I suppose it is ok to be modified at runtime.
It is handling ubuntu w/ snap in that way.

@c-knowles @jpadilla @jhmartin Just submitted #101 for this. Would it work for you guys?

@jinal--shah's I was able to notice that it was just a matter of adding 4 lines today, thanks to the last commit in your fork. Thanks for that 馃檹

Was this page helpful?
0 / 5 - 0 ratings

Related issues

heydonovan picture heydonovan  路  3Comments

dwilches picture dwilches  路  4Comments

TravellingGuy picture TravellingGuy  路  6Comments

johnnyplaydrums picture johnnyplaydrums  路  5Comments

JeremiahO1 picture JeremiahO1  路  4Comments