DevOps with DebOps

Connection Required

Once Ansible is set up on the configuration server, the next question is how to set up the connection with other servers – i.e., the ones you want Depops to configure. One thing is clear: Ansible does not rely on its own client-server protocol but uses the very well established SSH to perform commands. The next step is to set up Ansible and the other servers so that the login works.

One option is to create an unprivileged user account, which is then given root privileges via sudo . However, this approach is a little time consuming, because you then need to enter the sudo password manually each time you run Ansible, unless you want to store it in the DebOps configuration. It is also possible to enable sudo without the user’s password and instead manage access based on SSH keys.

On paper, this solution has significant advantages; the login is carried out via an SSH key that doesn’t require a password. As SSH keys are already standard in most setups, you immediately switch off the password login via SSH.

If you want to take the risk, you could theoretically generate an SSH key with an empty password and store its public part on all target servers for the user root via ssh-copy-id . In .debops.cfg in the configuration directory, the [ansible defaults] section then needs to be extended to include the remote_user = root entry. This ensures that Ansible actually uses the root account.

DebOps uses the ansible/inventory/hosts file in the folder previously created by debops-init to determine which host to connect to:

server1.example.net
server2.example.net
server3.example.net

A group name is missing in this example. The preceding file would thus lead to generic tasks that are not assigned to a specific group running on all three hosts. You could also use precisely this file combine server groups for DebOps, which simplifies configuration. The following entry would be necessary to roll out PostgreSQL on server 1:

[debops_postgresql_server]
server1.example.net

From previous painful experiences, the DebOps developers have learned that they need to check the condition of the target systems. The DebOps documentation recommends you enter the following command:

debops-task all -m setup

after you set up the connection and the inventory file.

Tricks for the Test

DebOps has not yet generated the necessary ansible.cfg file – after all, you have not even called debops thus far. A crude hack helps: enter debops immediately followed by [CTRL] + [C] to cancel the operation again as soon as possible. Then you can launch debops-task as described.

The reason for canceling the operation is that the debops command would start running and use all the playbooks on the hosts for which they are configured, which is not what you want at this stage.

A Nasty Surprise

The aim for this example is to install a working instance of PostgreSQL – such as the basis for a classic LAPP Setup – on at least one of the servers. Once the setup step for debops-task has completed successfully, you have one more problem to deal with before you get to work.

During a normal run, Debops runs the common.yaml playbook on each host. This step configures certain basic settings and also ensures that certain basic packages are installed and that the apt configuration is identical. The problem: It also installs the Ferm (For Easy Rulemaking, [4]) and TCP Wrapper tools. These tools nail down the host via iptables , so that it is no longer possible to login remotely. Ansible thus locks itself out.

The TCP Wrapper admin can prevent this issue simply by prohibiting this behavior. Use a parameter in ansible/inventory/group_vars/all/debops.tcpwrappers.yml within the Debops configuration directory. The required entry is:

tcpwrappers_deny_all: False

After this step, Tcpwrapper still can’t fully keep its hands off Iptables, but at least it no longer installs the deadly catch-all rule.