16:30:41 #startmeeting fedora_coreos_meeting 16:30:42 Meeting started Wed Jan 30 16:30:41 2019 UTC. 16:30:42 This meeting is logged and archived in a public location. 16:30:42 The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:42 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:42 The meeting name has been set to 'fedora_coreos_meeting' 16:30:49 #topic roll call 16:31:15 .hello sinnykumari 16:31:16 ksinny: sinnykumari 'Sinny Kumari' 16:31:17 .hello2 16:31:19 .hello2 16:31:19 slowrie: slowrie 'Stephen Lowrie' 16:31:22 bgilbert: bgilbert 'Benjamin Gilbert' 16:31:46 .hello2 16:31:47 jlebon: jlebon 'None' 16:32:15 .hello2 16:32:16 rfairley: rfairley 'None' 16:32:16 .hello2 16:32:19 walters: walters 'Colin Walters' 16:32:26 welcome back from devconf to all that went! 16:32:33 #chair ksinny slowrie bgilbert jlebon rfairley walters 16:32:33 Current chairs: bgilbert dustymabe jlebon ksinny rfairley slowrie walters 16:32:42 (I'll actually be here today as my usual Tae Kwon Do class was cancelled) 16:32:47 .hello2 16:32:48 dbenoit: dbenoit 'David Benoit' 16:32:51 .hello2 16:32:53 yzhang: yzhang 'Yu Qi Zhang' 16:34:06 .hello mnguyen 16:34:07 mnguyen_: mnguyen 'Michael Nguyen' 16:34:42 #chair yzhang mnguyen_ 16:34:42 Current chairs: bgilbert dustymabe jlebon ksinny mnguyen_ rfairley slowrie walters yzhang 16:34:54 walters: because of the crazy cold temperature? 16:35:04 geoff-: 'Geoff Levand' 16:35:13 #chair geoff- 16:35:13 Current chairs: bgilbert dustymabe geoff- jlebon ksinny mnguyen_ rfairley slowrie walters yzhang 16:35:19 nah, unrelated; the polar vortex isn't directly in the boston area 16:35:28 +1 16:35:45 i think lorbus[m] is sick - and andrew is AFK 16:36:00 let's check out AI from last meeting 16:36:06 #topic Action items from last meeting 16:36:25 and there were none :) 16:36:28 https://meetbot-raw.fedoraproject.org/teams/fedora_coreos_meeting/fedora_coreos_meeting.2019-01-23-16.29.txt 16:36:42 #info no action items from last meeting 16:36:47 \o/ 16:37:04 will move into meeting tickets :) 16:37:40 #topic Consider disabling SSH password login by default 16:37:47 #link https://github.com/coreos/fedora-coreos-tracker/issues/138 16:38:02 opened by bgilbert 16:38:31 right. the proposal is to set `PasswordAuthentication no` `PermitRootLogin prohibit-password` in sshd by default. 16:38:48 Fedora CoreOS will ship without passwords, of course 16:39:00 and passwords can be set via an Ignition config 16:39:06 but even if that is done, there are two possible uses: 16:39:16 1. logging in on console, which can _only_ be done via passwords 16:39:28 and 2. logging in over sshd. 16:39:45 the idea is that setting a password would allow 1 by default, while not allowing 2 unless the user took additional steps to enable it. 16:40:25 .hello2 lucab 16:40:26 kaeso: Sorry, but you don't exist 16:40:28 because in 2019 I don't think we should be encouraging passwords for network access, even in protected environments. but I wanted to bring it up here and ask if anyone had use cases to the contrary 16:40:33 .hello lucab 16:40:34 kaeso: lucab 'Luca Bruno' 16:40:43 bgilbert: so if I set a root password I can only log in on the console of the machine 16:40:52 note that this is just about changing the default 16:40:55 bgilbert: if I set a user password I could log in on console or sshd 16:41:02 dustymabe: right, or via 'su' 16:41:05 +1` 16:41:23 dustymabe: if you set a user password, by default you could only log in on console 16:41:45 dustymabe: if we wanted to make that distinction by default, we'd only set `PermitRootLogin` and not `PasswordAuthentication` 16:42:09 oh i see 16:42:10 yes 16:42:45 there's also a technical complication, which is that sshd doesn't support config directories, so changing the sshd config would currently require rewriting it from scratch, or some awkward workarounds 16:42:57 see the ticket for details 16:43:24 anyone opposed to this proposal? 16:43:32 but as it stands there are some awkward tradeoffs around how users would change the default. 16:44:00 for now I'm mostly curious whether the different default would be horrible for anybody 16:44:30 I can't think of any "password on SSH" I have ever seen on CL/tectonic, and I think disabling by default makes sense 16:44:47 is this a Fedora default, or an upstream default? 16:45:05 side question: does anyone know an sshd maintainer we could ask to help on the RFE? 16:45:23 jlebon: the current one, or the proposed one? 16:45:26 dustymabe: upstream or fedora? 16:45:33 kaeso: upstream 16:45:50 bgilbert: the current one. /me is checking 16:45:59 jlebon: I think upstream, but yeah, check me 16:46:40 kaeso: for the RFE, i think it would be best if we didn't carry a patch in fedora for that, so obviously if we could get it upstream that would be ideal 16:47:13 (to be clear, the RFE is for sshd to support config directories) 16:47:14 bgilbert: yeah, seems like it: https://github.com/openssh/openssh-portable/blob/master/sshd_config#L57 16:47:16 then we could backport it to fedora, until the new version hit fedora 16:47:42 jlebon: oh, but https://github.com/openssh/openssh-portable/blob/master/sshd_config#L32 16:49:12 https://src.fedoraproject.org/rpms/openssh/blob/master/f/openssh-6.9p1-permit-root-login.patch 16:49:29 so the defaults are `PasswordAuthentication yes` and `PermitRootLogin prohibit-password` 16:49:37 according to the sshd_config man page 16:49:54 hmm, that Fedora patch should probably also modify the man page :) 16:50:09 oh. /me clicks on the link jlebon just posted 16:50:19 dustymabe: upstream openssh-portable is a single guy pretty much 16:50:44 which one? 16:50:48 Damien? 16:51:08 jlebon: the man page is still right though. 16:51:14 fedora is changing the config, not the default 16:51:40 one thing we could do is see if Fedora would be willing to change it 16:51:48 though that would probably need to be filed as a "change" 16:52:17 https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no 16:53:23 #link https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no 16:53:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=89216 16:53:37 #link https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html 16:53:40 I haven't read through those yet 16:53:44 but the change was rejected 16:53:44 dustymabe: yes, him 16:54:06 bgilbert: I see 16:54:15 anywho let's circle back 16:54:38 is anyone opposed to making these changes and having them be the default for FCOS? 16:54:41 change proposal deadline for F30 has already crossed(29th January) 16:54:52 ksinny: yeah I noticed that 16:54:57 (I just discovered that history, to be clear) 16:55:31 dustymabe: yeah, true 16:55:46 IMO we should ship the defaults we want to see in the world, and make them less restrictive later if need be 16:56:02 subject to anything significant in those earlier discussions 16:56:09 the proposal itself SGTM. having to work around the limitations of the config file is unfortunate 16:56:49 walters: ksinny geoff- slowrie 16:56:54 any opposed? 16:57:05 no strong opinion on this 16:57:45 +1 to get this in 16:58:01 +1 16:58:08 I think there are two action items here 16:58:14 1. make the change to the config 16:58:23 2. add docs for a user how to change the default 16:58:41 I think its fine to not allow it 16:58:43 bgilbert: can you add a summary of this discussion and any new work that would need to be done to the ticketr ? 16:59:14 bgilbert: does the -o take precedence over the config file entry? 16:59:19 kaeso: yes 16:59:35 #action bgilbert to update the ticket with discussion summary, PR the design doc, and file tickets for needed work 16:59:42 +1 16:59:48 #topic Bare Metal Installer: Attempt to build media based on current strategy 17:00:07 #link https://github.com/coreos/fedora-coreos-tracker/issues/91 17:00:10 bgilbert: nice, so we could just ship a dropin replacement for exec-start without touching fedora rpm right? 17:00:26 I've been doing some investigation on this topic 17:00:56 was able to take neil's dracut module installer POC and bake it into an FCOS image (normal coreos-assembler build) 17:01:13 and then extract the kernel/initrd and make an ISO image and use that for install 17:01:26 starting small here - my next steps are 17:01:36 get the dracut module into FCOS 17:01:38 add a coreos-assembler command to generate an ISO image 17:01:59 kaeso: yes, though rewriting ExecStart has always felt brittle to me. will think on it some more. 17:02:01 then incrementally add PXE support 17:02:20 dustymabe: nice! 17:02:54 any thoughts on the proposal to start with getting the dracut module in and adding a command in coreos-assembler to create the ISO for us 17:02:56 dustymabe: did you use lorax to create iso? 17:03:05 ksinny: no - genisoimage 17:03:11 dustymabe: ah ok 17:03:30 bgilbert: indeed 17:03:31 ksinny: we are using the initrd and kernel from FCOS so no need to create a new one 17:03:42 +1 17:04:23 dustymabe: what is the installer using as the input parameter to dd? 17:05:30 kaeso: I modified it to just download a gz file and then zcat | dd 17:05:54 so it would be a raw.gz 17:05:58 I also did some work related to this in https://github.com/coreos/coreos-assembler/pull/302 17:06:06 but honestly this is just a work in progress that we can improve on 17:06:18 dustymabe: we're doing signature checking I hope 17:06:22 ? 17:06:40 ...just as soon as we start signing builds 17:06:49 bgilbert: that's the key 17:06:50 :) 17:07:06 we should probably start signing with a scratch key ASAP 17:07:17 good pun! 17:07:32 haha 17:07:48 dustymabe: I think the very first step would be to have coreos-assembler producing that raw image 17:09:08 kaeso: yeah or other 17:09:18 does bare-metal needs to have its own platform ID too? 17:09:32 these steps will mostly just set us up to incrementally improve 17:09:57 kaeso: I'm in favor. the CL approach of oem_id="" is weird 17:10:58 good point about oem_id 17:11:06 should we open that as a topic to discuss 17:11:11 and of course - bikeshed :) 17:11:19 One thing on this is that doing the dual efi/bios thing is going to require some nontrivial ostree and grub work 17:11:22 dustymabe: nah :-) 17:11:32 which is work I'd like to do but I think tactically we should go split for now 17:12:07 walters: to fix before the initial FCOS release, or after? 17:12:15 right. I'm separating this work from the dual BIOS/EFI work 17:12:32 bgilbert: fix = switch to dual? 17:12:36 right 17:12:37 right now MVP for me is BIOS bare metal install 17:13:02 mmm...I think MVP is having both BIOS and UEFI for metal 17:13:21 dustymabe: yes please, a github ticket, because I don't know right now if that has further implications 17:13:35 kaeso: wfm 17:13:48 #action kaeso to open a FCOS tracker issue to discuss if we should have an oem-id for bare metal 17:14:00 walters: asking because in CL we proliferated images and there was no good way to get rid of them 17:14:00 walters: maybe MVP is the wrong term 17:14:16 walters: so I'm hesitant to go too far down the road of split images 17:14:37 yeah, if we have dual uefi/bios and dual 512/4k sector that'll be 4 for metal, although I would guess that not many people have 4k drives and BIOS 17:15:15 and actually I'd favor leaving boot-from-4Kn unsupported rather than having a separate image for it 17:15:25 ok, reasonable 17:15:33 short term anyways 17:15:35 bgilbert: (same here) 17:15:40 next topic? 17:15:43 the way I'm thinking about this though the installer should detect the system state and parse the metadata 17:15:55 so if we later go dual that should be transparent 17:16:35 if we have dual we could also just symlink them on the server side too 17:16:39 walters: well, kinda. but IMO the installer is a convenience, and not a required thing 17:16:47 people can and will write their own fetch+dd scripts 17:17:38 * dustymabe looks at clock 17:17:41 moves on to next topic 17:17:43 we're getting off in the weeds some, but at some point I'd like to discuss how hard dual support actually is. CL does it :-) 17:17:46 +1 to moving on 17:17:52 #topic enhance ostree mirroring for better UX 17:17:58 https://github.com/coreos/fedora-coreos-tracker/issues/54 17:18:17 i believe there were some discussions at devconf 17:18:56 We have new cloudfront set-up for our existing ostree repo with porposed uer config mentioned at https://github.com/coreos/fedora-coreos-tracker/issues/54#issuecomment-458979768 17:19:20 This worked wel for jlebon and me (tetsing result I knew so far) 17:19:44 WFM too 17:19:52 can confirm, been using it for last few upgrades now 17:19:55 +1 17:20:06 first would like to know does this config looks to be shipped to users? 17:20:21 thanks walters 17:20:32 #info for those interested please test out the config in https://github.com/coreos/fedora-coreos-tracker/issues/54#issuecomment-458979768 on their ostree based systems 17:21:12 ksinny: just one minor edit 17:21:23 sinny - can we coordinate with releng/infra and make this config change as well as removing atomic from our URLs (https://github.com/coreos/fedora-coreos-tracker/issues/127) in the next week or two? 17:21:29 should we change gpgkeypath to just "/etc/pki/rpm-gpg" 17:22:03 this'll make upgrades easier, given that FCOS is single stream 17:22:07 dustymabe: yes, that's the plan 17:22:18 jlebon: we should but let's just make that change in the new configs we ship out in new media 17:22:33 jlebon: and as you suggest, let's deliver configs via rpms in the future 17:22:37 jlebon: we can, but I haven't tested it so far 17:22:47 ksinny: I tested it with latest rpm-ostree 17:22:50 dustymabe: if we're shipping code to edit user configs, we might as well do both mods at once, right? 17:23:10 jlebon: assuming that they have the latest rpm-ostree before they change their config 17:23:12 yes 17:23:46 I am not opposed to ship both changes if it is known to work (I will give it a go tomorrow with new gpg path) 17:24:21 cool 17:24:29 jlebon: one thing we could do is ship the rpm first and then have people rebase to the remote in the config provided by the rpm 17:24:48 then they'll be set forever TM 17:25:02 Regarding shipping user config, do we want to create a new rpm or can we make use of fedora-release package? 17:25:12 walters: ^^ 17:25:19 what ships the yum repos? 17:25:33 fedora-repos 17:25:43 i'm cool with not creating a new rpm if we can get the maintainer to accept the change 17:25:58 does it seem logical to add to an existing package? 17:26:52 also does ostree support multiple places for configs ? 17:27:00 I think I tried that before and stumbled a bit over the fact that it'd require ostree for RPM file ownership to drop a file in /etc/ostree/remotes.d 17:27:02 i.e. does one in etc override ones elsewhere ? 17:27:19 no, not today, though that'd certainly be a nice feature 17:27:39 yeah, that sounds cool 17:27:50 (bigger picture of course, ostree itself brings into existence /usr/etc which means one always has the /usr part that systemd implements, although it's a bit more crude) 17:27:53 walters: regarding file ownership - should we hoist that into a setup or filesystem rpm ? 17:28:06 also addresses my concern of suddenly shipping a file which could already be existing if the user's remote happens to have the same name 17:28:30 the sad thing is RPM file ownership only matters for cleaning up directories when packages are uninstalled which...well nevermind 17:28:44 :) 17:29:17 #action sinny to open a ticket where we discuss adding ostree configs to an rpm rather than having them be an unmanaged file on the system 17:29:17 too many ifs 17:29:29 so, what would be recommended way for now? 17:29:36 seems worth trying to add to fedora-repos even if it's a new fedora-repos-ostree subpackage 17:29:57 * dustymabe looks at time 17:30:05 walters: +1, I will look at it 17:30:11 cool 17:30:13 #topic roadmap 17:30:28 so not much time so this will have to go quick 17:31:05 #info dustymabe updated the roadmap: https://github.com/coreos/fedora-coreos-tracker/blob/master/ROADMAP.md 17:31:06 https://bugzilla.redhat.com/show_bug.cgi?id=1393545 17:31:19 we talked already about a few things like bare metal 17:31:44 i reached out to fedora releng to see if we could meet later this week to discuss some of our tickets we have that involve them 17:31:55 sinny is working with upstreams on pythong dependencies 17:32:25 we got positive feedback one some of python dependencies to split into sub-package 17:32:26 not sure if yzhang has had a chance to look at merging toolbox with fedora-toolbox (that's low priority, but have noticed fedora-toolbox gaining some traction) 17:32:51 bgilbert: is working with mattdm on metrics strategy 17:33:25 any comments on any of these before we open floor (for like 60 seconds) and then close? 17:34:10 #topic open floor 17:34:15 any comments for open floor? 17:35:26 thanks to everyone who gave a talk or had a conversation with someone at devconf about CoreOS (or broader OSTree) based systems 17:35:38 nice work all! saw a lot of twitter activity 17:35:53 will be good to have the recordings posted and reference those 17:35:55 dustymabe: we missed you at Devconf 17:36:00 agreed! 17:36:17 maybe I'll be at flock in budapest! 17:36:19 agreed also 17:36:31 if I come I'll make bgilbert come too 17:36:33 dustymabe: yeah! 17:36:37 :-D 17:36:44 yup 17:36:46 thanks everyone for staying a bit late! 17:36:53 #endmeeting