Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] [Cauldron] Install Ideas...

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] [Cauldron] Install Ideas...
  • Date: Wed, 16 Apr 2003 14:42:43 -0700

cool! the only thing i have to say is make sure there is a way to override
the preconfiguration stuff at any time, or step through things in the
slow manual way, ie what we have now. I really like being able to pause,
skip ahead or bail to a command line for a while.

I'll be happy to test net installs. I have a few boxes that are ready
to go for such a task.

On Wed, Apr 16, 2003 at 02:34:22PM -0700, Wyatt Draggoo wrote:
> Howdy all,
>
> I thought I'd toss out the ideas that Ryan and I had about Cauldron. I was
> going to head up that project, but a change in job positions has left me
> with zero free time to work on anything. I really hope this situation
> changes, but for right now, there's not a lot I can do about it.
>
> Some of these are related to each other, but I'm going to throw them out in
> the order I can remember them. Both my notes and my code are on a backup
> tape that got lost during the same move that drive crashed on. I guess
> there is something to be said for offsite backups. :)
>
> 1) Order of the installation:
>
> I had planned to do the install in two parts. The first part would ask all
> the configuration questions, and keep the answers in a config file. The
> second part would read that file and perform the install. This was to set
> up automated installs where cauldron would look for a config file at the
> beginning of the install, and start the install after a timed prompt using
> the provided config file. By the same token, the install would look for a
> .config file for the kernel and compile the kernel using that file if the
> previous portion of the install had been automated.
>
> The only thing that I hadn't taken the time to figure out yet was how to
> specify disk partitioning in the config file. I use Solaris here at work,
> and had thought of something along the lines of how Jumpstart partitions
> the disks, but hadn't decided on anything.
>
> 2) Networking first.
>
> To go along with the first part, I wanted to set up networking as one of
> the first install options. This in turn paves the way for network installs
> (think of an install from a floppy instead of a CD). The install would
> pull the basesystem down from the net and then continue the install
> process, downloading all the sources for a compile using the normal SMGL
> tools.
>
> 3) Local SMGL Server.
>
> This has been brought up on the list in the past couple of days, but I
> think it is very important to cauldron. By being able to specify a local
> SMGL server in the initial config file, you could even keep the majority of
> the config options, the kernel .config file, a custom grimoire (think
> companies who only want a specific set of spells on their systems), and the
> source file for that grimoire on a local server.
>
> This may be confusing because I hadn't named the files yet. :) Let me see
> if I can describe the files in a walkthrough of the full, automated network
> install:
>
> a) System boots from a floppy, and searches for an init.cnf file (making up
> names now for clarity). This file has the networking options, and
> specifies SMGL server.
>
> b) System loads the network modules, and sets up the network according to
> the init.cnf file.
>
> c) System downloads the base system, and hands control off to Cauldron.
>
> d) Cauldron checks the SMGL server for the smgl.cnf file. This is the file
> with the rest of the install options, including partitioning, timezones,
> etc.
>
> e) Cauldron performs the install according to the smgl.cnf file.
>
> f) Cauldron checks the server for a kernel config file. If found, it
> downloads this file and uses it to compil the kernel. If not found, it
> compiles the kernel with a default configuration.
>
> g) Because the install is automated, a continuation init script is added
> that will continue the install after a reboot. Upon reboot, this script
> will perform the scribe update and sorcery rebuild.
>
> h) Lastly, cauldron checks for a spells.cnf file, which is a list of spells
> to be cast. These are cast on the fresh system.
>
> Keep in mind that this is for the fully automated install, and that any of
> this should be able to be overridden or done manually. Boot from the
> floppy and do a manual install from the network, for instance.
>
> My goal was to be able to boot from a single floppy (or boot of the network
> even, although I've never played with that) and be able to walk away and
> come back in a few hours (or, in reality, the next morning :) to a fully
> compiled, updated sorcery system with a known set of spells already cast.
>
> Writing it all down in an email makes it seem quite complicated, but broken
> down I don't think it's all that bad. It's a boot floppy, two or three
> config files either on the floppy or on a server, and a server with the
> files shared out some way, be it ftp, http, nfs, etc.
>
> This could even pave the way for fully tested installs set up directly on
> sourcemage.org. Have a spell list for a gaming system, a server system,
> etc. This is probably way off in the future, though... :)
>
> Anyway, I thought I'd share my thoughts. I think this would be a very
> flexible system, and very powerful, both for individual users and for
> businesses that need to roll out large install bases.
>
> Wyatt
>
> --
> Wyatt Draggoo
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>From charkins AT upl.cs.wisc.edu Wed Apr 16 18:07:59 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 CB2F820047
for <sm-discuss AT lists.ibiblio.org>;
Wed, 16 Apr 2003 18:07:58 -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 8725027F76; Wed, 16 Apr 2003 17:07:58 -0500 (CDT)
Received: by data.upl.cs.wisc.edu (Postfix, from userid 26694)
id 4929D17AC5; Wed, 16 Apr 2003 17:07:58 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1])
by data.upl.cs.wisc.edu (Postfix) with ESMTP
id 363B013C8F; Wed, 16 Apr 2003 17:07:58 -0500 (CDT)
Date: Wed, 16 Apr 2003 17:07:58 -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:
<20030416143429.2483.h017.c001.wm AT mail.draggoo.com.criticalpath.net>
Message-ID: <Pine.LNX.4.44.0304161638460.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 22:07:59 -0000



On Wed, 16 Apr 2003, Wyatt Draggoo wrote:
> 1) Order of the installation:
>
> I had planned to do the install in two parts. The first part would ask all
> the configuration questions, and keep the answers in a config file. The
> second part would read that file and perform the install. This was to set
> up automated installs where cauldron would look for a config file at the
> beginning of the install, and start the install after a timed prompt using
> the provided config file. By the same token, the install would look for a
> .config file for the kernel and compile the kernel using that file if the
> previous portion of the install had been automated.

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

> The only thing that I hadn't taken the time to figure out yet was how to
> specify disk partitioning in the config file. I use Solaris here at work,
> and had thought of something along the lines of how Jumpstart partitions
> the disks, but hadn't decided on anything.

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

> My goal was to be able to boot from a single floppy (or boot of the network
> even, although I've never played with that) and be able to walk away and
> come back in a few hours (or, in reality, the next morning :) to a fully
> compiled, updated sorcery system with a known set of spells already cast.

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! ;-)

> Writing it all down in an email makes it seem quite complicated, but broken
> down I don't think it's all that bad. It's a boot floppy, two or three
> config files either on the floppy or on a server, and a server with the
> files shared out some way, be it ftp, http, nfs, etc.

I don't think it really sounds that bad.

> Anyway, I thought I'd share my thoughts. I think this would be a very
> flexible system, and very powerful, both for individual users and for
> businesses that need to roll out large install bases.

The latter is where I'm at right now, well, not really "large", but more
than I want to do individually. Add to this that I have two offices (600
miles apart) with about 20 workstations between them, plus 6 workstations
for people working out of their homes (with no high speed connection).

I've started working on the iso building script for this purpose. Once
completed, I'm going to roll out a custom installer for our internal uses.
I'm actually going to use a single sourcemage "build" system, and
distribute binary packages to the workstations through the custom
installer (which will be included on the installation cd). Once installed,
there will be a very simple update script which will grab updated binary
packages from a directory (nfs for offices, cdrom for remote users). If
something breaks, they just pop in the installation cd for a fully
automated re-install. The installer will even leave the "/home" and
possibly a "windoze" partition alone for remote users.

I need to have this done by the end of May. After that, I'd be happy to
aid the CAULDRON team with their duties, taking into account all that you
have mentioned here.

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.

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.

OK, I'm really rambling now...

-casey







Archive powered by MHonArc 2.6.24.

Top of Page