Date: Sat, 24 Feb 2001 07:55:04 -0800 From: Julian Elischer <julian@elischer.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Terry Lambert <tlambert@primenet.com>, arch@freebsd.org, archie@freebsd.org Subject: Re: Configuration management Message-ID: <3A97D958.6AFC713@elischer.org> References: <3A969CD0.DE9E94E1@softweyr.com> <200102232342.QAA01378@usr05.primenet.com> <20010224142406.A23979@roaming.cacheboy.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Adrian Chadd wrote:
>
> On Fri, Feb 23, 2001, Terry Lambert wrote:
>
> > Even if we stick with "flat text files", and we continue to
> > edit them by hand, instead of using a method with subschema
> > inforcement which makes non-sensical configurations impossible
> > (per Jordan's XML example), the idea that it should be _possible_
> > to easily and efficiently machine parse and write these files
> > using a single API, which can be proxied over a network through
> > a single data channel, is a valid one.
>
> Wow. I'm agreeing with Terry here.
We worked on this for the Interjet at whistle so Terry has the advantage
of having seen prototypes in action and taken part in discussions on it
over a long time.
Basically a namespace that looks at first glance similar to ASN/SNMP
but implemented differently.
Ascii storage came into it. A configuration daemon answered all
requests for configuration information, and it kept it's state in RAM.
It loaded that state at bootup, from an ascii flat file, and
saved new versions of that file after transactios were made on
the configuration database. We used Soft updates and the atomic
nature of rename() along with fsync() to ensure that the database was either
before or after a transaction but always consistent.
There was a lot more to it, of course, but the concept worked well in practice
though we never completely moved all configuration over to it.
We generated config files for 3rd party software
'on the fly' from the general configuration database,
when we wanted to start such a service. Services had templates
into which the extracted data from the database was written.
Data had rules associated, and there was the capability to associate
data in one part of the tree with data in another for consistancy
checking and such.
Since there was an 'on the line' spec for how this data looked
we could write many different 'back-ends' and 'frontends'.
>
> I once worked for a large ISP. They had lots and lots of boxes, and
> they were able to do stuff like install a custom (in-house modified)
> installation of Redhat (or FreeBSD if they really wanted to) which,
> when placed on the network, automagically picked up its "role" and
> configured itself. It then could continue this "role" with periodic
> configuration updates.
>
> How they did it was evil. They had an SQL database(s) with the
> entire network configuration which they then wrote scripts which
> would query the database with the machine hostname, pull down
> a configuration/to-do-list (eg create account "foo", delete account
> "blah", etc..) and then apply these changes locally.
>
> Each application required a seperate set of scripts to maintain.
> I don't think they had a cute way of updating the RPMs on the machines
> besides manually doing it, but I'm sure they've solved that one by
> now.
>
> The point is, in order to go from stand-alone UNIX machines to
> lots-o-machines and have them manageable and flexible required a hell
> of _a lot_ of work.
>
> Just a case study for y'all,
>
> Adrian
>
> --
> Adrian Chadd "Programming is like sex:
> <adrian@freebsd.org> One mistake and you have to support for
> a lifetime." -- rec.humor.funny
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000-2001
---> X_.---._/
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A97D958.6AFC713>