15:01:08 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2014-08-19)
15:01:08 <zodbot> Meeting started Tue Sep 23 15:01:08 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:08 <sgallagh> #chair sgallagh mizmo nirik davidstrauss stefw adamw simo tuanta mitr
15:01:08 <zodbot> Current chairs: adamw davidstrauss mitr mizmo nirik sgallagh simo stefw tuanta
15:01:08 <sgallagh> #topic roll call
15:01:16 * stefw is here
15:02:02 * danofsatx-work is here, too
15:02:11 * simo waves
15:02:39 * davidstrauss_ says hi.
15:03:11 * danofsatx-work runs to make room for and get some more coffee
15:04:16 * sgallagh waits a couple more minutes
15:05:21 <mitr> Hello
15:05:40 <sgallagh> #topic Agenda
15:05:40 <sgallagh> #info Agenda Item: Fedora 21 Beta Planning
15:05:41 <sgallagh> #info Agenda Item: Cockpit PolicyKit Rules
15:05:55 <adamw> ahoy
15:05:58 <adamw> sorry, late
15:06:03 <sgallagh> These are the two agenda items I've got so far.
15:06:03 <simo> chips ?
15:06:13 <sgallagh> Anything else pressing?
15:06:17 <sgallagh> "chips"?
15:06:31 <simo> sgallagh: nvm
15:06:36 <sgallagh> ok
15:06:47 <simo> sgallagh: what about f21 beta >
15:07:33 <sgallagh> simo: It's already on the list above...
15:08:33 <sgallagh> Nothing else?
15:08:34 <sgallagh> ok
15:08:45 <sgallagh> Let's start with Cockpit/PolicyKit
15:08:51 <sgallagh> #topic Cockpit PolicyKit Rules
15:09:04 <sgallagh> stefw: Would you mind giving a brief summary (with #info)
15:09:20 <stefw> So i guess the question here is, whether Cockpit can ship additional policykit rules in fedora. The reason is twofold.
15:09:36 <stefw> 1) To work around upstream bugs for Fedora 21.
15:09:57 <stefw> 2) To start to define further roles/groups besides just 'wheel' in a server administration context.
15:10:02 <sgallagh> #info Cockpit would like to ship its own policykit rules
15:10:25 * mitr looks in the direction of his polkit owner hat
15:10:30 <sgallagh> #info Cockpit wants to be able to define permission roles besides membership in the "wheel" group
15:10:32 <stefw> here's an example of such a rule: https://github.com/mvollmer/cockpit/commit/677a83b60f5e4e5e9b03959db22dca34ff35dbdf
15:10:41 <simo> stefw: I looked at the policy file you sent url for on the mailing list and I was unpleasantly reminded polkit uses js now
15:10:41 <stefw> those fit into the 1) category (ie: bug fixes)
15:10:50 <stefw> heh yeah :S
15:11:07 <simo> stefw: my main concern is how do you make sure you are not going to break stuff if upstream changes things
15:11:31 <stefw> that is a valid concern. but valid for any consumer of Fedora downstream of us.
15:11:40 <simo> yes
15:11:41 <stefw> these rules are originally targetted at sysadmins
15:11:55 <sgallagh> mitr: Aren't the JS policy rules a stable interface?
15:11:56 <stefw> and people deploying linux onto workstations/servers etc.
15:12:02 <stefw> any break would affect them too
15:12:06 <mitr> I am quite fine with 1) (noting that two of the 3 rules should go away soonish because a fixed package has already been built), of course the ideal thing is to just fix the other packages e.g. using provenpackager powers but this is not too bad IMHO.
15:12:49 <sgallagh> mitr: How difficult a task would fixing the other packages be for a provenpackager?
15:13:08 <stefw> accountsservice just needs a new release. i've requested access
15:13:15 <stefw> that covers two of the bugs
15:13:28 <stefw> the other NetworkManager bug was discovered and filed today
15:13:35 <mitr> Well polkit is in theory 0.something, but I have no intention of breaking the API.  As documented, the existence of JS and the JS API as documented is intended to be stable, and the action IDs desperately need to be stable if any upstream intends for their use of polkit to be at all useful.
15:13:56 <stefw> right
15:13:57 <mitr> sgallagh: 1-line change per each of the if(...)return in polkit’s JS
15:14:10 <adamw> we should maybe have restrictions around what rules can do
15:14:44 <adamw> just setting policy with stuff like polkit.Result.AUTH_ADMIN seems fairly reasonable in at least some cases
15:14:54 <adamw> but you can do all kinds of weird crap with PK, we wouldn't want to let it all in
15:15:01 <simo> mitr: I'd hoped JS could be dropped
15:15:07 <davidstrauss> How would additional grants break anything?
15:15:23 <davidstrauss> Or were the linked rules just an example?
15:15:26 <mitr> simo: Suddenly stopping processing existing user's security configuration… I don’t have the balls for that.
15:15:30 <simo> davidstrauss: what happen if some interface changes name and the JS code calls it ?
15:15:45 <stefw> those are not interfaces
15:15:49 <stefw> they're polkit action ids
15:15:52 <simo> mitr: ok let's discuss separatly
15:15:53 <stefw> and intended to be stable
15:16:26 <mitr> stefw: I would be happy if cockpit didn’t start to add long-term overrides; by filing the bugs you have clearly done the right thing.
15:16:43 <stefw> so, you're ok with use case 1) ... but not 2)  ?
15:16:47 <simo> stefw: so the rules just fail to act if the action.id changes name ?
15:16:48 <sgallagh> Yes, I'd rather we got these things escalated as a priority for Fedora Server
15:16:49 * stefw points above
15:16:57 <stefw> simo, yes
15:17:05 <sgallagh> I'd argue that this is a reasonable use of provenpackager powers
15:17:08 <simo> I guess it is just a string comparison, stuff at least things won't break, just chease to work
15:17:14 <sgallagh> (if the package owners aren't quick enough)
15:17:32 <mitr> sgallagh: To be fair, the last bug was filed literally today.
15:17:36 <stefw> indeed
15:17:52 <simo> I would say that we should ship rules only if there is some issue dealing with them in the respective packages
15:18:01 <sgallagh> I did qualify that statement
15:18:21 <simo> mitr: sure but you have to change them here or there, so why not just rebuild NEtworkManager ?
15:18:24 <sgallagh> In general, I'm against allowing the shipping of pk rules outside pk itself
15:18:34 <sgallagh> But, meh.
15:18:49 <stefw> sgallagh, so then we should have a larger discussion about whether we want roles in Fedora Server
15:18:55 <stefw> but maybe that should happen on the mailing list
15:19:01 <simo> stefw: I guess my q. is: why do you feel the need to override the rules in cockpit ?
15:19:02 <stefw> and by roles i mean user roles
15:19:07 <stefw> so many terms and so much overloading :D
15:19:07 <mitr> stefw: As for 2);  I _do_ like and want to support the idea of restricted admin roles.  As for the specific design (JS, perhaps even .pkla, some new mechanism) and ownership of the admin role setup, I don’t think IRC with zero thinking in advance really works.
15:19:29 <stefw> mitr, agreed
15:20:21 <mitr> sgallagh: There are several examples (e.g. gdm/lightdm-specific “user” accounts) where adding an extra .js override that is not “owned” by the package that defines the action makes fairly good sense.
15:21:07 <sgallagh> mitr: Sure, I just don't love the idea that any arbitrary package can drop PK rules onto the system. But that's an issue I can't actually solve.
15:21:38 <mitr> Though, yes, we _are_ falling into the trap of mixing internal OS implementation with user-facing configuration.  So far this has not been extensive and the support for both /usr and /etc mitigates this to a small extent.
15:22:52 * simo still fail to understand with stef felt the need to ask for these overrides instead of fixing the other packages, what am I missing ?
15:23:09 <mitr> simo: The first round of the bugs was filed a fair number of months ago.
15:23:23 <tuanta> .hellomynameis tuanta
15:23:24 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
15:23:27 <tuanta> sorry, I am late
15:23:35 <mitr> Arguably a deficit in our package maintenance model
15:23:41 <stefw> simo, mitr, i've tried to help package accountsservice upstream, but haven't been able to do the fedora parts
15:23:50 * tuanta is checking the logs
15:24:33 <stefw> so i want to find out if we have firm policy on this
15:24:50 <stefw> and secondarily
15:25:02 <simo> in general I would say that if we can fix it in the owning package we should always do that
15:25:12 <sgallagh> simo: +1
15:25:17 <simo> if you want to add additional rules then we can depbate where the pk files should go
15:25:25 <stefw> and secondarily, if it comes as a last resort, can we ship policy to make cockpit specific use cases work
15:25:47 <sgallagh> I'd also suggest that we ask FESCo for permission to have a provenpackager make the needed change if upstream doesn't fix it within a 14-day window
15:26:33 <sgallagh> stefw: Is it likely to have Cockpit-specific use-cases vs. server-specific use-cases?
15:27:16 <stefw> it would be nice to define broader server user groups/roles, but that would need to be discussed on the mailing list
15:27:21 <mitr> sgallagh: No need to ask FESCo
15:27:22 <sgallagh> (Or for that matter, use-cases where Cockpit's needs would conflict with defaults?)
15:28:02 <mitr> stefw: In theory upstream polkit says applications shouldn’t ship any policy but I’d like to change that (https://bugzilla.redhat.com/show_bug.cgi?id=956005 ) anyway.
15:28:18 <stefw> mitr, interesting
15:28:19 <sgallagh> Ah, right. Specialized local groups that have a subset of wheel permissions?
15:28:38 <stefw> exactly
15:29:02 <stefw> so right now on a server level we have wheel which by default can escalate to root
15:29:08 <sgallagh> Pre-configured or dynamically-created?
15:29:18 <stefw> and a few other things like 'docker' group which can manage containers etc.
15:29:30 <stefw> i would imagine pre-configured defaults
15:29:48 <mitr> Yeah; my first concern in there is whether there actually are useful groups we can define that aren’t root-equivalent.  I can see “log viewer” and "web restarter” are fine, but write access tends to be rather powerful.
15:29:57 <sgallagh> Well, I was thinking more whether we'd want to have a group-per-permission in Cockpit.
15:30:28 <stefw> yes, right, and then you need polkit rules to go along with that
15:30:31 <mitr> sgallagh: Only 1000 reserved GIDs…
15:30:35 <adamw> that kinda gives us a hostage to fortune in making sure cockpit actions aren't exploitable...
15:30:39 <stefw> anyway, i'll bring this up on the mailing list
15:30:55 <mitr> stefw: Please do, and thanks for bringing this up.
15:30:56 <stefw> the broader groups topic
15:30:58 * sgallagh nods
15:31:11 <stefw> it just tied into the polkit rules stuff that we're trying to get done for f21 beta
15:31:28 <stefw> sgallagh, what is the appropriate keyword to escalate for f21 beta
15:31:30 <stefw> for those three bugs?
15:31:50 <sgallagh> stefw: We don't actually have a policy for that, yet.
15:32:11 <sgallagh> I'll create a tracking bug for "Things Fedora Server WG needs to watch"
15:32:16 <stefw> k
15:32:17 <adamw> if they were going to be release blocking bugs the keyword would be BetaBlocker
15:32:24 <adamw> that, of course, reminds me we haven't written the beta criteria yet
15:32:26 <sgallagh> We should probably start reviewing that list each week from now until Beta.
15:32:31 <adamw> can we make that an agenda topic if we have time?
15:32:42 <mitr> If you want to propose it as a blocker, make it block “BetaBlocker”  (but then there should be a beta criterion this is violating)
15:32:44 <sgallagh> adamw: Well, the next topic is "Planning for Beta"
15:32:48 <adamw> sgallagh: works for me!
15:32:54 <adamw> guess who didn't read the agenda
15:32:58 <sgallagh> :)
15:33:01 <stefw> mitr, right, we don't have 'usable by non-root' as a beta criteria
15:33:21 <stefw> ok, i think we're done here
15:33:23 <sgallagh> I'd like us to keep a separate tracker from Beta
15:33:33 <stefw> if no movement on this, will escalate
15:33:42 <sgallagh> #action stefw to start a conversation on role definition in Cockpit on the mailing list
15:33:57 <sgallagh> #action sgallagh will create a tracking bug for BZs of interest to the Server WG
15:34:19 <sgallagh> #info Future WG meetings will involve a review and status update on any bugs connected to that tracker
15:34:30 <sgallagh> Let's move to Beta planning
15:34:38 <sgallagh> #topic Fedora 21 Beta Planning
15:34:52 <sgallagh> #info First topic: Beta release criteria
15:35:21 <sgallagh> adamw: Mind giving a quick historical overview of Beta criteria?
15:35:34 <adamw> mmmm
15:35:57 <adamw> the Beta Objectives in e.g. https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria are about all we have
15:36:22 <simo> adamw: tl;dr ?
15:36:23 <adamw> 'code complete' is a significant one, in that it's expected that the functionality that's intended for final release ought to be broadly *there* at beta
15:36:30 <adamw> simo: it's already three bullet points!
15:36:37 <adamw> simo: seems hard to make it any shorter :)
15:36:48 <adamw> (and only the first two really matter)
15:36:52 <simo> oh sorry had to scroll there :)
15:36:59 <adamw> get a vertical monitor ;)
15:37:26 <adamw> so from this perspective the key points i guess are "code complete" and "Changes" - everything we mean to be in final should be there in beta, but the bar to how well it should work is a bit lower
15:37:58 <adamw> i'd say that would imply that we need all 'primary roles' for a release to be present and at least deployable (for testing) by beta
15:38:15 <adamw> rolekit's basic functionality must be good enough for testing roles
15:38:26 <adamw> is this broadly making sense?
15:38:32 <sgallagh> adamw: Yes
15:38:37 <simo> ok so strictly speaking additional admin roles wouldn't be abeta blocker as that can be added at any time ?
15:39:09 <adamw> simo: i think we have kind of a concept of 'primary' roles, right? which are ones we consider a base part of the product
15:39:14 <adamw> i think the criteria should mostly focus on those
15:39:28 <adamw> oh, sorry, we're on PK roles
15:39:52 <simo> yeah usual confusion of terms :(
15:40:07 <adamw> so the 'feature' of adding restricted admin stuff, well, yeah, i wouldn't expect that to block the release
15:40:25 <adamw> from a QA perspective we might frown on sticking it in between beta and final, but that's outside of the criteria/blocker stuff
15:40:55 <adamw> some of the bugfix stuff discussed earlier could possibly constitute beta blocker, by the looks of it. but we really need to write down the requirements
15:41:01 * adamw goes back to the tech spec
15:42:21 <simo> ok
15:42:38 <simo> sgallagh: I think you also had something else in mind for the discussion ?
15:42:56 <adamw> looking over it briefly, i think it'll involve adding a bunch of role stuff, and a couple of logging things.
15:42:58 <simo> should we take action item for adamw to come up with server WG important beta criteria ?
15:43:04 <sgallagh> Well, basically I wanted us to try to figure out what we need to do by Beta
15:43:06 <adamw> it would be nice if it wasn't just me :)
15:43:10 <adamw> but it does need doing.
15:43:25 <sgallagh> Defining the release criteria is a very targeted way of accomplishing that, so I'm content to let adamw continue driving this discussion :)
15:43:32 <simo> sgallagh: anything needs to be done in rolekit ?
15:43:36 <sgallagh> Yes
15:43:47 <adamw> it may be over-targeted, in the sense that we may want to get things done that wouldn't strictly be considered blockers
15:43:57 <sgallagh> We still have a couple patches pending to deal with properly managing the firewall
15:44:18 <adamw> but sure. so, looking very off-the-top-of-my-head: 'primary roles must basically work', which implies we get Domain Controller working
15:45:00 <adamw> probably primary roles have to broadly meet hte 'role definition requirements'
15:45:30 <adamw> role firewall interaction has to be there
15:45:51 <adamw> remote logging
15:46:02 <adamw> (if any of these aren't actually on the table for f21 they can be taken out)
15:46:42 <sgallagh> remote logging right now should basically be handled by journald's syslog interaction
15:46:42 <adamw> cockpit's capabilities are fairly vaguely expressed in the tech spec, but i think it implies it should at least be there and basically 'work', however you define that
15:47:17 <sgallagh> Originally, Cockpit was going to be required to have a UI to manage each of the supported roles, but we deferred that to F22
15:48:13 <mitr> looking at rolekit/TODO: package installation? documentation
15:48:24 <sgallagh> Ah right
15:48:35 <sgallagh> Right now package installation is still under development as well
15:48:39 <adamw> 'role definition requirements' has quite a lot in it
15:48:46 <sgallagh> We hit a snag where packagekit didn't actually work :(
15:48:48 <adamw> =)
15:49:53 <sgallagh> adamw: Right, we should turn that entire list into Beta blockers
15:50:29 <simo> is there anything we need to decide on ?
15:50:30 <sgallagh> Except backup set
15:50:43 <simo> any bug/feature we need to decide to drop/keep now ?
15:50:51 <simo> or should we defer till later and see if they cna make it ?
15:51:18 <simo> (btw I have ahrd stop in 10 min)
15:51:23 <sgallagh> I don't see anything controversial at this point
15:51:34 <simo> ok
15:51:41 <simo> so who is going to make the list of blockers ?
15:53:09 <sgallagh> Each of the respective owners should
15:53:27 <adamw> i can try to get the criteria drafted this week, i really ought to
15:53:27 <sgallagh> I suppose that means twoerner, mitr and I for rolekit, stefw for cockpit, etc.
15:53:32 <simo> should we review them periodically in the meetings ?
15:53:34 <sgallagh> adamw: Thanks
15:53:52 <sgallagh> simo: We should review all open BZs associated with the tracker I'm going to create.
15:53:57 <simo> ok
15:54:13 <simo> then we should put that in the next meeting agenda immediately
15:55:30 <sgallagh> Yes
15:55:39 <sgallagh> I'm creating the tracking BZ as we speak
15:57:11 <sgallagh> .bug 1145747
15:57:14 <zodbot> sgallagh: Bug 1145747 [Tracker] Fedora Server 21 - https://bugzilla.redhat.com/1145747
15:57:37 <sgallagh> #topic Open Floor
15:57:41 <sgallagh> Anything for the last four minutes?
15:57:53 <sgallagh> Oh: "Great job, everyone! F21 Alpha is out!"
15:59:37 <adamw> yaay
15:59:53 <adamw> pity it didn't have the best freeipa, but hey
16:00:15 <sgallagh> Fixable with updates
16:00:50 <sgallagh> OK, thanks everyone
16:00:53 <sgallagh> #endmeeting