From owner-freebsd-hackers@FreeBSD.ORG Mon May 27 01:54:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2798AF25; Mon, 27 May 2013 01:54:32 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id E75DD9AE; Mon, 27 May 2013 01:54:31 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r4R1sPIS027346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 26 May 2013 20:54:25 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([10.132.99.23]) by LTCFISWMSGHT04.FNFIS.com ([10.132.206.15]) with mapi id 14.02.0309.002; Sun, 26 May 2013 20:54:25 -0500 From: "Teske, Devin" To: Dirk Engling Subject: Re: FreeBSD installers and future direction Thread-Topic: FreeBSD installers and future direction Thread-Index: AQHOWV60z6k72swSkkmGANUzy/EMLJkWZ1wAgAAkfQCAAE6UgIAAH7eAgAAtKgCAAUrxgIAAKQ4A Date: Mon, 27 May 2013 01:54:24 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7201F61FE0@ltcfiswmsgmb21> References: <51A0DC3F.9030301@cran.org.uk> <51A1025A.2020607@cran.org.uk> <51A14445.4060305@freebsd.org> <51A15EDF.6050600@erdgeist.org> <13CA24D6AB415D428143D44749F57D7201F5B2E7@ltcfiswmsgmb26> <51A29A5F.7010106@erdgeist.org> In-Reply-To: <51A29A5F.7010106@erdgeist.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="Windows-1252" Content-ID: <181571E007F07E4E98C01B62A7626EFE@fisglobal.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-27_01:2013-05-24,2013-05-27,1970-01-01 signatures=0 Cc: FreeBSD Hackers , Devin Teske , Nathan Whitehorn X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 01:54:32 -0000 On May 26, 2013, at 4:27 PM, Dirk Engling wrote: > On 26.05.13 05:42, Teske, Devin wrote: >=20 >> I chose 100% sh for bsdconfig because of a few good reasons=85 >=20 > First, the partedit tool makes heavy use of libgeom and the structs > returned from that lib, so I've rather wondered why for some parts C was > preferred, and not the other way around. >=20 I tend to be of the mind that shell (gpart in this case) would be a better choice for the installer than tapping into geom=85 (for the following) Using gpart makes you exercise both the end-user utilities and the developer framework (by-way of those utilities) whereas if you stick to just the developer framework (libgeom in this case) there's a chance that the installer can do things that can't be done from the command-line. Just a thought. If structs are what you want, I have those in bsdconfig: dteske@scribe9.vicor.com share $ pwd /home/dteske/src/freebsd_svn/base/head/usr.sbin/bsdconfig/share dteske@scribe9.vicor.com share $ grep '^# f_' struct.subr=20 # f_struct_define $type $member_name1 ... # f_struct_new $type $name # f_struct $name # f_struct $name get $property [$var_to_set] # f_struct $name set $property $new_value # f_struct $name unset $property # f_struct_free $name # f_struct_copy $from_name $to_name Naturally, because it's shell, the struct members are loosely typed (so no need to define their type). So I think there's great potential to write a very clean "gpart.subr" that combines the power of the above "struct.subr" with perhaps another of my modules=85 dteske@scribe9.vicor.com share $ grep '^# f_' device.subr=20 # f_device_try $name [$i [$var_path]] # f_device_register $name $desc $devname $type $enabled $init_function \ # f_device_reset # f_device_get_all # f_device_name_get $type $name type|desc|max [$var_to_set] # f_device_name_set $type $name $desc [$max] # f_device_desc $device_name $device_type [$var_to_set] # f_device_rescan # f_device_find $name [$type [$var_to_set]]=20 # f_device_init $name # f_device_get $name $file [$probe] # f_device_shutdown $name # f_device_menu $title $prompt $hline $device_type [$helpfile] NOTE: device.subr already uses struct.subr. For example, $device_type is actually a struct type, and when you call f_device_get_all() it creates a series of structs named "device_{name}" (where {name} is something like "da0") and the struct holds many properties for the device. I don't think there's any reason why we have to write it in C if we can wri= te it in sh. > Still, thanks for pointing all that out, but I rather wanted to look at > the installer from another angle, as it is supposed to provide everyone > from FreeBSD novices to experts with a comfortable way to do things the > right way and yet be flexible enough to avoid abandoning the tool once > the requirements differ. >=20 I don't see your angle as perpendicular to my own=85 but rather that I would like to seek to define in concrete terms what that means. Working backwards from your list=85 Flexibility: I think using a conflated shell namespace (where the entire installer is sh and is in-turn scriptable by sh) gives the most flexibility= . Much more than flexibility, I think this approach also lowers the barrier-to-ent= ry for integration and automation engineers. Open questions: was the fact that sysinstall was all C with a few forks to external programs a barrier to sys= tem- integration and system-automation engineers trying to automate the install- and-configure process? Maybe. The BSD-P certification exam requires you to script sysinstall in FreeBSD-8. If we go all-shell, this would become mu= ch easier IMHO. Novices to Experts: I'd like to strive to hit a full spectrum between those= two points. I recognize that these are not two discrete ends of a dichotomous tree, but instead a journey that is traversed (assuming the novice stays wi= th FreeBSD after trying it out). There are no defined sets of travel along this line either, some people skip being a novice when they come to FreeBSD for the first time because they have experience with similar operating syst= ems. That's why I've taken to developing every aspect of the utility. I want to = see the installer and configurator helpful to all people from developers to gra= nd- mothers and everybody in-between (that's the modular part=85 if you don't like the way something works=85 the sh(1) nature allows you to simply override it with your own module). > So I wonder if there has ever been a best practices document on how to > "properly" set up zpools, when to advice the user against using zfs at > all, whether it makes sense to use geli on the boot device, when it is > better to have multiple zpools and only encrypt the data pool(s). Maybe > the installer should be advocating concepts like manageBE, pre-setting > noexec-flags on /var, setting some default quotas. >=20 You'll get no complaints from me here. The installer is (in my view) not only where we need to provide the most he= lpful functionality, but the best place to stash real developer insight when it c= omes to analyzing the installation environment and providing "canned" recipes. > The second part, of course, is to find visual concepts on how the user > is guided through the default and expert bsdinstall/bsdconfig screens to > cover the most common scenarios and still offer enough options. >=20 I think there's two approaches to solving the issue of custom screens that = are not producible with normal dialog(1) or Xdialog(1) (the two interfaces that= are currently supported by bsdconfig; bsdinstall currently only supports dialog= (1)): 1. Use libdialog to produce variations that dialog(1) cannot produce. NOTE: This is what bsdinstall does. 2. Write a helper utility like ssh-askpass to be called from the shell code The latter can take more patience, but has (imho) greater potential for re-= use. > All this doesn't need a developer but a bunch of veteran FreeBSD admins, > a wiki and a lot of bike sheds to paint. >=20 Well=85 a developer doesn't hurt. Someone to make sure the code is clean and re-usable. > If there's no such document yet, I propose editing one in the wiki. >=20 Not aware of one. What would it talk about? --=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.