Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Jul 2010 20:07:23 -0700
From:      Garrett Cooper <yanegomi@gmail.com>
To:        sysinstall@freebsd.org
Subject:   Re: Proposal for new `post-install userland configuration utility'
Message-ID:  <AANLkTindeFv-xgeg2559WwhiNq_fraIaVHNLWGm3Ac-t@mail.gmail.com>
In-Reply-To: <AANLkTin8ISZ92N476KUS7SyhYX7RYayxJIU8fCgIx3SB@mail.gmail.com>
References:  <AANLkTim62ZElaCZ2jQ9REQoip8hexl24tZWGoSAp3Pky@mail.gmail.com> <AANLkTin8ISZ92N476KUS7SyhYX7RYayxJIU8fCgIx3SB@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 9, 2010 at 6:20 PM, Garrett Cooper <yanegomi@gmail.com> wrote:
> 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 b=
e
>> 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 default=
s
>> 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.

This was a thought, but I was told to restrict my scope to base
packages only. This could be easily extended though if others wanted
to add this functionality when libpkg becomes more realized on
FreeBSD.

>> 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.

Thanks,
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTindeFv-xgeg2559WwhiNq_fraIaVHNLWGm3Ac-t>