[plug] FAI, anyone?

[Marcos Raul Carot Collins]

Actually, the scenario is quite different.

I just want to avoid the need to boot a netboot cd, and to go through the 
questions in the debian installer.

What I exactly want is to install as soon as I pxe boot a computer in a subnet 
to get a standard debian with KDE, with absolutely no need to be checking the 
computer, until all finishes (or an error happens).

At this stage, I don't want to customise anything, just install a Debian as 
close as possible as it would be just pressing enter in the debian installer 
:p +KDE and a few other things (gimp, amarok, a couple language packs...)

And all of them should be the same (other than always install the latest 
version of the package available in debian testing).

I do appreciate all you shared with us, and obviously is a lot of great 
advices that would be great in a business / production environment :) Thanks 
for that!

The part that I don't understand is how a class is (automatically?) selected. 
If I have only one class, I am not sure how to write it too... I mean, the 
example that comes with FAI has some logic built in that I am not sure if it 
HAS to be there, or I just could delete everything under /srv/fai/config and do 
my own. 

Cheers!

Marcos

El Sun, 7 Dec 2008 06:38:46 PM Daniel Pittman escribió:
> Marcos Raul Carot Collins <marcos.carot at gmail.com> writes:
> > Has any of you tried FAI (Full automated Installation) in either
> > Debian or Ubuntu?
>
> Sure.  I have used it in a range of situations to do deployments of
> Debian, Ubuntu, and related environments across a range of hardware.
>
> > I am reading and re-reading the manual but can't understand the
> > classes thingy and how to write my own.
>
> Which part don't you understand: how to set the class of a machine, how
> to use the class to achieve some goal, or what?  Specifics matter here,
> because the way to use them varies wildly.
>
> [...]
>
> > I just want to Install a full Debian system on client computers using
> > FAI.
> >
> > I got to the point where everything works with the sample files
> > provided, but that only installs a very basic Debian over a PXE boot,
> > NFS mounted FS + a local Debian Mirror.
>
> My advice to you: don't do that.  It almost certainly isn't what you
> want to do.  Using FAI to do an initial install is fine, and if that is
> *all* you care about then you should be able to do the following:
>
> 1. Identify the 'task' virtual packages that represent the system you
>    want for the client.
> 2. Add those to the list of packages for your baseline class.
> 3. Huge Profit!
>
>
> My guess is that you want more than rolling out a system in a slightly
> easier fashion than booting from CD, right?
>
> I strongly advise you to invest in using a system configuration
> management tool such as puppet[1], bcfg2, or perhaps cfengine[2] to
> install your packages on a running system.
>
> These tools allow you to configure and manage the running machine
> effectively after the initial deployment, from a central repository.
>
>
> Generally, the best strategy for a fully automated rollout is:
>
> 1. Get a central host database, such as LDAP, that manages all your
>    hosts.
> 2. Ensure that your machines can netboot into FAI, and get a hostname
>    from DHCP based on the central host database.
> 3. Install the most basic system that boots with FAI, and install
>    puppet[3] plus the minimal configuration needed for it to run once.
> 4. Arrange for that tool to run on reboot; this probably doesn't involve
>    any effort these days, since most of them do.
> 5. Reboot off the hard disk.
> 6. Allow puppet to install all the packages and other configuration for
>    your machine, based on the central host database.[4]
>
> Then, when changes happen you can either:
>
> 1. Reboot of PXE, which restarts the above at step 3.
>
> *OR*
>
> 2. Update the puppet configuration, which reconfigures the running
>    system to match the new configuration, and life goes on.
>
>
> I strongly advise that you use option 1 for major changes, which is some
> effort, but ensures that you can build a clean system from scratch.
>
> (Speaking of scratch, always test your changes on a scratch VM or
>  machine before pushing them to production. ;)
>
>
> This is more work, but gives you a lot more benefit in the long run.  As
> an example, at work we recently needed a computer in the data center for
> an emergency.
>
> So, we shut down one application server, changed the hostname in DHCP,
> rebooted it and viola, one replacement server meeting the emergency
> need.
>
> To restore, when the real replacement came in, it we simply changed the
> hostname in DHCP back, rebooted and, viola, a working application
> server.
>
> Regards,
>         Daniel
>
> Footnotes:
> [1]  This is currently the best practice solution.
>
> [2]  If you are massochistic.
>
> [3]  ...or your tool of choice, naturally.
>
> [4]  This may source data directly from the database, or it may go
>      through the medium of the hostname.
>
> _______________________________________________
> PLUG discussion list: plug at plug.org.au
> http://www.plug.org.au/mailman/listinfo/plug
> Committee e-mail: committee at plug.linux.org.au