[plug] FAI, anyone?

[Marcos Raul Carot Collins]

Sonds good, as long as it can be done using PXE.

Last time I tried using the netboot debian image within pxe, it fails to get 
an IP AFTER it has loaded the installer, so can't contact the repo... :S

Anyway, I am looking into FAI because its possible that I may use it for 
business down the track, so gaining experience is good :)

Still, there must be something that doesn't click into my mind, because in all 
the tutorials I have read, the classes thing is treated as an obvious step 
that is supposed to be understood :P

I still don't get how classes are selected...

Cheers!

Marcos

El Sun, 7 Dec 2008 08:36:19 PM Adrian Woodley escribió:
> 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
>
> _______________________________________________
> 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