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

feature request: setup module import osquery data #14066

Closed
3rdman opened this issue Jan 22, 2016 · 4 comments
Closed

feature request: setup module import osquery data #14066

3rdman opened this issue Jan 22, 2016 · 4 comments
Labels
affects_2.2 This issue/PR affects Ansible v2.2 affects_2.3 This issue/PR affects Ansible v2.3 feature This issue/PR relates to a feature request. needs_info This issue requires further information. Please answer any outstanding questions. needs_template This issue/PR has an incomplete description. Please fill in the proposed template correctly. support:core This issue/PR relates to code supported by the Ansible Engineering Team.

Comments

@3rdman
Copy link

3rdman commented Jan 22, 2016

It would be really nice to have the setup module import osquery data if osqueryi is present on the system.

The simple path is to:

for table in $(osqueryi .tables)
schema=osqueryi '.schema $table'
for row in select * from $table
add row to setup_options["osquery_"]
done

@ansibot ansibot added triage affects_2.2 This issue/PR affects Ansible v2.2 labels Sep 7, 2016
@ansibot ansibot added the affects_2.3 This issue/PR affects Ansible v2.3 label Dec 13, 2016
@bcoca bcoca removed the triage label Dec 16, 2016
@rmetzler
Copy link
Contributor

rmetzler commented Mar 8, 2017

I think it would be beneficial to add an osqueryi module, so it would be easy to run ad hoc queries on a group of hosts.

Though, I disagree with doing a loop over all osquery tables in the setup module by default.

Nevertheless I would like to showcase a simple trick of integrating osquery selects into Ansible setup facts. By using the /etc/ansible/facts.d/ dir on the host machines, every host is able to provide local facts. The facts module will run all executables in the glob '*.fact' and will add the JSON returned from stdout to ansible_local.

This is a simple example

$ cat /etc/ansible/facts.d/osquery_etc_hosts.fact 
#!/usr/bin/env bash
osqueryi "SELECT * FROM etc_hosts;" --json

$ ansible localhost -m setup -a'filter=ansible_local'
localhost | SUCCESS => {
    "ansible_facts": {
        "ansible_local": {
            "osquery_etc_hosts": [
                {
                    "address": "127.0.0.1", 
                    "hostnames": "localhost"
                }, 
                {
                    "address": "255.255.255.255", 
                    "hostnames": "broadcasthost"
                }, 
                {
                    "address": "::1", 
                    "hostnames": "localhost"
                }, 
                {
                    "address": "fe80::1%lo0", 
                    "hostnames": "localhost"
                }, 
                {
                    "address": "127.0.0.1", 
                    "hostnames": "www.localhost"
                }
            ]
        }
    }, 
    "changed": false
}

@rmetzler
Copy link
Contributor

rmetzler commented Mar 9, 2017

Another workaround is using the shell modul and registering the output. Then you have to use set_fact like this. Please compare the debug messages to see the difference between the two variables:

- hosts: all
  tasks:
    - shell: osqueryi "SELECT * FROM etc_hosts" --json
      register: output
    - set_fact:
        osquery_etc_hosts: "{{ output.stdout }}"
    - debug: msg={{ osquery_etc_hosts }}
    - debug: msg={{ output }}

I also looked into how to create modules, and I think it would be easy to write a osqueryi_facts module.

@ansibot
Copy link
Contributor

ansibot commented Apr 11, 2017

@3rdman Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information.

Here are the items we could not find in your description:

  • issue type
  • ansible version
  • component name

Please set the description of this issue with this template:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

click here for bot help

@ansibot ansibot added needs_info This issue requires further information. Please answer any outstanding questions. needs_template This issue/PR has an incomplete description. Please fill in the proposed template correctly. labels Apr 11, 2017
@ansibot ansibot added the support:core This issue/PR relates to code supported by the Ansible Engineering Team. label Jun 29, 2017
@ansibotdev
Copy link

@3rdman You have not responded to information requests in this issue so we will assume it no longer affects you. If you are still interested in this, please create a new issue with the requested information.

click here for bot help

@ansibot ansibot added feature This issue/PR relates to a feature request. and removed feature_idea labels Mar 2, 2018
@ansible ansible locked and limited conversation to collaborators Apr 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.2 This issue/PR affects Ansible v2.2 affects_2.3 This issue/PR affects Ansible v2.3 feature This issue/PR relates to a feature request. needs_info This issue requires further information. Please answer any outstanding questions. needs_template This issue/PR has an incomplete description. Please fill in the proposed template correctly. support:core This issue/PR relates to code supported by the Ansible Engineering Team.
Projects
None yet
Development

No branches or pull requests

5 participants