On Wednesday, Sep 4, 2002, at 12:30 US/Pacific, Jason Frisvold wrote:
[..]
>
> Any idea on how to do this? Thoughts? Suggestions? Code!?
>
> ---------------------------
> Jason H. Frisvold
first off, I totally agree with phi - there is no quick
and easy solution... but some experience I have lived
through may help you work out which horror you wish to
live with down the road...
My personal experience is that you just stepped into
the usual 'config file management problem'.
Plan A: write the code to read only the 'real things you need'
and leave the problem of 'configuration file creation'
to some other process.... as noted, R. Schwartz
provides a way at this with:
http://www.stonehenge.com/merlyn/LinuxMag/col38.html
Plan B: build the all in one solution that cache's all possible
combinations of everything that ever could be into one
huge virtual machine capable of doing everything.
I put Plan B in a somewhat unpleasant light - since what started
out as an effort to 'automate' and 'source code control' the
configuration files - and then the input into the configuration
file generator - lead ultimately to a place where while it was
just 'fabulous' for being able to quickly generate config files
for say
a) the developer's net
b) the QA test net
c) operation's Acceptance Network
d) Operation's Production Network
right up until Operations went to shift to a whole new configuration of
boxes as 'an alternative back up Production network' - they
ran into the problem that the default configuration stuff
that was suppose to be pulled from the 'source code control
system' on NFS cross mounted file systems - had no idea what
to do with the new hostname schema.... let alone the fact that
they didn't have the NFS cross mounted file systems, access
to the network where those servers resided, nor any of the
source code control software to check out....
Plan C: a configure at install process model....
C1: Those with a background in the System V 'packages' and/or
the WIN::* registry approach - will be aware that you can
create 'package dependencies' - so that before you can
install 'WARPfoo' - one has to have installed 'WARPcore' -
which sets up all the basic 'config file basics' for
that network... This will allow the distinctions of
networks to be defined when that first WARPcore package
is pkgadded to the system - and your package comes along
and checks with it to find the basic things that you
need to define your configuration file information
relative to it....
C2: don't build that dependency upon a pre-existing
package being in place before you - and build the
more interesting 'gnu like' Configure process that
will try to resolve as much as it can, and then ask
the player what to do with anything it can not answer.
{ this works well for those who are accustom to having
a full build suite of tools... }
plan D: the ubiquitous zeroConf solution
find a protocol language that is secure and accessible
everywhere that will allow you to cache all possible
configuration information in a safe place that can
be authoritatively accessed when code is installed
and/or executed in such a way that will allow it to
safely re-configure itself.... then build the front
end management tool set that will maintain that
authoritative repository...
remember this will mean that your solution will have
to be able to install a host local replicating solution
that does not require network access to any external
resources....
ciao
drieux
---
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
