On Fri, Jan 30, 2004 at 04:29:33PM +0100, Steinar H. Gunderson wrote: > On Fri, Jan 30, 2004 at 02:58:41PM +1000, Andrew Pollock wrote: > > From my experience, what I believe the automated installs in d-i to do (not > > having seen it done or tested it yet), it's not going to scratch the surface > > of the functionality that FAI does, and FAI pisses all over KickStart for > > flexibility (with the appropriate increase in learning curve and > > complexity). > > Well, could you please elaborate a bit on what FAI could do that d-i will not > be able to do? (Ie. some sort of "requested feature list". :-) ) Also, will > FAI work for sid at all? (I can only find references to woody in the > documentation.)
I don't see the value in trying to make d-i be FAI, but here's some more info... FAI uses classes. These classes are used throughout the decision making process for configuration, package installation, etc. I liken it to allowing you make your Linux build process a jigsaw puzzle or a Lego toy. You can break down the components of what makes your installed system into components and assemble them how you wish. To give you a specific example, where I work, we have an Internet gateway. We have boxes that act as proxy servers, mail and DNS servers, NTP servers etc etc. I can specify a combination of classes for a particular installation to suit what that box's function is going to be, and where it will sit on the network for example, and FAI will install the relevant groups of packages I have predefined, and copy appropriate /etc/hosts, /etc/resolv.conf, /etc/ntp.conf (you get the idea) files appropriate for that particular class. FAI boils down to allowing you to manage a whole infrastructure. I'm just using it in one particular way, there would be many other ways than what I've described. FAI relies on a central (NFS) server to house all the FAI specific configuration, which is uses during the initial boot that performs the installation, whereas d-i would have a pre-made (more flat, ala KickStart) configuration, which is more like an unattended install than something modular. > > I think d-i automated installs and FAI will both have their place, going > > forward, for different reasons. d-i may be good for a bare-metal recovery of > > an existing installation, whereas FAI is probably going to be better at > > deploying new installations on inconsistent hardware (I use it to run up > > infrastructure servers, on random hardware). > > Hm? Why shouldn't d-i be able to handle inconsistent hardware? I mean, we > have discover and autopartkit; what else should touch hardware too much? True. I think what I was trying to say was I can have an install and all the appropriate class stuff setup such that I can have a proxy server built on a Dell 1650, which uses SCSI disks and an Intel EtherExpress NIC, or an IBM xSeries, which uses IDE disks and a Broadcom chipset, and I don't have to use discover in the end result, just during the initial FAI stage, and FAI determines which NIC I have and aliases eth0 appropriately. FWIW, I'm not a big fan of running discover all the time. I find the crap is spits out on bootup quite gross, and I think it would be disturbing for some inexperienced users. It would be better if discover ran once during installation, and added appropriate module aliases based on what it discovered... Just my 0.02 dollars worth... Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]