Date: Wed, 4 Feb 1998 20:19:17 -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: <l03130309b0fe9c794a0e@[208.2.87.4]> In-Reply-To: <199802042218.WAA18923@monoid.cs.tcd.ie> References: Message from Richard Wackerbarth dated Tuesday at 21:02.
next in thread | previous in thread | raw e-mail | index | archive | help
At 4:18 PM -0600 2/4/98, Colman Reilly wrote: > 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. >I'm worried that we'll end up translating things into easy to implement too >early, with the result that the semantic richness of the system is lost >before any of the intermediate layers have a chance to do anything with it. > >>From the point of access control is is nice to have available the operations >like append, restart, create which express the meaning of the transaction in >order to make it easier to write (say) ACLs. Would you rather rather write > deny "write" on ".hub.controls.reset" to richard >or > deny "hub reset" to richard Perhaps we are not talking about the same thing here. My model has a number of communicating entities. They are connected by some kind of link. Level 1. The user Connected by screen, keyboard, mouse, etc. Level 2. User interface module (Perhaps a web browser) Connected by "front-end directives" tunneling through http. Level 3. The configuration server Connected by "back-end directives" tunneling through perhaps a SSH link. Level 4. Implementation "glue" on the target machine Connected by system calls Level 5. The actual files that remember configuration parameters Note that this can involve three different systems. The user's workstation, an administration server, and the actual target machine being administered. Now, things are really a bit fuzzy in the description. If you were to use a http front end, a part of the logic would really be in CGI script that resides with the server. However, you might bypass that and simply use a direct set of commands. (Similar to shell scripting). However, the "front-end language" is that language which is common to both of these interface units. Similarly, you might replace the back end with a SNMP system. Again, there would be an adapter that translates the "back-end" language into the appropriate protocol. In the case where the server IS also the target, we would use something like Juliet to directly implement the back-end actions. Note that all validity checking, etc. of the user is handler in the server portion. By the time that we get to the "back-end" language, we are simply sending the elements of a transaction. If the back end does not know how to journal, buffer, or otherwise treat transactions, it would perform the steps as they arrive, just as we might do with a canned "daily" shell script. >Well, I'm very much in favour of the mix-and-match philosophy. I propose that we accomplish this by defining two interfaces to the administration server. The "front" language should be something that is "user friendly". At the same time, it should be something that we can imbed in an http form. (Click the button ==> execute a few "front" commands) The "back" language need not be "user friendly". Rather, it needs to be easy to implement (for minimum configurations such as sysinstall) and mappable onto common protocols (eg. SNMP) Richard Wackerbarth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130309b0fe9c794a0e>