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 pre-configured 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.

You can add the following parameter:

postgresql_server__admin_password:'top-secret'

parameter in ansible/inventory/group_vars/all/debops.postgresql_server.yml to set a global password: All PostgreSQLs rolled out by DebOps are then equipped with this password. Alternatively, the password can also be set for each host using the ansible/inventory/host_varsserver1.example.net/ debops.postgresql_server.yml file in the DebOps configuration directory.

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

Adminstrators 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.

DebOps provides similar functions: Using Enc-FS and the debops-padlock tool, you can store your password in encrypted form, so that it can only be used with your GPG key. You need to exercise caution: A separate GPG key should be created and used; the password should be known to all stakeholding administrators. The developers reveal details about debops-padlock in the documentation [5].

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, Logstach, 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 application you can deplop with Debops.

Secure Repository

The developers maintain the DebOps tools, as well as the corresponding playbooks, in separate directories on GitHub [6]. The DebOps team initially consisted of just a handful of people, and because they all had some kind of relation to Debian,they were quite open to collaboration with other developers.

The developers were well aware of the need for security: If you want to check your own code into the GitHub Directories, you first need to sign it using GPG. Only appropriately signed code can move into the Github directory. The project developers closely monitor the GPG keyring in which the keys are listed.

Basically, the creators have copied the workflow that Debian uses for its own packages: With Debian, only developers whose GPG key is included in the Debian keyring are allowed to upload new packages to the official Debian archive. To join up as a Debian developer or as a package maintainer, you need to add your own GPG key to the corresponding keyring.

The reliability of DebOps is thus similar to that of Debian: an attacker who gains access to the GPG key of an approved developer could theoretically cause a large amount of damage on the target systems, but if you rely on Debian or Ubuntu anyway, DebOps does not increase the risk.

Conclusions

DebOps takes a clever approach: After you install a system with the DebOps tools, you can quickly configure it to host a database, web server, or monitoring server. The prefabricated Ansible roles are extremely useful, because they save you from the need to invest a large amount of time in writing your own roles.

The fact that DebOps is not totally intuitive spoils some of the fun. Another issue is, if you have never dealt with Ansible, you will need to plow through many pages of documentation to understand DebOps. DebOps provides good start-up support, but it ultimately does not avoid the need for administrators to establish their own Ansible expertise.

If you are looking for fast automation for Debian or Ubuntu, why not give the fantastic DebOps automation system a try?

Special Thanks

     This article was made possible by support from Linux Professional Institute