Re: JumpStart autoinstall clone for Linux
"Richard G. Roberto" <robertor@typhoon.co.jp> writes:
> I just saw RedHat's write up for the up coming release of
> RedHat Commercial Linux 5.0. It includes what their calling
> "kickstart" and sounds like they hit the mark. No doubt its
> modeled after JumpStart, but I couldn't get any details from
> their web site. The fact that its here already is a good
> thing for linux. But how does this impact debian? We've
> identified the need for such functionality, but haven't come
> to agreement on how to provide it. When we do, do we try to
> be kickstart compatable or JumpStart compatable or either?
It was in Red Hat 4.9. UTSL. What's "jumpstart compatible"?
Kickstart does use BOOTP instead of RARP+broadcast NIS, but broadcast
NIS turns out to be a pain anyways.
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.
If I remember right, the beta version didn't have any sort of "finish"
script, but this may have changed.
This is not quite as nice as Solaris, where:
dsh -ngroupname 'reboot -- "net - install w"'
will reinstall every machine in the netgroup "groupname".
> 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.
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...
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.
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.
Steve
dunham@cps.msu.edu
--
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: