Proposal: FreeIPA Role for Fedora Servers Using Cockpit
kevin at scrye.com
Tue Dec 10 14:24:21 UTC 2013
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 10 Dec 2013 07:13:30 -0500
Stephen Gallagher <sgallagh at redhat.com> 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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the server