Date: Tue, 3 Feb 1998 21:02:03 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: Colman Reilly <careilly@monoid.cs.tcd.ie> Cc: config@FreeBSD.ORG, mike@smith.net.au Subject: Re: WebAdmin Message-ID: <l03130304b0fd7b876714@[208.2.87.4]> In-Reply-To: <199802040134.BAA17337@monoid.cs.tcd.ie> References: Message from Richard Wackerbarth dated today at 16:49.
next in thread | previous in thread | raw e-mail | index | archive | help
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/<user>/.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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130304b0fd7b876714>