Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: This benchmark is not suitable for the destination operating system Amazon Linux AMI 2017.09.1 #22

Open
link2anjan opened this issue Nov 16, 2017 · 7 comments

Comments

@link2anjan
Copy link

Hi,
I am using Ansible version 2.4.1.0 and Amazon Linux AMI 2017.09.1 (HVM).
This role is not working. I am getting following error:
"This benchmark is not suitable for the destination operating system"

If I need to modify this role what I have to do.

Please help...

@link2anjan link2anjan changed the title Error: This benchmark is not suitable for the destination operating system Error: This benchmark is not suitable for the destination operating system Amazon Linux AMI 2017.09.1 Nov 16, 2017
@dgeske
Copy link

dgeske commented Jan 2, 2018

Hi, I'm also running into this issue. Some support for Amazon Linux 2017.09 was added via c04cc25, yet remains unavailable via Ansible Galaxy, because it was not registered in the galaxy role meta data https://github.com/anthcourtney/ansible-role-cis-amazon-linux/blob/master/meta/main.yml file.

The underlying problem is that new platforms and platform versions need to be added to Ansible Galaxy manually, thus loads of platforms are missing in the list of currently supported platforms. Eventually, Galaxy issue ansible/galaxy#80 is supposed to resolve this.

In the meantime, possibly a similar solution as is suggested in ansible/ansible#11133 (comment) could help temporarily work around this.

@anthcourtney
Copy link
Owner

anthcourtney commented Jan 3, 2018

I have a local change to update the meta data for the role to include the 2017.09 version, however I can't tag and sync that to Galaxy until Galaxy itself supports those versions - otherwise the import/synch fails.

I'm not sure that ansible/ansible#11133 is a valid solution.

I noticed your comment on ansible/galaxy#80 that you'd hold off on raising requests for the new versions to be supported, but I see that as the immediate solution (and as much as its undesirable, the medium-term solution as well).

@dgeske
Copy link

dgeske commented Jan 10, 2018

Hey, yea you're right, as a stop-gap, continuing to raise per env issues is the way to go. Question is whether the team who handles these will resolve them, but as far as I can tell that's the best we can do from our side.

@chandanchowdhury
Copy link
Collaborator

Looks like both 2017.09 and 2017.12 (LTS Candidate) are now part of Ansible Galaxy currently supported platform.

@chandanchowdhury
Copy link
Collaborator

PR #34 implemented which should fix this issue.

@anjangithub123 can you please confirm?

@ghost
Copy link

ghost commented Oct 25, 2018

I have justed pulled the preflight checks so we can use this on the newer builds for aws Linux

@chandanchowdhury
Copy link
Collaborator

Thanks @steven-cuthill-otm, please do let us know of any issues you find

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants