Re: CDD Tool Proposal
On Thu, 23 Dec 2004, Andreas Tille wrote:
> also my problem, but from the first time I learned to know about FAI
> (it was in Bordeaux 2001) I was amazed and I would really love to
> integrate FAI in a reasonable way into CDD stuff. My problem with the
> previous mail was that it sounded if we could replace all what we did
> just by FAI.
FAI already does much of what was proposed:
> The CDD Meta-data Package
>
> The basic idea is that each CDD could be distributed in source form
> using a single deb package. This package will contain all the meta-data
> needed to install the CDD (or generate a system to install it) using the
> tools described here.
FAI doesn't yet package up a class description, but this is minor.
> For this tool a CDD is defined as a set of tasks that will be used to
> install the system; each task declares a list of packages that have to
> be installed and includes the information needed to configure them. All
> the information will be declared using a file that uses a format similar
> to the Debian Control Files.
FAI does this.
> Of course, if a task needs to add configuration data that will be
> declared on the CDD control file and will be distributed with it.
FAI does this, but yes it violates policy in several ways.
> Currently the configuration data that can be included and distributed
> includes debconf answers for the debian-installer and for the system's
> debconf and scripts that have to be executed after the package
> installation (needed to do things that can not be done with debconf
> pre-seeding) or before package or task removal.
FAI does all this, someone offered a debconf pre-seeding proof of
concept a while back on the linux-fai list.
> Other configuration data like special user menus can also be included on
> the CDD meta-data, but for other things like branding proper debian
> packages are probably a better idea and can be included on the task
> dependencies.
FAI can do this.
> The CDD Tool
>
> The idea is to have a single tool that acts as a fronted to all the CDD
> utilities, the syntax would be something like the following:
> * build: builds metapackages, task lists, installation CD, etc.
> * get: downloads all packages needed for the CDD (similar to
> debpartial-mirror)
> * install: installs all packages related to a CDD task applying
> preseeding and executing configuration scripts
> * update: updates all packages related to the CDD keeping
> customizations (without making questions to the user)
> * reconfigure: reconfigures all the packages included on a CDD task
> * remove: removes all packages related to a CDD task
> * purge: purges all packages related to a CDD task
FAI doesn't do this - class definitions are manually built, but
packaging them as above would allow this.
All I'm trying to say is FAI enables much of what you guys want. Its
primary goal is unattended installation, but in achieving this they've
defined "custom debian distribution" classes specifying which packages
to install, which to remove, pre/post install scripts, copy pre-built
config files, automate disk partitioning and formatting, perform the
installation itself etc. I'm not suggesting that FAI does everything
you want, or that the solution is to work on FAI, or even that CDD is
the solution.
What I'm saying is that FAI, CDD and debian-installer are all trying
to solve the same basic problem. Why not work together? Why
duplicate effort, not just in the implementation but in the concepts and
process flow? FAI has done a lot of groundwork, it would be a good idea
to see what they've learnt and take advantage of this knowledge instead
of repeating the same mistakes. At the very least, I'd work with FAI to
combine the FAI class and CDD meta-data concepts so that both projects
benefit from such an easy win. Concentrate on defining and packaging
the meta-data, and leave installation to FAI for now. Just get it
installing to a local chroot. Then I'd be looking at debian-installer
and investigating what's required to port all of FAI's functionality to
it, I believe most of the hooks are already there, and a single keypress
installation proof of concept has already been built. Maybe use udebs
for your CDD meta-data.
Why am I not doing this myself? I simply haven't had the time. But
I've thought about all of this a LOT over the last 2-3 years while
implementing fai-bootcd and building a large, national network of
"custom debian distributions". So I'm hoping that someone with time
is reading this and can see these and other commonalities across Debian
projects.
The logical place for all of this is with the debian-installer - allow
Debian GNU/Linux to have non-interactive installation of any CDD out of
the box. A CDD description could reside on a floppy or USB keyring, and
you could install it with any Official CD. Everyone wins! They could
even replace the old task packages, and some of the most popular CDDs
could be on the Official CD.
Just don't go down your own path, alone. Work together. Combine
resources and build a common standard, then aim for a stable sid release.
This advice is all I can really offer to the project at the moment.
Niall Young iiNet Limited
niall@staff.iinet.net.au Level 6, 263 Adelaide Terrace
Ph: (+61) 08 9213 1330 / 0408 192 797 Perth, Western Australia 6000
"Nothing for you to worry about; just skip where you see
impossible data."
-- Nick Andrew, May 2004
Reply to: