On maj 16, Imre Jonk wrote:
Hello, and welcome to the mailing list! :)
To business. I wrote some DebOps-integrated roles at CipherMail
might be useful to others. My employer has agreed to release the roles
under the GPL version 3 (or later).
Awesome, good to hear that your employer is OK with releasing your work to the
Some roles lack documentation, tests and functionality to be useful
anyone, so I'll have to do some work to improve the overall role quality.
I guess I'll do that and create PRs for new debops-contrib roles soon.
If the role is for something included in Debian, you should create PRs against
repository, so that we can keep
everything in one place. Commercial software could go into the
repository, which has similar layout
to the main DebOps monorepo. In the future the debops-contrib repository will
probably be downloadable and installable using some kind of debops script
These are the roles I'm talking about:
- amsw.dnsui: provides complete functionality for integrating Opera's
DNS-UI, an LDAP-authenticated web frontend for PowerDNS authoritative
server. The role uses the nginx PAM module for LDAP authentication.
Requires PowerDNS 4.1+ for DNSSEC functionality. Depends on
debops.secret, debops.users, debops.postgresql, debops.php, debops.nginx
For this you probably have to build the nginx .deb package from source to
include the LDAP support, correct? Now that nginx modules are in separate
packages in Debian, I wonder when LDAP support will be available in the
distribution itself. I'm not sure why it's not there yet, licensing? Lack of
manpower or interest?
As for using the debops.users and debops.cron roles from your own role, can
you tell me the reasons behind it? The roles mainly exist so that users can
create UNIX groups/accounts on the hosts and manage cron jobs via the Ansible
inventory, without the need to write their own playbooks. Ansible has modules
for managing users, groups and cron jobs, which you could use in your role
directly, without the additional overhead of using debops.users and
- amsw.powerdns_auth: a simple role for PowerDNS authoritative
management. Right now you can only use this role with the Postgresql
backend and the upstream packages (I needed v4.1 for DNSSEC capabilities
on the API). Nonetheless it should be very easy to integrate this with
debops.mariadb and the PowerDNS BIND backend.
- ciphermail.nut: almost complete role for managing a Network UPS Tools
(NUT) server. Needs documentation and tests.
- ciphermail.nut_client: NUT client management.
- ciphermail.cups: manages our CUPS print server. Integrates with
debops.pki and applies some hardening tricks to ensure our print jobs
are always TLS encrypted with verified certificates.
- ciphermail.simplesamlphp: manages a SAML 2.0 iDP-only SimpleSAMLphp
installation, integrated with debops.pki. We use it for Single Sign-On.
- ciphermail.docker_container: simple role for managing Docker containers.
- ciphermail.docker_network: additional Docker role for managing networks.
Very interesting set of roles, looking forward for the PRs. :-) If you want,
you could fork the debops/debops repository on GitHub and create a branch for
each role right away, perhaps some other DebOps users could help you clean
those up, test the functionality and prepare the documentation.
We've also modified some existing DebOps roles because they
entirely satisfactory for us. We'll contribute these changes back as
well. We're using a lot of DebOps roles :)
Any suggestions (on where I should start, for example) are most welcome!
I would start with creating PRs for existing roles to merge in your changes,
then your own roles that depend on them should be easier to merge as well.
Once again, welcome to the list and I'm looking forward for your