Date: Tue, 3 Feb 1998 09:42:29 -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.980202201628.25875A-100000@phobos.illtel.denver.co.us> In-Reply-To: <199802030210.TAA06735@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Feb 1998, Terry Lambert wrote: > 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. Looks like AIX. > 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. > [skipped] > > > 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. *between* them -- in the case when remote administration is done not through LDAP, and authentication comes through something else. If only local sockets are used, there will be no need for further authentication, however it creates two possible places where authentication will be possible to perform -- before or in LDAP, and depending on the protocol used it will be in one of those places. > > > 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. The only question is why. LDAP in this situation acts as an API to database encapsulated into protocol, but if protocol is used only locally, what is the point? Why not to manage bare database -- not that LDAP provides exactly the functionality we need. If the intention is to use LDAP as the only protocol for network propagation of changes, etc., I don't understand the reason for it -- with the need for external transactions support it doesn't look like the best psooible protocol for that. Database-like backend (but not necessarily replacing all config files with one big database -- one can handle files as database while not keeping it in any permanent storage) makes sense, but what is the reason for dragging in the protocol with it. > > 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. I am talking about operations, not just storage. For example: "Change default nameserver to the local nameserver on your subnet if it exists, otherwise to 192.168.111.222" -- and decision what to say to actual boxes is left to the local administration server. > > 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). While running, not on startup. You will have to make those programs aware of monitors and be capable of reporting success or failure of such reconfiguration -- and something should react to failures and recover systems while still supporting transactions. Programs that report failure won't be able to do much because their reconfiguration is a part of transaction, and they only can tell that something is wrong and hope that one who started it will return system into usable state. IMHO it's way more complex than just providing atomic updates in simple situations. > > > 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. No. Say, I map some sets of base URLs to operation (editing users list), make single key that defines operation and add it as the parameter, optionally other parameter that defines outpur format and the form entries contain all arguments. POST /admin/local/passwd?op=add&respond=application/x-www-form-urlencoded HTTP/1.0 Content-type: application/x-www-form-urlencoded (header) (as form upload:) username=joe passwd=* realname=Joe User uid=undefined gid=undefined ... (upload ends) (response:) HTTP/1.0 200 Ok Content-type: application/x-www-form-urlencoded (header) (the same,also url-encoded form with all parameters filled) (end of session) CLI utility can perfectly do this without dealing with HTML, just handling and encoding parameters lists. But replace "respond=application/x-www-form-urlencoded" with "respond=text/html", and the same interface to user database will produce human-readable HTML table instead of url-encoded response. The amount of programming necessary to implement such an interface to whatever kind of storage is minimal, and it provides more flexibility if transaction involves some additional actions that should be associated with database/file update. > 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. Why? Adding a user or a set of users is a single transaction. Who is the client and who is the server in your example? > > 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. Why? Server produces responses to requests while requests and responses pairs represent transactions. There is nothing for server to tell to the client after the transaction is done, and client can initiate transactions whenever it needs to. Monitoring the status and changes not initiated by the client is different task, and most likely it won't be an HTTP browser that will do it -- and for custom client any kind of "envelope" of update message, including MIME multipart, can be used. > > > 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. Umm... HTML, java and all kinds of tunneling are just some of applications -- HTTP by itself is just a protocol. The whole thing can be implemented through HTTP without any browser involved -- it's just nice to have interface that can be used from it directly. > I would hate to see yet another incompatible mechanism for server > push Configuration update doesn't need any server push -- client always initiates the transaction, and there is only one result returned to it. Server-push can be used for monitoring, but it's hardly an important part of design. > foisted into HTTP (which has the bad fortune to not support > IMAP-style asynchronous server responses). HTTP multipart/replace server push is made without breaking MIME, so it at least fits into the protocol, however in this case it's unimportant. -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980202201628.25875A-100000>