Date: Thu, 10 Oct 2013 04:04:15 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Allan Jude <freebsd@allanjude.com> Cc: Devin Teske <dteske@freebsd.org>, "<freebsd-current@freebsd.org>" <freebsd-current@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com> Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Message-ID: <13CA24D6AB415D428143D44749F57D720FC4DCD1@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <52561AD6.9070807@allanjude.com> References: <52531295.7090700@allanjude.com> <5254D231.5070803@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC4B3F2@LTCFISWMSGMB21.FNFIS.com> <525596A7.2090701@allanjude.com> <13CA24D6AB415D428143D44749F57D720FC4B907@LTCFISWMSGMB21.FNFIS.com> <52561AD6.9070807@allanjude.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 9, 2013, at 8:11 PM, Allan Jude wrote: > On 2013-10-09 14:14, Teske, Devin wrote: >> On Oct 9, 2013, at 10:47 AM, Allan Jude wrote: >>=20 >>> On 2013-10-09 13:21, Teske, Devin wrote: >>>> On Oct 8, 2013, at 8:49 PM, Allan Jude wrote: >>>>=20 >>>>> On 2013-10-07 15:59, Allan Jude wrote: >>>>>> Devin Teske and I have been working on a big patch to bsdinstall to >>>>>> implement installing on a ZFS pool. It supports both GPT and MBR, th= e 4k >>>>>> sector gnop trick, and optional GELI encryption. We would like to co= mmit >>>>>> this in time for 10.0-BETA1 so it needs some testing to work out any >>>>>> obvious bugs before we send it off to re@ to get it committed. >>>>>>=20 >>>>>> It includes a single configuration menu that allows you to select al= l of >>>>>> the required details, including which drives to use (gets details fr= om >>>>>> camcontrol, also includes an inspection utility that presents the >>>>>> detailed output of camcontrol inquiry/identify, and gpart show), what >>>>>> ZFS RAID level to use (taking in to consideration the selected numbe= r of >>>>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. >>>>>>=20 >>>>>>=20 >>>>>> Additional, it includes some other changes to bsdinstall: >>>>>> 1. Change the default to the 'non-standard keyboard mapping' prompt = to no >>>>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with = just 1 >>>>>> 3. Remove the dialog asking if you wish to enable crash dumps, this >>>>>> feature has been combined into the regular 'services to enable' dial= og >>>>>> and enabled by default >>>>>>=20 >>>>>>=20 >>>>>> You can browse the patches here: >>>>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ >>>>>>=20 >>>>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, >>>>>> available compressed (48 MB) or uncompressed (211 MB): >>>>>>=20 >>>>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz >>>>>>=20 >>>>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso >>>>>>=20 >>>>>>=20 >>>>>> We look forward to your feedback >>>>>>=20 >>>>> We've made more improvements, including corporating most all of the >>>>> feedback we've gotten so far >>>>>=20 >>>>>=20 >>>>> Outstanding items: >>>>> 1. Apply the changes to ipv6 config the way we did ipv4 >>>>> 2. improve disk identification (model info and serial # instead of one >>>>> or the other) >>>>> 3. Include a helpful message before the GELI step where you have to >>>>> enter your password many times, the user will be less confused if it = is >>>>> explained why they have to enter their password 3 * number of disks t= imes >>>> I'm hopeful that we can script the application of a password that we >>>> first prompt for. >>>>=20 >>>> What tool is prompting for a password? Can we not just provide an answ= er >>>> on stdin? (e.g., echo "$pass" | tool_that_needs_pass) >>>>=20 >>> It is 'geli create' and 'geli attach'. I am not sure if we want to have >>> the password show up in the process list (obviously in the installer >>> this is less of an issue, but) >>>=20 >> It won't. >>=20 >> echo is a shell built-in. >>=20 >> If we're uber paranoid... we prefix the word "builtin"; e.g.,... >>=20 >> builtin echo "$pass" | tool_that_needs_pass >>=20 >> You'll see the tool in ps, but you won't see the echo (that's part of the >> shell invocation -- all you see in ps is an instance of sh). >>=20 > I have implemented this, 'geli init' takes the -J <file> flag, which can > be set to - to mean stdin. 'geli attach' is the same except the flag is -j >=20 > I first prompt for the password with a dialog --passwordbox, so the user > only has to enter it once >=20 > Do we think it makes sense to prompt the user twice, and confirm the two > entered passphrases are the same? >=20 I think so. I'm afraid someone could make a typo and then not be able to log into their system because the password that was actually used is different than what the user thinks it is. >=20 >>=20 >>>>> 4. Validate vdev type choice inside the vdev type menu, and warn the >>>>> user if they have made an invalid selection, so they can add more dis= ks >>>>> or chance their selection, without having to try to start the >>>>> installation first >>>> This will be done with fanciness ;D (read: ... --and-widget --infobox = ... and >>>> sundry smartness; retaining as much as possible the ability to do thin= gs >>>> out of order but never arise at a point of astonishment). >>>>=20 >>> I don't think we need --and-widget, just in the function where we apply >>> the results of the menu selection, >> The purpose of --and-widget with an --infobox is to let the user know th= at >> validation is occurring each/every time they make a selection. >>=20 >> Seeing the infobox before being returned to the previous menu (in the ca= se >> of selecting a valid vdev_type) is to cement in the mind of the user tha= t their >> selection was validated. Of course, in the case of an invalid selection,= they >> get a message box. What the message box says depends on: >>=20 >> 1. Are they trying to select a vdev_type for which they don't have enough >> devices? Tell them that they don't have enough devices, and bring them >> back to the vdev_type menu (to select a different [valid] vdev type *or* >> cancel and go back to the ZFS menu where they can optionally Rescan >> for more devices -- allowing that vdev_type to be selected without issue= ). >> In the prompt that tells them that they don't have enough disks in their >> system to select that vdev_type, we sould hint that they can choose canc= el >> and go back to use the "Rescan" option to scan for more devices. >>=20 >> 2. Are they trying to select a vdev_type for which they have enough devi= ces >> but have not yet made enough selections? Drop them back to the ZFS menu >> so they can go select the appropriate number of devices. >>=20 >> Good? >>=20 >=20 > I kind of shortened it a bit. When you make a selection in the vdev > submenu, if your selection is invalid you get a --yesno box explaining > that 'type <blah> requires <X> disks'. And are prompted to either > 'choose again' (back to the vdev menu) or 'return to the zfs menu' (to > select more disks) >=20 Nice. >>> we can add a regular --msgbox telling >>> them that their config won't work, and they need to either select more >>> drives or a different vdev type >>>=20 >> I agree on the msgbox -- and I still think the temporaneous infobox >> injected via --and-widget would be value-add. >>=20 >> Question is what to do after the msgbox. >>=20 >> I posit that if the vdev_type is valid but they don't have enough disks >> currently selected, that they be tossed back at the ZFS menu. However, >> if they instead select a vdev_type which couldn't possible be satisfied >> given the number of devices available to the hardware... keep them >> in the vdev_type menu.=20 >>=20 >>=20 >>>>> 5. Whatever else you guys find wrong tonight >>>>>=20 >>>>> I generated new test images, and attached the patch (which got REALLY >>>>> big when Devin Teske decided to fix "all of the things": >>>>>=20 >>>> And then I merged "all of the things" into HEAD, so the patch-set shru= nk >>>> back to its normal size. Now we have global exit codes which will make >>>> merging of code that is based off of Thomas Dickey's samples easier. >>> I am glad to see all of the good ideas, and plans to make everything >>> wonderful, but my biggest concern is getting this over to re@ so it can >>> get in to 10.0-BETA1, the deadline for which is looming (like, tomorrow >>> I think). >>>=20 >> I hate to say it... but it was the netconfig and keymap changes that put= us >> out of our way. If anything, I'd like to see those get dropped and have = us >> focus on ZFS. >>=20 > The netconfig changes other than Warren's wireless patch have been > backed out >=20 > The keymap change has been simplied down to just Warren's test system, > but implemented as a menu instead of a yes/no/other box >=20 > This can be redone better later >=20 Or... how about *now*? I'm committing the completely reworked keymap code as I type this. >>> As such, I have rolled back the patches to netconfig and netconfig_ipv4 >>> (my stuff to reduce the number of dialogs to configure ipv4, it posed >>> some problems with the possible usage of xdialog, and didn't actually >>> offer an option to 'cancel'). I kept Warren's netconfig wireless patch >>>=20 >> Cool. We're thinking along the same lines. >>=20 >>=20 >>> This leaves the only real outstanding problem the keymap thing. I >>> propose changing it from a yes/no/other to a --menu, and hopefully we >>> can find the bug with the display name, or just make it show the keymap >>> name instead. >>>=20 >> Last night I started doing what I knew "had to be done". >>=20 >> Just as was the case with "bsdconfig timezone" ... I literally went into >> tzsetup(8) and converted the C code line-by-line to shell. (don't take >> that *too* literally... swaths of optimization were applied int he proce= ss; >> point being that the shell quite-ably reads the ISO3166 tables and zone >> files in the same *exact* manner as tzetup). > tzsetup says 'if you are not sure if your CMOS clock is in UTC, choose > no', but the default in the dialog menu is not 'no'. This is wrong. I > couldn't fix this because tzsetup is C not SH >=20 Well, no longer the case anymore ;D Does that still need fixing? (maybe not right now; let's stay focused) >> I've gone into kbdmap and looked at how it parses things. >>=20 >> No biggie... looks like INDEX.keymaps (whose suffix matches the directory >> he lives in) is nothing more than a colon-delimited 3-field syntax with = leading >> whitespace chopped and a comment-character of "#". Nothing a trival awk(= 1) >> script couldn't handle. >>=20 >> To make things cute... I've got the code parsing into a shell structs (t= he same >> way I parse dhclient.leases and other file formats). By having an awk sc= ript >> read the file and generate shell statements that in-turn load the data i= nto the >> exigent namespace. >>=20 >> I'll see what I can get in ASAP. > If you can work something out, great. I fixed it 'good enough' for now >=20 Committing now. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D720FC4DCD1>