Proposal: FreeIPA Role for Fedora Servers Using Cockpit

Stephen Gallagher sgallagh at
Tue Dec 10 14:31:05 UTC 2013

Hash: SHA1

On 12/10/2013 09:24 AM, Kevin Fenzi wrote:
> 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"

I didn't say it had to be broadcast. I was thinking more of using
something like OpenLMI, which requires authentication, to query it.

>> * 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?

I was intentionally avoiding specifying an implementation for fear
that we'd end up talking about that rather than high-level goals and
user experience. Remember, we don't need an implementation for the
PRD, just a set of things we want to achieve.

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

We've proven in the past that we don't have the resources to do a
complicated matrix. I'd like to hear from QA on this, but I suspect
enforcing full-role testing will make life easier for them.

Obviously, "bug fixes" should have some leeway, but no one should be
upgrading major versions independently of a role upgrade.

>> * *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).
> Yeah.
> kevin _______________________________________________ server
> mailing list server at 

Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the server mailing list