Date: Fri, 9 Jul 2010 18:20:20 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: sysinstall@freebsd.org Subject: Re: Proposal for new `post-install userland configuration utility' Message-ID: <AANLkTin8ISZ92N476KUS7SyhYX7RYayxJIU8fCgIx3SB@mail.gmail.com> In-Reply-To: <AANLkTim62ZElaCZ2jQ9REQoip8hexl24tZWGoSAp3Pky@mail.gmail.com> References: <AANLkTim62ZElaCZ2jQ9REQoip8hexl24tZWGoSAp3Pky@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 9, 2010 at 4:26 PM, Garrett Cooper <yanegomi@gmail.com> wrote: > Hi all, > =A0 =A0Randi has highly recommended several (*chuckles*) times now that I > develop a post-install userland configuration utility to essentially > replace the Configure dialogs to some degree (there's some stuff in > there that's going to go, and some things that are going to stay). > =A0 =A0What I've let ferment for a few days is how exactly this should be > done, and several concerns that I have with such a utility. > > Design: > > 1. The utility would be presented to the end-user in the motd like is > done today with sysinstall. > 2. The primary audience would be novice users and/or folks looking for > an opportunity to hit the ground running ASAP with a new install. They > would be given the option of a few simple configurations: > =A0 =A0a. Desktop > =A0 =A0b. Laptop > =A0 =A0c. Server / workstation > =A0 =A0Depending on the configuration chosen, a series of preset defaults > would be provided (ssh on, configure an X11 greeter, etc); I realize > that this may require adding hooks into pkg_install//libpkg (which is > fine, because portmgr wants more visibility with libpkg eventually > anyhow). The primary configurations could also have popular > subconfigurations like: > =A0 =A0i. BAMP (BSD-Apache-MySQL-PHP) (server/workstation) > =A0 =A0ii. Gnome (desktop/laptop/workstation) > =A0 =A0iii. KDE (desktop/laptop/workstation). > =A0 =A0etc. > 3. The idea in mind would be a straightforward interface like so: > > i. Welcome (basic preamble about the tool and where to find more info > the handbook) > ii. Choose system configuration (Desktop, Laptop, Etc) > iii. Give the user an option to customize after pressing Ok. > iv. Fine tune configuration if user wanted to customize install (or to > remain at the whim of the profile maintainer and/or package > maintainers :)...). > v. Enable Services (provide a list of popular services like what are > available in sysinstall today, in addition to some items that aren't > available above). > vi. Install Dependencies via libpkg/pkg_install for third party > configurations, if required. > vii. Complete configuration. > viii. Done. > > Each page and each bit would have a corresponding section in the > handbook and/or manpages on how to configure the services so they > wouldn't need to depend on the tool past the first install. > > I'll draw up pretty pictures later if someone wants visuals :) (Dammit > Jim! I'm an artist, not a doctor!). > > The flow will be linear: you can go backwards and forwards, but no > going back to the beginning when you partition the disk and it fails > to contact the FTP server to download packages, and then fails to > partition the disk on the second go-around (sorry... I couldn't > resist...). KISS is key. > > Implementation: > 1. It was suggested that it be written in C. That way I could port > over existing code from sysinstall with minimal changes. > 2. It would continue to use libdialog, as it would carry over code > from sysinstall. > 3. The code would be monolithic in the beginning, but would evolve > over time to become more modular so that groups could predefine > package groupings, have install scripts, and thus could custom tailor > their installs with something similar to the fat package idea that > Julien Lafette is working on for GSoC this year ( ;)...). > > Concerns: > 1. It's written in C. > =A0 =A0 This is a concern, because anyone running the tool on a system > with a prebuilt configuration where I wouldn't be able to fetch all of > the configuration data (rc.conf is nothing more than a glorified > bourne shell script anyhow, and you can evaluate code dynamically like > with most scripting languages with bourne shell). I'll make a single > pass to ensure that variables aren't superficially defined, but won't > get too fancy with the parsing (otherwise I would need to develop > and/or hack the bourne shell parser, which wouldn't make sense :(... > 2. It contains sysinstall-code. > =A0 =A0- Well... any jkh code is fun to deal with, so I wouldn't expect > anything less. > > Anti-bikeshed: > > Q: We're going to have X11 configuration code, and a bunch of other > stuff we don't need in FreeBSD! > A: So? We want to be a more usable OS, correct? Attracting new users > is the big key that we need to be successful. > > Q: PC-sysinstall does this already, why do we need to have another > tool to do this?! > A: PC-sysinstall (and realistically PCBSD) only really supports a KDE > install and configuration track and isn't really flexible to extend > on. It's already several thousands of line of bourne shell long, and > has established code-paths. Thus, it's not a good base for > generalization. As someone else pointed out to me, yes.. pc-sysinstall is generalized. What I was referring to was the installation distribution and the GUI/configuration tools, which I suppose is more PCBSD centric and developed on QT, not necessarily pc-sysinstall centric. Sorry for that :(... -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin8ISZ92N476KUS7SyhYX7RYayxJIU8fCgIx3SB>