Second draft of server criteria, questions (was Re: Initial set of proposed release criteria for Server product)

[Stephen Gallagher]

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