Public SourceMage Discussion List

["Wyatt Draggoo" <wyatt AT draggoo.com>]

On Wed, 16 Apr 2003 17:07:58 -0500 (CDT), Casey Harkins wrote:

> Specifying which kernel and patches would need to be an option too.

Oh, right.  I don't think we had those options when I started this... :) 
It might be possible to keep these in the SMGL config file, and have
cauldron write the file that keeps the linux spell options.  Not sure,
though.

> There are basically two options:
> 
>   1) store part info in format suitable for passing to sfdisk
>   2) store part info in our own format and use this to produce
>      input for sfdisk, I recommend #1 for simplicity

The first is simpler, but I like the second because there isn't any
gaurantee all the drives are the same.  Being able to set certain
partitions, and then add the rest of the drive to a /data partition is a
good example of this.  Although, this may be possible with sfdisk.  I
haven't looked at it, except to see the multitude of warnings it comes
with. :)

> Actually, you'll come back the next morning to the init.d dialog asking
> which scripts to update. This of course happens during the 'sorcery
> update', so you haven't even started the 'sorcery rebuild' yet! ;-)

Oh yeah.  I forgot about that. :)  Is this behaviour being changed?  This
has caught me several times.  Darned annoying.

> I'd also like to look into a more versatile binary packaging system for
> sourcemage. I know this goes completely against the SMGL ideals, but could
> be extremely useful for large installations to similar hardware (corporate
> desktop environs, clusters, server farms, etc). I actually looked into
> using SystemImager[1] for this purpose and even have spells for it and
> some of its dependencies. However, the SystemImager approach does not work
> well for my remote users. While my work in this area doesn't need to be
> part of SourceMage, it will be tied very closely to the sorcery tools.

I know gentoo has a binary system as well.  Haven't looked into it.

> One approach I thought of for binary packages, is to just use
> /var/cache/sorcery and patch cast/sorcery to provide an option to ONLY
> resurrect, never summon and cast.

If the architectures are the same, /var/cache/sorcery could be an NFS mount
to the server.  If the spell hasn't been cast, it builds it and the spell
is cached on the server for other systems to use...

Wyatt

--
Wyatt Draggoo
>From charkins AT upl.cs.wisc.edu  Wed Apr 16 19:26:40 2003
Return-Path: <charkins AT upl.cs.wisc.edu>
Delivered-To: sm-discuss AT lists.ibiblio.org
Received: from enterprise.upl.cs.wisc.edu (enterprise.upl.cs.wisc.edu
        [128.105.45.69])
        by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 58D17200B2
        for <sm-discuss AT lists.ibiblio.org>;
        Wed, 16 Apr 2003 19:26:40 -0400 (EDT)
Received: from data.upl.cs.wisc.edu (data.upl.cs.wisc.edu [128.105.45.42])
        by enterprise.upl.cs.wisc.edu (Postfix) with ESMTP
        id 1FE8E27F7F; Wed, 16 Apr 2003 18:26:40 -0500 (CDT)
Received: by data.upl.cs.wisc.edu (Postfix, from userid 26694)
        id E37C817AC5; Wed, 16 Apr 2003 18:26:39 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
        by data.upl.cs.wisc.edu (Postfix) with ESMTP
        id D0B1013C8F; Wed, 16 Apr 2003 18:26:39 -0500 (CDT)
Date: Wed, 16 Apr 2003 18:26:39 -0500 (CDT)
From: Casey Harkins <charkins AT upl.cs.wisc.edu>
To: Wyatt Draggoo <wyatt AT draggoo.com>
Subject: Re: [SM-Discuss] [Cauldron] Install Ideas...
In-Reply-To: 
<20030416161115.10180.h017.c001.wm AT mail.draggoo.com.criticalpath.net>
Message-ID: <Pine.LNX.4.44.0304161816140.25830-100000 AT data.upl.cs.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: sm-discuss AT lists.ibiblio.org
X-BeenThere: sm-discuss AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Public SourceMage Discussion List <sm-discuss.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/sm-discuss>,
        <mailto:sm-discuss-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/sm-discuss>
List-Post: <mailto:sm-discuss AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/sm-discuss>,
        <mailto:sm-discuss-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Apr 2003 23:26:40 -0000



On Wed, 16 Apr 2003, Wyatt Draggoo wrote:

> >   1) store part info in format suitable for passing to sfdisk
> >   2) store part info in our own format and use this to produce
> >      input for sfdisk, I recommend #1 for simplicity
>
> The first is simpler, but I like the second because there isn't any
> gaurantee all the drives are the same.  Being able to set certain
> partitions, and then add the rest of the drive to a /data partition is a
> good example of this.  Although, this may be possible with sfdisk.  I
> haven't looked at it, except to see the multitude of warnings it comes
> with. :)

It is possible to specify that a partition grow to fill the drive, but it
only works for primary partitions. I'm going to play around with it here.
I'm actually leaning towards #2 too. Or, it may be possible that a more
versitle command line partitioning tool already exists.

> > Actually, you'll come back the next morning to the init.d dialog asking
> > which scripts to update. This of course happens during the 'sorcery
> > update', so you haven't even started the 'sorcery rebuild' yet! ;-)
>
> Oh yeah.  I forgot about that. :)  Is this behaviour being changed?  This
> has caught me several times.  Darned annoying.

I don't think it has yet, but I'm sure it will when someone gets around to
it.

> > One approach I thought of for binary packages, is to just use
> > /var/cache/sorcery and patch cast/sorcery to provide an option to ONLY
> > resurrect, never summon and cast.
>
> If the architectures are the same, /var/cache/sorcery could be an NFS mount
> to the server.  If the spell hasn't been cast, it builds it and the spell
> is cached on the server for other systems to use...

I don't like the idea of trusting the clients to build the package, making
the nfs mount read-only would take care of that. Then remote users could
sync up their cache directory to one provided on a cd.

-casey