Installing Linux (without CD/floppies)

[Robert G. Brown]

On 18 Feb 2003, Ashley Pittman wrote:

> Takes a tiny ammount of admin time but you do have to wait for the node
> to finish.  One problem we have here is that it installs a entire cd's
> worth of software, most of which never gets used, a quick look shows
> that there is 650Mb of software installed on our compute nodes, thats
> *far* to much.

Sure, but if you spend just a bit of time refining the kickstart
package/group lists, you can can cut this down if you like.  However, we
tend to be lazy and install relatively fat nodes as well.  This is
because hard disk is so cheap as to be free, compared to the size of any
sane operational image (the 3-4 GB unpacked for even a totally full and
fat X workstation image is a small fraction of the smallest hard disks
available today).  Given "free" disk it seems better (from a CBA point
of view) to just go ahead and install anything there is ANY chance of
somebody needing rather than having to invest the human time to install
it on demand later, unless there is some nonlinear cost associated with
the additional delay required for the actual install.  Usually this is
just unattended waiting time and moderately antibunched, so that the
admin can do other useful things while it completes.

> My reasoning was to get the node install time as *low* as possible and I
> was assuming that kick-start wasted to many cycles/bandwidth on stuff

I'm not certain about this.  A package is typically compressed (to be
network efficient) as the network and disk write rates are likely to be
the rate limiting steps, not the decompression.  The CPU required for
decompression and installation %post configuration is "free" anyway.  A
tgz image probably requires very similar amounts of network bandwidth
and decompression CPU -- at most it saves some of the %post processing.

> that would just end up the same anyway. kick-start wouldn't allow you to
> customise the image as much either.

I'd have to disagree with this and would indeed roll the opposite way.
kickstart installs already automagically probe for hardware and manage
moderate differences between e.g. sound and video and network and disk
configuration.  To accomodate these with diskless images, one has to
build the diskless image for EACH supported hardware configuration
separately.  This can be quite time consuming, because one WON'T
generally have e.g. kudzu or some other probe/configuration tool to do
most of the work for you, one has to do it by hand or by somehow running
an "install" on a mounted template on an architypical node.

One is always free to build as many kickstart images as you like or need
for distinct configurations; customizing them is likely as simple as

cp basicnode.ks customnode.ks
emacs customnode.ks
 (add or delete packages, change hard configuration parameters)
emacs /etc/dhpcd.conf or whatever
 (direct nodes to use customnode.ks on their standard install)

and then boot the install.  Alternatively, for slightly different
one-of-a-kind nodes (could we install the compiler group only on THIS
node) that are standard plus a package or two, one can do a kickstart
install to a basicnode.ks state, then yum install pkgname.

> This would take some effort to setup the "install" script and possibly
> wouldn't be worth it because it would only save a few minutes (in
> parallel) of unattended time while the node installs itself.

Yeah, that's the rub;-) Once things are bleeding edge efficient and
scalable, it stops being worth it to screw around saving even
significant fractions of the little time things take, especially
unattended time.  Five minutes or ten minutes of network install time
per node is pretty irrelevant, as long as I don't have to wait around
for either one to complete and as long as both complete without incident
on request.

> However... Once you have got the node-install time low enough then you
> have the possibility of requesting node configurations when you submit
> your jobs, they could install with a different flavour of the os and
> different kernels depending on what requirments the job has.  I've not
> heard of anybody doing this though so perhaps it isn't desirable but I
> know I can think of uses for it.

This is the goal of the "computing on demand" (COD) project at Duke.
Justin Moore is working on The Ultimate Environment Loader.  With it,
one will be able to select, in real time, to boot into the entire
install image of your choice including OS, kernel, work environment.
He's shooting for times of order minutes for the "boot/install" to
complete.  With this nodes can be dynamically reconfigured to work on
completely distinct projects with completely distinct operating systems
and work environments and user account and security environments, giving
one a whole new perspective on scheduling and resource sharing.  Need a
freebsd node?  Boot it that way.  Need a linux node within your
organizational domain?  Not a problem.  Plan to break the hell out of
your node installation while doing research on e.g. operating systems,
networks, kernels?  Fine, break away and reinstall the base image when
you're done.  Even WinXX, in principle, loaded on demand and it just
goes away when the demand ceases (in practice, of course, one has to
manage all sorts of copyright issues that I don't want to even think
about, or break the law:-).

I think that this will be very, very cool and might even change the very
way we think about compute resources from the desktop on down.

   rgb

P.S.  See Justin, sometimes my legendary verbosity contains a valuable
plug for a struggling grad student's valuable work...;-)

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu