Re: JumpStart autoinstall clone for Linux
On 22 Nov 1997, Steve Dunham wrote:
> It was in Red Hat 4.9. UTSL. What's "jumpstart compatible"?
I mean having similar, if not identicle configuration
elements (i.e. rules files, profiles, begin and finish
scripts, etc.) Also, it would be useful to provide
compatable environment variables to begin/finish scripts to
make such scripts more portable. The concept of a system
state file is also kind of nice, although this is partially
broken under Solaris (2.5.1 on Ultra2's anyway).
>
> Kickstart does use BOOTP instead of RARP+broadcast NIS, but broadcast
> NIS turns out to be a pain anyways.
Sun's can't do bootp, but their rarp implementation reads a
bootparams file or map, which provides a lot of needed boot
information. Also, NIS is not required for JumpStart,
unless you want to make it completely hands free, and even
then, only for locale, timezone, and terminal settings.
These could likely be dealt with on the image side with
little difficulty. I do think that broadcast NIS has its
merits though -- any machine can respond and serve the
client so the clients don't need fore knowledge about NIS
servers. Again, this is not required for Jumpstart since
the NIS or NIS+ server can be specified in bootparams.
>
> The basic process is: The Red Hat disk BOOTP's for it's network
> configuration and server name. Gets configuration file off of server.
> Configuration file tells how to partition disk, what packages (and
> collections of packages) to use. It partitions the disk, installs the
> package, and configures everything.
This is about as detailed as the web site gets. It would be
useful to find out how the root and boot servers are
configured and related, how the install server needs to
be configured and integrated, how the clients get associated
with an installation profile, how such profiles get created,
etc.
>
> If I remember right, the beta version didn't have any sort of "finish"
> script, but this may have changed.
I suppose with RPM it should be easy enough to create a
"finish" RPM that would get installed and then do stuff at
the first reboot, confirm the results, and remove itself.
This is still required under Solaris for installing some
packages that gag on a relocated root under pkgadd. It also
fixes some of the statefile issues that used to work but
broke under 2.5.1.
>
> This is not quite as nice as Solaris, where:
> dsh -ngroupname 'reboot -- "net - install w"'
> will reinstall every machine in the netgroup "groupname".
This is only easy after everything has been set up in
advance. It takes a lot of thought and care to get desired
custom results from an autoinstall. Its well worth it, of
course.
>
> > In any case I find it inspiring that Linux now has a
> > professional style, hands free network installation method.
> > As long as its GPL'd, I'm sure we could leverage it for our
> > benefit to some degree -- even if our autoinstall
> > implementation differs. I'm very interested in this in
> > general, so I'll be looking into kickstart as soon as
> > documentation on it is available on the redhat web site. If
> > anyone knows of another source for the kickstart details,
> > please let me know.
>
> The source is on Red Hat's FTP site (it's part of their install
> program) and a sample configuration file is with the source. The only
> part we would need to leverage is the partitioning stuff, and I think
> sfdisk would be sufficient.
I think the point I was making is that they must have a
standard way to set up an install/boot/root server
combination, generate the client disks, etc. Why reinvent
the wheel? If its GPL'd, perhaps we should leverage this
work. That would mean you could use a redhat system to
generate a boot floppy for autoinstalling a debian system,
and vise versa. Even the client configuration description
syntax may be reuseable. I've not seen their stuff yet,
though, so this may not be a good idea. It depends on how
they've done it.
>
> For Debian most of the pieces are there, the only thing holding us
> back is our packaging system, which is kind of a shame, since even NT
> has a non-interactive install...
I don't even think the packaging system is holding us back.
dpkg could easily be used to backend a higher level tool
that organized packages into package clusters, and clusters
into meta-clusters, or install profiles. The
interactiveness of a package is a matter that could be taken
care of with a pkgask type utility in the short term. In
the long term we should define an external* method for
packages to get configuration data that would otherwise
require interaction. We could do this now, even without a
centralized database. All we need is a method to call. The
method could abstract how the information is retrieved,
stored, etc. We would need some kind of per package state
flag or something to indicate that the package should use an
external method to get config data instead of prompting.
I'm not sure how to accomplish this.
>
> The main problem with our packaging system is interactive post-install
> scripts. We would also need a way to specify "collections" of files,
> but that could easily be done with a simple text file, like Red Hat
> does.
So does Sun. I wrote a handful of tools that verify Suns
.custertoc .packagetoc and .order files for a Solaris
autoinstall server setup, so I'm pretty familiar with their
implementation. Its then a matter of being able to make use
of such information.
>
>
> The rest of the job would be writing some simple scripts. Disk
> paritioning being the hardest part. But I gave up, because nobody
> else seemed to think that non-interactive scripts were worth bothering
> with.
Alas, they're not so simple once the bigger picture comes
into focus. Then there's always that little issue of
getting everyone to agree on a format ...
--
"Until we extend the circle of our compassion to all living
things, we will not ourselves find peace" -Albert Schweitzer
Richard G. Roberto
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: