Date: Mon, 02 Feb 98 13:15:00 PST From: Adam Turoff <AdamT@smginc.com> To: Terry Lambert <tlambert@primenet.com> Cc: hackers <hackers@FreeBSD.ORG>, "'abelits@phobos.illtel.denver.co.us'" <abelits@phobos.illtel.denver.co.us> Subject: RE: WebAdmin Message-ID: <34D6373B@smginc.com>
next in thread | raw e-mail | index | archive | help
Alex writes: > On Sat, 31 Jan 1998, Terry Lambert wrote: > > > I think that the atomicity of the transaction for HTML is an implementation > > detal; a detail best served by defineing how a transaction is to take place. > > > > That the HTML post is a "transaction" is seperate from "what to do when > > an HTML post is seen and you are an HTML server". > > Of course, implementation can treat it as a transaction or not. I only > mean that HTTP protocol with forms uploaf provides a mechanism that allows > HTTP server to use transactions regardless of the model used by client for > its actions as long as the client uses HTTP. Standardizing on HTTP as a client/server interface between multiple clients has a lot of possibilities. First, we start with a well defined API to write the server side bits (the admin component subset will require more structure than generic CGI), and the client side starts out with a well defined API that's mostly implemented in almost any language today. However, I'm concerned that HTTP 1.0 is a stateless protocol, and that it's pretty much nothing more than a NFS with remote execution. HTTP 1.1, once everything supports it sufficiently, will handle the stateless part with keep-alive that actually works. Then there's also the question of security. Running a bunch of scripts that create users and such against Apache is not secure. Picking a port other than 80 or 8080 and possibly using SSL on it is marginally better. Since we're talking about system security, it sounds like we need a better security model to establish connections than straight https. I'm guessing writing a new httpd from existing libraries (or hacking Apache to run as admind with a different authentication module) would have a better login model than standard httpd would solve this concern, hopefully once and for all. Once that issue can be settled, the next step is standardizing on a remote call interface. This could be as simple as coming up with a standard set of name=value pairs that both the client and server would understand, or doing something a little more complex and having the client perform resource discovery to see what the server can do. I'd lean towards the latter, since it allows a much finer grain of tuning for the sysadmin - i.e. let anyone log in and change their shell, but only let root change a password and don't let anyone change crontab. > In other words, one can use any browser or proxy or another > server program that replicates its configuration or custom-made client > program, and the transactions model won't be broken if the server uses it. > If the server doesn't care about transactions (plain CGIs with no > locking), transactions support won't magically appear, but IMHO it's > reasonable to keep the requirements to server higher than ones to the > clients. Yes, keeping the server requirements higher than client requirements is a reasonable decision. But transactioning should not be something to ignore. If at the very least journaling wasn't supported, this system would be friendly but risky to use - kinda like NT. :-) -- Adam.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34D6373B>