Proposal: FreeIPA Role for Fedora Servers Using Cockpit

Kevin Fenzi kevin at
Tue Dec 10 14:24:21 UTC 2013

Hash: SHA512

On Tue, 10 Dec 2013 07:13:30 -0500
Stephen Gallagher <sgallagh at> wrote:

> I was too focused on the user experience explanation that I missed a
> few conceptual pieces I wanted to talk about. I'll write a second blog
> post on that in a little while, but here is the basic gist of it:
> == Mechanism ==
>  * We want to have a role inventory so that we can trivially query
> which roles are deployed on a target system (with additional per-role
> meta-data). Ideally, I'd like to see us also presenting this inventory
> via discovery mechanisms like Avahi or OpenSLP for other monitoring
> tools to consume.

I think we should be very very careful there not to provide too much
help to attackers. :) "Oh, that machine is telling me it's the FreeIPA
server version foo. Cool"

>  * We should support role dependencies and conflicts. For example,
> it's acceptable to have both the "BIND 9" role in our tool belt, as
> well as the "FreeIPA DNS Server" role (which uses BIND 9 under the
> hood but integrates its operation with FreeIPA). The latter should
> only be possible to deploy to a server that already has the FreeIPA
> role deployed, whereas the BIND 9 role could be deployed to a machine
> without FreeIPA installed.

What implementation do you see for this? packages? config file?

> == Policy Compliance ==
> We talked a bit about having strict upgrade policies and
> backwards-compatibility guarantees. I'd like to highlight a few
> specific policies we should require:
>  * Updates must occur without requiring user intervention beyond
> initiating it. No questions should be posed to the user.
>  * Updates must be atomic; if a role incorporates multiple underlying
> technologies (e.g. FreeIPA with 389 and MIT Kerberos), the complete
> set must be upgraded together with a complete set of tested
> components. Do not update piecemeal; it usually breaks.

Yeah, or if it is peicemeal, make sure anything that goes out is tested
to not break things. 

>  * *Upgrades* to major new releases that offer substantially different
> functionality and that have no fully automatic upgrade path should NOT
> be considered an update to the current role. E.g. a BIND 9 role must
> not upgrade to a BIND 10 role. Instead, it should be expected that a
> new role is created and tools *may* be offered to port the
> configuration. (Note: Upgrade tools are absolutely not a short-term
> goal. In practice, most environments would likely just deploy a new
> role on a new [physical|virtual] machine anyway).


Version: GnuPG v2.0.22 (GNU/Linux)


More information about the server mailing list