-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Tue, 10 Dec 2013 07:13:30 -0500
Stephen Gallagher <sgallagh(a)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).
Yeah.
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJSpyQVAAoJEEs3sNgP+7tekNQQANNab6glI22n4LYwbpMBvHgW
qaeAZwfzyVMrbebrmKiLuJpf2yBd4OPv02mbord3gKMNbbkUiidwxyAsg6du9lEU
Dq8rW4vPtc+qKzUyp9FfmxXGbOKS+eGHICR9dR17Gk0kGp8W6lh8Li3ltzafeK92
RMCmy8XOAKC1/o2rBmFxndKgiTANZVRWXrVKlwfjLJ9osTe+Q5b1A2nCn5srPVAV
VMwE0BPemw3smowyCSAmPW5RgSSa2E2vuChtdj1xz48OI3EqtSBS9AM9pADBCK5J
m3xSbss9b2ybUq93Tkdoo1wUcWIEdUrizls/Mdi3bbnF+4E7/YCoO8rGnaDv0SB0
2XdSBVEBDCi0tcABkSFw1tarlKFJZfSYn9XFCzn4UcyOzQpFrOEfmJC34epfw68a
KQIMhhSMzewWzQUcA5NQB4IIC23znfYFnZy3aWg8NHOp0vidP+vfAa+Ch80RoOkL
7u/okraQwtBQMqv2sWaLDQWm3D+YFMtYK1RpzWifMyyaokXXf8jiWnBTDmgGjJil
996U2/cC2GN3H/tEuIso4LUePSN5kz5tNfFa7V3kBzOBcQW5DYqxZPhO0eygMLrY
5SmPB1/Hu0Aau40qiNZtrNFbVJ0obYFyKeuIps5MNNFP+ORuwOdl+h5IU5BRtWlA
imNISKskafy7K0o3+ER5
=jK3b
-----END PGP SIGNATURE-----