14:59:34 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2014-04-01)
14:59:34 <zodbot> Meeting started Tue Apr  1 14:59:34 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:59:39 <sgallagh> #chair sgallagh mizmo nirik davidstrauss Evolution adamw simo tuanta mitr
14:59:39 <zodbot> Current chairs: Evolution adamw davidstrauss mitr mizmo nirik sgallagh simo tuanta
14:59:42 <sgallagh> #topic roll call
14:59:47 <sgallagh> #info sgallagh is present
15:00:12 <mizmo> #info mizmo here
15:00:42 <sgallagh> We've got a fairly full agenda this week, so I'm going to get us going as soon as we hit quorum
15:01:17 <tuanta> .fas tuanta
15:01:18 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
15:01:46 <nirik> morning
15:01:46 <mitr> Hello
15:01:51 <sgallagh> #info tuanta is here
15:01:54 <sgallagh> #info nirik is here
15:01:58 <sgallagh> #info mitr is here
15:02:02 <tuanta> Good evening
15:02:04 <sgallagh> Ok, that's quorum
15:02:08 <sgallagh> #topic agenda
15:02:12 <sgallagh> #info Agenda Item: Deadlines for Fedora Server Product internal deliverables
15:02:14 <sgallagh> #info Agenda Item: Progress on Change Proposal filing
15:02:17 <sgallagh> #info Agenda Item: Change Proposal: Install Media
15:02:18 * jreznik_q10 is watching from smartphone
15:02:20 <sgallagh> #info Agenda Item: Change Proposal: Anaconda support for role deployment
15:02:23 <sgallagh> #info Agenda Item: Discuss and identify security defaults for the Server Product
15:02:38 <sgallagh> Anyone have other items for the agenda? (Please say no)
15:02:51 <davidstrauss> I'm not sure, but I'll say no.
15:02:52 <mizmo> no!!!
15:03:07 <sgallagh> Ok
15:03:12 <sgallagh> #topic Deadlines for Fedora Server Product internal deliverables
15:03:49 <sgallagh> Simo noted at the end of last week's meeting that while Fedora has deadlines set, we haven't talked about setting individual milstones.
15:03:52 <adamw> .hellomynameis adamwil
15:03:53 <zodbot> adamw: Sorry, but you don't exist
15:03:54 <sgallagh> *milestones
15:03:55 <adamw> .hellomynameis adamwill
15:03:55 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
15:03:57 <adamw> better?
15:04:02 * simo hails
15:04:47 <sgallagh> So we have several pieces with obvious dependencies on each other, so we really should set early deadlines for those
15:05:19 <sgallagh> From my perspective, these are: 1) (Guidelines for) Packaging of roles
15:05:31 <sgallagh> 2) D-BUS service to deploy and configure roles
15:05:43 <sgallagh> 3) local command-line tool for interacting with that service
15:06:02 <sgallagh> 4) Domain Controller Role
15:06:08 <sgallagh> 5) Database Server Role
15:06:17 <sgallagh> 6) Cockpit support for deploying roles
15:06:33 <sgallagh> 7) Installation process changes and documentation
15:06:55 <sgallagh> That's my list off the top of my head.
15:07:40 <adamw> well, that sounds a bit like 'everything we have to do', but sure :)
15:07:45 <nirik> that seems like a good list to me. I'm not sure what else to add.
15:07:48 <sgallagh> Sorry, yes
15:07:52 <sgallagh> THat was the full list
15:08:02 <jreznik_q10> Are deliverables part of 7?
15:08:05 <sgallagh> We need to sort the dependencies as well as what can overlap
15:09:28 <sgallagh> I think the basic infra (1 and 2) clearly needs to be done first
15:09:37 <adamw> 2) and 3) seem fairly standalone
15:09:48 <sgallagh> 3) will probably end up getting built as a side-effect
15:10:16 <adamw> we should get 7) done as early as possible, though it's going to have dependencies on other bits
15:10:16 <nirik> 1 would be helped by having 2 and 4/5 further along to straw man up packging.
15:10:16 <tuanta> 4) and 5) could be done concurrently, I think
15:11:14 * sgallagh wonders if he should have left this topic until after the "Install media" and "anaconda plugin" topics
15:11:15 <nirik> oh.. 8) docs changes and 9) websites?
15:11:23 <nirik> and 10) marketing
15:11:25 <sgallagh> nirik: yes
15:11:40 <sgallagh> I think those are pretty clearly going to have to come late in the game
15:11:55 <sgallagh> Maybe we should work backwards from there, though
15:12:07 <sgallagh> What's the latest we could deliver everything else and not screw over 8, 9 and 10?
15:12:33 <sgallagh> Though I suppose that's probably equivalent to "Alpha freeze"
15:12:40 <adamw> a sec
15:12:50 <adamw> docs freeze comes somewhat later than alpha freeze iirc
15:13:14 <adamw> there is a bit more slack than 'alpha freeze' for all of those things, i think, but i don't have precise dates right here
15:13:48 <adamw> release notes string freeze is listed as 2014-09-15 on current schedule at http://fedorapeople.org/groups/schedule/f-21/f-21-docs-tasks.html
15:13:54 <adamw> (which is based on GA 2014-10-14)
15:13:55 <sgallagh> Sure, but if we operate on "alpha freeze" for those, we're giving them more time, which isn't a bad thing
15:14:10 <adamw> well, sure, but we need to know the *realistic* deadline too. ;)
15:14:16 * sgallagh nods
15:14:53 <adamw> GA announcement is listed as 2014-09-29 (we'd probably want stuff in alpha/beta publicity too though i guess)
15:15:06 <adamw> website string freeze is 2014-09-16
15:15:15 <sgallagh> adamw: Well, with string freeze on 9/15 and alpha freeze on 7/22, that's probably a good spread.
15:15:16 <adamw> so, basically, we're looking at mid-september.
15:15:35 <sgallagh> We don't need to be bug-free at Alpha, but our functionality needs to be testable
15:16:09 * nirik nods
15:16:23 <sgallagh> At that point, those three groups should be able to proceed in parallel
15:16:28 <sgallagh> So that makes a good milestone point
15:16:32 <sgallagh> Agreed?
15:17:00 <nirik> 3 groups ?
15:18:06 <sgallagh> docs/websites/marketing
15:18:44 <nirik> ah, ok.
15:18:45 <nirik> yep
15:20:13 <sgallagh> Ok, so let's agree on that part and work backward further
15:20:39 <simo> +1
15:20:45 <nirik> sure
15:20:47 <sgallagh> #agreed The Alpha Change Freeze deadline will also be the milestone to start working on docs/websites/marketing
15:20:59 <sgallagh> (I skipped the vote for lack of disagreement)
15:21:45 <sgallagh> So of the other things on the list, I figure the Cockpit integration is the one with the most dependencies.
15:21:46 <davidstrauss> +1
15:22:21 <davidstrauss> Presumably, Cockpit uses the same DBus API as the CLI?
15:22:24 <sgallagh> We should figure out from them at what point we would need to have the roles and local tools in place for them to be able to build that
15:22:34 <sgallagh> davidstrauss: Yes, without a doubt
15:22:39 <nirik> yes, sure hope so
15:22:44 <sgallagh> They will likely assist in developing it with that in mind
15:23:04 <sgallagh> The code for that D-BUS daemon may live in the Cockpit project as well (TBD)
15:23:41 <davidstrauss> What exactly will run in our DBus daemon?
15:24:28 <sgallagh> davidstrauss: very little; this should be an activated daemon that isn't running except when a change is requested
15:24:43 <sgallagh> It should exist to do deployments and make changes
15:24:58 <sgallagh> In the future, it *might* also grow monitoring capabilities, but let's not get into those details right here
15:24:58 <davidstrauss> Is there a wiki spec or only the mailing list thread?
15:25:12 <sgallagh> davidstrauss: Only the mailing list thread so far
15:25:28 <sgallagh> I got pulled onto other stuff for the last week and haven't made progress there
15:27:53 <davidstrauss> I'm eager to give some looks over that stuff when you do. I'm most concerned about network configuration. Between NetworkManager CLI, systemd network tooling, and traditional env-style files, I'm most worried about finding a consistent direction for our tooling there.
15:28:26 <adamw> i think we'd settled on NM as The Standard for fedora.next.
15:28:33 <sgallagh> davidstrauss: I think that's off-topic for the role discussion
15:28:39 <nirik> well, I think we already decided NM for now, and keep an eye out for later
15:28:45 <sgallagh> Or I misunderstood which thread you were referencing
15:29:42 <sgallagh> Ok, so I'll take an action item to ask the Cockpit guys how much time they'd need post-local role deployment
15:29:55 <sgallagh> We can revisit next week for that to be considered a milestone?
15:30:12 <nirik> sounds good
15:30:36 <sgallagh> #action sgallagh to get roadmap requirements from the Cockpit project
15:31:00 <sgallagh> I *think* the rest of these efforts can be mostly handled in parallel up to that point.
15:31:10 <sgallagh> Please correct me if you think they should have firmer milestones
15:32:04 <sgallagh> #info Delivery milestone for the core role infrastructure will base its deadline around the needs of the Cockpit project to build an interface to them.
15:32:34 <davidstrauss> sgallagh: I had seen some mention of configuring DHCP, possibly as just an arbitray example, in the D-BUS thread.
15:32:43 <davidstrauss> That's why I asked.
15:32:54 <mitr> davidstrauss: IIRC that was a DHCP _server_
15:33:44 <davidstrauss> Oh, of course. This is what I get for skimming the thread.
15:33:45 <sgallagh> Anything else for the schedule discussion or shall we continue?
15:33:50 <sgallagh> The agenda is a bit heavy this week
15:34:19 <mizmo> +1 continue
15:34:34 <sgallagh> #topic Progress on Change Proposal filing
15:34:52 <adamw> i've thought about it really pretty hard!
15:35:11 <sgallagh> #info Domain Controller Role Change Proposal is filed and awaiting Wrangler. It's being held off until the role infra proposal is available, since it's a dependency.
15:35:14 <nirik> I drafted a database server role change and had tuanta fix it up. ;)
15:35:32 <sgallagh> #url https://fedoraproject.org/wiki/Changes/DomainControllerServerRole
15:35:50 <sgallagh> #url https://fedoraproject.org/wiki/Changes/DatabaseServerRole
15:36:11 <sgallagh> I started a Cockpit Change Proposal as well, which is waiting for the Cockpit guys to fill in a few holes
15:36:20 <sgallagh> #url https://fedoraproject.org/wiki/Changes/CockpitManagementConsole
15:36:51 <mitr> I'm afraid the role infra proposal has barely started, sorry.  I'll work on it this week.
15:36:59 <sgallagh> After conversations we had last week, the OpenLMI guys have withdrawn from F21 deliverables
15:37:05 <sgallagh> So we won't be filing that one.
15:37:18 <sgallagh> #info Role infra proposal hasn't been started yet.
15:37:27 <sgallagh> #action mitr and adamw to work on role infra proposal this week
15:37:28 <nirik> when is deadline? next week, right?
15:37:34 <adamw> yeah, i checked that this morning
15:37:34 <sgallagh> A week from yesterday, I think?
15:37:43 <mitr> April 8
15:37:49 <adamw> plenty of time!
15:38:21 <sgallagh> adamw: GIven that other proposals are depending on it, I respectfully request doing so sooner rather than later, so all three can have time to marinate on the lists
15:38:33 <adamw> yeah, sorry about that
15:38:54 <sgallagh> adamw: Sorry if that sounded accusatory. Not the intent.
15:38:57 <adamw> though it is a *proposal* deadline - proposed changes are still up for review/discussion after the date
15:39:20 <sgallagh> Yes, but speaking as a FESCo member, I hate the meeting one week after the deadline...
15:40:07 <sgallagh> Ok, I think that was all the CHanges we had agreed on last week
15:40:12 <sgallagh> #topic Change Proposal: Install Media
15:40:29 <sgallagh> jreznik_q10 suggested that we should file a Change Proposal to cover our specific installation needs
15:40:32 <nirik> does this need to be a change? I guess it could be due to changing things for releng.
15:40:50 <nirik> or deliverables could be part of some higher level change?
15:40:52 <adamw> seems like a bit of process judo, but eh
15:40:55 <sgallagh> nirik: Well that and it may have implications for Anaconda itself
15:41:15 <sgallagh> nirik: I'm open to suggestions
15:42:02 <nirik> yeah, not sure any of the others make any sense.
15:42:08 <nirik> so I guess a seperate one would work
15:42:23 <sgallagh> We might merge this and the next agenda topic together
15:42:23 <mitr> It might be a trifle simpler to have a single Change for "installation media delivered in f21" with all information in one place, but creating the Product-specific ones is easier to coordinate
15:42:35 <sgallagh> ("Anaconda support for role deployment")
15:43:43 <adamw> yeah, that seems like the sane approach
15:43:52 <sgallagh> adamw: Which approach?
15:43:53 <nirik> yeah, that could work
15:44:08 <adamw> a single Change for the .next deliverable rework
15:44:14 <adamw> not splitting it up arbitrarily per-product
15:44:19 * sgallagh nods
15:44:22 <adamw> we need to make sure the whole approach makes sense anyway
15:44:43 <sgallagh> In that case, should we shunt this to Base and offer a representative to assist?
15:44:50 <mitr> File a FESCo ticket for FESCo to start the Change page as a template, then ask WGs to fill stuff in?
15:44:57 <mitr> sgallagh: Base would be even better, yes :)
15:45:14 <sgallagh> I think we covered that "installation" was a Base task
15:45:20 <sgallagh> (in earlier discussions)
15:45:21 <mitr> right
15:46:14 <sgallagh> adamw: Could I talk you into liaising with Base on this? Of all of us on the WG, you have the deepest knowledge of the installer.
15:46:29 <sgallagh> (to the best of my knowledge, anyway)
15:46:42 <adamw> um. i don't want to commit to too much work, honestly.
15:46:56 <adamw> also i'm terrible with deadlines. i'd prefer to just have the one change proposal to be working on if possible.
15:47:04 <sgallagh> ok
15:47:07 <adamw> i'm always around to be poked on IRC, but...
15:47:31 <sgallagh> Volunteers?
15:47:43 * mizmo is overcommitted :(
15:48:02 * sgallagh has the same problem
15:48:06 * nirik too
15:48:40 * simo hides :(
15:49:19 <sgallagh> Given that I was already planning to volunteer to drive the proposal for the "anaconda support for role deployment" in the next topic, I'd *really* prefer to hand this one off.
15:49:54 <nirik> I guess I can try... not sure how far I will get. ;)
15:50:03 <sgallagh> nirik: Thanks, I appreciate it
15:50:36 <sgallagh> #action nirik to liaise with Base and help get a unified Fedora.next Installation Change Proposal together
15:50:55 <sgallagh> nirik: Please try to get the Base WG to do most of the work
15:51:15 <adamw> nirik: if there's anything i can help with relatively *quickly*, do ping :)
15:51:19 <nirik> sure.
15:51:27 <sgallagh> #topic Change Proposal: Anaconda support for role deployment
15:52:02 <sgallagh> So as part of the discussions we had last week around the local tools for role deployment, it occurred to me that we are going to need some tweaks to anaconda
15:52:16 <mitr> This is a nice-to-have item, isn't it?  Users could manually add a comps group and call fedora-role-manage from %post
15:52:26 <sgallagh> Specifically, we're going to want to take a page out of realmd's book and add an anaconda plugin to support new kickstart directives.
15:52:37 <sgallagh> mitr: fedora-role-manage won't work without helpers
15:52:51 <sgallagh> Because it would be talking to the D-BUS system bus running in the anaconda session, not the chroot
15:53:09 <mitr> sgallagh: %post can run inside the chroot
15:53:36 <mitr> ... Oh I see, but the daemon wouldn't be running without yet more manual work.
15:53:40 <sgallagh> exactly
15:54:01 <sgallagh> realmd already solved this problem, so I intend to steal as much code as possible from there
15:55:15 <sgallagh> I'm not ready to call this a blocker for F21, but I think we'd have a poor unattended-installation story without it
15:56:06 <sgallagh> Anyway, I volunteer to file this Change Proposal, unless we want to make the decision right now not to try to do this for F21.
15:56:36 <mitr> Seems very worthwhile to me (now that I understand the problem)
15:56:43 <adamw> +1
15:57:31 <sgallagh> #action sgallagh to file Change Proposal for "Anaconda support for role deployment"
15:57:54 <sgallagh> I'm not committing to having a GUI component here. In F21 I'm only aiming for kickstart directives.
15:58:42 <nirik> +1
15:59:26 <davidstrauss> +1
15:59:26 <sgallagh> #topic Discuss and identify security defaults for the Server Product
15:59:36 <sgallagh> simo: You want to drive this one?
15:59:41 <simo> sure
16:00:05 <simo> so in a discussion somewhere I was remainded that some defaults are well suited for single user machines in fedora
16:00:16 <simo> but not for multi-user which is what servers often are
16:00:28 <simo> for example default policies for policykit related actions
16:00:36 <simo> and other similar things
16:01:15 <simo> I would like to know if people like mitr would want to get involved in identifying policies where we need different defaults for a server product
16:01:18 <simo> security-wise
16:01:25 <mitr> Is that actually the case?  Per https://fedoraproject.org/wiki/Privilege_escalation_policy the defaults should be suitable
16:01:32 <simo> and also brainstorm on how we would deliver different defaults
16:02:14 <mitr> I'm not saying that the polkit policies are always perfect, but there isn't an inherent conflict between the requriements for a single-use desktop and mult-user desktop ~ server, at least for polkit
16:02:32 <simo> mitr: well I know for example that the workstation product puts the first user automatically in a "privileged" user mode
16:02:41 <simo> I am not even sure we should have a first use ron server
16:02:54 <adamw> simo: that's part of gnome-initial-setup, so not really relevant to us
16:02:58 <mitr> simo: Right, that would be proglematic.
16:03:03 <simo> but we need to understand what/if we need to change, somehow
16:03:06 <adamw> anaconda's requirement is that you either create an admin user or set a root password.
16:03:21 <simo> adamw: understood, which means we will have different behavior
16:03:34 <adamw> eh
16:03:39 <simo> adamw: we need to understand if our behavior is consistent with a server's need
16:04:03 <adamw> um. who is 'we' and what 'behaviour' will be different from who else?
16:04:06 <simo> I am not saying we definitely have a problem
16:04:20 <simo> I am saying, how do we find out and how do we make changes if we need ?
16:04:22 <sgallagh> simo: I think this particular example isn't actually a problem at this point
16:04:44 <simo> sgallagh: fine
16:04:51 <sgallagh> We need more concrete examples of places where (for example) Workstation's default is unsafe from a multi-user system's perspective
16:04:53 <simo> but do we have a process here ?
16:05:05 <sgallagh> I *think* FESCo has done a decent job of making that the case for Fedora historically
16:05:22 <mitr> simo: I don't think it's practical to do a widespread review unfortunately; We are probably stuck with reacting to highlighted issues mostly.  (Well we could do a quick automated scan of polkit policies throughout the distro and ensuring they aren't "allow this action to everything")
16:05:23 <sgallagh> So I suspect that it would be more likely that Workstation would want to change, rather than Server.
16:05:24 <adamw> i'm not aware of any process, really, no.
16:05:38 <simo> do we have a page where we have a list of things we can go through and check ?
16:06:01 <sgallagh> Realistically, I think it's "policykit", "selinux" and "sudo"
16:06:06 <simo> sgallagh: I am asking for a process :)
16:06:09 <mitr> simo: The privilege escalation policy has an item for explicit approval / broadcasting existence of new mechanisms that would have to be checked; it has never been invoked though.
16:06:13 <adamw> it probably wouldn't be infeasible for someone to just look through all policykit policies, consolehelper executables etc after a deployment of our supported role for f21 manually
16:06:20 <adamw> i don't think the number would be unmanageable
16:06:37 <simo> and we do not need to look for everything
16:06:42 <nirik> yeah, would just take footwork
16:06:46 <mitr> simo: That would _allow_ setting up a review process, but such a process doesn't exist (well the RHEL errata process does do some checks on polkit and setuids, but that's way too indirect)
16:06:49 <sgallagh> selinux is the one place that might be painful
16:06:52 <simo> but we need a process to manage change if we find out something is not a good default
16:07:19 <simo> sgallagh: I think selinux will be mostly fine
16:07:20 <sgallagh> simo: I think that probably warrants a Change Proposal
16:07:24 <mizmo> guys i gotta bail
16:07:28 <mizmo> i can't do more than 1 hour
16:07:30 <sgallagh> simo: Probably, but verifying that will be painful
16:07:32 <simo> oh shit it *is* late
16:07:35 <sgallagh> mizmo: Sorry, and thank you
16:07:38 <simo> sgallagh: want to discuss more next week ?
16:07:42 <mizmo> sure im sorry im not more helpful
16:07:46 <sgallagh> simo: Maybe take it to the list first?
16:07:50 <simo> I think this is more of an intrnal WG process than a change proposal
16:08:02 <simo> sgallagh: feel free to reply to the mail I sent ?
16:08:03 <sgallagh> Try to gather some specific examples we should explore
16:08:05 <mitr> simo: We can write code to check policy values, but not code that understands the semantics of the controls being modified by those values, so full automation is difficult.
16:08:07 * davidstrauss has to duck out of the meeting.
16:08:10 <simo> or want me to do something more detailed ?
16:08:17 * nirik also has a full queue of stuff to get to today
16:08:28 <simo> mitr: I am not talking code or being proactive on everything
16:08:33 <sgallagh> simo: If you wouldn't mind, I'd appreciate it
16:08:41 <mitr> simo: We _should_ have a review process to ensure new packages don't introduce stupid policies, and Server would probably want to work on it, yes.  I don't know who has time though
16:08:41 <simo> sgallagh: ok I'll take a note, I need to run now
16:08:46 <sgallagh> I think everyone needs to pack up.
16:08:50 <sgallagh> See you folks next week :)
16:08:55 <simo> mitr: reply to my email then, ok ?
16:09:02 <mitr> simo: sure
16:09:05 <sgallagh> #action simo to expand on the security discussion on the mailing list.
16:09:11 <sgallagh> #undo
16:09:11 <zodbot> Removing item from minutes: ACTION by sgallagh at 16:09:05 : simo to expand on the security discussion on the mailing list.
16:09:16 <sgallagh> #action mitr and simo to expand on the security discussion on the mailing list.
16:09:23 <sgallagh> #endmeeting