Proposal: FreeIPA Role for Fedora Servers Using Cockpit

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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

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


More information about the server mailing list