-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/11/2014 08:14 PM, Adam Williamson wrote:
On Fri, 2014-06-06 at 15:55 -0700, Adam Williamson wrote:
> Hi, folks. Here's my initial dump of proposed release criteria
> specific to Server. This is primarily a Server WG responsibility
> (per the draft test plan -
>
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_21_test_plan
> - and the discussion of same), but CCing test@ as I know some
> folks there will be interested. Please ensure follow-ups *at
> least* go to server@ (no follow-ups only to test@.)
I've now cleaned up three of the proposed criteria and posted them
in the 'stock format' here:
https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria
I did some refinements as I wrote. Things tend to occur to you as
you write release criteria. Do check over the notes. Particularly,
there's this, from the firewall criterion:
"Should kickstart firewall options conflict with the settings that
would otherwise result from a deployed server role, the kickstart
options must take precedence."
that seems to make sense to me, but assuming everyone agrees that's
how it should be, we need to design the anaconda server role
integration in that way. If everyone thinks I'm nuts and we should
resolve conflicts the other way around...we need to do the
implementation that way around. It's something we need to take into
account, is what I'm sayin'. :)
That would be difficult to do, as the current expectation is that
Roles will be configured as part of the first-boot environment, after
Anaconda has concluded and the system has rebooted.
I think we should not make "resolution order of firewall conflicts" a
release criterion.
Also note "the system firewall must be active on all
non-loopback
interfaces" and "The only ports which may be open to incoming
traffic" - I think those are correct/appropriate clarifications.
Also note "Supported install-time firewall configuration options
must work correctly." - I think it's reasonable to require that,
but it does introduce a moderate burden of testing and installer
functionality. Full testing might involve four install runs. One
'clean' one, one with just a server role configured, one with a big
set of kickstart firewall directives, one with both server role and
kickstart firewall directives to test the conflict case. We could
do a milestone split; maybe the 'port 22 only on clean install'
part at Alpha, 'server role' bits at Beta, and 'kickstart and
role/kickstart conflict' parts at Final, or something like that?
Manual firewall rules will *always* throw a wrench in the mix. I'd
argue that we should only commit to testing 1) clean state, 2) clean
state + role ports, 3) manually-specified rules only
I think testing Role ports + manually-configured is likely to be a
mine-field that will never have a p
You'll note one criterion missing, because I spotted a rather big
ambiguity. It's the remote auth configuration one. The tech spec
says:
"The Fedora Server is expected to nearly always be configured for
'centrally-managed' user information; it must be possible to
configure it to rely on a directory service for this information.
Fedora Server will provide and support the realmd project for
joining FreeIPA and Active Directory domains automatically.
Interacting with other identity sources will remain a manual
configuration effort."
What it never says is whether this is expected to work *at install
time* or post-install. My guess would be that we'd want to have
install time configuration of this, but I wanted to clarify it
before writing it into the criteria.
Note that this is *not currently the case*. anaconda does not have
any remote auth configuration support of which I'm aware at
present. (I'm kinda surprised it wasn't considered a blocker for
RHEL 7, in all honesty, but hey, RHEL ain't my beat). So if we
wanted to block on that, we'd need to work out a plan with anaconda
devs to have it implemented, ideally by Alpha.
Thoughts on all the above? Thanks!
This is available today with realmd's anaconda plugin (which is also
present in RHEL 7.0 final). I'm not sure if there's a graphical
solution at present; I'll need to spin up a RHEL 7 VM and check it. I
know it works in kickstart though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlOZvNMACgkQeiVVYja6o6OA0wCeMwE4+sSJBdoPGZqsAasjdYI+
+RQAnAmp0MzpsAYPGILNam/KWJ3XuGiF
=DmPs
-----END PGP SIGNATURE-----