--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 11, 2003 at 11:05:48AM -0700, dann frazier wrote:
> On Mon, Feb 10, 2003 at 11:25:35PM -0600, Brian Elliott Finley wrote:
<snip>
> > Specifically, I like:
> > * The idea of having a database for tracking client information
> > -- this ties in nicely to some design ideas that are currently
> > on the table.
This exists in SIS today via SystemInstaller
> > * The database being a text based database.
Although not text based for ease of implementation, the db is easily
accessed from perl.
> > * Breaking up the autoinstall scripts into components, and
> > having clients pull the pieces they need.
> > * The idea of eliminating the symlink "database".
With the mapping in the SIS database, per client autoinstall scripts as the
default would be the best approach
> > * The EXTRA_SCRIPTs idea -- being able to call arbitrary scripts
> > from within the autoinstall script framework.
This was added to SystemConfigurator with the 2.0.0 release (Oct/Nov '02).=
=20
The functionality is call USEREXIT. The excerpt from the SC man page is
included for reference:
[USEREXIT\d+]
System Configurator supports an arbitrary number of user
exits. Each user exit will be run in turn. The user
exits are the last things run by systemconfigurator, so it
will have full access to the client operating system. The
first user exit to return a bad exit code will stop the
processing of the rest of the user exits.
Each user exit block takes two stanzas.
CMD The command to be run (e.g. touch). If the command is
not found, or not executable, this user exit will be
skipped.
PARAMS
Any parameters needed to be passed to the command.
Future versions may allow the passing of other vari=AD
ables that System Configurator has access to, but this
is not yet supported.
<snip>
> phase 1 could be having a config file for each clienttype, which=20
> contains all meta information - /etc/sis/clientdefs/<mastername>.
> mkautoinstallscript could use that information for generating master scri=
pts
> (which would definitely help upgrades).
If you used the SIS db, and added other meta info a required, you could use
existing infrastructure to do this.
> phase 2 could be removing the symlinks, and having a config file(s) that
> associates nodes with images.
You would get this for free if mkautoinstallscript used the SIS db to gather
its info about a client
> phase 3 could be adding /etc/sis/partitionschemes/, and referencing them
> from within /etc/sis/clientdefs/<mastername>.
Adding DISK info to the SIS db has been a goal for a while. Mike C-S has a
more info about the designs we kicked arround. Again, if
mkautoinstallscript talked to the SIS db, it would "just work".
> phase 4 could be adding a PRE_INSTALL / POST_INSTALL options to the clien=
tdefs
> configs, to enable adding arbitrary scripts, and having a defined environ=
ment
> for those scripts (you can find your IP in the IPADDR variable, etc).
You can do this today via USEREXITS
> phase 5 could be breaking up the master script and eliminating its need
> to exist (and therefore the need to be regenerating), by making the insta=
ll=20
> client smart enough to grabbing the appropriate pieces it needs at runtim=
e.
You would have to add a lot more logic on run time to the client. I would
state this is a bad idea because the fact that BOEL is pretty dumb, and the
scripts it runs are smart (and static). This is great benefit as there are
a small number of moving parts on the client, and anything that goes funky
can usually be corrected by vi on the server. If the code was in the
client, you'd have to rebuild BOEL for a fix, which would suck much more.
> this evolution could take a week, and make the next release, or a few mon=
ths,
> and be spread over a couple releases, but would allow us to keep things in
> a pretty-much-releasable-state at all times.
>=20
> if this phased approach makes sense, i'd be glad to write-up a more formal
> outline of possible phases, and a brief summary of each, then we can disc=
uss=20
> the outline, and began adding more detail (here's the options in config
> file foo we'll support, and how we'll upgrade from earlier versions, etc)=
until
> it becomes a plan.
-Sean
--=20
_______________________________________________________________________
=09
Sean Dague [EMAIL PROTECTED] http://dague.net
There is no silver bullet. Plus, werewolves make better neighbors than
zombies, and they tend to keep the vampire population down.
_______________________________________________________________________
--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE+SUMLSamXem9TdyYRAtDpAJ48ndU+RfLCc4tRt+GX80UseaJwKgCfbQtZ
WEEbpTvoJjc6P/lwkUCVN8Y=
=LJxG
-----END PGP SIGNATURE-----
--zhXaljGHf11kAtnf--
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
