Date: Wed, 07 Oct 1998 00:29:22 +0200 From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> To: Andrzej Bialecki <abial@nask.pl>, James da Silva <jds@torrentnet.com> Cc: Mike Smith <mike@smith.net.au>, FreeBSD Small <freebsd-small@FreeBSD.ORG> Subject: Re: Yet another configuration model (long) Message-ID: <Version.32.19981007001534.0103f830@pop.wxs.nl> In-Reply-To: <Pine.BSF.4.02A.9810061434250.3751-100000@korin.warman.org. pl> References: <199810051918.PAA21621@torrentnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 15:26 06-10-98 , Andrzej Bialecki wrote:
>On Mon, 5 Oct 1998, James da Silva wrote:
>> 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).
Why would we need to allow programming to admins/users on a, say, router?
As far as I can see we only need an UI with a command set to let the admin
manipulate the device. Note that I am speaking out of my router/dial up/in
experiences mostly...
>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.
One file? Hmmm, sounds awkward. Better would be to use small files based on
toplevel structuring or some other similar grouping, as constantly updating
one big file when one change 172.16.0.5 to 172.16.0.4 sound tedious. All
IMO offcourse...
>> 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.
OK, that's one of the top priorities I think, to strip all the useful
networking manipulation tools to the barest minimum, yet usable, form.
Any pointers how to create a work directory under FreeBSD 3.0 in which I
can maintain different picoBSD images along with the patches/diffs? I have
some ideas, but some of you have already done it and might warn me for some
pitfalls.
>> 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...
Lame Q, was Forth a scripting language or a progamming language? I have
been to forth.org and read the discussion but haven't paid attention to
that point... =|
>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.
>
>And now, for the really wild idea... :-)
*Bracing self*
>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... ;-)
OK, lemme repharse all that:
O = database of configuration
* = client (service/daemon)
admin tries to ping from the router, and the IP stack hasn't done any
config of the router yet (lame and very lame example =P ) so the client
will ask the IP number, netmask and gateway from the Configuration Database
Manager(CDM)?
Admin | IP # ping 172.16.0.8
( * --------[get IP config data request]-----> O
* <-------[supplied IP config data ack]----- 0 )
Or am I missing something? (I know the example sucks heavily, better one
would be with dial up, fetching remote adresses from the CDM including
PAP/CHAP authentication specifics, telephone numbers, etc)
regards,
Jeroen Ruigrok van der Werven / Asmodai <asmodai(at)wxs.nl>
ICQ-UIN: 1564317 .:. Ninth Circle Enterprises
Network/Security Specialist
/==|| FreeBSD and picoBSD, the Power to Serve ||==\
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com>;
iQA/AwUBNhqLs4Y752GnxADpEQIrLQCfeskKBhVyc7Psb8bddWcvHwmHchMAoIhC
/lE1x9obO99eR5O4heV46PkR
=N6Xj
-----END PGP SIGNATURE-----
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?Version.32.19981007001534.0103f830>