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

Rule 1.2.4 error in run order #49

Open
animatco opened this issue Aug 26, 2024 · 3 comments
Open

Rule 1.2.4 error in run order #49

animatco opened this issue Aug 26, 2024 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@animatco
Copy link

Describe the Issue
If in the defaults/main.yml file the the rule 1.2.1 is not moved below 1.2.4 the code errors out.

Expected Behavior
1.2.4 should run before 1.2.1

Actual Behavior
1.2.1 is running before 1.2.4

Control(s) Affected
rule 1.2.4

Environment (please complete the following information):

branch being used: devel
Ansible Version: 2.16.3
Host Python Version: 3.12.3
Ansible Server Python Version: 3.12.3
Additional Details:

Additional Notes
Anything additional goes here

Possible Solution
change run order.

@animatco animatco added the bug Something isn't working label Aug 26, 2024
@MrSteve81 MrSteve81 self-assigned this Dec 3, 2024
@MrSteve81
Copy link
Contributor

MrSteve81 commented Dec 3, 2024

Good Day @animatco Sorry to get to this so late but Im wondering if you are running in a cloud environment or a local system? I believe we have resolved this already and maybe the system type is not being picked up. The order of the tasks are setup in the section1.yml and are calling in the correct order depending on the type of system ansible finds. The default main should not control that.

@animatco
Copy link
Author

animatco commented Dec 4, 2024

No this was on a On-Prem vSphere VM

@MrSteve81
Copy link
Contributor

MrSteve81 commented Dec 5, 2024

Hmmmm ok I will see if i can replicate this. We dont have vSphere internal but I believe it may be having issues figuring out if its a hyper-v and running it the non hyper v way this is where it checks for that. I wonder if vpshere logs the type differently. So in your case it is running the cloud based hardening not the normal one.

Which means below the instance is registering the when statement when your running it.
I do not have a copy of vsphere to test against but would it be possible to get the ansible facts for that copy of windows and send them to me to see if i can find another method to filter out vsphere.
the ansible should register it as this
['virtualization_type'] = 'VMware'

but it seems it is not.

of course feel free to remove anything that is private info
you can reach me on the discord @MrSteve

HVM is Amazon AMI's, Hyper-V is Azure's, KVM is used for ('QEMU', 'Amazon EC2', 'DigitalOcean', 'Google', 'Scaleway', 'Nutanix', 'KVM', 'KVM Server', 'Bochs', 'AHV')
Current list is elastic and will be updated as we test more cloud based services.
Current testing is working in Azure using Hyper-V. We are currently using this for reference:
https://github.com/ansible/ansible/blob/905131fc76a07cf89dbc8d33e7a4910da3f10a16/lib/ansible/module_utils/facts/virtual/linux.py#L205

  • name: PRELIM | Set fact if cloud-based system.
    ansible.builtin.set_fact:
    prelim_win22cis_cloud_based_system: true
    when:
    - ansible_system_vendor == 'Microsoft Corporation'
    - ansible_virtualization_type == 'Hyper-V' or
    ansible_virtualization_type == 'hvm' or
    ansible_virtualization_type == 'kvm'
    tags:
    - always

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants
@animatco @MrSteve81 and others