Pre-Assembled

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 as soon as possible. Then, you can launch ansible.

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.

One thing that is very useful while working with DebOps is to ensure that the hosts have a properly configured DNS domain; you can check this by running the dnsdomainname command. If the domain is empty, most of the project should still work; however, more useful features like PKI infrastructure might not work correctly or at all.

An important feature in a multihost distributed environment is support for encrypted connections. The DebOps project provides this support using X.509 certificates and internal Root CA out of the box, including the free certificates of the Let's Encrypt project.

A Nasty Surprise

The aim of 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 ansible 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; however, it also installs the ferm (For Easy Rulemaking) [6] and TCP Wrapper tools. These tools nail down the host with iptables so that it is no longer possible to log in remotely. Ansible thus locks itself out.

DebOps is designed from the ground up for a production environment, and roles assume that it's correctly configured to allow Ansible Controller to make connections over SSH. The project itself tries to ensure that possibility by checking the source IP address from which the connection is coming and adding it to the firewall and TCP Wrapper whitelist; however, the code is not perfect and lockouts can still happen.

Try to think of this as a "rite of passage" at this point. Because an unknown IP address (one not allowed by the firewall) has been blocked, it seems that the project is working as intended. Still, if you want to avoid the headache (e.g., in a development environment), one of the ways to deal with this might be disabling the firewall and TCP Wrapper support through the Ansible inventory with:

ferm__enabled: False
tcpwrappers__enabled: False

Turning off the firewall might affect some functionality, like setting up internal networks, but should be fine at first. After this step, TCP Wrapper still can't fully keep its hands off iptables, but at least it no longer installs the deadly catch-all rule.

Rolling Out PostgreSQL

After you work around the login problem, continue with the installation of the first real application: PostgreSQL. The packages for Debian and Ubuntu are meaningfully preconfigured so that you just have to lend a hand, and only in one place: You need to define the password for admin in the PostgreSQL database. To set a global password, you can add the parameter

postgresql_server__admin_password:'top-secret'

in ansible/inventory/group_vars/all/debops.postgresql_server.yml: All PostgreSQLs rolled out by DebOps are then equipped with this password.

If the hosts file is modified as described so that server1.example.net belongs to the debops_service_postgresql_server group, you just need to call debops from the DebOps configuration directory: DebOps then starts Ansible rolling out the desired service on the target host.

Administrators are – quite rightly – not usually happy about the passwords for critical services being stored in the clear on any host. Ansible even provides a vault for this purpose, which means that the passwords can be stored with GPG encryption. Only the owner of the GPG key can open the encrypted file and see the password when calling Ansible.

One of DebOp's greatest strengths is that it automatically generates random passwords to all important services. Using EncFS and the debops-padlock tool, you can store your password in encrypted form so that it can only be used with your GPG key. The root account passwords are randomized, and database passwords and others are all stored on the Ansible Controller host in the secret/ directory beside the Ansible inventory. Therefore, there's no need to set passwords for the services manually – unless you want to for some reason. You need to exercise caution: a password should be known to all stakeholding administrators. The developers reveal details about debops-padlock in the documentation [7].

The example described in this article looks at DebOps with PostgreSQL. Other Ansible roles work in the same way: By adding individual hosts to groups in the host file, you can determine which services should run on them. DebOps then makes the configuration available, globally or by host.

At this point debops-defaults is very useful: It displays all available configuration parameters for currently active roles. If you want to add something to the configuration of a service on a host, this command first gives you a general overview; you can then proceed to configure the settings as described.

You will find some real gems in the DebOps playbooks: You can quickly set up the entire LAMP stack, for example, with DebOps and PostgreSQL. Lesser known tools like Elasticsearch, Logstack, and Kibana (Figure 3) are no more a problem than Samba, Postfix, or SNMPD.

Figure 3: The Elasticsearch visualization tool Kibana is just one of many applications you can deploy with DeBops.