15:01:27 #startmeeting Server Working Group Weekly Meeting (2014-06-17) 15:01:27 Meeting started Tue Jun 17 15:01:27 2014 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:27 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:27 #chair sgallagh mizmo nirik davidstrauss stefw adamw simo tuanta mitr 15:01:27 Current chairs: adamw davidstrauss mitr mizmo nirik sgallagh simo stefw tuanta 15:01:34 #topic roll call 15:01:39 .hellomynameis kevin 15:01:40 nirik: kevin 'Kevin Fenzi' 15:01:43 .hellomynameis tuanta 15:01:44 tuanta: tuanta 'Truong Anh Tuan' 15:01:45 .hellomynameis sgallagh 15:01:46 \o\ /o/ 15:01:47 sgallagh: sgallagh 'Stephen Gallagher' 15:01:57 stefw is here 15:01:58 .hellomynameis adamwill 15:01:59 adamw: adamwill 'Adam Williamson' 15:02:08 simo: Is that arms waving or two TIE fighters attacking? 15:02:42 sgallagh: could be a pair of hard staring eyes too :) 15:02:55 Creepy. Moving on. 15:03:31 i think it's a pair of terminally unco-ordinated concertgoers. 15:03:39 * danofsatx-work is present and accounted for (mostly) 15:03:49 ,hellomynameis simo 15:03:53 .hellomynameis simo 15:03:54 simo: simo 'Simo Sorce' 15:03:55 lol fail .. 15:05:00 .hellomynameis dmossor 15:05:01 danofsatx-work: dmossor 'Dan Mossor' 15:05:19 ok, we have quorum 15:05:27 #topic Agenda 15:05:33 #info Agenda Topic: Release Criteria 15:05:37 #info Agenda Topic: Server Role Daemon Naming 15:05:49 Any other items to add to the agenda today? 15:06:40 Going once 15:07:17 * mizmo here 15:07:30 * jsmith lurks 15:07:33 Going twice 15:07:42 Okay, let's move on 15:07:46 #topic Release Criteria 15:08:09 #link https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria 15:08:51 thanks for working on this adamw. ;) 15:08:59 no probs 15:09:07 yeah adamw++ 15:09:16 how much of this reflects capabilities we already have? 15:09:27 i was just hoping to get some feedback on whether it's going in the right direction, whether i'm leaving anything out, any thoughts on specific issues i raised as i went along 15:09:29 * stefw apologises if he's missed where that is tracked 15:10:16 stefw: This is derived from the Technical Spec and PRD 15:10:18 stefw: i'd say that's more an issue of 'reality vs. the tech spec' - the way i conceive of the release criteria is crystallizing the bits of the tech spec that we would require to be implemented at release time for a given instance of Fedora Server 15:10:31 It's not making any claims of the current state (or tracking it) yet. 15:10:37 nod 15:10:50 there are likely to be other things that come up as we go along, the 'general' release criteria have grown over time 15:10:59 I'd suggest that once we ratify this, we should probably start a bug tracker to cover the gaps 15:11:21 yeah, we will be sure to have to adjust some things as we go... 15:12:01 adamw: Can we rephrase this sentence a bit: "It must be possible to deploy supported roles successfully both at install time and post-install." 15:12:16 The actual implementation of "at install time" is likely to be "during the first boot following install" 15:13:07 So it might be better to make that clear that it must be running at the end of the first post-installation boot-up 15:13:12 sgallagh: i think bugs to track bits of the tech spec that aren't implemented yet are a good idea regardless of criteria state 15:13:17 Wow, that was a run-on sentence... 15:13:26 adamw: +1 15:13:42 sgallagh: i can rephrase that, sure 15:13:53 throw an action item at me :) 15:14:22 once we've signed off on the criteria we could promote any of the bugs that violate the agreed-upon criteria to 'release blocker' status, but we could work on the bugs right now 15:14:37 I have a small question regarding "Role firewall configuration" 15:14:43 #action adamw to clarify "at install" phrasing to mean "running at the conclusion of the first boot-up after installation concludes" 15:15:35 adamw: A related question (to all present): Should we be using RHBZ to track these or set up our own tracker? If the former, what component? :) 15:15:36 adamw, shouldn't cockpit be on that criteria list? 15:15:57 twoerner: Go ahead and ask 15:16:14 ie: https://fedoraproject.org/wiki/Changes/CockpitManagementConsole 15:16:21 "It must be possible to query supported roles for a list of network ports the role operates on, and whether those ports are firewalled. It must be possible to open and close these ports using the server role interface." 15:16:34 stefw: that was actually an interesting question for me 15:16:46 I thought that the role will take care of the ports/services 15:17:03 stefw: we envisage Fedora Server instances as being manageable by cockpit, but is the management side of that equation a part of our supported/critical functionality? 15:17:11 twoerner: I don't see why those two statements are contradictory. 15:17:17 During the first boot following install is a strange way to define "install time." 15:17:19 but this implied more that the user of the API can change them and open/close ports from the list 15:17:31 twoerner: the role design envisages them as being queriable and modificable 15:17:32 twoerner, i know that in cockpit we'll certainly want to ask the role about ports and services, and not just have them handled automatically. 15:17:37 twoerner: modifiable* 15:17:40 davidstrauss, i agree - is during first boot just a stopgap for f21 and later on will be in installer? 15:17:45 twoerner: That's part of the intent (though full implementation might be deferred) 15:18:05 stefw: AFAICS, there is no "Server management role" at least for Fedora 21, and the server side of the Cockpit stuff isn't mentioned in the tech spec 15:18:07 adamw, yes, it's a good question ... i sorta imagined that having cockpit by default would be part of what makes fedora server attractive. ... but that doesn't mean it needs to go into the criteria of course 15:18:16 mizmo: Some pieces of this are a technical limitation of Anaconda (some parts of configuration and deployment really need to be run on the target system) 15:18:24 adamw, cockpit is not a manager that goes out and manages other servers (although it can) 15:18:26 Would roles be installable and configurable using Kickstart? 15:18:29 cockpit is the ui of the server 15:18:37 davidstrauss: Yes 15:18:46 stefw: sorry, yeah, i'm not sure what terminology to use 15:19:01 sgallagh, i think if the system has to run some stuff post-install that's okay, if ultimately the user gets the impression everything begins during anaconda that's probably better 15:19:04 The "by the time first boot concludes" is a hedge, really. 15:19:05 Okay, then I think install time is a reasonable definition then. 15:19:06 no worries, just making sure we're not talking about yet another fedora next flavor that is a server manager :D 15:19:11 anyway, the "bit where someone sits down and uses Cockpit to manage a Fedora Server machine" - that bit isn't in the spec, or if it is, i missed it. 15:19:20 mizmo: Everything will begin there, yes. (Or in kickstart) 15:19:24 sgallagh, okay perfect 15:19:44 sgallagh: are we depending on firstboot running ? 15:19:58 I ask because I sometimes disable it 15:20:00 I suppose there's "The default user-experience for the Fedora Server will be the bash shell on the console and the Cockpit web management console. " 15:20:01 simo: No, we're depending on systemd being the init system 15:20:08 but that's just sitting there on its own, cold and exposed. 15:20:09 sgallagh: ok then I am fine 15:20:18 adamw, yeah, maybe it doesn't need to be in the criteria ... it's just a second way of doing the configuration of the server. 15:20:22 sgallagh: ok 15:20:46 twoerner: Sorry, I lost the thread. What are you agreeing with? :) 15:20:54 i'm not entirely sure what "the Cockpit web management console" being "The default user-experience" even *means*, really. I guess we could interpret that as "the Cockpit web management console must be available after installation"? 15:21:06 (though under the current policy it'd be firewalled) 15:21:14 adamw, i'm filing bugs about that 15:21:29 now i wrote that down, though, i guess it makes sense as a criterion 15:21:33 it should not be firewalled, and it should be enabled by default 15:21:33 so thanks for bringing that up 15:21:39 i'll add it 15:21:39 adamw: Right, I think we should extend the criteria to allow Cockpit as well as sshd 15:22:02 sgallagh: roger, i'll change that too 15:22:10 sgallagh: " twoerner: That's part of the intent (though full implementation might be deferred)" 15:22:17 OK 15:22:37 twoerner: Yeah, the idea is that once we set up a Role, it is plausible that we'll want to close it off on certain interfaces 15:22:47 We discussed about doing that via zones in firewalld, IIRC 15:23:05 what do folks think about the idea i floated based on russell's idea of role functional requirements, btw? 15:23:14 I am willing to defer that from the *API* in F21, but it's on the todo list. 15:23:49 adamw: Would you mind doing 'info' or 'action' for the decisions above? 15:23:52 stefw: uhmm isn't it available via ssh from a "management" workstation ? Or do you depend on your port being open ? 15:23:58 his questions were interesting, and do sort of imply the need for a set of 'role guidelines' along the lines of the packaging guidelines 15:24:01 Too many concurrent discussions... we'll want those summaries. 15:24:10 stefw: btw is the cockpit port registere with IANA ? 15:24:18 sgallagh: eep, i'll do the ones i saw 15:24:24 Thanks 15:24:24 simo, the default cockpit use case is to connect to the server being managed 15:24:33 simo, you can also then connect out to other servers 15:24:42 #action adamw to reword "role deployment" criterion to be a bit vaguer (as part of install-time role deployment may happen during firstboot) 15:25:02 #action adamw to revise firewall criterion to allow port to be open for access to Cockpit web management console 15:25:16 there's no "management workstation" in normal use cases 15:25:18 simo: Cockpit is currently running (unapproved) on 1001. You can sign into it from there and then use the SSH port on any other system from it to add them to the managed list 15:25:28 #action adamw to write criterion requiring Cockpit web management console to be available OOTB 15:25:45 stefw: I am just concerned that a port is open by default, I have used fail2ban in the past, what is available for cockpit ? 15:25:49 s/any other system/any other Fedora Server/ 15:26:15 simo, that's a good question and one worthy of a bug 15:26:17 sshguard? 15:26:18 those are the ones i've noted, if you/twoerner agreed on something you'd better add that one :) 15:26:20 sgallagh: right so why does it need to be open by default ? You can run it on your own machine and use ssh to connect to Fedora Server 15:26:42 cockpit is meant to be usable out of the box without setting up prior infrastructure 15:26:53 erm, let me find it, it's something along those lines. I met the maintainer at TXLF on Saturday. 15:26:54 there are many ways to setup a management infrastructure on your network 15:27:09 cockpit wants to be usable without prior infrastructure, that's always been our goal 15:27:18 although we want to integrate well with such infrastructure when it's present 15:27:39 stefw: ok are you working on registering the port with IANA ? 15:27:39 #info Server Role API must *eventually* support blocking ports by network interface, but this feature is eligible for deferral in Fedora 21 15:27:43 but yes, lets look at fail2ban and similar solutions 15:27:51 adamw: ^^ keep that in mind for F21 criteria 15:28:07 simo, sgallagh was going to register, but we decided to defer on that, as it wasn't clear we met the criteria 15:28:10 simo: Registering 1001 would require an IETF resolution 15:28:13 as we're just an http server 15:28:28 there are many reasons why we're not on port 80 15:28:38 Basically, when I've asked about it, they've told us to just use 80 or 443 15:28:39 and happy to enumerate them further, perhaps on the mailing list 15:28:40 stefw: we can't be on 80 15:28:54 sgallagh: well it would be bad to have to change later 15:28:59 lots of firewall rules to change 15:29:26 it's not as bad as it sounds, as we can listen on multiple ports 15:29:37 stefw: If you can find a memorable port in the LANANA range instead of the IETF range, I can get it registered 15:29:38 if in the future such a change became necessary (and i don't see why it would) 15:29:55 simo: this will at best be handled with a firewalld service.. so we can easily switch 15:29:58 stefw: It's not just you. We'd have to change default firewall rules for the platform, handle upgrades, etc. 15:30:17 Not insurmountable, but simo is right that we should avoid extra work if possible 15:30:19 sgallagh: where is the LANANA registry ? 15:30:23 sure, but such things can be done in a gradual approach without fear of locking out the user 15:30:36 twoerner: its not just the firewall on the server itself 15:30:48 simo: I know ... 15:31:17 simo: I don't have the link handy. I'll get back to you on that. 15:31:25 www.lanana.org 15:31:26 just left taht out for the moment 15:31:30 but I do not see a port registry 15:31:42 in addition ... if there is some perceived benefit to < 1024 ports 15:31:45 then cockpit definitely should be on one 15:31:51 as people are typing their root passwords there etc... 15:31:58 stefw: I honestly do not see any benefit in < 1024 15:31:59 but that is a subject of much debate 15:32:03 * nirik is with simo 15:32:09 It is possible to control access to any port with selinux policy. 15:32:24 simo: http://www.iana.org/ 15:32:30 If it is socket-activated, as well, then systemd will squat on it before anything in the rest of userland comes up. 15:33:17 sgallagh: iana requires registration of a port 15:33:17 so...anyone on the role functional requirements topic? 15:33:26 sgallagh: but you said lanana :) 15:33:28 That said, there are plenty of ports <1024 that are distinctly non-Linux services that could run a Linux-only service. 15:33:31 simo: I misspoke 15:34:11 sgallagh: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=1 feel free to search, at page 16 you fin 1001-1008 marked as free 15:34:26 simo: I realize that, but we can't register it 15:34:38 Ports < 1024 have to go through IETF standardization 15:34:46 Not just a simple registration 15:34:56 right, so pick a higher one 15:35:10 (11:29:34 AM) sgallagh: stefw: If you can find a memorable port in the LANANA range instead of the IETF range, I can get it registered 15:35:26 s/LANANA/IANA/ obviously 15:36:17 10001? :) 15:36:19 sure, we can examine this all again, although during tihs meeting is probably not the best place 15:36:35 this will probably become the port that admins type thousands of times 15:36:43 adamw: taken obviously :) 15:36:44 so there's far more riding on it than some backend service 15:36:51 agreed 15:36:52 + adamw, 10000 is default port for Webmin, so 10001 may be good 15:37:08 ndmp is also 10000 15:37:11 * stefw really liked the idea of just using the same port as webmin and conflicting with it :D 15:37:13 tuanta: Hmm... is that reserved for webmin? 15:37:14 but everyone else vetoed me 15:37:15 * nirik shudders. webmin. 15:37:15 scp-config is 10001 15:37:16 for good reason 15:37:25 ... 15:37:37 stefw: I wouldn't mind 10000 :) 15:37:45 sgallagh, it is default port when you install Webmin 15:38:01 I am not sure it has been registered or not 15:38:02 I'll see if webmin has a reservation for that 15:38:08 stefw: 10011 is unassigned apparentl 15:38:20 If they do, we probably *can* coopt it, since we're providing a similar (better!) service 15:38:29 we should use 1001001 :) 15:38:33 :) 15:38:52 yeah, five digits and up are much harder to get at a glance 15:38:57 port 1M and up are certainly free, though a bit unreachable :) 15:39:01 Reserved officially for NDMP 15:39:12 sgallagh: see above, I already mentioned it :) 15:39:22 yes, sgallagh, I see 15:39:35 #link http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10000 15:40:24 Ok, let's take this offline 15:40:28 ack 15:40:28 yup 15:40:33 I'll take an action item to follow up on this 15:40:37 +1 sgallagh 15:40:46 #action sgallagh to work with Cockpit team to find memorable port for reservation 15:41:32 we can search for all reserved (free?) ports here: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=reserved 15:42:03 tuanta: s/reserved/unassigned/ 15:42:17 thanks, simo 15:42:18 tuanta: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt is the assigned ones 15:42:39 Let's move on 15:42:56 adamw: Did you have other parts of the criteria to discuss? 15:44:57 sgallagh: i've been asking for the last 10 minutes. :) 15:45:08 so...anyone on the role functional requirements topic? 15:45:36 what do folks think about the idea i floated based on russell's idea of role functional requirements, btw? 15:45:49 adamw: Sorry, I missed that in the other noise 15:46:33 adamw: I'd like to see that germinate a little longer on the list, I think 15:46:55 just so long as it germinates :P 15:46:56 From the last messages, it sounds like rdoty will be sending out a new proposal in a separate thread? 15:47:34 * nirik was rescanning that thread. 15:49:09 i don't know what he's planning to do 15:49:12 yeah, seems ok to me... but sure more list discussion is fine. 15:49:27 he proposed three separate things 15:49:42 * sgallagh only had time to skim them before this meeting 15:49:44 to me, one of them is clearly not for the criteria (at least yet), as it's a proposal for server to cover completely new ground 15:49:54 (that's the thing about resource management) 15:50:24 the thing about user accounts is somewhat borderline; i have some very ill-defined antenna for what is and is not release criteria material and that doesn't quite trigger them, but i find it hard to quantify 15:50:54 the one i'm mainly interested in was his first idea, to have specific functional requirements for particular roles - i.e. make sure the roles actually do what they're meant to do. i suggested a way forward with that 15:51:13 thats the one I was saying seemed ok to me. ;) 15:51:17 which is to have a criterion that says "primary supported roles must meet their functional requirements", more or less, and have the actual requirements documented as part of the role definition 15:51:20 nirik: ah, thanks 15:51:37 that implies that we actually have some kind of 'paper trail' for roles, which i'm not sure we've actually done yet. 15:51:43 that seems like it should scale better when/if we add a bunch more roles. 15:51:48 adamw: I +1 that 15:52:06 with *that* being: "primary supported roles must meet their functional requirements" 15:52:07 nirik: we may as well do the right design even with two roles. 15:52:32 it runs a risk of getting messy if we start baking requirements for specific roles into the criteria, i think. 15:52:39 adamw: We have a paper trail in the Change Proposals 15:52:44 we'd probably just wind up having to unpick it later 15:52:49 sgallagh: well, yeah, but that' 15:52:52 We should be ensuring that those specify functional requirements 15:52:53 that's part of a different process 15:53:23 yes, +1 to correct process. 15:53:25 can we structure things such that the change proposals do ongoing duty as the specifications for the roles? i'm not sure 15:53:29 if we can, great 15:54:20 True, maybe we should do the reverse 15:54:32 Maintain a page of functional criteria and link that from the Change proposal 15:55:39 that might work better 15:55:54 i was figuring we might wind up with something a bit broader, of which the criteria would just be a part, let's call it a 'role specification' 15:56:23 and yeah, in future the new role workflow would be to draw up the draft role spec within the Server WG, and then propose a change which is backed by the role spec document, i guess 15:56:49 +1 15:56:59 * adamw clearly missed his calling in local government bureaucracy 15:57:01 * nirik nods. 15:57:01 We're almost out of time for this week. 15:57:05 'i want everything in triplicate! twice!' 15:57:09 yup, sorry 15:57:13 Mind if we jump to the other topic? 15:57:18 no objection 15:57:38 #topic Server Role Daemon Naming 15:57:38 #info Proposed Name: RoleD/roled 15:57:39 #info Proposed Name: thespian 15:57:39 #info Proposed Name: RoleKit 15:57:39 #info Proposed Name: RoleMgr 15:57:40 #info Proposed Name: RoleManager 15:58:05 sgallagh: ok how do you propose to handle this bikeshed ? 15:58:07 :) 15:58:13 * nirik dislikes camel case personally, otherwise I don't care. 15:58:27 WG members: please state your favorite. If one is overwhelmingly chosen, it wins. 15:58:36 After that, we'll figure it out :) 15:58:37 * tuanta has got another meeting in 2 minutes 15:58:42 Vote: RoleKit 15:58:53 I do not like roled, I think rolled and in general not sure how to say/what it means, but do not care enough to say -1 to it 15:58:55 i'm fine with any of the straightforward ones (i.e. not thespian) 15:59:19 how about serverd? 15:59:21 yeah -1 on thespian 15:59:31 twoerner: -1 (I think that's too confusing with systemd) 15:59:42 #info Proposed Name: Serverd 15:59:53 RoleKit is good choice, I think 15:59:57 sgallagh: nah, it's ok 16:00:16 simo: Sure, enter it as a candidate. I'm just exercising my right not to like it :) 16:00:22 I did 16:00:29 though I think it is inappropriate 16:00:42 What is? 16:00:49 i like roled 16:00:49 so I will vote my own RoleKit evn though I am not sure it is the best name :) 16:01:12 note that there is also already a rtkit... not sure if thats too close or not. 16:01:14 stefw: except it is not just/only a daemon ? 16:01:28 nirik: sounds quite different to me 16:02:12 could we make it 'rolekit' ? ;) 16:02:20 nirik: I do not care about case 16:02:22 nirik: I'm fine with that 16:02:50 * nirik would +1 rolekit then 16:03:13 I see +4 for rolekit, +1 for roled and a few abstentions 16:04:00 mizmo: Any opinion? :) 16:05:45 adamw: Want to strengthen your vote and settle this? 16:05:55 rolekit fine for me 16:06:11 i'm not against rolekit, probably my second choice 16:06:49 * jsmith is not voting, and just throwing out "RoleCtl" as a drive-by comment -- he likes the way "Role Control" rolls off his tongue 16:07:07 #info Proposed Name: RoleCtl 16:07:17 Role Cthulhu sounds good too :-P 16:07:19 rolekit wfm 16:07:22 hmmm, not bad 16:07:24 fits the theme 16:07:28 i like rolectl 16:07:39 rolectl kind of rhymes tho, hehe 16:07:39 supposed to be a tool/api, not a daemon that's constantly doing stuff 16:07:43 could be the name of the cmd line tool 16:07:55 simo: +1 16:08:12 rolekit for the daemon, rolectl for the CLI? 16:08:18 +1 16:08:24 * jsmith likes it 16:08:30 +1 16:08:45 I would say rolekit for the project, maybe roled for the daemon and rolectl for the cmdline 16:08:50 so we are all a happy family :-D 16:08:56 if I were voting, I'd +1 that 16:09:14 I am, and I will :) +1 16:09:24 sure. +1 16:09:56 +1 16:10:12 +1 16:10:35 #agreed Project will be named 'rolekit', it's daemon will be 'roled' and its command-line interface will be 'rolectl' 16:10:41 #topic Open Floor 16:10:47 Any topics for Open Floor this week? 16:11:07 * sgallagh notes we're over time, so perhaps email to the list would be better unless it's quick 16:11:51 OK, going once. 16:12:13 I will not be at the meeting next week due to RH300 class. 16:12:31 Ah, good point. I will also not be at the meeting next week due to a business trip. 16:12:41 Would someone mind volunteering to chair the meeting in my absence? 16:13:42 * adamw did it last time, someone else do it :P 16:13:43 I will probably not be able to participate in July, I am traveling+vacation 16:13:53 but I will follow the ML 16:14:20 sgallagh: I can chair next week 16:14:21 sounds like maybe we won't be having one 16:14:29 * simo hopes to remember o_O 16:14:38 simo: Thanks. 16:14:46 #action simo to chair next week's meeting 16:14:49 assuiming we need one of course 16:14:57 I'll also be having a very busy latter half of July. 16:15:11 Vacation and moving 16:15:19 Ok, thanks for coming, everyone! 16:15:24 #endmeeting