Date: Tue, 3 Feb 1998 02:10:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: abelits@phobos.illtel.denver.co.us (Alex Belits) Cc: tlambert@primenet.com, 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: <199802030210.TAA06735@usr01.primenet.com> In-Reply-To: <Pine.LNX.3.96.980202150300.24252B-100000@phobos.illtel.denver.co.us> from "Alex Belits" at Feb 2, 98 03:56:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > ,---. ,---------. ,---------. ,---------. ,---------. > > |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? No. The LDAP server can have different backends. LDBM is one. So would the proposed "Zillions of FreeBSD files Backend" be one. They are mapping the same space. This would let you replicate the FreeBSD configuration data on any LDAP server (if that's what you wanted). The backend is only relevent in that the administration code has to deal with an existing directory, which has historically existed outside of a schema, and then only loosely normalized (ie: /etc/passwd, /etc/groups). *Ideally*, FreeBSD programs needing this information would use the standard LDAP client API's, and one day we could throw a switch and the whole thing would be a database, and not zillions of files. But that's my ideal, and there's no reason FreeBSD should be required to conform to it (except it makes life easier for everyone to have exactly *one* place the "hostname" is define, *one* place the user "terry" is defined, etc.). Lets things like appletalk servers and samba servers find your hostname a lot easier, instead of adding yet-one-more-place the hostname needs to live. The backend would register "handlers" for schema branch points. Thus if I were to set the hostname in the schema, whatever registered for that branch point would blow it into all the files it needed to. Like /etc/hosts, /etc/rc.conf, /etc/sendmail.cf, /etc/sendmail.cw, and so on. > Files as self-contained and unrelated storage?) No. The "unrelated" storage is only an apparent truism. The files (in the "zillions of files" case) are actually related by schema. It is the job of the backend to enforce this relationship. > and two protocols - LDAP (you mentioned network connection -- so > it is also internal "wire protocol" and at least one external > "wire protocol" -- say, HTTP. The "LDAP as wire protocol" case is only if you want to allow replication and/or remote administration via LDAP. You don't have to actually *use* these features, but they are there, and they are free. > Where the authentication is going to be performed? At connect time, via the "AUTH" extension, using MD5 and a shared secret, so the code can be exported. Clearly, if a connection comes in via the UNIX domain socket (something the UMich LDAP server doesn't do), it's coming in via a trusted interface (in the Juniper firewall vernacular) and so could be automatically authenticated. Unless you wanted to open up the "registry" for general use (not a bad idea). Then you could use process credentials, which if you will read the Steven's books on TCP, you can get via a call on a UNIX domain socket. Thus the credentials will be the credentials of the requesting process for local usage, and the "AUTH"'ed credentials for remote. There are patches for SSL for LDAP, as well, which transfers credential information on the connection. I would discourage their use, however, because of ITAR restrictions. > and if in two places, how authentication information and/or credentials > will be passed in this system between them? Read the RFC's. LDAP is an IETF standards track protocol. The question is answered there, in great, gory detail. > 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? This is a schema issue. This problem is resolved by "distinguished names". > 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? If a change needs to be propagated within an administrative Realm, Yes, "LDAP will do that". If you are talking about the atomicity of the contents of a POST'ed form specifying new data, the atomicity must be handled by correct form design. The httpd exposing the LDAP objects must account for the objects at the container level. Which it can do, easily, with the given container design for transactioning. > 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? LDAP supports referrals. Read the RFC's. > 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? The back end will need to institute monitors. Objects whose data impact a program or group of programs trigger a monitor event. The monitor configuration information will be used to tell it what to do. Ideally, monitors will fade away to nothing, as intelligent programmers rewrite these bad programs to make them stat their configuration data files occasionally before running (worst case) or to directly use the directory themselves (best case). > 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, Agreed. > 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. I frankly don't envision changing an entire corporations domain name or netblock with a single edit. Nevertheless, yes, it's important to consider artificial "realms" when considering the schema. You certainly wouldn't want to architect against it being possible at some future date, even if you certainly won't have it working by Tuesday. > > 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. HTTP isn't a practical soloution mostly because it doesn't resolve all of the user interface mechanics which need to be contended with; how would a hypothetical HTML-using command-like "adduser" script, which implements a CLI, not a TUI or GUI, function? You would have to invent a whole new set of tags; and since the user interaction is not POST/GET in the CLI case, you would introduce an unknown processing delay during which you are not sure if the request has failed or not. In the LDAP case, the function would not return until the data had been read. You could use a "client poll" based mechanism, but the delay you will introduce doing that is, IMO, unacceptable for a batch create of 200 users at the beginning of a Semester/Quarter. You could use "multipart/replace", but that would seriously limit the available clients. What is needed is a "server push" technique that is not delay-loop polling, and is supported across all servers. LDAP offers that, HTTP does not. > 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. I do as well. HTML is useful for browser-based administration, which some people feel is the holy grail of GUI. HTTP is useful for the transporting of HTML, and for the tunnelling of data to/from ActiveX controls and/or JAVA applets. I would hate to see yet another incompatible mechanism for server push foisted into HTTP (which has the bad fortune to not support IMAP-style asynchronous server responses). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802030210.TAA06735>