Date: Mon, 13 Mar 2000 06:14:52 -0700 (MST) From: Bruce Gingery <bgingery@gtcs.com> To: Edward Gold <edgold@mindspring.com> Cc: freebsd-hackers@freebsd.org Subject: Re: rewrite of sysinstall Message-ID: <200003131314.GAA24487@ home.gtcs.com> In-Reply-To: <38C5BAD7.7AA9E6A3@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-hackers, Edward Gold wrote:
-> I was actually planning a near-complete rewrite of sysinstall anyway!
-> How about everyone throwing in whatever suggestions you would like
-> (about anything regarding sysinstall), and I will try to incorporate them!?
-> The things I am specifically going to focus on are:
-> 1. depretzel the GUI from the logic and modularize.
Excellent!!!
Please add vikeys as a possible option for the GUI itself.
I've had some times running on a remote machine over bad enough
links that cursor keys were unusable, hence it was impossible to
use the current GUI. Even just the hjkl key-set would have
made it usable. If not enabled, make option letters non-
case-sensitive. If enabled, force all option selection keys
uppercase, similar to Lynx's handling of the "h" versus "H" key.
At a minimum, make everything navigable by single-byte-key
commands.
-> 2. implement scripting capability so we can control the user's path
-> through the various menus from a script file of sorts.
Yep, although one of the biggest neophyte complaints I've seen
so far is too many navigation paths, which makes the whole
process seem more complex than it is.
Perhaps moving all of the post-install configuration items
to a seemingly distinct interface would answer that.
One thing often ignored is the presumption that /var/ will
be the default proxy queue for Apache, and even the default
database location for MySQL. Running either of these with
default configurations tend to increase the need for /var/
space. Logging Apache logs to /var/log/ on a popular server
adds that much more. Mailservers with large /var/mail or
mail or print or fax servers with large /var/spool/ usage
similarly. This info should be in help when the disk is
partitioned.
-> 3. possibly make stand alone post-install GUI based utilities for
-> fdisk/disklabel and other configuration functions.
Yes PLEASE! By decoupling the post-install GUI from the distribution
install (although perhaps "sharing modules"), we can look at a number
of things:
* Migration assistance when installing an update. Several
upgrades since v2.0.x haven't been painless, and some
have been a bit confusing.
* Less confusion in "adding distributions" without committing
to a complete re-install.
* Make kernel builds a part of the post-install GUI (at least
eventually).
* Even (eventually) allow non-root port/package installs part
of the post-install GUI. Even PIB needs to run as root, last
I checked. It wouldn't be all that hard to check for a
system-wide install already in place, and change $PREFIX
for a non-root install, so long as pkg_add and pkg_delete
could also be directed to other than /var/db/pkg/ when run as
non-root.
OTHER THOUGHTS
If it's to be modular (e.g. plug-in in basic design) anyways, how
about preserving a single basic binary for the GUI, and defaulting
to a different set of "plug-ins" depending upon whether it's running
from RAMfs or /stand/sysinstall, and whether it's being run with an
EUID as root or not. E.g:
Run to install: Presume that it's a new install or upgrade
unless launched with an override flag, perhaps
-configure That would allow post-install to
merely re-invoke itself as an exec'd subtask.
/stand/sysinstall as root: Presume it's a system configuration
unless launched with an override flag, perhaps
-software or -upgrade
/stand/sysinstall non-root: Presume it's for user configuration
or by-user ports/package install tasks, but warn
that for system configuration it must be run as
root.
Despite the gradual decrease in usefulness of diskettes, its likely
that a user-level interface built on /stand/sysinstall should be
available for formatting diskettes.
Space permitting, there could be a menu option to switch from one
to another, even if it required an exec re-launch of the GUI shell
to get into that "other setup task".
**
You might wish to consider also, HTTP fetch capacity of these
"modules". This would allow, for example, mounting a CD on one
LAN host with a webserver, or over-the-internet installs to fetch
far more even for the basic system install and configuration, than
would ever be desirable in kern.flp or the memory filesystem root.
So long as the module has a checksum in its file format, partial
fetches could be handled fairly easily, even with a minimal
webserver that doesn't send file sizes in the protocol headers
(in fact non-error headers could be merely tossed in the bitbucket
and MOVED errors should merely be reported rather than followed).
That would also allow for a far more complete HELP system in the
basic install. Only an HTTP1.0 plus file:/// would be needed,
so long as all links are relative once that BASE is set, because
multi-file fetches would seldom (if ever) be any enhancement. It
should send a Host: header, though, for HTTP. Perhaps a questonmark
on EACH option could offer context-sensitive help.
It would even be logical to register an application/vnd. MIME type
for these modules. With OpenSSL in the base distribution for 4.x
(${OSVERSION} >= 400014) and up, should the shell try for https://
before http:// ??
**
Color code the modules. The Royal Blue is pretty, but this can help
with remote voice support, and even E-Mail/Usenet support and FAQ
documentation.
**
Check for screen/terminal size with the GUI. If post-install
configuration is run (later) in an X-Term that's 80x60 - or even
160x80, why should it still be stuck at about 80x24, if there are
more options to display than fit in that size.
**
If system component addition is done from an X-Term, open another
one as a log view, comparable to the 2nd console in a basic system
install. (e.g. if DISPLAY is a non-null shell variable).
**
In post-install, allow for the TRADITIONAL distinct kernel hostname
from kernel domainname, whether or not NIS will be used. I know
that this is a "religious battle" but there are still some of us on
the other side of that argument from current presumptions. Sure
each active interface (other than lo0) should have a FQDN assigned,
ideally, but certainly there are a lot of status displays that
benefit from a shorter hostname. Sendmail defaults (last I
installed one) still allow for Dj set following $w set to
`hostname` appending .`domainname` internally.
Many other utils allow for this, as well, including Perl's host
determination. Very few are able to handle both a FQDN as
`hostname` and a non-null `domainname`. I know of quite a
bit of UUCP use still going on around the world, and although
UUCP on FreeBSD handles internet addressing ...
**
In disk partitioning, several preset presumptions could be selected
from, rather than a single default.
/ swap /usr - Personal use
with /var/ symlinked to /usr/var/
/ swap /var /usr - Plain server
/ swap /var /usr - Print, Fax or Mail server
/ swap /var /usr
and /home and/or /usr/local
/ swap /var /usr
and /var/cache or similar for proxy servers
/ swap /var /var/db /usr for database servers.
etc. Even if only half a dozen typical uses were used for
formulation it could cut down on the "I've run out of room on..."
posts in the mailing lists and newsgroup.
**
Would it be easier to just do the rewrite based on Tcl which
already has regexp's and socket support built in, along with
UTF-8 for internationalization, sub-interpreter for "safe"
zones, and the like. The XF86Setup utility is Tcl/Tk without
a "normal" Tcl/Tk install, already, for example. With the Tk
dynamic loading in the works, it could even make sysinstall
evolve into one which is OPTIONALLY an X application when
used post-install.
Bruce Gingery <bgingery@gtcs.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003131314.GAA24487>