4:45 p.m.
On 22-05-19 22:28, Maciej Delmanowski wrote:
DebOps v1.0.0 is here, let's release the HypnoDrones.
Awesome, thanks a lot for making it happen! I've been using DebOps at
CipherMail, Bits of Freedom and Amsterdam Wireless since v0.8.1, and I
just finished the update to v1.0.2. DebOps has greatly improved the way
we manage our servers. It's been a big step-up from our own Ansible
playbooks.
The LDAP support has been completely redesigned from the ground up,
both on the
server-side ('debops.slapd' role), and in the new client-side
('debops.ldap'
role). At the moment LDAP can be enabled for basic system services - UNIX
accounts and groups, 'sudo' configuration, SSH public key lookup. There are
still many more DebOps roles which have to be updated to use the new
infrastructure, but that will come in later releases.
I used the old debops.slapd role at CipherMail and Amsterdam Wireless.
Migrating to the new role did take some effort since my LDAP knowledge
is limited, but I got it all done in a day or so. We're also using the
debops.ldap role to manage shell accounts at Amsterdam Wireless.
Unfortunately it turned out that FusionDirectory, the web-based LDAP
management tool we used previously, would break the new directory
structure, so it had to go. We're using LDAP Account Manager now which
works just as well. It even has a nice directory tree viewer :)
Maciej, thanks a lot for all the hard work you put into the new LDAP
roles, they definitely are a big improvement over the old one. I
especially like the new ACLs and automated snapshots. I really enjoyed
reading the message you posted about it to debops-users. It's great to
see that so much care was put into it.
By the way, you mentioned that you had difficulties writing a role for
deploying a FusionDirectory frontend because it couldn't detect the base
DN. We had this issue as well, using the stretch-backports version
solved it for us. But like I said, we're using LDAP Account Manager now.
The stable branch, first one named 'stable-1.0', will get
bugfixes and security
fixes as long as the code in the 'master' branch is compatible, but there will
be no new features or major changes in the existing roles. If a role in the
'master' branch has been modified too much and direct cherry-picking of the
changes is impossible, the bugfixes might go directly to the stable branch, but
at this point a given release will probably become unsupported when a few more
recent releases are available.
That's great to hear, we can always use faster bug fixes!
Cheers,
Imre