Thank you and good bye.
blacky+fai at fluffbunny.de
Tue May 5 23:58:47 CEST 2009
[I had to push participation in this mailing list aside for quite some
time, trying to catch up]
Henning Sprang wrote:
> Russ Allbery wrote:
>> Hm, that's interesting -- I didn't think about trying that route. How
>> do I specify a different base.tgz to unpack in the newly created file
>> system? It looks like the path to base.tgz is hard-coded into
>> subroutines-linux, at least in the version I'm currently looking at
>> (which isn't the latest).
> The task extrbase looks in the directory "basefiles" inside the fai
> configspace for a file
> CLASS.tar.gz - for any of the clases defined for the host currentlyx
> being installed.
I disliked this kind of behaviour, that's why I rewrote the hook in my
configspace. I don't recommend it for the faint of heart, just to show
a different possibility.
I was faced with having to install
- Debian Etch/Lenny/Speedy/Sid
- Ubuntu 8.04 8.10 9.04
- SuSE Linux Enterprise Server 10 / 10SP1 / 10SP2
in 32 and 64 bit which would mean I had to find names for 20 classes,
(which are never used elsewhere) just to be able pull in the correct
base image. (And _never_ have a base.tgz in your nfs root, or fai would
always use this one. At least if i recall correctly.)
The most significant change to default behaviour is, that integration
of Debian Speedy (current "testing") was just a question of allowing
the variable OS_VERS to assume the value "speedy". (I set these during
execution of a different script in class/...) Because no valid base
image can be found, debootstrap is used automatically. Ubuntu 9.04 would
have been equally easy, but the appropriate debootstrap script was
missing from my nfsroot. (I blame Debian Lenny.)
Doing it the canonical way would have meant to create 2 new classes e.g.
BASE-DEBIAN-SPEEDY-X86_32 and -X86_64 and either provide base images or
also create 2 new files BASE-DEBIAN-SPEEDY-X86_32.var and -X86_64.var
in $FAI/classes which contain the correct FAI_DEBOOTSTRAP variable.
This script assumes there are 3 variables
OS_TYPE (Debian, Ubuntu, SLES)
OS_VERS (etch/lenny/speedy/.. or
OS_ARCH (X86_32 / X86_64)
which define the operating system to be installed.
hint: You can provide these variables at the boot-prompt.
There's also an unconditional "cat" in line 27 - it's a recent addition
and I didn't found the time to properly secure this command.
the scary stuff
(Please keep in mind that I controll 4 very different FAI-environments
with exactly the same config-space.)
There a other variables, most importantly:
SWREPO the location of the base-files, it doesn't hurt if it's
not defined-> the default behaviour kicks: $FAI/basefiles
(I didn't like to have to carry these multi-megabyte files
in my config-space all the time.)
In my environment a so called IDENTITYFILE is written during execution
of the scripts in $FAI/class/. It holds a lot of different options and
is used mostly to limit the number of classes. (I'm using classes mostly
to define which "major building blocks" this installation should contain
and define small environment- or host-dependent settings in the identity
I'm also patching fai on the fly, so I don't have to remember to
patch the nfs roots after an upgrade. This behaviour is customizable
via a script in $FAI/class/.
install_packages -> "and"-patch
fai-do-scripts -> "perl"-patch, if necessary
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the linux-fai