-----BEGIN PGP SIGNED MESSAGE-----
On 12/10/2013 09:24 AM, Kevin Fenzi wrote:
On Tue, 10 Dec 2013 07:13:30 -0500 Stephen Gallagher
> 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).
kevin _______________________________________________ server
mailing list server(a)lists.fedoraproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----