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 did at-once. 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 bidding. No? -- Devin 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 > front-end. > 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. > > http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall > > Checkout examples/README for all the gory details of config-file > generation. > > 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 ;) > -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/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 <-Received on Thu Apr 08 2010 - 15:01:54 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC