[plug] FAI, anyone?

[Adrian Woodley]

I'd personally wouldn't bother with the FAI system - a well crafted 
preseed file should be enough to automatically install a system, even 
down to installing KDE/Gimp/etc.

You can specify the extra packages to install using either:

tasksel tasksel/first multiselect standard, kubuntu-desktop

or

d-i pkgsel/include string kde gimp

If you're really serious about it, you could build your own 
meta-packages which depend on everything you want installed. An extra 
repository containing your custom packages can be specified with:

d-i apt-setup/local0/repository string http://your-web-server/path hardy 
custom

The biggest problem I had when first playing with preseeds was getting 
the installer to recognise the file, particularly if netbooting. The 
most effective way I found was to add the preseed to the initrd, so its 
available immediately from boot.

Marcos Raul Carot Collins wrote:
> 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
>>     
>
> _______________________________________________
> 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
>