15:01:08 #startmeeting Server Working Group Weekly Meeting (2014-08-19) 15:01:08 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:08 #chair sgallagh mizmo nirik davidstrauss stefw adamw simo tuanta mitr 15:01:08 Current chairs: adamw davidstrauss mitr mizmo nirik sgallagh simo stefw tuanta 15:01:08 #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 Hello 15:05:40 #topic Agenda 15:05:40 #info Agenda Item: Fedora 21 Beta Planning 15:05:41 #info Agenda Item: Cockpit PolicyKit Rules 15:05:55 ahoy 15:05:58 sorry, late 15:06:03 These are the two agenda items I've got so far. 15:06:03 chips ? 15:06:13 Anything else pressing? 15:06:17 "chips"? 15:06:31 sgallagh: nvm 15:06:36 ok 15:06:47 sgallagh: what about f21 beta > 15:07:33 simo: It's already on the list above... 15:08:33 Nothing else? 15:08:34 ok 15:08:45 Let's start with Cockpit/PolicyKit 15:08:51 #topic Cockpit PolicyKit Rules 15:09:04 stefw: Would you mind giving a brief summary (with #info) 15:09:20 So i guess the question here is, whether Cockpit can ship additional policykit rules in fedora. The reason is twofold. 15:09:36 1) To work around upstream bugs for Fedora 21. 15:09:57 2) To start to define further roles/groups besides just 'wheel' in a server administration context. 15:10:02 #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 #info Cockpit wants to be able to define permission roles besides membership in the "wheel" group 15:10:32 here's an example of such a rule: https://github.com/mvollmer/cockpit/commit/677a83b60f5e4e5e9b03959db22dca34ff35dbdf 15:10:41 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 those fit into the 1) category (ie: bug fixes) 15:10:50 heh yeah :S 15:11:07 stefw: my main concern is how do you make sure you are not going to break stuff if upstream changes things 15:11:31 that is a valid concern. but valid for any consumer of Fedora downstream of us. 15:11:40 yes 15:11:41 these rules are originally targetted at sysadmins 15:11:55 mitr: Aren't the JS policy rules a stable interface? 15:11:56 and people deploying linux onto workstations/servers etc. 15:12:02 any break would affect them too 15:12:06 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 mitr: How difficult a task would fixing the other packages be for a provenpackager? 15:13:08 accountsservice just needs a new release. i've requested access 15:13:15 that covers two of the bugs 15:13:28 the other NetworkManager bug was discovered and filed today 15:13:35 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 right 15:13:57 sgallagh: 1-line change per each of the if(...)return in polkit’s JS 15:14:10 we should maybe have restrictions around what rules can do 15:14:44 just setting policy with stuff like polkit.Result.AUTH_ADMIN seems fairly reasonable in at least some cases 15:14:54 but you can do all kinds of weird crap with PK, we wouldn't want to let it all in 15:15:01 mitr: I'd hoped JS could be dropped 15:15:07 How would additional grants break anything? 15:15:23 Or were the linked rules just an example? 15:15:26 simo: Suddenly stopping processing existing user's security configuration… I don’t have the balls for that. 15:15:30 davidstrauss: what happen if some interface changes name and the JS code calls it ? 15:15:45 those are not interfaces 15:15:49 they're polkit action ids 15:15:52 mitr: ok let's discuss separatly 15:15:53 and intended to be stable 15:16:26 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 so, you're ok with use case 1) ... but not 2) ? 15:16:47 stefw: so the rules just fail to act if the action.id changes name ? 15:16:48 Yes, I'd rather we got these things escalated as a priority for Fedora Server 15:16:49 * stefw points above 15:16:57 simo, yes 15:17:05 I'd argue that this is a reasonable use of provenpackager powers 15:17:08 I guess it is just a string comparison, stuff at least things won't break, just chease to work 15:17:14 (if the package owners aren't quick enough) 15:17:32 sgallagh: To be fair, the last bug was filed literally today. 15:17:36 indeed 15:17:52 I would say that we should ship rules only if there is some issue dealing with them in the respective packages 15:18:01 I did qualify that statement 15:18:21 mitr: sure but you have to change them here or there, so why not just rebuild NEtworkManager ? 15:18:24 In general, I'm against allowing the shipping of pk rules outside pk itself 15:18:34 But, meh. 15:18:49 sgallagh, so then we should have a larger discussion about whether we want roles in Fedora Server 15:18:55 but maybe that should happen on the mailing list 15:19:01 stefw: I guess my q. is: why do you feel the need to override the rules in cockpit ? 15:19:02 and by roles i mean user roles 15:19:07 so many terms and so much overloading :D 15:19:07 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 mitr, agreed 15:20:21 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 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 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 simo: The first round of the bugs was filed a fair number of months ago. 15:23:23 .hellomynameis tuanta 15:23:24 tuanta: tuanta 'Truong Anh Tuan' 15:23:27 sorry, I am late 15:23:35 Arguably a deficit in our package maintenance model 15:23:41 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 so i want to find out if we have firm policy on this 15:24:50 and secondarily 15:25:02 in general I would say that if we can fix it in the owning package we should always do that 15:25:12 simo: +1 15:25:17 if you want to add additional rules then we can depbate where the pk files should go 15:25:25 and secondarily, if it comes as a last resort, can we ship policy to make cockpit specific use cases work 15:25:47 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 stefw: Is it likely to have Cockpit-specific use-cases vs. server-specific use-cases? 15:27:16 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 sgallagh: No need to ask FESCo 15:27:22 (Or for that matter, use-cases where Cockpit's needs would conflict with defaults?) 15:28:02 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 mitr, interesting 15:28:19 Ah, right. Specialized local groups that have a subset of wheel permissions? 15:28:38 exactly 15:29:02 so right now on a server level we have wheel which by default can escalate to root 15:29:08 Pre-configured or dynamically-created? 15:29:18 and a few other things like 'docker' group which can manage containers etc. 15:29:30 i would imagine pre-configured defaults 15:29:48 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 Well, I was thinking more whether we'd want to have a group-per-permission in Cockpit. 15:30:28 yes, right, and then you need polkit rules to go along with that 15:30:31 sgallagh: Only 1000 reserved GIDs… 15:30:35 that kinda gives us a hostage to fortune in making sure cockpit actions aren't exploitable... 15:30:39 anyway, i'll bring this up on the mailing list 15:30:55 stefw: Please do, and thanks for bringing this up. 15:30:56 the broader groups topic 15:30:58 * sgallagh nods 15:31:11 it just tied into the polkit rules stuff that we're trying to get done for f21 beta 15:31:28 sgallagh, what is the appropriate keyword to escalate for f21 beta 15:31:30 for those three bugs? 15:31:50 stefw: We don't actually have a policy for that, yet. 15:32:11 I'll create a tracking bug for "Things Fedora Server WG needs to watch" 15:32:16 k 15:32:17 if they were going to be release blocking bugs the keyword would be BetaBlocker 15:32:24 that, of course, reminds me we haven't written the beta criteria yet 15:32:26 We should probably start reviewing that list each week from now until Beta. 15:32:31 can we make that an agenda topic if we have time? 15:32:42 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 adamw: Well, the next topic is "Planning for Beta" 15:32:48 sgallagh: works for me! 15:32:54 guess who didn't read the agenda 15:32:58 :) 15:33:01 mitr, right, we don't have 'usable by non-root' as a beta criteria 15:33:21 ok, i think we're done here 15:33:23 I'd like us to keep a separate tracker from Beta 15:33:33 if no movement on this, will escalate 15:33:42 #action stefw to start a conversation on role definition in Cockpit on the mailing list 15:33:57 #action sgallagh will create a tracking bug for BZs of interest to the Server WG 15:34:19 #info Future WG meetings will involve a review and status update on any bugs connected to that tracker 15:34:30 Let's move to Beta planning 15:34:38 #topic Fedora 21 Beta Planning 15:34:52 #info First topic: Beta release criteria 15:35:21 adamw: Mind giving a quick historical overview of Beta criteria? 15:35:34 mmmm 15:35:57 the Beta Objectives in e.g. https://fedoraproject.org/wiki/Fedora_21_Beta_Release_Criteria are about all we have 15:36:22 adamw: tl;dr ? 15:36:23 '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 simo: it's already three bullet points! 15:36:37 simo: seems hard to make it any shorter :) 15:36:48 (and only the first two really matter) 15:36:52 oh sorry had to scroll there :) 15:36:59 get a vertical monitor ;) 15:37:26 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 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 rolekit's basic functionality must be good enough for testing roles 15:38:26 is this broadly making sense? 15:38:32 adamw: Yes 15:38:37 ok so strictly speaking additional admin roles wouldn't be abeta blocker as that can be added at any time ? 15:39:09 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 i think the criteria should mostly focus on those 15:39:28 oh, sorry, we're on PK roles 15:39:52 yeah usual confusion of terms :( 15:40:07 so the 'feature' of adding restricted admin stuff, well, yeah, i wouldn't expect that to block the release 15:40:25 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 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 ok 15:42:38 sgallagh: I think you also had something else in mind for the discussion ? 15:42:56 looking over it briefly, i think it'll involve adding a bunch of role stuff, and a couple of logging things. 15:42:58 should we take action item for adamw to come up with server WG important beta criteria ? 15:43:04 Well, basically I wanted us to try to figure out what we need to do by Beta 15:43:06 it would be nice if it wasn't just me :) 15:43:10 but it does need doing. 15:43:25 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 sgallagh: anything needs to be done in rolekit ? 15:43:36 Yes 15:43:47 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 We still have a couple patches pending to deal with properly managing the firewall 15:44:18 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 probably primary roles have to broadly meet hte 'role definition requirements' 15:45:30 role firewall interaction has to be there 15:45:51 remote logging 15:46:02 (if any of these aren't actually on the table for f21 they can be taken out) 15:46:42 remote logging right now should basically be handled by journald's syslog interaction 15:46:42 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 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 looking at rolekit/TODO: package installation? documentation 15:48:24 Ah right 15:48:35 Right now package installation is still under development as well 15:48:39 'role definition requirements' has quite a lot in it 15:48:46 We hit a snag where packagekit didn't actually work :( 15:48:48 =) 15:49:53 adamw: Right, we should turn that entire list into Beta blockers 15:50:29 is there anything we need to decide on ? 15:50:30 Except backup set 15:50:43 any bug/feature we need to decide to drop/keep now ? 15:50:51 or should we defer till later and see if they cna make it ? 15:51:18 (btw I have ahrd stop in 10 min) 15:51:23 I don't see anything controversial at this point 15:51:34 ok 15:51:41 so who is going to make the list of blockers ? 15:53:09 Each of the respective owners should 15:53:27 i can try to get the criteria drafted this week, i really ought to 15:53:27 I suppose that means twoerner, mitr and I for rolekit, stefw for cockpit, etc. 15:53:32 should we review them periodically in the meetings ? 15:53:34 adamw: Thanks 15:53:52 simo: We should review all open BZs associated with the tracker I'm going to create. 15:53:57 ok 15:54:13 then we should put that in the next meeting agenda immediately 15:55:30 Yes 15:55:39 I'm creating the tracking BZ as we speak 15:57:11 .bug 1145747 15:57:14 sgallagh: Bug 1145747 [Tracker] Fedora Server 21 - https://bugzilla.redhat.com/1145747 15:57:37 #topic Open Floor 15:57:41 Anything for the last four minutes? 15:57:53 Oh: "Great job, everyone! F21 Alpha is out!" 15:59:37 yaay 15:59:53 pity it didn't have the best freeipa, but hey 16:00:15 Fixable with updates 16:00:50 OK, thanks everyone 16:00:53 #endmeeting