Re: JumpStart autoinstall clone for Linux
"Richard G. Roberto" <robertor@typhoon.co.jp> writes:
> On 22 Nov 1997, Steve Dunham wrote:
> > 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.
This seemed pretty clear to me. There was some documentation
somewhere. (I've never seen the web page.)
> > 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.
Yeah, we use this method on Solaris, we have all of our postinstall
stuff on an automounted partition sorted by version number in a nice
init script-like layout. Makes it easy to add stuff, etc.
> > 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.
Yup, I started here after it was set up.
> > > 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.
If it's flexible enough. What I saw was a first pass. There were no
scripts to automate adding a client. (For Solaris, we ended up rolling
our own scripts anyways.)
> > 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.
Have the variable fetching method return an error if the data isn't
there.
> > 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.
Sun's format is more fragile than Red Hat. If you don't get
everything exactly correct they segfault. Red Hat's file is
basically:
0
1 *beforeskel*
setup
pamconfig
filesystem
end
1 Base
MAKEDEV
SysVinit
adduser
ash
at
bash
bc
bdflush
bootpc
end
0 Clustername
package
package2
end
This would do the trick.
> > 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 ...
Thats not really a big issue. The key here is that you do the work
first, and people will accept the format because they don't want to
redo it.
I personally don't have a lot of x86 boxes to play with and Debian for
sparc isn't ready. (The monolithic install script refuses to believe
the disk is mounted, some packages on the ftp site depend on packages
that aren't on the ftp site.)
Here are the minimal docs from Red Hat's install floppy:
: Red Hat Kickstart Mode
:
: Red Hat provides a method for unattended installation of a system
: using a text configuration file. To enter the kickstart mode, type
: ks <ENTER>.
:
: Once in this mode, the installation program will expect to be able to use
: a bootp server to gain networking information and to bootstrap itself into
: the installation.
:
: The installation program looks in the following places for the config file:
: o the broadcast server from bootp.
: o the bootp server if no other server name is broadcast.
: o on the boot floppy if ks=floppy <ENTER> is given.
:
: The file it looks for is given by the bootp server as either a directory or
: an explicit file name. If a directory is given, then kickstart looks for a
: file in that directory with the IP of the client as the file name followed
: by "-kickstart" (ie. 192.168.0.1-kickstart). If the floppy argument is
: given, then it will look for a file named "ks" on that floppy.
:
And here is a sample config file:
# eventually, we'll allow cdrom kickstarts
nfs --server porkchop.redhat.com --dir /mnt/test/i386
# keymap to use, same as keymap named in kbdconfig
keyboard us
# Disk partitioning stuff goes here. It also sets up the fstab stuff
# and selects which partitions are formatted. All swap partitions are
# formatted and used though.
# this should be install or upgrade, defaults to 'install' if omitted
install
# it would be nice if we could setup networking parameters for installs
# which weren't bootpd :-(
# printer configuration goes here
# mouse types are: ps/2 mousesystems microsoft logitech atibm logibm msbm
# the default device is right for busmice, /dev/cua0 for serial mice, and
# can be overridden with "--device cua2"
# if three button emulation is needed, specify "--emulthree"
#
# this is just like /usr/sbin/mouseconfig
mouse ps/2
# the timezone command takes the same args as /usr/sbin/timeconfig
# see the timeconfig 2.0 man page for details
timezone --utc US/Eastern
# xconfiguration
# Video card selection:
# You can let it try to find you PCI card automatically, OR
# specify --card <cardtype> (see Xconfigurator --help for list), OR
# specify --server <servertype> (also see Xconfigurator --help)
#
# Monitor selection:
# If none specified, assumes 640x480@60hz.
# Otherwise, use --monitor <type>, see Xconfigurator --help for list, OR
# use --hsync <hsync> and --vsync <vsync>. For example:
# --hsync "31.5,35.5,50-65" --vsync "50-70"
#
#
xconfig --monitor "tatung cm14uhe"
# this root password goes over the network in the clear for NFS kickstarts
# it's probably a good idea not to use the real root password here
rootpw kickmeRH
# lilo install goes to mbr by default w/ no append line. you can modify
# this as shown in the example
# lilo --append "mem=128M" --location mbr
# the location is one of mbr (default), none, or partition
# this command is called 'silo' on the sparc, and doesn't exist on the alpha
#
# zerombr yes|no
#
# Should the install automatically zero the partition table if it is corrupt?
#
zerombr yes
#
# clearpart - requires --all or --linux
#
# --all removes everything from ALL DRIVES
# --linux removes all linux native/swap from ALL DRIVES
#
clearpart --linux
#
# part <mntpt> --size <size in megs> [--grow] [--maxsize <size in megs>]
#
part / --size 250
part swap --size 32
part /usr --size 500 --grow --maxsize 800
part /tmp --size 100 --grow
# packges to install follow here
# '@ component' may be used to include entire components, redundant items
# are okay
%packages
@ Networked Workstation
bsd-games
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-admintool-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: