apt-class WAS: fai next level

[Chad Walstrom]

On Wed, Nov 14, 2001 at 02:44:30AM -0800, Diane Trout wrote:
> How about "apt-class"? 

Unless the tool will rely upon apt and dpkg alone, I would stay away
from the apt-\(.*\) namespace.  Currently, the classes that FAI uses are
defined by two things: scripts and lists.  The scope of a class is far
greater than the packages that FAI installs; another reason to stay away
from the apt-\(.*\) namespace.

> In my mind the program is designed to be run on client machines, it
> receives a class list from some external source (in my case from
> cfengine). From that list it determines what packages should be
> installed, removed, and perhaps held. 

Tom has listed a softupdate script that's in the workings, and it has
promise.  FAI is actually a very client-oriented installation scheme.
The BOOTP/DHCP client mounts the FAI root directory and share
directories over NFS, then executes rcS_fai.  Classes are defined, tasks
are performed.  It's all very client-centric.

The next step is really to clean up FAI as it is so that more of the
tasks can be re-entrant.  In some cases, this may be as simple as
keeping a state file in ${target}/var/state/fai for each task.

	e.g. task_install 

> Looking into the problem slightly further, it looks like the easiest
> solution is to write out a selections file that could be installed via
> dpkg --set-selections and then use a apt-get dselect-upgrade to
> actually initiate the upgrade.

I believe FAI already uses this.  I recall seeing such calls in the
rcS.log file.  I'll have to look at it closer, but I'm still of the
opinion that

> It should be pretty easy to parse the current FAI package_config file
> format. Though I'm not really sure what the difference between a
> "PACKAGE taskinst" and just specifying task-* as a package is.

taskinst???  Do you mean "install"?

Just to bring you up to date on the Debian "tasks", they're rethinking
the whole "task" structure.  If you haven't noticed already, but the
"task-\(.*\)" packages have slowly been disappearing from the Debian
tree.  A perfect example is the task-devel-common file that I had to
remove from our FAI package_config/DEVEL list.

> To take advantage of the hold state, I'd need to add a "PACKAGE hold"
> to the current package_config file format. A held package won't
> be upgraded without being removed from the held state.

That would be nice.

> As far as I can tell the consequences of the design are:
> 
> * A package can have the following desired install states: install, hold,
>   deinstall, purge, and unknown. 
> * To prevent a package from being automatically upgraded it would have
>   to be placed in the "held" state, things in the unknown or install
>   states get upgraded.
> * apt-get dselect-upgrade can deal with constructing the dependency list.
> * apt-get dselect-upgrade ignores package names that don't exist in
>   the available database. (solving the original problem with apt-get)

I'm skeptical about this one.  I recall the apt-get dselect-upgrades
failing on me as well as that standard "upgrade" target.  Either a
package pre-verfication run has to be made, or we need to chunk out the
packages into smaller bites.  That way a failure won't be a total
failure.  If apt could be altered to do the "best it can" with a
package install list, that would be idea.

> * there really isn't any error handling of packages not being in the
>   archive. 

Exactly.  One of those reasons I think a state-based install would
benefit us greatly.

> I was thinking of writing it in either C++ or Python, any preferences?

Bash, unless you're willing to commit us to installing Python on our
systems as well, or porting your C++ tools to a number of architectures.
Currently, we can't get a working install without Perl.  This is
unfortunate.  I know there are developers working on tools to make
Python a necessity as well.  Again, unfortunate.

> Also what can be done about packages that are reading/writing to the
> console? The best solution I thought of is to provide a timer that can
> either kill the install or send email after some delay. However for
> the email to be useful the program would need to provide a way for the
> sysadmin to log into the machine and connect to the apt-get session.

debconf already addresses this issue with it's non-interactive target.
If you would like to help out in this regard, start uploading NMU's to
existing packages that you stumble across.  There are other ways to get
around this as well: expect scripts, mkdivert, FAI hook scripts.

The really unfortunate/fortunate thing about FAI is that you're forced
to learn a lot about your systems and the tools you use to manage them
in order to make the install work.  Tom has given us a great head-start.
We just need to help him clean it up a bit.

It'll always be a custom job to install FAI.

-- 
Chad C. Walstrom <chad at ima.umn.edu>             http://www.ima.umn.edu
Assistant Systems Manager, IMA                  Phone: 612-624-4353
                                                Fax: 612-626-7370