Thank you and good bye.

[Thomas Neumann]

hiya
[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
                gutsy/intrepid/jaunty or
                10/10SP1/10SP2)
   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.)

   IDENTITYFILE

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 
file.)


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

tschüß
thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: extrbase.DEFAULT
Url: http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20090505/e50b6ce1/attachment.bat