On Wed, 2014-06-11 at 17:14 -0700, 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 -
> 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:
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
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'. :)
uhmm are firewall rules aplied at *install* time for roles or at
configuration time ?
If so does configuration override kickstart defaults ?
Also note "the system firewall must be active on all
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?
Sounds reasonable but I am not entirely convinced it makes sense to have
kickstart defined firewall rules override the roles. The roles do have
an interface to tell whether you want to apply firewall rules or not, so
if you explicitly ask for firewall to be poked then we have
contradicting rules, and I think the role should win in that case.
You'll note one criterion missing, because I spotted a rather
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
Does it really matter if it is install or post-install ?
Note that this is *not currently the case*. anaconda does not have
remote auth configuration support of which I'm aware at present.
It used to, has it been evicted ?
(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!
I do not think we should make it a blocker, however I think the user
MUST NOT be forced to create a first user in this case.
Simo Sorce * Red Hat, Inc * New York