17:03:52 <dgilmore> #startmeeting FESCO (2014-06-25)
17:03:52 <zodbot> Meeting started Wed Jun 25 17:03:52 2014 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:55 <nirik> yep
17:03:58 <dgilmore> #meetingname fesco
17:03:58 <zodbot> The meeting name has been set to 'fesco'
17:03:58 <dgilmore> #chair abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones  sgallagh t8m
17:03:58 <zodbot> Current chairs: abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones sgallagh t8m
17:04:01 <pingou> mattdm: nice timing :)
17:04:01 <dgilmore> #topic init process
17:04:03 <pjones> hello.
17:04:06 <mattdm> magic!
17:04:06 <mitr> Hello
17:04:08 <kylem> bueller.
17:04:08 <nirik> morning
17:04:26 <abadger1999> Hola
17:04:27 <dgilmore> looks like we have enough folks
17:04:31 <mattdm> I have a hard stop at 10 before the hour, btw.
17:04:33 <dgilmore> lets get started
17:04:40 * jreznik is around
17:04:45 <dgilmore> mattdm: its a short agenda
17:05:22 <dgilmore> #topic #1310 Reconsidering rpcbind's exception allowing it to start by default
17:05:26 <dgilmore> .fesco 1310
17:05:27 <dgilmore> https://fedorahosted.org/fesco/ticket/1310
17:05:28 <zodbot> dgilmore: #1310 (Reconsidering rpcbind's exception allowing it to start by default) – FESCo - https://fedorahosted.org/fesco/ticket/1310
17:06:55 <dgilmore> not sure where we are with this
17:07:10 <nirik> we were waiting for some feedback from steved..
17:07:18 <nirik> which doesn't seem to have happened.
17:07:28 <dgilmore> yeah
17:07:48 <nirik> but if it's needed for the client, I'm inclined to leave it autostarting (at least for now)
17:08:00 <dgilmore> i know it is needed for the client
17:08:04 <mattdm> the comment about it being socket-activated seems like a balancing factor.
17:08:13 <abadger1999> s/autostarting/start by default/ ?
17:08:19 <mattdm> that is, it's not _really_ autostarted unless needed?
17:08:27 <dgilmore> The question seems to be can rpcbind be started automatically when you go to mount a nfsv3 share
17:08:28 <abadger1999> I think steved asked whether it would start on-demand.
17:08:37 <mitr> mattdm: From a security/risk limitation perspective socket activation makes no differene.
17:09:09 <mattdm> mitr true. but from a resource consumption one it does.
17:10:11 * abadger1999 notes that socket activation is something that fesco should be addressing in its "autostart" list but currently hasn't set precedent by doing so.
17:10:32 <mattdm> abadger1999: yeah
17:11:15 <dgilmore> I guess someone need to test if rpcbind starts when needed, and if it doesn't can it be made to do so
17:12:03 <mitr> Do I read steved's note right that on the client, we need rpcbind running but not necessarily network reachable?  Having the default localhost-only but enabled would be much more attractive to me.
17:12:24 <mattdm> mitr yes, I think that's correct
17:13:07 <amluto> IIUC the client needs nfs-lock.service (unless -o nolock is set), and nfs-lock.service requires rpcbind.service
17:13:19 <dgilmore> So the question is will this type of network activity (remote and local) cause rpcbind to start before its needed? If the answer is yes, then good I will be more than willing to try.
17:13:39 <amluto> so the only likely regression i can think of is that maybe omitting -o nolock behaves better if rpcbind is running (but not nfs-lock.service) than if rpcbind isn't running
17:14:45 <nirik> so, wait another week for steved? assign one of us to just do the testing?
17:15:20 <dgilmore> lets wait one week, for further feedback, if none then we get someone to do some testing and provide it
17:15:55 <abadger1999> And be sure to comment on the ticket what we're wanting to know :-)
17:15:59 <nirik> +1
17:16:07 <dgilmore> abadger1999: already writing it up
17:16:10 <mattdm> okay, sure. doesn't seem urgent
17:16:11 <abadger1999> Cool.
17:16:12 <mattdm> +1
17:16:54 * kylem can do the testing.
17:17:18 <kylem> i can also harass steved tomorrow.
17:17:23 <dgilmore> kylem: okay
17:17:30 <mattdm> kylem: do both! :)
17:17:41 <kylem> i'll update the ticket before the next meeting with whatever the result is.
17:17:57 * jwb shows up
17:17:59 <dgilmore> #action kylem to test and harass steved to find out if things can be made to work for nfsv3
17:17:59 <abadger1999> Thanks
17:18:13 <dgilmore> kylem: thanks i wont add anything to the ticket then
17:18:23 <kylem> ok. no problemo.
17:18:30 <dgilmore> lets move on
17:18:31 <dgilmore> #topic #1311 Disable syscall auditing by default
17:18:31 <dgilmore> .fesco 1311
17:18:33 <dgilmore> https://fedorahosted.org/fesco/ticket/1311
17:18:33 <zodbot> dgilmore: #1311 (Disable syscall auditing by default) – FESCo - https://fedorahosted.org/fesco/ticket/1311
17:19:31 <dgilmore> are waiting further info here on the actual performance impact
17:19:42 <dgilmore> I think we are waiting further info here on the actual performance impact
17:19:44 <mattdm> I got some feedback from steve grubb
17:19:56 <mattdm> he, in turn, is waiting for the performance team to do some testing
17:20:35 <dgilmore> okay, so wait a week for more feedback?
17:20:41 <dgilmore> or should we wait longer?
17:20:53 <mattdm> I'll ping and ask the rough timeline
17:21:21 <dgilmore> okay lets update the ticket when we know when we should expect feedback so we can skip until then
17:21:36 <mattdm> however, he did say that it's probably going to be on a slower schedule than fedora might like
17:21:57 <kylem> nobody has made a particularly good case why it should stay on...
17:22:12 <kylem> besides "it helps sometimes"
17:22:32 * nirik nods.
17:22:44 <dgilmore> indeed
17:22:47 <kylem> then again, if a handful of ns per syscall is really a performance concern, you can turn it off yourself anyway.
17:22:51 <pjones> with the counterpoint "it clearly hurts sometimes"
17:22:55 <kylem> pjones, indeed.
17:23:01 <mattdm> kylem correct. I think the case is basically: if it's on in fedora, people are more likely to notice when something goes wrong and we get this feedback, which helps for the few people for whom it is vital
17:23:03 <kylem> amluto makes a good point wrt security too.
17:23:03 <pjones> and "it doesn't seem to be maintained, so it will hurt more in the future"
17:23:22 <kylem> (then again, the same is true for a lot of kernel code.)
17:24:03 <amluto> this particular piece of kernel code is unusual in that seccomp can't protect against it
17:24:29 <pjones> kylem: yeah, but not much of the code you're referencing is on /every/ syscall path
17:24:34 <mattdm> And, from my point of view... I appreciate that role of fedora in general, but I don't think that very many people are actually using it in fedora in a way that really helps
17:24:38 <kylem> indeed. frankly, i turn it off anyway, so i'm +1.
17:24:45 <kylem> ;-)
17:24:46 <mitr> pjones: The 32-on-64 case is AFAIK being actively addressed right now; the code is maintained but nobody is actively looking for bugs every week
17:25:00 <nirik> if we want to turn it off, we should be clear which way we want to turn it off. ;)
17:25:02 <pjones> mitr: well, that's some consolation.
17:25:30 <amluto> mitr: what 32-on-64 case?  is there yet another bug i don't know about?
17:25:35 <mitr> nirik: yeah; I'd be fairly strongly against kicking it out of the kernel; the default rule to disable it for all processes would be quite fine
17:25:50 * nirik nods. Just need to be clear.
17:25:58 <mitr> amluto: I'd expect everything to be discussed on linux-audit (but I'm not subscribed there)
17:26:03 <abadger1999> mitr: +1
17:26:44 <mitr> I'm still not _thrilled_ with disabling it, and dwalsh does say that it is somewhat useful, but nobody has been too strongly fighting for leaving it on either, so...
17:27:26 * nirik is ok with the disable for all processes config option.
17:27:34 * pjones is too
17:28:53 <mattdm> Is there a way we can turn it off in the cloud image which allows auditd to not be installed/running?
17:29:21 <jwb> isn't that what nirik just mentioned?
17:29:27 <mitr> mattdm: You need to run an auditctl command (i.e. have the package installed) but that doesn't require auditd running
17:29:41 <dgilmore> im okay with turning off for all processes, especially if we document a way to turn it on for the use cases where it is useful
17:29:48 <mitr> mattdm: That might be deviating from the default setup somewhat but AFAIK is fairly feasible
17:31:07 <amluto> mattdm: if nothing has ever enabled audit (that is, auditctl -e 1 or the equivalent never happens after boot), then syscall auditing will be off
17:31:17 <amluto> I think that, if auditd is not installed, then that's what happens
17:31:59 <mattdm> Okay -- I thought someone told me otherwise. But I may just be confused. This is definitely not an area of expertise for me -- we never had to audit things at this level at my sysadmin jobs :)
17:32:21 <dgilmore> should we vote on something or wait?
17:32:36 <pjones> mitr: that might be an argument for splitting the package into a -daemon and -tools or somesuch
17:32:47 <kylem> well, i assume we're not going to change f20, so i don't see harm in deferring the vote another week for rawhide.
17:33:02 <dgilmore> we wont change f20
17:33:15 <mitr> dgilmore: If we could expect to hear back from the perf team soon enough, I don't see harm in waiting (but then I don't see much harm in just flipping it now and perhaps flipping it back later)
17:33:18 <dgilmore> lets see if some magic data comes back soon
17:33:28 <mitr> pjones: It might; I'm not so intent on saving every 100 kb
17:33:40 <mattdm> mitr, pjones yes, it is small.
17:34:07 <abadger1999> mitr: I feel the same as you.
17:35:04 <mattdm> I'm +1 to mitr's parenthetical proposal
17:35:24 <mattdm> flip it now, and leave open the possibility of flipping it back if more data comes in
17:35:32 <abadger1999> +1 to mitr's proposal as well.
17:35:42 * nirik is +1 too
17:35:53 <mitr> Count me as +1 to either :)
17:36:36 <dgilmore> #proposal turn off syscall auditing for all processes by default. we will reevaluate when we get infor from the perf team
17:36:38 <pjones> Might be worth flipping it now and seeing if we get any anecdata in return.
17:36:46 <pjones> dgilmore: +1
17:36:47 <dgilmore> #proposal turn off syscall auditing for all processes by default. we will reevaluate when we get info from the perf team
17:36:56 <mattdm> dgilmore: +1
17:37:00 * dgilmore fixes typo
17:37:02 <nirik> dgilmore: +1
17:37:04 <abadger1999> dgilmore: +1
17:37:37 <dgilmore> since mitr did not actually put up a proposal
17:37:52 <dgilmore> we need one more +1 i think
17:37:57 <mitr> dgilmore: +1
17:38:03 <dgilmore> though i am +1 to my proposal
17:38:39 <dgilmore> #agreed turn off syscall auditing for all processes by default. we will reevaluate when we get info from the perf team (6-0-0)
17:38:52 <dgilmore> #topic #1312 F22 System Wide Change: Replace Yum With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
17:38:57 <dgilmore> .fesco 1312
17:38:57 <dgilmore> https://fedorahosted.org/fesco/ticket/1312
17:38:57 <zodbot> dgilmore: #1312 (F22 System Wide Change: Replace Yum With DNF - http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF) – FESCo - https://fedorahosted.org/fesco/ticket/1312
17:39:18 <dgilmore> didnt we approve this last week?
17:39:27 <nirik> yep
17:39:35 <mattdm> yeah there was something about asking the dnf maintainers here to talk more
17:39:44 <mattdm> but I don't actually have anything more to add :)
17:39:52 <mattdm> I said what I think
17:40:08 <mattdm> and after the devel mailing list I think it could use a nice calm rest
17:40:31 <dgilmore> okay, so lets get the ticket updated, actually invite dnf guys if we have questions for them
17:40:58 <dgilmore> #action dgilmore will look back at last weeks minutes and update the ticket appropriately
17:41:14 <dgilmore> #topic Next week's chair
17:41:24 <dgilmore> who wants to run the meeting next week?
17:41:33 <nirik> I've not done it in a while, I can
17:42:21 <dgilmore> #action nirik to run next weeks meeting
17:42:27 <dgilmore> #topic Open Floor
17:42:32 <mattdm> So.... https://fedorahosted.org/fesco/ticket/1317
17:42:36 <dgilmore> anyone have anything?
17:42:39 <mattdm> the election...
17:42:51 <nirik> yeah, we should move that forward
17:42:56 <mattdm> Last week, sgallagh tasked me with sending out an announcement as FPL
17:43:15 * kylem will be without internet in the wild and miss the meetings in 2 weeks and 3 weeks. apologies in advance.
17:43:15 <mattdm> but I'd like the details of what exactly is to be announced worked out :)
17:44:10 <mattdm> I'm happy to help and to send messages and lend voice and etc., but would someone else be able to drive this?
17:44:14 <nirik> proposal: nominations from announcement time to 2014-07-07, election from 2014-07-07 to 2014-07-14
17:44:28 <kylem> what is everyones thoughts about me stepping down to let notting's seat be re-elected?
17:44:40 <nirik> kylem: you can do so if you like. ;)
17:44:49 <mattdm> kylem If you want to, do it sooner rather than later :)
17:44:50 <abadger1999> yeah, entirely your choice to me.
17:44:55 <dgilmore> kylem: your choice
17:45:10 <pjones> what they all said.
17:45:11 <kylem> ok. i'll do that then. ;-)
17:45:21 <nirik> ok, so 3 seats?
17:45:23 <pjones> Alright, then we're electing 3 seats.
17:45:39 <kylem> sounds right to me.
17:45:48 <pjones> nirik: +1 to that timeline
17:45:58 <dgilmore> nirik: +1
17:46:04 <kylem> +1
17:46:29 <nirik> the last election we didn't do a questionare... we could do a townhall tho if desired. Not sure how usefull they have been.
17:46:38 <abadger1999> nirik: +1
17:46:58 <mattdm> nirik We should have some standard questions for the questionnaire
17:47:46 <mitr> nirik: The townhalls were always useful to me; knowing about a long-term contributor doesn't always mean knowing their thoughts on the questions of the day.
17:48:13 <nirik> mattdm: we could, but in the past we asked for people to ask, and got very little response...
17:48:16 <mattdm> I can be +1 to the timeline, but it might be nice to have another week for publicity and letting potential candidates think about it.
17:48:19 <nirik> we could do a townhall next week?
17:48:23 <dgilmore> i know last election cycle the townhalls didnt work out
17:48:26 <mattdm> nirik: yeah that's a whole problem with the whole thing.
17:48:34 <dgilmore> due to devconf and people travelling
17:48:37 <mattdm> ftr I tried to give some but I put them in the wrong place :)
17:49:04 <mattdm> in any case, I need to go.
17:49:47 <dgilmore> thanks mattdm
17:49:49 <kylem> thanks matt.
17:49:54 <nirik> ok.
17:50:12 <dgilmore> should we reuse the questions from last cycle?
17:50:33 <jreznik> any volunteer for elections wrangler? while talking about elections, maybe I missed it
17:50:55 <dgilmore> jreznik: not that I know of
17:51:05 <nirik> I've not seen one, but would be great to have one to nag everyone to keep things moving
17:52:17 <dgilmore> anyone want to volunteer to run the elections?
17:52:19 <jreznik> for special elections, it's maybe not as much needed as for standard ones
17:52:23 <dgilmore> abadger1999: ^
17:52:38 <jreznik> but it's always to have someone you know he's responsible for to avoid mess
17:53:08 * abadger1999 doesn't want to but is willing to handle the technical aspects (setting up the electrion in the election app and getting the results to the person making the announcement)
17:53:20 <abadger1999> Since I'm not running I can do that :-)
17:54:11 <dgilmore> abadger1999: so you will be the wrangler?
17:54:49 * dgilmore needs to run in a minute
17:54:50 <abadger1999> dgilmore: no.  I'll handle the technical side of it.
17:54:57 <dgilmore> abadger1999: okay just clarifying
17:55:10 <abadger1999> not the schedule/townhall/etc side.
17:55:36 <jreznik> I can help with schedule, as I always do it
17:55:40 <dgilmore> so we need a wrangler, we need to set a schedule and we need to work out questionaire, townhall details
17:56:13 <jreznik> but I never did that questionaire/townhall stuff
17:56:28 <dgilmore> jreznik: want to learn?>
17:57:07 <jreznik> dgilmore: why not? it's probably going to be easier if I do it whole with abadger1999 to setup bits
17:57:25 <dgilmore> #info jreznik to be election wrangler
17:57:42 <dgilmore> anything else we need to sort out here today?
17:57:46 <jreznik> what's the timeframe for it? asap?
17:57:55 <dgilmore> jreznik: yep
17:58:37 * nirik notes we sort of agreed on a schedule above... although mattdm wanted perhaps another week of lead time
17:59:06 <dgilmore> nirik: can you take over the last bit of the meeting please, i really need to run
17:59:23 <jreznik> nirik: ah, ok I see it
17:59:40 <nirik> dgilmore: sure. I think we are almost done...
17:59:45 <nirik> any other open floor business?
17:59:52 <jreznik> I'll take a look tomorrow, will update the ticket with proposal
18:00:01 <jreznik> nirik: one topic - schedule
18:00:04 <abadger1999> another week would be fine for me too.
18:00:05 <dgilmore> jreznik: nirik: thanks
18:00:15 * nirik would be ok moving the elections out another week too.
18:00:21 <kylem> indeed, i'm fine with pushing all dates in mattdm's original proposal out a week
18:00:42 <jreznik> we are still in "no earlier than" in the schedule and folks started pinging me if change freeze/branch is happening for real or they have more time
18:01:01 <nirik> jreznik: Yeah, I thought we finalized that a while ago, but perhaps I am wrong.
18:01:07 <mitr> jreznik: prooposal: s/no earlier than //g
18:01:12 <nirik> mitr: +1
18:01:28 <jreznik> it makes sense
18:01:32 <abadger1999> at least for change freeze and branch that makes sense.
18:02:08 <jreznik> abadger1999: well, we can remove "no earlier than" and continue with standard slipage from this point
18:02:19 <abadger1999> really.. we could slip no matter what the schedule says so  "no earlier than" is just telling people that hte schedule is more fluid than normal this time around.
18:02:28 <abadger1999> jreznik: yeah.  agreed.
18:02:46 <abadger1999> mitr: +1 to your proposal
18:02:47 <jreznik> maybe I just missed we agreed it's really that final, I consider it as final, just want final confirmation
18:03:38 <nirik> more votes please? thats +3 assuming mitr is for his proposal. ;)
18:03:45 * mitr is +1 for the record
18:03:54 <kylem> +1
18:04:00 <pjones> eh, +1 I guess.
18:04:49 <nirik> #agreed Will finalize current schedule and remove 'no earlier than' from milestones. (+5,0,0)
18:04:55 <nirik> anything else for open floor?
18:05:04 <jreznik> thanks!
18:06:30 <nirik> ok, if nothing else will close meeting in a random indeterminate time around a minute from now.
18:07:08 <abadger1999> :-)
18:07:11 <kylem> heh
18:07:23 <nirik> ok, thanks for coming everyone!
18:07:26 <nirik> #endmeeting