Hi Chris, On Tue, 19.12.2006 at 03:00:04 -0700, Clint Pachl <[EMAIL PROTECTED]> wrote: > I am working on an automation system that will commence from OS > installation. For instance, all the questions asked during OS > installation can be placed in a config file on the central repos. To
I've also recently looked into automating OpenBSD installation. > initiate an installation, run bsd.rd via CD or PXEBOOT. When asked > whether to run install, upgrade or shell, run shell. Then ftp your > system build script to the bare system and run it. The script will then > run the installation for you and build you a base system, filling in the > blanks. It will then "customize" the system by pulling individual > updates meant only for that server. I want _fully_ automatic installation, so I'd like to replace the /install.sh script in order to have the system work on it's own, after being powered on. Looking into the way bsd.rd is built, I came to the conclusion that cooking a custom bsd.rd isn't desirable. What looks much easier to me is to install from an NFS server. So, have a bsd with "root on nfs" with a full OpenBSD installation on said NFS server and no stringent space limitations, but a full-fledged toolkit that you can work with. > # ftp central-repos:/buildsys > # buildsys <image-name> > Because the ramdisk kernel has a limited number file retrieval commands, It also has a fixed installation script that's too cumbersome to replace (ie, who wants to build a new kernel every time the installation script got beefed up?). > you will need interface with your central server using ftp. Or http, or nfs, or or or. Right. You may be confined to ftp and http if you stick with the original ramdisk kernel, though. > initially, your buildsys script will need to ftp things like disklabels > and instructions on how to run newfs. It would be MUCH better to have some procedure to automatically figure out disk partitioning, similar to what FAI does. Then you can replace hard disks at your leisure and still have a reasonable partitioning after swapping out a dead one for a new one. > The sets to install should be predefined ssomehow; read from a config > file or placed in a directory. For an example of the latter, your > buildsys script could do something like this: > > ftp -o - central-repos:/images/<image-name>/OS/*.tgz | tar xpzf - -C /mnt Why not make that ftp -o - central-repos:/images/<arch>/<hostname>/<image-name>/OS/*.tgz | tar xpzf - -C /mnt or some such, to have the ability to accommodate variations in your hardware and host setup? I mean, putting _the_same_ code on many machines only works for rare cases. Most often, I find slight variations to be desirable, and if it's only that machine A has a bge interface while machine B has em interfaces. > Just thinking and typing. Hopefully someone that has experience can fill > in the blanks, comment, or criticize. FAI is worth reading, imho, even if it requires a Debian host system. Just my .02 cents... Best, --Toni++
