On Jun 05, Imre Jonk wrote:
Right now I mostly miss roles for Docker container management
This type of thing would probably be done via docker_service, docker_compose
and other docker_* Ansible modules. Creating a role that has the correct order
of tasks general enough so it can be useful for most users might be hard,
although I haven't looked into that yet. I imagine that it might be easier to
let users write playbooks to manage their containers on Docker hosts managed
by DebOps - no need for crazy default variables that are modified via
inventory, just write docker_compose tasks directly. But, you are working on
a Docker client role, I'm eager to see how that looks like. :-)
an authoritative DNS server
I'm starting to feel the need for a better, centralized DNS/DHCP services as
well. Currently I'm working with two tinc VPN networks with separate subnets
and subdomains, which makes handling the resolver interesting. Having a local
unbound that redirects the requests to the correct DNS server based on the
subdomain helps, but I imagine that a central DNS that has dynamic subdomains
managed by DHCP could work better and not be confined to my workstation.
I'm looking into ISC BIND since this is what we are currently using in
production, and it nicely compliments the existing debops.dhcpd role which
uses ISC DHCPD. But I know that many DebOps users prefer PowerDNS, so if
anybody has a role for that, let me know.
a SAML iDP with two-factor authentication
In Debian there's lemonldap-ng package which apparently provides OpenID,
CAS and SAML support but I have no idea how popular this solution is. At work
we are using Jasig CAS which is now apparently Apereo CAS(?). It's not in
What I would like to work in next with the LDAP support is Samba support, to
leverage the slapd-smbk5pwd support in Debian to synchronize Samba and basic
auth passwords. This will force us to the Heimdal Kerberos implementation if
we want to integrate that as well though. I haven't played with Kerberos at
all yet, so I don't know if that's good or bad vs MIT Kerberos.
an OpenVPN server (with LDAP and maybe 2FA).
Indeed, Tinc VPN currently supported in DebOps is a nice solution for internal
mesh network in a data center, but it lacks sufficient controls for authorized
access. Having OpenVPN integrated with LDAP for authentication would be nice,
but that requires use of the shared secrets, right?
If we would want to support certificate authentication with OpenVPN, that
would require improvement of the client certificate support in debops.pki
role. A simple set of scripts that let sysadmin generate client certs based on
the e-mail address locally on Ansible Controller, against a specific internal
CA should probably be enough for small setups, something bigger might require
a dedicated service.
Perhaps users could authenticate to a website using their LDAP credentials,
and after checking the authorization the service could generate a client
certificate for them with installation instructions provided. I wonder if
something like this exists... Probably FreeIPA and/or Dogtag PKI has something
like this built-in, but they are currently in eternal Sid basement hell since
I remember, at least a few years now (in Debian Unstable with bugs that
perpetually kick them out from current Testing release). Maybe Debian Bullseye
will be a lucky break?
I've implemented these as
custom Ansible roles which I plan on improving and contributing to DebOps.
Looking forward to the PRs. :-)
There are some gaps in the documentation that should be filled. Some
basic things like provisioning a new host took me quite some time to
figure out when I first tried DebOps, for example. I read on the list
that Nicolas Quiniou-Briand wants to work on that, which is great!
I try to fill the gaps in the documentation at least a bit every major
release, but right now I'm more focused on cleaning up and rewriting existing
old roles, and adding new features here and there. But I agree, DebOps is now
so much beyond simple Ansible roles that for a new user it all probably looks
intimidating and they probably have to have a real need to even consider
trying out the project in the first place. A few documentation pages that
introduce Debian, Ansible and finally DebOps to new users would probably help;
Ansible because I see many new Ansible users that try out DebOps and then
vanish without a trace, and Debian because a basic knowledge about the
operating system of choice is very helpful when debugging errors during
playbook execution. There are excellent tutorials for both of these things
elsewhere, but having a more focused ones in relation to DebOps itself might
be a good thing.
I tried out the new LDAP roles before migrating our existing
I installed FusionDirectory from stretch-backports after running the
ldap/init-directory playbook, but the final step of the installation
process required performing migrations on the LDAP directory that
failed, leaving me with a broken setup. I didn't investigate it further.
I think that sidestepping the setup wizard entirely and generating the config
files needed by FusionDirectory directly might be a solution to this. I'm not
sure what changes FD requires in the LDAP directory itself, will have to
> Unfortunately, LDAP Account Manager package was removed from
Yeah I noticed that as well. It was also the main reason why we wanted
to use FusionDirectory in the first place. I guess we'll backport the
upstream packages when we migrate to Buster.
Note that FusionDirectory has an ACL system of its own, which might not
be easy to combine with the ACL rules that are set by DebOps. All LDAP
operations are performed by an LDAP admin user under the hood. What I
like about LDAP Account Manager (besides the directory tree browser) is
that it does not require an administrative user, additional LDAP schemas
or inserting/migrating LDAP entries to work.
Indeed, a non-opinionated client that doesn't try to impose any specifics and
lets the users manage their entries might be best. I'm currently using Apache
Directory Studio to work with the LDAP directory, but this might be overkill
to staff administrators and other such personnel.
There's also phpLDAPadmin web application... which also has been kicked out of
Debian Buster, so that's moot. Looks like standalone clients or a custom
in-house applications tailored to the needs of a particular organization are
the preferred solutions to LDAP management these days.