Re: Looking for students to work on sysinst (the NetBSD installer) for GSoC 2010

[Malcolm Herbert <mjch%mjch.net@localhost>]

Sticking my ore in where it probably doesn't belong, but for my money
I'd like to see some time spent on working on an extensible config file
to hold basic information about a host, in XML or some key-value manner
with appropriate blocks for various sections ...

If we can seperate the interface(s) used to collect/collate information
about the host from the bits and pieces that actually do the install and
setup then the following happens:

* we would allow easy drop-in replacement of the UI whether that be 
  text or X11 or whatever (a WebUI for headless operations?  Braille?)

* more importantly, it would allow hands-off, scripted installs such as
  that offered by Solaris' JumpStart or Red Hat's KickStart (iirc)

To my mind, that would be a significant step forward ... we wouldn't
need to do everything right away - probable steps would be:

* Determine current configuration items collected by sysinst

* Ratify a config file format

* Seperate the sysinst UI from the backend, using the new file format

Once that's bedded down:

* Create an X11 version of the sysinst UI that also uses the new format

* Create the hands-off JumpStart/KickStart capability (presumably some
  minimal netboot, using PXE or whatever, with appropriate script paths
  supplied by DHCP)

Automating this will certainly help those that provision large numbers
of NetBSD hosts and just make the OS more useful generally ...

I haven't looked, but it might also be a Good Thing to see what other
*BSD variants or Linux do in this regard ... perhaps a common file
format between the *BSD family may help migrating from one to another?

I'm a Solaris admin by day, so know more about how JumpStart operates
than anything else - in particular JumpStart doesn't pretend to be able
to do everything for a host but does allow the user to run arbitrary
scripts from the installer environment with the newly deployed OS
mounted at /a

JET (the JumpStart Enterprise Toolkit) expands on the capability of
JumpStart by setting up standard scripts to do a lot of the heavy
lifting that JumpStart doesn't cover. Within JET, there is the ability
to schedule events to happen at the first or nth boot to cater to
things which need to be set up in a particular order after an initial
deployment completes, such as patching or applying sets of packages
and so on ... 

So, with something like that we could automatically populate Xen guest
instances using the same mechanism (ie, domU netboots and does the
install into the virtual disk via the virtual NIC) ... or rather than
boot a new guest, use the tool to populate a disk or directory tree and
build a new OS ready to be used as a domU or a FreeBSD jail, for example

Just thinking out loud ... :)

Regards,
Malcolm

-- 
Malcolm Herbert                                This brain intentionally
mjch%mjch.net@localhost                                                left 
blank