Date: Mon, 2 Feb 1998 15:56:15 -0800 (PST) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin Message-ID: <Pine.LNX.3.96.980202150300.24252B-100000@phobos.illtel.denver.co.us> In-Reply-To: <199802021911.MAA08865@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Feb 1998, Terry Lambert wrote: > OK, I think that you may be missing where I'm putting LDAP. I am > not presenting LDAP as a wire protocol, but as an API. > > This would work better with a whiteboard, but... > > ,---. ,---------. ,---------. ,---------. ,---------. > |R | | Browser | | JAVA | | | | | > |e A| `---------' `---------' | TEXT | | X | ... > |m d| ,---------. ,---------. | UI | | UI | > |o m| | HTTPD | | JNI | | | | | > |t i| `---------' `---------' `---------' `---------' > |e n| ,----------------------------------------------. > | | | LDAP Client API | > | | `----------------------------------------------' > | `-----------------------. ,----------------------. > | Network connection | | UNIX Domain socket | > `---------------------------' `----------------------' > ,----------------------------------------------------. > | LDAP Server | > `----------------------------------------------------' > ,--------------. ,-----------------------------------. > | LDBM Backend | | Zillions of FreeBSD files Backend | > `--------------' `-----------------------------------' So you have here dual backend (AIX-like with the same data duplicated in both? Files as self-contained and unrelated storage?) and two protocols - LDAP (you mentioned network connection -- so it is also internal "wire protocol" and at least one external "wire protocol" -- say, HTTP. Where the authentication is going to be performed? and if in two places, how authentication information and/or credentials will be passed in this system between them? Also how will that system work if an operation is done on the network with large number of hosts, and host-dependent or subnet-dependent macros should be used? If HTTP will be one of secondary protocols, it's unlikely that it will be used in requests propagation and transactions handling -- then what will do that - LDAP? Or there can't be any propagation or host-dependent macros, and everything must either have only one administrative server or be managed in the boundaries of one host? Also how this system will accomodate the fact that changes in files are not changes in the configuration of the running system, and successful files or database updates should be followed by running scripts, restarting daemons, etc., and those actions may fail thus requiring transaction to be reported as failed and system to be returned if not into the original state, at least into one that allows it to communicate with the administrator? My idea is that configuration data (in zillions of files) can be represented as some hierarchical database, however operations on that database involve more than editing those files, and the need for handling networks as a whole creates need for symmetric macros-capable interfaces that receive requests for some complex operations and issue requests for performing parts of those operations while managing transactions over it. This is more important than just adding another way to manually edit the data from remote box in some structured way. [skipped] > The issue isn't the wire protocol; the issue is building a common > API to the "Zillions of FreeBSD files". LDAP is an API for accessing > directory schemas; why reinvent another protocol? I don't think, it will be sufficient to just make some conversion from configuration files to directory-like structure and back, and put some protocol over it. The need for atomic transactions on files and database entries is only one of things where LDAP needs something to work over itself, and IMHO the end result of using LDAP won't worth the effort of implementing those things. HTTP has the capabilities necessary in the protocol, administration system can be built around, it's unlikely the only practical solution, however since it's going to be present somewhere in this system anyway, and managing lists, organized in [URL] hierarchy with performing some additional non-database-related actions on them is basically what HTTP does when it deals with form-like data, there is a valid reason for it to be used internally. Again, I consider HTTP, CGI and HTML to be pretty much unrelated things when applied to this problem, and CGI is something that doesn't have any reason to be used for this task -- there are plenty of better ways to manage HTTP requests. -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980202150300.24252B-100000>