14:01:21 <otaylor> #startmeeting Workstation WG
14:01:21 <zodbot> Meeting started Mon Nov  5 14:01:21 2018 UTC.
14:01:21 <zodbot> This meeting is logged and archived in a public location.
14:01:21 <zodbot> The chair is otaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:21 <zodbot> The meeting name has been set to 'workstation_wg'
14:01:27 <otaylor> #meetingname workstation
14:01:27 <zodbot> The meeting name has been set to 'workstation'
14:01:34 <otaylor> #topic Roll call
14:01:41 <otaylor> .hello otaylor
14:01:42 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
14:01:58 <otaylor> Let's see how many people figured out the time change
14:02:02 <bcotton> .hello2
14:02:03 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
14:02:12 <juhp> .hello petersen
14:02:13 <zodbot> juhp: petersen 'Jens Petersen' <petersen@redhat.com>
14:02:24 <ryanlerch> .hello ryanlerch
14:02:25 <zodbot> ryanlerch: ryanlerch 'Ryan Lerch' <rlerch@redhat.com>
14:02:55 <otaylor> #chair otaylor juhp ryanlerch
14:02:55 <zodbot> Current chairs: juhp otaylor ryanlerch
14:03:07 <ryanlerch> otaylor: i did! :(
14:03:34 <cschalle> ./hello
14:03:39 <mcatanzaro> .hello catanzaro
14:03:40 <cschalle> .hello
14:03:40 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org>
14:03:43 <zodbot> cschalle: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
14:04:21 <otaylor> #chair otaylor juhp ryanlerch cschalle mcatanzaro
14:04:21 <zodbot> Current chairs: cschalle juhp mcatanzaro otaylor ryanlerch
14:04:46 <otaylor> ryanlerch: gets further into the wee hours for you and juhp I guess  :-(
14:05:12 <juhp> Yeah, only 11pm for me
14:05:25 <ryanlerch> yeah, had a bit of a nap! luckily my alarm went off :D
14:05:49 <ryanlerch> juhp: jealous!
14:05:59 <ryanlerch> i'm already into tomorrow now
14:07:13 <otaylor> OK, pfrields sent his regrets, mclasen and kalev and rdieter are not obviously around to ping, guess we might as well get started
14:07:28 <otaylor> As long as we vote unanimously we can make decisions...
14:08:13 <ryanlerch> sounds good!
14:08:19 <otaylor> Anybody have any topics they want to start with before we start going through tickets?
14:08:54 <otaylor> It's on to F30 today! (well, plus any wrap-up for F29)
14:09:43 <otaylor> Quick status on Flatpaks: I see no reason we shouldn't have a production repository this week for users to install from
14:10:16 <juhp> Great
14:10:48 <otaylor> #topic LUKS by default  - https://pagure.io/fedora-workstation/issue/82
14:11:06 <otaylor> mcatanzaro: Want to introduce that?
14:11:59 <mcatanzaro> Sorry
14:12:05 <mcatanzaro> Um, straightforward enough
14:12:11 <mcatanzaro> Everything should be encrypted, the end :)
14:12:31 <otaylor> mcatanzaro: what's the current interface for enabling it - do you have to go into custom partitioning, or is there a checkbox?
14:12:31 <mcatanzaro> In the past we decided not to do this because we were waiting for halfline to figure out how to use the LUKS password to unlock gnome-keyring
14:12:46 <mcatanzaro> otaylor: There's just a checkbox in the installer, it works with automatic partitioning. Couldn't be easier TBH.
14:13:07 <otaylor> mcatanzaro: so it's just switching the default for that check? You have to uncheck it to proceed without a password?
14:13:20 <mcatanzaro> Yup, that's the proposal
14:14:00 <mcatanzaro> The problems are (a) it's still separate from your user account password unless you enable autologin, and autologin is broken because it still doesn't unlock the login keyring. And (b) because it's annoying and weird to need to type your encryption password twice when rebooting to install updates (or once when shutting down to install updates). I d
14:14:00 <mcatanzaro> on't think anybody ever tried to fix (b) but somebody had ideas (sgallagh?)
14:14:24 * sgallagh reads scrollback
14:14:29 <mcatanzaro> Anyway my proposal is to forget about those and just check the checkbox by default, because unencrypted workstations/laptops are no longer acceptable in 20`8.
14:14:33 <mcatanzaro> *2018
14:14:46 <mcatanzaro> But if anyone wants to fix (a) or (b) too, that'd be great
14:14:54 <otaylor> mcatanzaro: I agree, I think those are separate issues/improvements
14:14:54 <ryanlerch> yeah i'm +1 on this
14:14:59 <mcatanzaro> halfline had something working for (a) I had thought, but it's definitely broken in F29
14:15:04 <aday> it would be good to have relevant issues listed in the ticket
14:15:13 <otaylor> proposed: check the encryption checkbox in anaconda by default
14:15:15 <otaylor> +1
14:15:30 <sgallagh> mcatanzaro: Right, once upon a time I had patches to allow PackageKit to `systemctl isolate system-update.target` instead of rebooting to perform the update.
14:15:39 <ryanlerch> not sure if it makes it clear what the password is for in anaconda if it is pressed by default thought
14:15:53 <sgallagh> They're super out-of-date and don't apply cleanly anymore, but I could probably try to resurrect them.
14:16:08 <ryanlerch> like it may make senese after you have chosen encryption
14:16:18 <juhp> I before having separate passwords anyway
14:16:19 <sgallagh> Mostly they were criticized because not rebooting means not being guaranteed of the mount table state
14:16:53 <ryanlerch> but by making it default, we will need to check if whe encryption password asky thing expkains what is going on
14:17:15 <ryanlerch> but that is implementation detail.
14:17:24 <ryanlerch> +1 to the proposal from me
14:17:36 <otaylor> ryanlerch: Yeah, there needs to be a runthrough of the experience and issues filed and linked ot the ticket
14:17:36 <aday> ryanlerch, but one that we shouldn't forget about...
14:17:44 <aday> i'd hate for us to enable this and not do the necessary follow up
14:18:10 <otaylor> cschalle / juhp : ? (assume mcantazaro is +1)
14:18:36 <mcatanzaro> sgallagh: Why could the mount table be messed up? I don't think updates have to work if the user has decided to unmount important filesystems?
14:18:42 <cschalle> isn't aruiz and his team also looking at this? (trying to 'fix' single sign on with the LUKS unlocking?)
14:18:50 <juhp> I am +1 (only priviso being don't really need encryption if running in a VM)
14:19:24 <sgallagh> mcatanzaro: My thoughts exactly, but the intention of offline updates is apparently to be super-paranoid
14:19:25 * sgallagh shrugs
14:19:39 <cschalle> I am not against, I would just prefer us to switch with a proper fix
14:19:50 <otaylor> cschalle: it's certainly related - having an *effectively* passwordless encyption experience
14:19:51 <juhp> But better to default to encrypted I suppose unless there is a way to detect that
14:20:23 <sgallagh> juhp: systemd has ConditionVirtualization, so it must be detectable
14:20:30 <juhp> aha
14:20:35 <otaylor> cschalle: I'm thinking you'd still have an ecypted password as well - since otherwise motherboard dead => data lost
14:21:25 <sgallagh> otaylor: clevis/tang ?
14:21:49 <otaylor> #agreed check the encryption checkbox in anaconda by default (+5; 0; 0)
14:22:06 <otaylor> #action otaylor to summarize follow-up items and discussion into the issue
14:22:46 <otaylor> sgallagh: that's for network escrow, right?
14:23:26 <sgallagh> otaylor: Yes
14:23:32 <sgallagh> Well, not escrow exactly
14:24:06 <sgallagh> It's not meant to be a retrievable key; it's just meant to ensure that if the disk is being read from some other network, they can't get the key.
14:24:35 <sgallagh> I think the preferred term is NBD: network-bound encryption
14:25:09 <mcatanzaro> So what's the procedure for talking to anaconda maintainers about this?
14:25:16 <otaylor> sgallagh: there's a ton of enterprisey complexity here that should be enabled at the kickstart level at least, but not in the default flow
14:25:27 <mcatanzaro> Bug report somewhere?
14:25:38 <otaylor> mcatanzaro: I think the first step is review and screenshots and make sure we know what we are asking for
14:25:55 <mcatanzaro> Just check the checkbox. ;)
14:26:18 <otaylor> mcatanzaro: Right now, password is a separate screen? or on the same screen?
14:26:49 <otaylor> mcatanzaro: But basically, once we know what we want, we should file a bug/issue against anaconda and follow up with the maintainers
14:27:16 <otaylor> htere's also the VM question that juhp raised, and also if we want this to be a workstation-only thing, or we think it applies across all editions
14:27:25 <otaylor> (probably not!)
14:27:53 <otaylor> #topic Default disk partitioning layout for Workstation - https://pagure.io/fedora-workstation/issue/54
14:28:15 <otaylor> Let's jump to this related issue
14:28:37 <mcatanzaro> otaylor: Password is a separate screen that pops up only if you check the checkbox
14:28:43 <otaylor> There's basically two proposals in there a) no lvm by default and b) unified /root and /home by default
14:29:10 <otaylor> mcatanzaro: I think you'd probably not want that if you checked the checkbox by default  - would be better to have them unified
14:29:26 <otaylor> (either enter a password or uncheck the checkbox to proceed)
14:30:43 <aday> as a side note, i had a really tough time converting an existing install to efi recently, mostly as a result of missing docs
14:31:02 <otaylor> to me, the alternative to going super-simple with partitioning is enable the desktop for https://fedoraproject.org/wiki/Changes/StratisStorage
14:31:28 <aday> a partitioning tutorial would be a big help
14:31:58 <otaylor> aday: Hmm, yeah, I think that falls into the category of things that we don't think users need to do, but probably need to do sometimes anyways :-(
14:32:16 <juhp> I remember having trouble setting up non-LVM + combined /root+/home on this laptop
14:32:24 <aday> otaylor, yeah. just finding out which partitions i needed was really hard
14:32:47 <juhp> It seemed surprisingly hard/confusing
14:33:06 <otaylor> aday: What was your motiviation - getting newer boot features?
14:34:18 <otaylor> juhp: it's certainly not something I'd expect am inexperienced user to be able to do without step-by-step instructions - we have to assume that the default partioning is the only accessible partioning for 95%+ of users
14:34:23 <mcatanzaro> Why would anyone ever need to convert an existing install that is working fine to EFI?
14:34:39 <mcatanzaro> Surely that is not intended to be, er, user-serviceable... you have to be an expert
14:35:34 <bcotton> mcatanzaro: moving a hard drive to a new system, maybe?
14:36:06 <mcatanzaro> otaylor: BTW I recently discovered that when installing Workstation on an actual workstation-class machine with 64 GB of RAM, the automatic partitioning created 32 GB of swap space... so I had to use the manual partitioning to avoid that. We probably need a more reasonable cap on the amount of swap that gets created.
14:36:16 <juhp> otaylor: yeah not sure of anaconda storage has improved/changed since then (f25?)
14:36:18 <juhp> if
14:36:20 <mcatanzaro> bcotton: Oh, that would be quite hard indeed if it needs to switch to EFI :(
14:36:21 <otaylor> Does anybody want to lay out a case for keeping the current LVM+separate-/ and /home ?
14:37:27 <otaylor> juhp: there was a major change to the UI at some point, but I'd guess a bit before f25 - but I don't think it got much easier (or harder) for the stuff I need to do. My feeling about it before and after was "mildly confusing" - but probably that's just inherent to the task of partitioning!
14:37:43 <juhp> okay
14:38:46 <juhp> I am +1 to both - I think it should be the default for Workstation
14:39:40 <mcatanzaro> Reading the comments in the issue, two comments seem relevant: https://pagure.io/fedora-workstation/issue/54#comment-528086 and https://pagure.io/fedora-workstation/issue/54#comment-531756
14:39:53 <mcatanzaro> Looks like the main concern about getting rid of LVM is docker? (I don't know anything about this.)
14:40:46 <otaylor> I think we've changed the default for docker not to use thinp for storage?
14:42:51 <otaylor> Anybody have a fairly vanilla install that they want to do 'docker info | grep Storage'
14:43:40 <otaylor> (Also, we're moving away from docker to podman/storaged)
14:44:17 <otaylor> (and the default there is to store thing in /var/lib/containers)
14:45:00 <juhp> Yeah I feel docker is less of an argument now
14:45:46 <mcatanzaro> I suppose I'm +1 to both changes
14:45:48 <otaylor> Proposed: For F30, change the default partitioning for workstation to no LVM, unified / (separate /boot, swap)
14:45:57 <aday> otaylor, sorry, had to step away... lvfs didn't work with non-efi, and i needed a bios update
14:46:51 <mcatanzaro> I guess getting rid of LVM seems more obviously beneficial to me than getting rid of separate /home, what was the justification for that? 50 GB not enough for flatpak runtimes?
14:46:59 <mcatanzaro> And libvirt VMs?
14:47:00 <otaylor> aday: ah, OK. I think it's sort of inherently hard :-(
14:47:28 <aday> otaylor, but a guide to manual partitioning with fedora and efi seems a useful thing
14:47:59 <juhp> mcatanzaro: on smaller disks I find it very hard to predict how to partition root and home accurately
14:48:04 <otaylor> mcatanzaro: To me, the justification is that predicting the right split is really outside of what a user could do ... and if you get it wrong, it's *really* hard to fix.
14:48:12 <juhp> indeed
14:48:23 <aday> top google result for "fedora partitioning efi" is currently https://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s2-diskpartrecommend-x86.html - fedora 18!!!
14:48:51 <aday> top google result for "ubuntu partitioning efi" - https://help.ubuntu.com/community/UEFI
14:50:04 <aday> oh, ha, that last one was last edited 2015. ok i'll shut up now
14:50:08 <otaylor> aday: I think if you were set up wrong it could be virtually impossible - if you had /boot and a big LVM partition and didn't have enough space to rejigger the /boot partition, then it becomes super hard
14:50:48 <otaylor> aday: But I haven't done it recently (or at all) so I forget the details
14:51:10 <otaylor> OK, let's vote and see if we have a clear consensus
14:51:27 <otaylor> I'm +1 for the changes, as is juhp and mcantazaro
14:51:45 <otaylor> cschalle ryanlerch ?
14:51:53 <cschalle> +1
14:52:51 * otaylor wonders if ryanlerch fell back to sleep ;-)
14:52:55 <ryanlerch> +1
14:53:13 <otaylor> #agreed For F30, change the default partitioning for workstation to no LVM, unified / (separate /boot, swap) (+5; 0; 0)
14:53:34 <otaylor> OK, are there any tickets or other items that people think we need to get through in the next 7 minutes?
14:54:28 <otaylor> https://pagure.io/fedora-workstation/issue/78 - What's new in F29 Workstation article for Fedora Magazine  - is still sitting around staring at us, but if nobody is volunteering to write it (I'm not!) then we'll have to do without.
14:54:52 <juhp> Wasn't it already published? :)
14:55:26 <juhp> https://fedoramagazine.org/whats-new-fedora-29-workstation/
14:55:30 <otaylor> Oh, great!
14:55:40 * otaylor thanks pfrields !
14:55:48 <juhp> Thanks to stickster (et al) yep!
14:55:53 <juhp> stickster++
14:55:53 <zodbot> juhp: Karma for pfrields changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:55:54 <cschalle> +1
14:57:50 <otaylor> OK, last call for quick items before I end the meeting
14:58:10 <otaylor> Thanks everybody!
14:58:12 <otaylor> #endmeeting