In this video we are going to get to grips with managing Users with Ansible.

Rather than try and re-invent the wheel, I am going to make use of the fantastic Users role by Mivok. This is the role I use in both my personal, and client projects to manage Users.

To begin with, we will install the new role using Ansible Galaxy:

sudo ansible-galaxy install mivok0.users

There are as many pros as there are cons to Ansible Galaxy - in my opinion - but that is for another video.

Password Hashword

As we are dealing with Users, we are going to need to provide at least one password.

We could go ahead and generate these passwords a number of ways, but the Ansible FAQ gives us a good solution that works without much fuss.

sudo apt-get install whois

Then to generate the password, one of either:

mkpasswd --method=SHA-512
# or
mkpasswd --method=SHA-512 --rounds=10000

mkpasswd encrypts the given password with the crypt(3) libc function. Learn more about mkpasswd here.

Where To Store Our User Config?

As part of the Users role we are given some variables that have satisfactory defaults, and some we need to configure. The main one being populating the users list.

As we are editing our Common role in the video, it might make sense - in your situation - to put your users inside your roles/common/defaults/main.yml file.

Personally, I have moved my Users role to a standalone role - something we will come to later in the Ansible Galaxy video. To me, it is a little confusing to put the users inside a Common role. Well, maybe not confusing, but not immediately obvious where to look when changes need to be made a few weeks or months later.

If you go with a standalone Users role then by all means, if it makes sense in your environment, put your users inside your roles/users/defaults/main.yml file. To me, that seems pretty sensible.

However, another way of doing this would be to use group_vars.

One of the things Ansible gives us for free, if we choose to use it, is the group_vars/all file. We can put variables in here, and anything we do put in here will be available to all our Ansible hosts.

In my environment, this would be a good place for my common users. Decide what makes most sense for your own.

Note, the group_vars/all file has no yml extension, and as such, it looks fugly.

# group_vars/all
---
users:
  - username: chris
    name: "Chris from Code Review Videos"
    groups: ['sudo', 'some-other-group', 'a-third-group']
    uid: 2001
    password: $6$rounds=10000$g3mFskqEff0x$MPq3Zxaget/cVSb8sMHTfnq6LQJccXbAvXxUDsDH5E9GlBbwfuYnYyTl7VUSZB2yQRS9V2Ma/J4kKBO3Lugov.
    ssh_key: 
      - "ssh-rsa AAAAA.... chris@laptop"
      - "ssh-rsa AAAAB.... chris@desktop"
    shell: /bin/zsh
  - username: ebachman
    name: "Erlich Bachman"
    groups: ['pied-piper']
    uid: 2002
    password: $6$rounds=10000$x00lC/pdl3LaIQ$jJgYqRQalY4eZSE8uWrYSzmCVru8hhEiLN0G0ZD4bd4aiGLH9egg8d6wlW5Nyt.MmhiucnVEjKpW.zxusBpye1
    ssh_key: 
      - "ssh-rsa AAAAA.... erlich@aviato"

And so on.

Because Mivok is a stand up guy we can also do cool things like create Groups, remove old users, and should we have install Zsh for example, we could set individual users to use a different shell.

Notice, I begin our UID numbers at 2001, rather than 1001 - just to avoid any potential overlap.

Enabling The Users Role

With all this configuration, the Role itself won't run unless we tell it to do so. And of course, we do that by updating our Ansible Playbook.

In this case, we are running the Users role as part of our Common playbook.

#common-playbook
---
- hosts: all

  roles:
    - common
    - mivok0.users

If you're unsure where to find the role name, it's the same name you used when you ran the ansible-galaxy install command.

Time To Deploy

Assuming you have saved all your changes and uploaded (or git pushed) to your Ansible server, we should be good to go.

Running our playbook is similar to always. We are going to limit our deployment to only our target machine, but aside from that, much the same as usual:

ansible-playbook common-playbook.yml -i hosts -l target -k -K -s 

If any of this is not making sense, be sure to check out the Playbooks tutorial video.

As you'll see in the video (07:20), because we haven't deployed to this machine before - or even connected to it from the Ansible master - the first time we run we get a fatal error telling us that this host's fingerprint is not in our known_hosts file.

This is easy enough to fix, just connect via SSH from the Ansible server to your deployment target. Then, exit from the SSH session, and re-run the command.

Once your deployment is good and the playbook run finishes, we can test this by connecting via SSH as our new user from one of the machines we configured the id_rsa.pub key file for, and we should get in without requiring a password.

Magic.

Learn to Enunciate!

Apologies for my pronunciation of Mivok as as Mivoko in the video!


Code For This Course

Get the code for this course.

Share This Episode

If you have found this video helpful, please consider sharing. I really appreciate it.


Episodes in this series

# Title Duration
1 How To Install Ubuntu Server in Oracle VirtualBox 10:21
2 How to Rename our Ubuntu Server 02:00
3 Installing Ansible on Ubuntu Server 00:33
4 Safety First, Safety Second - Snapshots are like Ctrl+Z 00:11
5 Managing the Ansible Inventory Hosts File 02:16
6 Ansible Ad Hoc Commands 04:27
7 Introduction to Ansible Playbooks 02:14
8 Ansible Handlers 01:38
9 Ansible Variables 03:16
10 Git Your Deploy Just Right 05:34
11 Ansible Roles 05:51
12 Looping in Ansible with_items 04:34
13 Ansible Files For Beginners 06:14
14 Variable Precedence - Where To Put Your Role Vars? 04:13
15 Ansible Templates 05:51
16 Ansible Inventory With Our Own Hosts Files 06:57
17 How to Manage Users with Ansible 08:32
18 Ansible Vault Tutorial 03:48
19 Ansible Galaxy Tutorial 10:03
20 Real World Ansible - Common Role Walkthrough 06:19
21 Ansible MySQL Tutorial 13:44
22 Ansible Symfony and nginx 09:37