Date: Tue, 6 Oct 1998 15:26:00 +0200 (CEST) From: Andrzej Bialecki <abial@nask.pl> To: James da Silva <jds@torrentnet.com> Cc: Mike Smith <mike@smith.net.au>, FreeBSD Small <freebsd-small@FreeBSD.ORG> Subject: Yet another configuration model (long) Message-ID: <Pine.BSF.4.02A.9810061434250.3751-100000@korin.warman.org.pl> In-Reply-To: <199810051918.PAA21621@torrentnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Oct 1998, James da Silva wrote:
> It seems to me that the basic goal here for picoBSD is to be able to
> configure the whole thing from one script file, including perhaps some
> extensibility (which IOS does not have).
Yes, that was my goal when I started this discussion...
> But that's not the problem. The problem is the mapping from this small
> simple script-based language onto the "real" configuration base of the
> system. This can bloat up in a hurry.
Yes, that's the main problem. I proposed Forth as an alternative to
/bin/sh, because it's smaller and more flexible _for_writing_programs_,
not as a user shell per se. Anyway, still the main problem is the
structure of the (single) config file, and its relation to UI and existing
config files, which are often application-specific (but large part of them
is not).
My idea was to keep and change the config basing on a single file, and
then regenerate needed files on the fly. But I have yet another idea how
this could be done... Read on.
> Eg, does each subsystem read from the config file, or is there a single
> command shell that updates some registry (ldap and agentx spring to mind
> for the registry)? Either way, you have to modify all your programs to get
> their config info from this centralized place. Or, if you don't want to do
It depends on the type of the system. In some cases, all you have to do is
just to ifconfig, add static routes and off you go. Besides, we still need
(IMVHO) to write more picobsd-ified versions of standard system utilities
- making them compatible with the new config scheme would be simple then.
> that, you can have your script processor generate the traditional conf
> files. The mapping can be complicated if you aren't careful.
>
> If forth is being considered as way to implement a lot of the
> non-performance critical "glue" code, and not necessarily as the interface
> through which the admin operates, then that's less controversial.
Performance of Forth programs is _way_ better than that of normal shell
scripts, at least that's what people say...
>
> Wouldn't Java or some other bytecode language be similarly compact, or at
> least in the same ballpark? I know, a typical java runtime, like tcl, is
> bloated; but how much of that is necessary? How big would a simple JVM
> with only the basic classes be?
I highly doubt you could beat Forth when it comes to resource consumption
(not only static size, but also RAM footprint). Unless you can share with
us your (free) implementation of the JavaCard standard... :-)
But as you noted above, the main problem lies not in the tool with which
we write the "configurator", but in its interaction with multiple config
files needed by various programs.
As a side note:
Not long ago I implemented in Java a flexible hierarchical configuration
database, where you could store and retrieve device parameters just like
this:
String loc;
Base base=new Base(10);
Base b;
// Store an object in database. 3rd param. is a type name.
// This also does an equivalent of mkdir -p /main_db/devices/UPS/UPS1
base.put("/main_db/devices/UPS/UPS1/location","Main building","String");
b=base.chdir("/main_db/devices/UPS1");
// Retrieve the object. I can also check its type using Base.getType()
loc=b.getString("location");
b=b.chdir("../");
// List available keys
for( Enumeration e=b.keys(); e.hasMoreElements(); ) {
...
}
etc, etc...
I can imagine something similar to store and change parameters for FreeBSD
subsystems (this is what I meant by saying "a config database"), other
issue here is something what Java people call "serialization", i.e.
changing this database to a flat file. Yet another issue is when exactly
the change of a parameter affects running configuration. The
"configurator" should monitor what changes were made, and be able to
restart appropriate services.
And now, for the really wild idea... :-)
Yet another idea occured to me: it's also possible to view "the
configurator" as a "service (daemon) providing its clients necessary
configuration data". In this model, the database could be stored in some
internal format known only to the config daemon, and converted on the fly
when it receives a request from some client to supply config data. Of
course, all programs would have to be converted in order to make calls to
the config daemon on startup, register with him to receive notification
when configuration changes or when the service should be stopped. Some
general aspects of the system (such as ifconfig, static routes, hostname)
could be performed by the config daemon itself. Hopefully, one could hide
most of the gory details in some library which would translate ordinary
calls to read the config file, to calls to the config daemon.
Now, what do you think of it? Go, you can laugh at me... ;-)
Andrzej Bialecki
-------------------- ++-------++ -------------------------------------
<abial@nask.pl> ||PicoBSD|| FreeBSD in your pocket? Go and see:
Research & Academic |+-------+| "Small & Embedded FreeBSD"
Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/
-------------------- ~-+==---+-+ -------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9810061434250.3751-100000>