Ansible : distribute file to all users

General
1

Hi,

For the last few weeks, I’ve decided to follow jlehtone’s suggestion and learn Ansible. Bought a thick book about Ansible, read about half of it and started experimenting with a number of VMs.

There seems to be no forum or mailing list for Ansible, so I thought I’d ask the odd question about it here.

What’s a proper way to distribute a file to all “real” users (e. g. users who are neither root nor system users) ? Here’s what I found after quite some fiddling:

    - name: Configure Vim editor for existing users
      ansible.builtin.copy:
        src: vimrc
        dest: /home/{{ item.key }}/.vimrc
        owner: "{{ item.key }}"
        group: "{{ item.key }}"
        mode: 0644
      loop: "{{ ansible_facts.getent_passwd | dict2items }}"
      when:
      - item.value.1|int > 999
      - item.value.1|int < 65534
      loop_control:
        label: "{{ item.key }}"

What this does is essentially find all the “real” users on the system and copy a default .vimrc file in their respective home directories.

Now I wonder if there’s maybe some magic module that does this in a much more simple way.

Any suggestions ?

2

copy is probably one of the best you can use. There are other modules, whereby you can download a file from a URL source and set the destination of where to save it on the appropriate server. You can also use jinja template files whereby you would replace info in it. For example, if I was wanting to use ansible to create a cron file on a server, and I could be using multiple distributions, where for example on RH-based it’s the apache user, and on Debian/Ubuntu it is www-data. Then in my template file, I would have something like:

* * * * *     {{ apache_user }}     /path/to/program/to/run

notice the double-braces which is for referencing a variable that will be used by the jinja templating to replace it with apache or www-data.

Since you are just copying a file that you are managing to each of the home directories, then the one you are using is probably the best and easiest.

The ansible docs are a great resource: https://docs.ansible.com/

You can also use:

ansible-doc cmd

where cmd is the ansible command you want to use, eg:

ansible-doc template

for when wanting to use jinja templates and how to use it within the playbook. It also lists examples as well, which means even in an offline environment (no internet), you can still get decent working examples.

1 Like
3

Thanks for the clarification.

On a side note, where’s the best place to look for help with Ansible ? There doesn’t seem to be a forum or mailing list.

4

To be honest, a lot of the stuff you can get from the Ansible Docs. This is where I tend to go, or googling which sometimes will show up posts on stackexchange, stackoverflow, etc.

I haven’t found any other forum resources as such.

5

Another remark:

Perhaps you want to put the .vimrc into /etc/skel/ before starting to creat users.
At least that’s what /etc/skel is for (populating user’s homedir at creation time).
See man useradd(8)

Cheers
-Fritz

6

@felfert yeah that’s another way, but let’s say there are already 100 servers created. That would mean creating a file on each of those servers - time consuming.

Now, a better way would be create the file, and use Ansible to then copy that file to /etc/skel on all those 100 servers by the use of the Ansible playbook. Then for new users being created, they would have that file. However, for existing users, they will not. So there still needs to be done the task that he has done so far to copy that file to the existing user directories.

As he’s already got it being created for the existing users, another one can be added to manage/maintain the file in /etc/skel for all new users. So:

    - name: Add vimrc to /etc/skel
      copy:
        src: vimrc
        dest: /etc/skel/.vimrc
        owner: root
        group: root
        mode: 0644

the ansible.builtin. isn’t required, hence my example above is missing that and just has copy. It will still work.

7

That is true. You also get the same documentation with both:

ansible-doc ansible.builtin.copy
ansible-doc copy

The (optional) prefix is a namespace. With ansible-core some modules are now in collections and a third-party collection could reuse a name, trusting that (use of) namespace (prefixes) resolve it. Essentially the same story as with C++ namespaces.

The ansible-doc finds the installed collections too.

@microlinux

  • Your task ensures that every user has that exact Vim config. If they had something different, then those customizations get overwritten. A policy choice. An “add only if not there” is a bit more complicated
  • The /home/{{ item.key }} presumes that every (regular) account does have a home directory in /home. That is probably true in your site. A more generic implementation would pick the path from the item (and possibly filter out “the impossible”)
  • I know sites with centrally shared volumes. On such I would do these “drop files” tasks only on one machine, preferably the file server (where the paths might be unique too)
  • I know sites, where uid’s run way beyond the “nobody” (65534)
  • Like @iwalker, I usually browse the Ansible Docs (and whatever Google bothers to find – choosing the words wisely is an art though)
1 Like
8

I’m not a lamer for RTFM. I have a full library full with printed Linux books. Hey, I even wrote five of these. But with any piece of software, there comes a time where you need to be able to ask a question, and maybe someone out there has the answer, or at least some intuition to get you on the right track. Isn’t this what this forum is about?

1 Like
9

And thats why we are discussing it. I didnt say RTFM. I replied to say that there doesnt seem to be an ansible specific forum and suggested the only resources that I have been able to find and use.

Since there doesn’t seem to be an ansible-specific forum, we can discuss it here obviously.

1 Like
10

There are some mailing lists and chat rooms described here:

https://docs.ansible.com/ansible/latest/community/communication.html

11

Hearsay:

Red Hat’s perspective has been that Ansible provided in RHEL is only supported for the use case of handling RHEL System Roles, not generic automation use cases. The extra tooling (ansible-galaxy, etc) is available for those that wish to do so, but isn’t a use case considered by the team.

This was mentioned in discussion about ansible-core in el9_2. It requires now python3.11.
The el9_2 (and el8_8) did add python3.11. However, as “AppStream package”, the python3.11 is
supported only to May 2026; the team that manages Ansible for RHEL has to switch Python again by then.

Not surprising. Whatever is in EL has always been its own branch.