Configure Linux Hosts

With Ansible installed and a basic environment configured, we’re ready to create our first playbook. This playbook will configure our remote hosts, enabling Ansible to easily access and manage them under our user account(s).

For this article, we’ll assume our user account is named “Bob.”

Configure Role

On your Ansible controller install git.

sudo apt install git

Clone the linux_join role into your roles directory.

git clone https://github.com/twobyteblog/ansible_join.git /opt/ansible/roles

User Accounts

As the concept of a role in Ansible is similar to that of a function in programming — code that can be reused with only the input changing — we need to specify several variables that the role will use when deployed. In our case, these variables will include the user account(s) we want to create on our remote hosts, along with any relevant host setup information.

But where should we place these variables? That’s a good question!

When Ansible runs, it first collects all variables from an assortment of areas:

1. Any groups the host is a part of.
2. All variables specified under a special group that applies to all hosts: group_vars/all.yml.
3. Variables defined under the role itself: role/vars/main.yml.

Following the layout we created in the Environment article, you can expect variables in the following files to be available to the role when run as part of a playbook:

• group_vars/all.yml
• group_vars/linux_hosts.yml
• host_vars/[hostname]

Understanding the above, the most logical spot to place our variables will be group_vars/linux_hosts.yml as the role is only meant to work on Linux-based hosts.

1. Open the linux_hosts.yml file.

vim /opt/ansible/group_vars/linux_hosts.yml

2. Within add the following, replacing bob with your username. Add an additional line for each user you’d like setup on your remote hosts.

user_accounts:
  - { name: 'bob', uid: 1001, group: "sudo,adm" }

In the example above we’re creating an account called bob with a UID of 1001. This user will be added to the sudo and adm groups, granting the account administrative privileges and the ability to read system logs stored under /var/logs/.

SSH Public Key

Next, create a file for each user under /opt/ansible/roles/ansible_join/files. Ensure the file is named [username].pub.

bob.pub

Within the .pub file, copy in the user’s SSH public key we created earlier. The SSH public key can be located at ~/.ssh/id_edsa.pub on the respective user’s workstation.

ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBABDH7li4FEqUh ...

Create Playbook

Create a playbook called linux_join.yml.

touch /opt/ansible/linux_join.yml

Open the file with your preferred editor and add the following content.

- name: Configure host for Ansible management.
  hosts: linux_hosts
  become: yes
  roles:
    - role: ansible_join

This small playbook tells Ansible to run the ansible_join role against all hosts who are a member of the linux_hosts group.

As the playbook specifies linux_hosts and not windows_hosts or the special group all, only Linux-based hosts will be valid targets for this play (assuming only Linux-based hosts are members of the linux_hosts group).

Deploy to Hosts

It’s time to deploy our playbook to configure our user account(s) on our remote hosts. For this we’ll use the ansible-playbook command.

Run the following command.

ansible-playbook -i production -kK -u [username] linux_join.yml

Flags

• -i indicates which inventory file we’d like Ansible to use. This is how you can switch between running Ansible plays against production and development hosts.
• -kK indicates that you’ll need to provide a password both to connect (-k) and to gain access to sudo privileges (-K). After Ansible has configured the host, you’ll no longer need these flags.
• [username] is the username of the account on the remote host Ansible will be connecting too. This account must have sudo privileges.

Testing

If everything went well, our remote host has now been configured with SSH key-based access which Ansible can use to run plays on.

Let’s do a final test using the handy ping command.

ansible -m ping linux_hosts

You should see the following results indicating that Ansible was able to successfully connect to your remote hosts.

web01.prod.twobyte.blog | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/opt/virtualenv/bin/python3.11"
    },
    "changed": false,
    "ping": "pong"
}
web02.prod.twobyte.blog | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/opt/virtualenv/bin/python3.11"
    },
    "changed": false,
    "ping": "pong"
}
db01.prod.twobyte.blog | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/opt/virtualenv/bin/python3.11"
    },
    "changed": false,
    "ping": "pong"
}

We’re now ready to deploy other playbooks against our hosts.

If you’ve made it this far congrads :) For Linux-only folks you’re done! For Windows, lets move onto the next article.