Using your own control host with the lab

Whilst a control host for Ansible is provided with the course, i.e. the Virtual Machine called ubuntu-c, some prefer to configure their own control host.

It is recommended that you leverage the provided control host for the best experience, however, this post gives some guidance on aspects that need to be considered to see the best from the course, should you decide to create your own.

Assumed user of packt for Section 02. Ansible Architecture and Design, 01. Ansible Inventories

In some of the examples used, the playbooks provided in the repo for both the centos and ubuntu hosts directly reference the target hostname with no implicit user -

1
2
3
4
5
6
7
8
9
[centos]
centos1
centos2
centos3

[ubuntu]
ubuntu1
ubuntu2
ubuntu3

In the starter sections of Architecture and Design, Ansible Inventories, if you were running this from the supplied control host (ubuntu-c), the user you’d be connecting from would by default be the packt user. Subsequently, the packt user, exists on all of the target lab hosts.

The local user of your own control host is likely to be different and as a result, you’d experience issues with connectivity.

To mitigate, make the following changes to playbooks, adding ansible_user=packt -

1
2
3
4
5
6
7
8
9
[centos]
centos1 ansible_user=packt
centos2 ansible_user=packt
centos3 ansible_user=packt

[ubuntu]
ubuntu1 ansible_user=packt
ubuntu2 ansible_user=packt
ubuntu3 ansible_user=packt

Whilst this can be achieved in a more convenient fashion using vars, this isn’t covered until a later section, hence the approach above is recommended for consistency until familiarity with the different approaches is achieved.

When progressing through the course, should the hosts file contain a connectivity that assumes a non root user, update the file either directly as above, or via a hosts var directive, i.e.

1
2
[ubuntu:vars]
ansible_user=packt

Thanks to Andrew Graham (queglay) for highlighting this issue at https://github.com/spurin/masteringansible/issues/9

DNS Issues

The control host supplied with the virtual machine is configured to resolve it’s DNS, from the supplied machine, dnsmasq.

There’s a few ways of resolving this. A quick fix, is to set your DNS server temporarily, to that of the dnsmasq resolver at 192.168.0.40, it acts as a generic forwarder for other internet connectivity so shouldn’t affect your online experience, whilst the VM is running.

Alternatively, if you’re familiar with editing hosts files, you can add entries accordingly on your control host as per the IP details provided in the lab slides. When doing so, add both the hostname and hostname.masteringansible.com entries for each.

Again, thanks to Andrew Graham (queglay) for highlighting this issue at https://github.com/spurin/masteringansible/issues/8

Nginx playbook

The nginx playbook template was mapped against the nginx configuration of that available on the associated lab instances, i.e. centosx and ubuntux. The default nginx configuration across the multitude of linux flavours will vary and as a result, this exercise may or may not work effectively in your own environment outside of the lab.

I suggest for this, either use the lab, or work on changing the templates to meet your local configuration, it shouldn’t be too difficult. If you do succeed, let me know in the comments and reference your updated templates.

Thanks to Raj Burnwal (rajkrburnwal) for highlighting this issue at https://github.com/spurin/masteringansible/issues/6

Share