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