Hi! > hiya > > >> If FAI isn't told anything, then the result of the installation will > >> be a SuSE Linux Enterprise Server (SLES) 10 in 64bit. If you tell fai > >> to install a 32bit machine, then this results in a 32bit SLES. If you > >> just want a Debian Box, then you'll get Debian Lenny / 64bit. If you > >> just want a "debian style" box, then this will result in a Ubuntu > >> 8.04LTS. > > >> Any other ideas? > > > Just use the FAI classes for this. You can write a very intelligent > > program (or script) that prints a FAI class to stdout, for > > e.g. UBUNTU08 or SLES10_64. > > Maybe I didn't make myself clear enough. I don't want to address the > implementation (that part is already done and working very well), but the > decision-finding. (In the simplest case it's just "Always install OS foo > in version bar.") >
To be honest, Thomas (Neumann), it's still not quite clear to me. What exactly, i.e., which step of a FAI run, do you mean by "decision-finding"? I'm trying to detail my questions and thoughts below, but please keep in mind that by no means I think that FAI is already perfect and that your setup is sub-optimal; you surely have good reasons that your setup is precisely the way it is at the moment and we should absolutly seek ways to improve FAI to simplify setups such as yours. Still, I don't yet understand all details of the problem and would thus ask for further clarifications. > > > On a sidenote: I ~hate~ using classes for this. Mostly because when using > the default fai scripts and hooks you need a class for every aspect of the > OS (Linux Flavour, OS Version, architecture) and _also_ quite a lot of > helper classes. > > Classes I would need: > > "descriptive" classes > > flavour: Debian, Ubuntu, SLES 3 classes. > version: etch, lenny, squeeze, sid, hardy, 10SP2, 10SP3, 10SP4 + 8 classes. > architecture: x86_32, x86_64 > + 2 classes. Most notably, you need all these classes because they have distinct requirements. I'm not sure whether you doubt this at all, but anyway: If you don't use classes, you'll use some other $foo. Anyway, you will have 13 $foos. > "helper" classes > > DEBcommon (packages that are the same in Ubuntu and Debian) > DEBIAN_32 (installs linux-kernel-2.6-i686) > DEBIAN_32-xen (installs linux-kernel-2.6-i686-xen) > DEBIAN_64 (installs linux-kernel-2.6-amd64) > DEBIAN_64-xen (installs linux-kernel-2.6-amd64-xen) > UBUNTU-xen (installs linux-image-2.6-server-xen) > SLES10 (installs kernel-smp) > SLES11 (installs kernel-default) > SLES10_32_VMware (installs kernel-vmipae) > SLES10_32_VMware (installs kernel-vmi) > Ok. Now these may or may not be necessary (depending whether or not you use the "and"-patch, as you discussed below). For example, the DEBcommon class can be replaced by !SLES if you use the "and"-patch, or DEBIAN UBUNTU without the "and"-patch. But that's a detail. My main point is that you will always need some $foo that distinguishes these 9-10 different combinations of hardware/OS/version, unless your mix of distros has something in common. > and also one BASE_$flavour_$version_$arch class for each installable OS to > pick up the correct "base.tgz" (Would total in 16 classes currently.) > Because these are different. > One could also differentiate even further - as of SLES10SP2 zypper has > become available as an installation tool. Sadly the command line syntax > has changed between SLES10SP2 and SLES11, so you have to treat both > zyppers differently. > Still, at this point you only need to distinguish SLES10SP2 and SLES11, you need not care about $arch, $flavour, etc. > > Using the "and"-patch for install_packages has lessend the number of > "helper"-classes quite considerably, but I still found it necessary to > rewrite/extend the following hooks: configure, debconf, extrbase, > instsoft, partition, prepareapt, updatebase. > I might be lacking the necessary creativity to see a solution, but to me it seems that you do have all those different aspects and you need to tell FAI about this. Therefore you need some $foo that describes those aspects. Within FAI that is called a class. Regarding the huge number of hooks: I'd really think that these should _not_ be necessary and instead be patched in mainline. Maybe some of hooks are necessary because you do multi-distro, but the new FAI website broadly claims that it supports a large number of distros, so it should better really do so. Best, Michael
pgpcbWljZtdYw.pgp
Description: PGP signature
