Proposal for new `post-install userland configuration utility'

[Garrett Cooper]

On Fri, Jul 9, 2010 at 6:20 PM, Garrett Cooper <yanegomi at gmail.com> wrote:
> On Fri, Jul 9, 2010 at 4:26 PM, Garrett Cooper <yanegomi at gmail.com> wrote:
>> Hi all,
>>    Randi 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).
>>    What 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:
>>    a. Desktop
>>    b. Laptop
>>    c. Server / workstation
>>    Depending 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:
>>    i. BAMP (BSD-Apache-MySQL-PHP) (server/workstation)
>>    ii. Gnome (desktop/laptop/workstation)
>>    iii. KDE (desktop/laptop/workstation).
>>    etc.

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