Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Jul 2010 16:26:30 -0700
From:      Garrett Cooper <yanegomi@gmail.com>
To:        sysinstall@freebsd.org
Subject:   Proposal for new `post-install userland configuration utility'
Message-ID:  <AANLkTim62ZElaCZ2jQ9REQoip8hexl24tZWGoSAp3Pky@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
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.
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.

Besides, if you like PC-sysinstall so much you should be using PCBSD.

Q: OMGCat disapproves this idea! It's just another application that's
going to become bitrotted in the sourcebase. It'll eat my dog, etc,
etc.
A: If you feel that way, there have other issues that need to be
discussed off-list :P.

Let's let the fur fly (well ok, not too much ... ow...)!

Cheers,
-Garrett



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