From owner-freebsd-config Tue Feb 3 19:06:30 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA27546 for config-outgoing; Tue, 3 Feb 1998 19:06:30 -0800 (PST) (envelope-from owner-config) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA27537 for ; Tue, 3 Feb 1998 19:06:23 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id VAA16399; Tue, 3 Feb 1998 21:03:01 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199802040134.BAA17337@monoid.cs.tcd.ie> References: Message from Richard Wackerbarth dated today at 16:49. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Feb 1998 21:02:03 -0600 To: Colman Reilly From: Richard Wackerbarth Subject: Re: WebAdmin Cc: config@FreeBSD.ORG, mike@smith.net.au Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 7:34 PM -0600 2/3/98, Colman Reilly wrote: >From an abstract point of view we can actually look at all the operations in >Juliet as having the form of triples: (NODE,OPERATION,ARGS). Intermediate >layers only need to know how to deal with these triples. This doesn't seem >too onerous. >Is storing this information in a DBMS a useful thing to do? I'm not >convinced. There are two types of activity to be considered. First, and I think primarily, we need to be able to manipulate configuration parameters. Consider the case of "add user". This requires that we add an entry to the master password file and another entry to the "/home" directory. We also need to "set" the value of the "/home//.cshrc" file to its default value, etc. When we "commit" the addition, a command will be executed (passwd ?) if it is on a running system. However, that should not be done for each new entry. As much as possible, this logic should be imbedded in a table driven which belongs to the core of the admin tool. It is quite possible that this is NOT the target machine itself. In general, we need to be able to build "transactions" which are composed of multiple operations which are then taken on an "all or none" basis. The easiest way to do this may be to build a "shadow" of the target system and manipulate that image rather than forcing the target to support the ability to back out partial transactions, etc. In such a case, the "shadow" is really just a DBMS. >But quite arbitary. We end up with SNMP, where I reset a hub by setting >.hud.restart to 1. That's a pain to type and remember, and not very clean >semantically. I agree that SNMP is not a "friendly" communications tool for humans. However, it does have the virtue of "simplicity of implementation" at the machine level. I see no reason why it could not be used for the "back-end" language. However, just as HTML is not the "front-end" language, link adapters would perform the translations. Don't misunderstand. I am not advocating that we use any particular mechanism as the transport layer(s). Rather, I think we need to develop a modular structure that allows us to "mix and match" pieces. The front-end and back-end languages are the connecting pieces. The front-end needs to be sufficiently friendly that it can be used as a command line language. The back-end needs to have simple-to-implement functionality. Richard Wackerbarth