[plug] FAI, anyone?

[Daniel Pittman]

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.