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.
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
As we are editing our Common role in the video, it might make sense - in your situation - to put your
users inside your
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
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.
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.
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.
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.
Apologies for my pronunciation of Mivok as as Mivoko in the video!
If you have found this video helpful, please consider sharing. I really appreciate it.
|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|
|10||Git Your Deploy Just Right||05:34|
|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|
|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|