16:30:09 #startmeeting fedora_coreos_meeting 16:30:09 Meeting started Wed Feb 6 16:30:09 2019 UTC. 16:30:09 This meeting is logged and archived in a public location. 16:30:09 The chair is lorbus[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:09 The meeting name has been set to 'fedora_coreos_meeting' 16:30:30 #topic roll call 16:30:33 .hello2 16:30:34 ajeddeloh: ajeddeloh 'Andrew Jeddeloh' 16:30:38 .hello mnguyen 16:30:40 mnguyen_: mnguyen 'Michael Nguyen' 16:30:41 .hello sinnykumari 16:30:43 ksinny: sinnykumari 'Sinny Kumari' 16:30:46 .hello2 16:30:47 rfairley: rfairley 'None' 16:30:51 .hello2 16:30:53 dustymabe: dustymabe 'Dusty Mabe' 16:31:10 .hello2 16:31:11 slowrie: slowrie 'Stephen Lowrie' 16:31:31 .hello lucab 16:31:32 kaeso: lucab 'Luca Bruno' 16:31:37 .hello jeyoung 16:31:38 jeyoung: Sorry, but you don't exist 16:31:41 :( 16:31:59 .hello2 16:32:00 walters: walters 'Colin Walters' 16:32:06 * jcajka is lurking 16:32:06 #chair ajeddeloh mnguyen_ ksinny rfairley dustymabe slowrie kaeso 16:32:06 Current chairs: ajeddeloh dustymabe kaeso ksinny lorbus[m] mnguyen_ rfairley slowrie 16:32:16 .hello miabbott 16:32:17 miabbott: miabbott 'Micah Abbott' 16:32:20 jeyoung:Hey! try with your fas id 16:32:30 #chair walters miabbott 16:32:30 Current chairs: ajeddeloh dustymabe kaeso ksinny lorbus[m] miabbott mnguyen_ rfairley slowrie walters 16:32:50 o/ hi jeyoung! 16:33:50 .hello2 16:33:53 yzhang: yzhang 'Yu Qi Zhang' 16:33:55 .hello2 16:33:56 jlebon: jlebon 'None' 16:33:59 ok let's move on to the agenda! 16:34:05 #topic Action items from last meeting 16:34:06 .hello2 16:34:07 emv: Sorry, but you don't exist 16:34:19 #chair jlebon 16:34:19 Current chairs: ajeddeloh dustymabe jlebon kaeso ksinny lorbus[m] miabbott mnguyen_ rfairley slowrie walters 16:34:39 * lorbus[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/kVzAYiNfLiwuOwAHXXVgDqEk > 16:35:17 #topic bgilbert to update the ticket with discussion summary, PR the design doc, and file tickets for needed work 16:35:24 * bgilbert 16:35:26 * bgilbert to update the ticket with discussion summary, PR the design 16:35:28 doc, and file tickets for needed work 16:35:30 * kaeso 16:35:32 * kaeso to open a FCOS tracker issue to discuss if we should have an 16:35:34 oem-id for bare metal 16:35:36 * **UNASSIGNED** 16:35:38 * sinny to open a ticket where we discuss adding ostree configs to an 16:35:40 rpm rather than having them be an unmanaged file on the system 16:35:42 lorbus[m]: matrix replaced your message with a link 16:35:44 :) 16:36:04 #info opened ticket https://github.com/coreos/fedora-coreos-tracker/issues/143 16:36:18 dustymabe: oh, I see 16:36:31 .hello sayanchowdhury 16:36:34 sayan: sayanchowdhury 'Sayan Chowdhury' 16:36:35 was wondering why it looked so nice on my client :P 16:36:43 .hello vielmetti 16:36:43 emv: Sorry, but you don't exist 16:36:44 lol 16:36:46 lol 16:36:53 rofl 16:37:00 #chair sayan 16:37:00 Current chairs: ajeddeloh dustymabe jlebon kaeso ksinny lorbus[m] miabbott mnguyen_ rfairley sayan slowrie walters 16:37:11 #info kaeso opened #142 for oem-id for bare metal 16:37:15 #link https://github.com/coreos/fedora-coreos-tracker/issues/142 16:37:48 I think bgilbert did what he said he was going to do - I forget which ticket that action item was for 16:37:54 bgilbert is AFK this week 16:38:09 so re-action? 16:38:16 one sec 16:38:24 i'll see if I can figure it tout 16:39:29 dustymabe: did we forgot to note in the action item what was the discussion about? :) 16:39:36 *forget 16:39:39 #info bgilbert updated #138 with discussion from last weeks meeting about ssh password login by default 16:39:53 #link https://github.com/coreos/fedora-coreos-tracker/issues/138#issuecomment-459219374 16:41:12 re metal I just updated https://github.com/coreos/coreos-assembler/pull/305 16:42:18 I think that covers all of last weeks action items! (unfortunately the set topic isnt correct, but anyway. move on? 16:42:47 +1 16:43:03 #topic Decide how to handle user SSH keys 16:43:11 #link https://github.com/coreos/fedora-coreos-tracker/issues/139 16:43:53 ok I added the meeting label to this 16:44:09 there was a lot of discussion in the ticket and bgilbert laid out our options very nicely 16:44:11 walters: is this related to one of last weeks topics? or should I add a topic for it after these? 16:44:24 re oemid on bare metal 16:44:28 and also for general interest 16:44:33 walters: nvmd 16:44:47 #undo 16:44:47 Removing item from minutes: 16:44:48 #undo 16:44:48 Removing item from minutes: 16:45:02 #link https://github.com/coreos/coreos-assembler/pull/305 16:45:10 #topic Decide how to handle user SSH keys 16:45:22 #link https://github.com/coreos/fedora-coreos-tracker/issues/139 16:45:25 * dustymabe rewind 16:45:33 there was a lot of discussion in the ticket and bgilbert laid out our options very nicely 16:46:09 it looks like we are currently thinking that we will implement an authorized_keys.d/ approach using a `AuthorizedKeysCommand` 16:46:13 Can you have multiple AuthorizedKeysCommand's? 16:46:28 because GCE wants to hijack that for oslogin 16:46:46 ajeddeloh: probably not 16:47:11 ajeddeloh: my read of the manpage is a "no" 16:47:57 regardless of whether we use authorizedkeyscommand or hack up authorizedkeysfile we believe our path forward does not include update_ssh_keys code 16:48:08 does anyone object to that direction/strategy? 16:49:11 how long do we wait for an upstream reaction before going to option 4? 16:49:44 For #6 there are CL implications 16:49:44 lorbus[m]: i don't think we should 'wait' on upstream at this point 16:50:05 since we currently use that directory. I think it would be fine but effectively keys would be added twice 16:50:05 dustymabe: ack 16:50:11 lorbus[m]: basically once we get ready to implement something then we do it. 16:50:40 ajeddeloh: #6 is something like: https://github.com/coreos/fedora-coreos-tracker/issues/139#issuecomment-458341663 ? 16:51:13 err my bad 16:51:14 #5 16:51:22 modifying openssh 16:51:44 ah I see, thanks for linking dustymabe 16:51:58 ajeddeloh: if we modify upstream it would no doubt take some time to get into a released sshd 16:52:07 so the implications for CL are probably minimal? 16:52:45 yeah but we'd pick it up eventaully 16:53:02 since there _will_ be another openssh vuln probably before CL EOL 16:53:12 do you guys already use a directory in AuthorizedKeysFile ? 16:53:43 for CL 16:53:55 no I'm saying since update-ssh-keys is already doing its job 16:54:03 openssh would see every key twice 16:54:05 ah, I see 16:54:13 +1 16:54:35 I think i'd be happy to tackle that problem because that means upstream would have implemented that functionality 16:54:37 :) 16:55:00 anyway that's all I had for this topic, just wanted to FYI where we currently are and ask for input/concerns 16:55:08 ajeddeloh: maybe add that comment about CL to the ticket 16:55:16 But if things break then we lock users out or let other users in 16:55:20 +1 16:55:21 ajeddeloh: I don't think CL will have problems, we are not pointing directly to the .d 16:56:01 kaeso: isn't that where update-ssh-keys reads from 16:56:44 ajeddeloh: yes, but not sshd itself 16:57:01 yeah, that's my point 16:57:11 ack 16:57:12 OH 16:57:23 let's take followup offline, it's not super-relevant here now 16:57:28 +1 16:58:05 #topic Keep/Remove Python dependent package: nfs-utils 16:58:15 #link https://github.com/coreos/fedora-coreos-tracker/issues/121 16:59:17 ksinny: would you like to summarize our conversation with the nfs team? 16:59:27 sure 17:02:13 In order to separate python dependencies in nfs-utils package, we need to separate them into separate python sub-package. unfortunately nfs-utils in F30 include a Python script nfsconvert.py which is to convert deprecated sysconfig/nfs configuration into /etc/nfs.conf 17:02:28 Related change proposal - https://fedoraproject.org/wiki/Changes/nfs.conf 17:03:14 ksinny: it's this one, isn't it?: https://src.fedoraproject.org/rpms/nfs-utils/blob/master/f/nfsconvert.py 17:03:38 we had a disussion on bug https://bugzilla.redhat.com/show_bug.cgi?id=1667889 with nfs-utils maintainer and so far it seem sthat they want to keep Python script into nfs-utils package 17:03:55 One proposed solution is in https://bugzilla.redhat.com/show_bug.cgi?id=1667889#c13 17:04:21 which is about we create a nfs-utils-coreos package that has minimal needed to do a NFS mount 17:05:11 I believe this new package can contain utilities which we need from current nfs-utils 17:05:31 we floated the idea of a rewrite of the `nfsconvert.py` but it was rejected for a good reason, being that they already had a ton of testing on the existing implementation 17:05:58 yeah and it makes sense 17:06:07 would we maintain the -coreos package or would they 17:06:28 having a minimal package that doesn't ship this legacy convert script sounds like a good way to me 17:06:39 ajeddeloh: I think they are offering to carry it 17:06:51 it's basically an extra paragraph in the spec file to generate another rpm 17:06:55 but is -coreos the right suffix for it? shouldn't it be something like -minimal? 17:06:56 +2 to the -coreos package 17:07:03 lorbus[m]: ++ 17:07:11 so obviously having a nfs-utils-coreos package would give us everything we would need but I worry about this approach 17:07:15 I think the minimal -coreos idea works as long as all reverse dependencies of nfs-utils are switched to that 17:07:41 kaeso: I think "reverse dependencies" can be satisfied with a virtual provides and a conflictes 17:07:58 Maybe we can have something sub-pacakge with nfs-utils-minimal which we FCOS can use and existing nfs-utils package can add requires on it 17:08:07 that way there will no duplication 17:08:46 a bit surprised https://src.fedoraproject.org/rpms/nfs-utils/pull-request/7 didn't come up in that thread 17:08:47 regarding -coreos or -minimal. If we go with this approach (which I don't know if it is good or not) I'd prefer the -coreos suffix 17:09:18 what worries you and why -coreos instead of -minimal 17:09:31 personally I feel like as long as yum uses python trying to stop people from using it is going to be a somewhat lost cause 17:09:40 dustymabe: but then with virtual provides -coreos and -utils can't be co-installed, I guess 17:09:49 kaeso: right 17:09:56 ajeddeloh: let me do those one at a time 17:10:15 if we use minimal then I think people will misinterpret it and also try to mold it for different uses 17:10:21 if we use coreos it's explicit 17:10:33 and other people won't try to shoehorn it for other things they want to do 17:10:42 and now for the 2nd part 17:11:29 this approach worries me because I don't think it's scalable (i don't think every package that has python parts will want to carry a coreos sub package nor do I really want them to) 17:11:51 so while it's great they are offering this, I think it will be hard to convince others of this 17:12:01 that echoes walters' statement above 17:12:12 kaeso: yep 17:13:04 so what do we think we want to do here 17:13:12 If we want to name it -coreos then what dustymabe suggested sounds good to me 17:13:13 Any python removal (especailly in this case where we're removing non-upstream legacy stuff) is good in my book 17:13:20 https://github.com/coreos/fedora-coreos-tracker/issues/32#issuecomment-455579535 17:13:28 so I think we ought to take it where we can get it if they're offering 17:13:55 +1 to take them up on their offer 17:14:00 ajeddeloh: 17:14:00 I'd be in favor of removing everything in /etc/sysconfig if that were feasible 17:14:23 BTW see also the "Python as a security vulnerability" subsection of https://lwn.net/Articles/723823/ 17:14:46 ajeddeloh: 'non-upstream legacy stuff' ? i think the nfsconvert script was recently introduced 17:15:21 (It's not just python of course, beyond other scripting langauges on Unix, on Windows Powershell is also a focus of similar attempts to restrict it where possible) 17:16:22 dustymabe: the header at the top of the file says its for reading a deprecated file 17:16:33 so we are in favor of taking up their offer? 17:17:01 +1 If it moves us forward 17:17:03 ajeddeloh: yeah that'd be nice.../etc/sysconfig is IMO a weird relic of a Red Hat Linux era attempt to improve configuration but it ended up being "we put an /etc in your /etc" 17:17:27 lorbus[m]: I think we are, but their offer might not be useful to us if we have to declare python bankruptcy with the other packages 17:17:38 +1 on taking them up on their offer 17:17:38 this nfsconvert doesn't need any external pylib, so it could be a good candidate for system-python too without further fallout from additional dependencies 17:18:07 kaeso: agree - i think maybe we should start to consider walters' proposal 17:18:22 #link https://github.com/coreos/fedora-coreos-tracker/issues/32#issuecomment-455579535 17:18:36 the two are not mutually exclusive 17:18:38 dustymabe: I think it's probably cumbersome for all py packages on our list...but at least this moves us there slowly 17:18:41 ajeddeloh: I'd be interested in your thoughts there ^^ 17:18:56 I don't see a downside in taking their offer 17:19:25 Like yes, we _can_ not take their offer but we don't gain anything by doing it 17:19:42 lorbus[m]: I don't disagree with you. but do realize that the "extra package" could be a source of maintenace/breakage possibly 17:19:45 ajeddelloh++ 17:19:53 ajeddeloh: 💯 17:19:54 so it's not without cost (even though that cost isn't on us) 17:19:55 in fact it would let people use /etc/sysconfig, which is an antifeature 17:20:08 would -utils depends on -coreos or would they just duplicate some of their content? 17:20:34 kaeso: my understanding is they would have the exact same file set except remove python files 17:21:29 I'd personally prefer to take their offer and accept the maintenance risk 17:21:49 dustymabe: ack, now I understand better your virtual provide hint above 17:21:49 +1 17:22:01 But I'm definitely of the opinion that I'd like to not ship python :) 17:22:05 I was thinking of the plain utils pkg depending on -coreos/-minimal, hence preferring -minimal pkg naming 17:22:25 * ajeddeloh doesn't really care if its -coreos or -minimal 17:22:35 lorbus[m]: same here, but dustymabe had something different in mind :) 17:22:37 no opinions here on the package naming either 17:22:45 fcos is image based not package based so it really doesn't matter 17:23:03 matter to us* 17:23:04 ack 17:23:14 it's true. let's move on for now. only little time left 17:23:33 #topic https://github.com/coreos/fedora-coreos-tracker/issues/91 17:23:39 #undo 17:23:39 Removing item from minutes: 17:23:39 #proposed we'll agree to accept nfs-utils-coreos subpackage and continue to fight the python battle against other rpms to see where we land 17:23:48 acks/nacks? 17:23:54 #topic Bare Metal Installer: Attempt to build media based on current strategy 17:24:02 ack 17:24:04 so, we agreed on having -coreos sub-package with functionality equivalent to nfs-utils - python ? 17:24:13 #link https://github.com/coreos/fedora-coreos-tracker/issues/91 17:24:40 ksinny: yes I think so, sorry didn't info. 17:24:45 #undo 17:24:45 Removing item from minutes: 17:24:51 #undo 17:24:51 Removing item from minutes: 17:25:17 #info Agreement on having -coreos sub-package with functionality equivalent to nfs-utils - python 17:25:22 acks to proposal 17:25:24 #topic Bare Metal Installer: Attempt to build media based on current strategy 17:25:34 #link https://github.com/coreos/fedora-coreos-tracker/issues/91 17:25:44 I added this item to the meeting list 17:26:01 https://github.com/coreos/fedora-coreos-tracker/issues/91#issuecomment-461100135 17:26:20 I've got a few open PRs for adding an installer ISO to be output from CoreOS Assembler 17:26:44 There's still some work to be done (and some PRs for me to consider - thanks walters for your patience there) 17:26:47 but it's a start 17:27:05 and I've been working with some other people who have been interested in this work to get them hacking on it and successful 17:27:30 that's mostly all I had 17:27:45 dustymabe++ 17:27:45 ajeddeloh: Karma for dustymabe changed to 9 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:28:27 👍 17:28:35 nice 17:29:15 any more comments on this? otherwise i'll open the floor for one last minute 17:29:48 #topic Open Floor 17:30:38 anybody got anything? otherwise let's end meeting in 30 sec :) 17:30:42 Everone is doing amazing work, keep it up! 17:30:49 ksinny++ 17:30:52 thanks everyone! 17:30:54 ksinny++ 17:31:00 thanks everybody! 17:31:02 lots of hacking on coreos-assembler lately :) 17:31:11 thanks for joining in everyone! 17:31:19 jeyoung: anything for open floor today? 17:31:40 or jcajka 17:31:40 dustymabe: just trying to follow along :) 17:31:44 and I exist! 17:31:47 ksinny: if any packet related questions come up pls route them to me 17:31:48 jeyoung: woot! 17:32:04 emv aka vielmetti 17:32:26 dustymabe: not really, digging now in to the build process 17:32:44 jeyoung, emv: thanks for joining as well! 17:32:56 jcajka, too! 17:33:00 jcajka: +1 17:33:00 #endmeeting