18:00:25 #startmeeting EPEL 18:00:25 Meeting started Wed Mar 1 18:00:25 2017 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:25 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:25 The meeting name has been set to 'epel' 18:00:25 #meetingname EPEL 18:00:25 #chair smooge nirik Evolution bstinson avij 18:00:25 The meeting name has been set to 'epel' 18:00:25 Current chairs: Evolution avij bstinson nirik smooge 18:00:25 #topic aloha 18:00:29 Hello everyone 18:00:36 greetings 18:00:43 morning 18:00:45 o/ 18:00:50 hey all 18:01:16 Thank you all for coming to day 18:01:27 #topic plans for the week 18:01:27 #info Meeting has a HARD stop at 18:50 UTC today. 18:01:27 #info Nagios update in EL7 broke production people 18:01:27 #info Working on PRD need an idea about mission/vision 18:01:27 #info Other? 18:01:47 I can talk about the EPEL5 gpg key drill. 18:01:56 Cool. I will start with that 18:02:11 #topic EPEL5 gpg fire drill. <<< EVERYTHING IS FINE >>> 18:02:18 ha 18:02:36 so, the epel5 key was created just about 10 years ago. Exactly 10 years ago yesterday. 18:02:42 So it expired. 18:02:50 We tested and nothing in the actual OS cares. 18:02:58 yum doesn't care, rpm doesn't care, etc 18:03:18 However, we didnt test our signing server. It turns out it does care. It won't sign anything with an expired key. 18:03:19 that seems like a security issue. someone should file a bug 18:03:20 * Evolution flees 18:03:25 (because gpg cares) 18:03:52 so, thanks to a bunch of work from puiterwijk yesterday, he was able to implement a way to adjust the expiry and we are back in business. 18:04:09 the centos-5 key expired in january sometime. ;) 18:04:52 I wonder how the CentOS 5 packages got signed regardless of that 18:05:57 I don't think there have been any 18:06:00 you can extend the expiry on the signing machine(s) without redistributing the key 18:06:06 It is a dead parrot. 18:06:17 ah 18:06:22 bstinson: ... as long as you have the key passphrase :-) 18:06:58 which puiterwijk was able to come up with by sheer willpower 18:07:11 that and it was password123 18:07:11 there was a CentOS 5 kernel update as recently as 25th February, and apparently it got signed 18:07:26 Nope. Nobody knows the actual key passphrase for our epel5 keys :) 18:07:27 * nirik has no idea what software centos uses to sign 18:07:28 ah ok. I didn't see it 18:07:35 I suspect it's not the same as fedora/epel. ;) 18:07:42 i hope when i grow up i can summon passwords out of thin air 18:08:05 bstinson, puiterwijk might be younger than you 18:08:22 anyway. 18:08:26 thanks puiterwijk for that work 18:08:26 it is possible that whatever CentOS uses to sign stuff doesn't care about expired keys. but that's OT, thanks to puiterwijk for fixing the signing. 18:08:35 +1 18:08:40 +1 puiterwijk 18:09:17 So the end result is that we don't have to try and push out new keys? 18:09:20 thanks nirik for taking it up.. I was actually more of 'well its 35 days till we expire EPEL-5 anyway.. and we didn't want new packages pushed anyway 18:09:32 right. no new keys needed 18:09:38 which is great 18:10:06 I just know someone planned this ten years ago. 18:10:09 I'm completely fine letting 5 wither a little early. 18:10:32 We could. It just wouldn't do anything since yum/rpm/... don't care :) 18:11:10 so how does EPEL-6 look? 18:11:34 Evolution, actually I think we put in a bit of buffer time originally because the lifespan of a release was 3 years shorter then 18:11:38 none of the rest of our keys expire. 18:11:53 cool 18:12:05 epel5 only did because it was made by a human 18:12:09 pesky humans 18:12:23 ah .. 18:12:32 different servers different admins, different company 18:12:44 Someone actually had the key and its passphrase in their hand at the same time.. scary! 18:12:50 well when the revolution comes we will all be happy when their robot keys never expire 18:13:15 ok anything else on this? 18:13:46 thanks again guys. 18:14:46 OK next item 18:14:49 #topic Nagios Update. 18:14:49 #info Please review https://bugzilla.redhat.com/show_bug.cgi?id=1427895 18:14:49 #info Nagios needs an outside review 18:14:49 #info Suggestions on fix since it has been out for a week? 18:14:50 #info Discuss. Smoogen recuses from votes 18:15:18 meh, bad updates have happened to us all. ;) 18:15:29 pick yourself up and work on fixes. ;) 18:15:30 So background, I took over nagios this Fall and did a bunch of updates to try and get it in compliance with FHS and such. I also thought I had put it so it wouldn't autopush 18:15:44 Well the big things I want looked over: 18:16:00 I note that unlike many other EPEL packages, the nagios update actually got a number of +1 karma votes on https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0f3297a19b (and no -1 votes) 18:16:03 1) This was a major update to an existing package. Did I follow proper procedures 18:16:52 yes, I think so... 18:17:01 if people are +1ing it, it should work for them 18:17:05 2) Could I get someone to review the package to make sure that my change 'was correct' and how to fix where it is 18:17:57 considering the upstream security model, i think updating was/is appropriate 18:18:12 I agree. Plus, you announced it to epel-announce. 18:18:41 I'd be happy to take a look at the package, but not sure when I will get time... might not be for a bit. 18:18:41 If someone _relies_ on epel, and isn't subscribing to epel-announce, then they have only themselves to blame. 18:18:50 smooge: you're looking for a full package-review style review posted to that bug? 18:19:04 all the larger places relying on epel should be gating and doing their own testing/repos. 18:19:10 It does suck that it autopushed. I don't think any of us expect epel updates to go out quickly. 18:19:49 The reporter of the bug indicates "That information unfortunately did not reach us or the our users that have reported issues with Nagios to us :/". 18:20:03 Does that imply that this is a business without the time to even read epel-announce? 18:20:44 whats the bug(s)? 18:20:55 https://bugzilla.redhat.com/show_bug.cgi?id=1427895 18:21:12 I expect that the number of people on epel-announce is a tiny fraction of the businesses which use epel. 18:21:20 But that's their fault. 18:21:26 I am mostly wanting to make sure that because I am on the EPSCO that I am not getting a free pass 18:21:43 Honestly I don't think this is a problem with the nagios package. It's a problem with the implied promise made to people who use EPEL. 18:22:05 yes that is the part I want to fix 18:22:32 yeah, sometimes it's hard to know what people expect. 18:22:47 At minimum, https://fedoraproject.org/wiki/EPEL_Updates_Policy needs a promise that disruptive updates will be announced to epel-announce. 18:22:53 I had a bug the other day where someone said "I'm a paying customer! please fix this right now!" 18:23:09 They might be someone's paying customer, I guess. 18:23:59 I also think that the epel "promise" needs to be clearly documented, and needs to include a section on the promise the user is expected to make in return. 18:25:12 so the main problem was caused by me trying to fix something. Nagios by default rights everything to /var. The older nagios 'fixed' that by putting everything in /var/log/nagios/ which was fine in 2.x series because it was only 2-3 files 18:25:14 https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy also needs a note about disabling autopush. 18:25:19 thats a good idea. +1 18:25:25 tibbs++ 18:25:56 Let me do some edits. 18:26:44 I wish more people would use epel-testing so that any issues would be caught before wider deployment. perhaps its use should be encouraged somewhere. 18:26:59 the new nagios uses a lot of different files and so I put them in /var/spool/nagios and /var/lib/nagios because they fit that tree space. I tried making a script to do the changes but looking at various sample ones it was danger prone 18:27:11 speaking of nagios, there was also a selinux issue that I stumbled on 18:27:37 and then there was the selinux policy that was added to the old nagios rpm which was supposed to be done 18:27:47 ( https://bugzilla.redhat.com/show_bug.cgi?id=1426824 ) 18:28:37 https://fedoraproject.org/w/index.php?title=EPEL_Updates_Policy&diff=487168&oldid=433153 18:28:39 I removed that because it would break if they updated selinux-policy or with other file issues 18:29:04 thanks tibbs 18:29:48 anyway the major change in file locations should probably not have been done in the EPEL packages but just fixed in the Fedora ones 18:30:33 tibbs: yes, looks fine, thanks 18:30:49 I am wearing camel hair sackcloth for the next week and going to put in a sample fix script and a sample selinux policy for people to apply without the package doing so. 18:30:58 https://fedoraproject.org/w/index.php?title=EPEL_incompatible_upgrades_policy&diff=487169&oldid=466318 18:31:02 in the past selinux-policy folks were pretty fast to respond... that seems less so these days, but oh well. 18:31:15 dwalsh has docker to play with now 18:31:30 tibbs: +1 18:31:40 Actually https://fedoraproject.org/w/index.php?title=EPEL_incompatible_upgrades_policy&diff=487170&oldid=466318 because my fingers left out a word. 18:32:31 right 18:32:34 I think selinux got moved to another team, and they are likely busy to be up to speed from the previous people (but they are cleaning the repo, so that's great) 18:33:18 are there any other suggestions on this? 18:33:34 because I have a bikeshed for us to paint 18:34:03 If someone can tell me where the actual promises make about stability actually lives, I'll have a look at it. 18:35:16 I have no idea myself. I am wanting to get it much clearer and rebuilt 18:35:28 #topic Working on EPEL PRD 18:35:29 #info Looking at sgallaghs Srver https://fedoraproject.org/wiki/Server/Product_Requirements_Document 18:35:29 #info Looking at https://fedoraproject.org/wiki/Server 18:35:29 I'll at least add something to https://fedoraproject.org/wiki/EPEL 18:35:53 So I would like to update the EPEL docs and layout closer to the other SIG/Working Groups Fedora has. 18:36:19 The Server group looked closest to what we do so I have been looking to crib it 18:36:42 Are there any concerns or questions about that? 18:39:38 << crickets >> << crickets >> 18:40:14 * nirik doesn't until there's something to review. ;) 18:40:14 Completely out of my wheelhouse, sorry. 18:40:22 if they have something useful for us, sure, that's good 18:40:42 smooge: happy to help however you need 18:41:06 I haven't looked at Fedora's SIG documentation that much, so I can't really comment 18:41:08 ok cool. Basically I am going to go with a short vision/mission which says we are the Pabst Blue Ribbon of Enterprise Software 18:41:28 Should be fine 18:42:03 ok anyway I started on this and ended up going down a bunch of other holes. I hope to have a first draft by next meeting 18:42:27 #topic Open Floor 18:42:40 OK open floor for up to 8 minutes. Anything 18:43:16 Working on a "can I rely on these packages" section for the EPEL page. Will probably not have it done before the meeting ends but I'll send a diff to #epel. Can always back it out if it's controversial. 18:44:06 Note also that I do think that 4+ week orphaned packages really, really need to be announced to epel-announce. 18:44:28 But I don't know how those reports get generated. 18:45:39 tibbs, it is on my list of things that I am trying to get done 18:45:50 no progress 18:46:24 tibbs, thank you very much 18:46:25 It's reasonable to do it manually, for a while at least. 18:47:23 currently till generates it on a machine of his and emails the lists 18:48:05 ok thank you all for coming to the meeting and giving input. 18:48:09 #endmeeting