Date: Tue, 3 Feb 1998 22:57:41 +0800 (WST) From: Adrian Chadd <adrian@obiwan.creative.net.au> To: hackers@FreeBSD.ORG Subject: RE: WebAdmin Message-ID: <Pine.BSF.3.95q.980203225206.331A-100000@obiwan.creative.net.au> In-Reply-To: <34D6373B@smginc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Feb 1998, Adam Turoff wrote: > 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. > Depends. <INPUT TYPE="HIDDEN"> ? I've written a couple of web-based SQL databases, and I have been able to sucessfully encode enough state into the webpages themselves to make the databases useable and stable. > 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. > Possibly. But then SSL on port 80 would be more than enough. Just verify the 'admin' user somehow using the root users' password (THAT is going to be a fun thing to do.. :) and it will make it a hell of a lot easier to manage. Saves having one root password, then another for web admin, and having to synch them together. Users will forget ;) > 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. > I'd be more inclined initally to auth people out of the password database, yes. Custom httpd would be nice to do this. :) That way, what you say above would be nice. Users can configure their own settings via the web, although I dont' see this having much use outside the local box anyway. > > 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. :-) I'm sure many other people have done this. I don't think you have to worry too much about 'locking' and so forth, as there SHOULD only be one admin user doing stuff at one time. But if the scripts are written right, with the right information embedded in the HTML, you'll be safe. -- Adrian Chadd | "I used to be thin, handsome and smart. <adrian@creative.net.au> | Then I discovered UNIX." |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.980203225206.331A-100000>