[RFC] Rewriting sade(8)
dteske at vicor.com
Thu Apr 8 17:01:54 UTC 2010
Randi and I were discussion the possibility of having sysinstall
"remember" what you did and then able to write out a suitable
`install.cfg' file that could be subsequently used to perform a human-
less automated install with the same settings.
To expand a little on that...
I'd like to draw a similarity to AppleScript. If you are familiar with
AppleScript, you know that one can launch on Macintoshes (going back as
far as Mac OS 7.0.1) an application known as the "Script Editor" which
had a "Record" button in the [then] top-left corner of the window. After
clicking that "Record" button, the system then recorded what you did
(including in the Desktop [Finder] and other 3rd-party programs) and
saved a series of scripted commands which could simply be "Run" (or
optionally saved into an executable script) to reproduce everything you
The way that this worked was by way of the developer "plugging in"
specific resources (if you're familiar with the ol' days, you'll
undoubtedly remember ResEdit -- specifically, a developer would add an
'aete' resource to the RSRC fork of the HFS file structure (among
others). Then, when a scriptable-action was performed within the
application, rather than calling some internally obscure sub-routine to
perform the task, the developer would have the application actually send
an AppleScript event to the MacOS which then sent it back to the
application. Therefore, when the ScriptEditor is "recording", what it
records is the events being passed from the application to itself as you
go about clicking, dragging and typing things.
It is in this manner that I think we would be best served in
contemplating a "self-scripting" engine.
That is to say, that -- altogether now -- we:
a. separate the GUI front-end from the actual tasks that need to be
performed (back-end; for example, tasks to partition disks, perform
newfs, etc. etc.)
b. have either all commands in the library pass through a "dispatcher"
or only export a single dispatcher function from the library (requiring
all "commands" to pass through this single function)
Then it would then (I perceive) perhaps become a trivial task to have
the dispatcher "record" the events.
Another benefit of this would be that it wouldn't matter whom or what
performed anything at all... there would be a mechanism for recording
what was done regardless. And thus, we would usher in the age of being
even the lay user being able to script the installer to do his/her
On Thu, 2010-04-08 at 12:48 +0000, Kris Moore wrote:
> On 04/08/2010 16:30, Marian Hettwer wrote:
> > On Thu, 08 Apr 2010 10:53:48 +0000, Kris Moore<kris at pcbsd.org> wrote:
> > It's not nice to hijack a topic, but this is way to interesting for me, so
> > I do it anway :)
> :) I didn't mean to hijack either, was trying to discuss advantage of
> having backend
> as a executable vs a library which can't be used standalone without
> This would in effect lock you completely into front-end logic, which may
> not meet
> a users specific needs, even though backend can do what user wants.
> >> This has a few advantages, in that the backend can be used stand-alone
> >> for scripted installations and also provide great flexibility
> >> to the front-end developer. They don't need to worry about performing
> >> any of the actual installation logic, they just provide a way
> >> for users to select their installation options, generate a configuration
> >> script, and let the backend run with it.
> > scripted installation!
> > Are you able to do a pxeboot, nfsroot and then scripted installation?
> > Are those scripts portable to FreeBSD or PC-BSD only?
> > Could you give me a hint where to find them?
> > TIA,
> > Marian
> Correct, every install it does is a fully-scripted installation, and
> it can be used with pxeboot, or in a custom mfsroot image easily.
> Supports ZFS, glabel, gmirror, geli, GPT, gpart, vanilla FreeBSD
> installs, etc.
> Checkout examples/README for all the gory details of config-file
> One caveat, the version in trunk is being very actively worked on by
> myself at the
> moment to prepare for 8.1, needs more docs, etc ;)
-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-621-2020 Office Fax
devin.teske at fisglobal.com
-> LEGAL DISCLAIMER <-
This message contains confidential and proprietary information
of the sender, and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person is strictly prohibited. If you have received this
message in error, please notify the e-mail sender immediately,
and delete the original message without making a copy.
-> END TRANSMISSION <-
More information about the freebsd-current