No JSON `setup' file when running as non-root with sudo

Archives Ansible Project
1

(I know from a previous conversation here, that Michael isn't fond of
the setup file, but I am. :slight_smile:

Running devel (commit 3b83a87bcca6b394611d50fb143fccfbe635d5e1),
I note that the JSON `setup` file (typically /etc/ansible/setup) isn't
left in /etc/ansible/setup when a playbook runs as non-root with sudo:

        - hosts: someservers
          user: ansible
          sudo: True

I caught a glimpse of ~ansible/.ansible/tmp/.ansible/setup, cleaned that
all away to try and determine whether it gets there consistently, but
it seems to land in ~root/.ansible/tmp/.ansible/setup

Is this a bug and/or is there a reason for not leaving it in
/etc/ansible/setup?

        -JP

2

(I know from a previous conversation here, that Michael isn't fond of
the setup file, but I am. :slight_smile:

Running devel (commit 3b83a87bcca6b394611d50fb143fccfbe635d5e1),
I note that the JSON `setup` file (typically /etc/ansible/setup) isn't
left in /etc/ansible/setup when a playbook runs as non-root with sudo:

- hosts: someservers
user: ansible
sudo: True

I caught a glimpse of ~ansible/.ansible/tmp/.ansible/setup, cleaned that
all away to try and determine whether it gets there consistently, but
it seems to land in ~root/.ansible/tmp/.ansible/setup

Is this a bug and/or is there a reason for not leaving it in
/etc/ansible/setup?

It's kind of there to work around some things -- though it's not perfect yet.

Basically the issue is that if you run a playbook as multiple users (do some stuff as root, do some stuff as mdehaan, etc), you aren't guaranteed permissions on /etc/ansible/setup, so it's going to try to use paths in $HOME that it knows it can write. However, I would expect that to be the current user you logged in as, not root. (Did it use ~/username or /root)?

The other issue is that if multiple invocations of ansible are happening at the same time, it's a bit of a race condition to rely on generating the file and reading it, (assume multiple sysadmins), so it's better to use different locations. Using the user's directory as root
here really doesn't help though -- clearly that's not good enough.

It is useful for debugging, but I am thinking most likely it *will* go away in the future, since the original purpose was for writing template files on the machine, and these now are evaluated on the ansible "server" instead.

So technically, writing the setup file is an artifact, and I think we don't need to write it to disk.

Since you sometimes DO want to see the results of that module on the system though, maybe if it doesn't write by default, the setup module could get a parameter that allows it to save to disk, and this could be controlled by a ansible variable of some kind. (save_setup_results = path) ?

Sorry if that's a bit of a confusing answer :slight_smile:

3

> (I know from a previous conversation here, that Michael isn't fond of
> the setup file, but I am. :slight_smile:
>
> Running devel (commit 3b83a87bcca6b394611d50fb143fccfbe635d5e1),
> I note that the JSON `setup` file (typically /etc/ansible/setup) isn't
> left in /etc/ansible/setup when a playbook runs as non-root with sudo:
>
> - hosts: someservers
> user: ansible
> sudo: True
>
> I caught a glimpse of ~ansible/.ansible/tmp/.ansible/setup, cleaned that
> all away to try and determine whether it gets there consistently, but
> it seems to land in ~root/.ansible/tmp/.ansible/setup
>
>
> Is this a bug and/or is there a reason for not leaving it in
> /etc/ansible/setup?

It's kind of there to work around some things -- though it's not perfect yet.

Basically the issue is that if you run a playbook as multiple users (do some stuff as root, do some stuff as mdehaan, etc), you aren't guaranteed permissions on /etc/ansible/setup, so it's going to try to use paths in $HOME that it knows it can write. However, I would expect that to be the current user you logged in as, not root. (Did it use ~/username or /root)?

The other issue is that if multiple invocations of ansible are happening at the same time, it's a bit of a race condition to rely on generating the file and reading it, (assume multiple sysadmins), so it's better to use different locations. Using the user's directory as root
here really doesn't help though -- clearly that's not good enough.

It is useful for debugging, but I am thinking most likely it *will* go away in the future, since the original purpose was for writing template files on the machine, and these now are evaluated on the ansible "server" instead.

So technically, writing the setup file is an artifact, and I think we don't need to write it to disk.

Since you sometimes DO want to see the results of that module on the system though, maybe if it doesn't write by default, the setup module could get a parameter that allows it to save to disk, and this could be controlled by a ansible variable of some kind. (save_setup_results = path) ?

Sorry if that's a bit of a confusing answer :slight_smile:

Slight correction -- the setup file IS necessary for templates if you are running templates with /usr/bin/ansible vs /usr/bin/ansible-playbook, because you want to write variables with one command and template with a later command. So we can't remove the setup file.

Though it is true play books don't have to do anything with that file, we keep it around so the /usr/bin/ansible command line can use it.

It seems that if you are sudoing to root saving the results to /etc/ansible/setup is desired behavior, as you say.

The question then comes up how to do you handle multiple simultaneous ansible invocations. I think for play books this won't matter (they don't need the file), and this is probably not such a bad corner case unless people are running the template "module" with /usr/bin/ansible.

I think we're ok, and I'll file a bug that if sudo'ing to root the metadata location should be /etc/ansible/setup.

4

It seems that if you are sudoing to root saving the results to
/etc/ansible/setup is desired behavior, as you say.

Indeed.

The question then comes up how to do you handle multiple simultaneous
ansible invocations.

I'd never do that! :wink:

How about having Ansible return the setup file back to the manager, i.e.
to the machine invoking Ansible, storing it in a configurable directory,
a little bit like the FETCH module does? That would certainly fulfill
my needs nicely.

I think we're ok, and I'll file a bug that if sudo'ing to root the
metadata location should be /etc/ansible/setup.

Good, thank you.

        -JP

5

How about having Ansible return the setup file back to the manager, i.e.
to the machine invoking Ansible, storing it in a configurable directory,
a little bit like the FETCH module does? That would certainly fulfill
my needs nicely.

Running /usr/bin/ansible to invoke the setup module with the --tree option will do this, but it's not something play books do. May be good enough? Brings me to this point:

=== IDEA ==

I've been toying with the idea of making an optional (configurable) key/value store integration where we save those as they progress over time, as well as pass/fail results and things like that. The idea is ansible facts have a lot of interesting data where I want to view and do interesting things with that data as it changes over time. In some sense, it's monitoring, it other senses, it is inventory and trending.

I'd be curious what folks thought might be interesting/useful.

graphite seems to be popular though I'd also like things I can query and ask questions about (like Riak or Hadoop maybe).

I don't particularly want to write my own visualization web app, RRD implementation, or anything like that… and I'm definitely not adding any new required components. If this exists, it would probably look to see if /usr/bin/ansible-data-helper (a separate project) was installed and that program would have a configuration file, and have configurable plugins that spoke to multiple data storage endpoints.

So maybe graphite (carbon?) is one thing it can speak to, and maybe Riak or Hadoop is another, and we start with just one that gets us the most shiny things.

Riak is super easy to use from a REST API perspective and I also think we have some Basho folks interested in Ansible. Yet we also have some folks doing things with using Ansible with Hadoop!

I want to be able to answer questions like "which nodes have ever ran this version of this package", and things like that.

If done correctly, this tool might even be somewhat generic, allowing you to funnel data to it in a special format from multiple applications, so it is effectively a systems-management data-store abstraction layer.

I'm not trying to get enterprisey, really I'm not… but that seems like it would be an incredibly cool thing to have and Ansible has a lot of data it isn't making full use of yet.

--Michael

6

Running /usr/bin/ansible to invoke the setup module with the --tree
option will do this, but it's not something play books do. May be
good enough?

I missed the `--tree' option in the fine manual. That's pretty good,
even though ansible ovewrites the file on each run, but I can live
witht that.

Can you add --tree to ansible-playbook? That would make it perfect.

I've been toying with the idea of making an optional (configurable)
key/value store integration where we save those as they progress over
time, as well as pass/fail results and things like that. The idea is
ansible facts have a lot of interesting data where I want to view and
do interesting things with that data as it changes over time. In some
sense, it's monitoring, it other senses, it is inventory and trending.

Yesh! Ack to the optional and configurable. The managing host should be
able to specify that ansible *and* ansible-playbook invoke a program
with the JSON results from the managed nodes and that co-utility could
then store/forwared the results in/to whichever method is appropriate
for the environment. Something like this?

7

> Running /usr/bin/ansible to invoke the setup module with the --tree
> option will do this, but it's not something play books do. May be
> good enough?

I missed the `--tree' option in the fine manual. That's pretty good,
even though ansible ovewrites the file on each run, but I can live
witht that.

Can you add --tree to ansible-playbook? That would make it perfect.

I'm not going to do it, but I'll accept patches to that effect.

> I've been toying with the idea of making an optional (configurable)
> key/value store integration where we save those as they progress over
> time, as well as pass/fail results and things like that. The idea is
> ansible facts have a lot of interesting data where I want to view and
> do interesting things with that data as it changes over time. In some
> sense, it's monitoring, it other senses, it is inventory and trending.

Yesh! Ack to the optional and configurable. The managing host should be
able to specify that ansible *and* ansible-playbook invoke a program
with the JSON results from the managed nodes and that co-utility could
then store/forwared the results in/to whichever method is appropriate
for the environment. Something like this?

---
- hosts: somehosts
user: ansible
collector: /usr/bin/ansible-data-helper
sudo: True
vars:

I think most of the configuration would be done in the collector, and ansible just detects that the collector is installed.
  

> I'd be curious what folks thought might be interesting/useful.

In the environments I'm using Ansible in at the moment, a collection of
JSON result-files is more than enough -- everything else is overkill,
but I'm sure there are people who'd like Riak, Carbon, etc.

I'd doing this for my own ends, so I'd probably not implement a JSON tree option initially, but it would be plugin oriented enough
for someone to contribute one and nothing would prevent that.

Plus I'm thinking --tree could just be an option to playbooks, but we'd have to decide on what was a meaningful output structure. If it is just saving the setup
files, which I think it should, that becomes fairly simple.

some_specified_directory/hostname/setup

Though it also makes sense to save some_specified_directory/hostname/results … possibly

8

Maybe at some basic level, but that's not really the inspiration. I
think Puppet reports were generally about pass/fail status, which is
not so interesting.

I'm really interested in two things:

(A) getting graphical views quickly without having to maintain
another GUI interface program, and in a way that can integrate with
other data (from other monitoring tools you may be running all in the
same view).

(B) being able to ask historical questions of a key value store that
supports search, and have it be able to tell me things about my
infrastructure. Show or tell me all my CentOS nodes that are running
Apache. It is super easy to write custom facts now (any module can
return a dictionary called ansible_facts), so ansible seems well
suited to that kind of data collection, and it makes it an interesting
way to write reporting applications too.

I'm also not really looking to build a new dashboard-like web
application (why does every application have it's own, etc?), but be
able to leverage applications that already exist. That seems to be a
very good strategy for us as web apps can be a lot of work with
browser compliance, security, UX, and so forth.

9

Maybe at some basic level, but that's not really the inspiration. I think Puppet reports were generally about pass/fail status, which is not so interesting to me.

I'm really interested in two things:

(A) getting graphical views quickly without having to maintain another GUI interface program, and in a way that can integrate with other data (from other monitoring tools you may be running all in the same view).

(B) being able to ask historical questions of a key/value store that supports search, and have it be able to tell me things about my infrastructure. Show or tell me all my CentOS nodes that are running Apache. It is super easy to write custom facts now (any module can return a dictionary called ansible_facts), so ansible seems well suited to that kind of data collection, and it makes it an interesting way to write reporting applications too, or have other management applications integrate with that data. We could easily go schema less here (unlike Puppet) and have the advantage of supporting complex datastructures in ansible facts already.

I'm also not really looking to build a dashboard-like web application, but be able to leverage applications that already exist. That seems to be a very good strategy for us as web apps can be a lot of work with browser compliance, security, UX, and so forth.

We're probably only talking about a few thousand lines of code for all of this, and it's also something other apps would be able to call and use to get the same kind of capabilities.

--Michael