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 so Ansible can easily access and manage these hosts under our user account(s).

For this article, we’ll assume our user account is called “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 idea of a role is similar to that of a function in programming; code that can be used repeatedly with only the input being changed, we need to specify a number of variables the role will use when deployed. In our case, the variables will consist of the user account(s) we want created on our remote hosts along with any relevant host setup information.

But where do we put these variables? Thats a good questions.

When Ansible runs, it first collects all variables associated with any group(s) the host is apart of. Additionally, it also pulls in all variables in group_vars/all.yml as all is a special group associated with all hosts.

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]

Additionally the role itself also can have variables so also include role/vars/main.yml.

Knowing this, the most logical place to input our variables will be linux_hosts.yml as the role is only meant to work on Linux-based hosts. Open the linux_hosts.yml file.

vim /opt/ansible/group_vars/linux_hosts.yml

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 all tasks within the ansible_join role against all hosts listed under the linux_hosts group we configured earlier. As as specified linux_hosts and not windows_hosts or the special group all, only Linux-based hosts will be valid targets for this play.

Deploy to Hosts

It’s time to deploy our playbook (which runs the role) 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. The 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 more configuration is necessary.