Date: Tue, 3 Feb 1998 20:26: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.980203154555.29185C-100000@phobos.illtel.denver.co.us> In-Reply-To: <199802032255.PAA01679@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Feb 1998, Terry Lambert wrote: > > > 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. > > Yes. As stated, the RFC's describe an "AUTH" mechanism. If you > need more than that, then use NDS or X.500, with an LDAP server > operating against the MIB. Is your idea to transfer authentication information "transparently" from "wire protocol" or authenticate over "wire protocol", check access and use separate authentication information for LDAP? [skipped] > > 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. > > 1) Schemas are transportable; database files are not. Using > the protocol abstracts the schema from the implementation. Tab-separated lists are very portable. URL-encoded lists are even more portable -- they have predefined encoding rule for "odd" characters. In any case configuration replication can't be done between host that supports configuration database-like system and one that doesn't, whatever database-like system is chosen. It's good to use a protocol that everyone can understand and build such system over it, but portability is hardly the unique feature of LDAP. > 2) Everyone will eventually support LDAP. Sun does. Netscape > does. Novell does. Sun doesn't configure their hosts by LDAP (and considering their creativity in protocols, unlikely will). Novell doesn't and even less likely will. Netscape will only if every system its server runs on, will. All protocols except some irrelevant to this discussiuon proprietary ones, are implemented everywhere, and none of them are used for remote administration system of this kind, especially portable one. > 3) There is already a reference implementation. What you are > proposing does not have one. Managing lists taken from url-encoded form input has more implementations than necessary, interfaces to databases exist, too (probably LDAP-like ones, too), and I'm not aware of any existing implementation of FreeBSD tadministration hrough databases or LDAP. > 4) It is already a standard. What you are proposing is not. Both protocols are standard and both require something to be placed over them to achieve the stated goal. Also it's obvious that the administration framework that should be placed over any of those protocols to become a base for remote administration system. I propose something of the same scale over HTTP that your propose to make over LDAP, and I prefer HTTP only because its requests structure and expected actions seem to be closer to the expected from the whole system's model. > > > > > 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. > > This is too complicated. How would you present this as a radio button > list, a checkbox, or an input field in a user interface? If the > answe is "you can't", then the model is too complicated for users to > understand. IMHO the system shouldn't be made in a way, "only every fool can use it" -- if you propose heavy modification of the configuration data storage you can't make new system less flexible than original one. I can make a script that will perform this on the files, rsync hundreds of hosts with it and make cron run, then delete it. Ugly, requires writing separate files editing procedure for any kind of configuration, but very efficient. If the system will have "nice" remote configuration editing capability, I expect the same thing nice way, too -- if someone can't make script in it, distribute and call it "by one button", it's his problem, but one who needs it deserves to have it. > How many people do you know who know how to work lamps? A computer > should be as easy to operate as a lamp or a television. A VCR at > worst case... Whth predefined operations of this kind it may pass for "configuration wizards" system ;-) > > > 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. > > I think it is wrong to cause the smtpd (for example) to enforce smtp > configuration semantics. The enforcement must occur before the change > takes (a "schema-check"). They already enforce it. I change configuration, program returns an error. Trying to make all possible chacks before the program, then giving configuration to it blindly, ignoring program's errors produces very fragile system. > [ ...more "HTML as a replacement for SQL" ... ] More like limited frontend to it -- some complex lookup can be done in completely different way (say, LDAP). > When the only tool you have is an HTTP server, everything looks like a URL. > 8-). Not really, just IMHO HTTP semantics is close to it than LDAP one -- no one originally expected LDAP to perform some complex actions on complex system with parts that can succeed or fail. HTTP more or less was supposed to have something "do things" on request. > > > 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? > > The "client" is the "adduser" command line utility. The "server" is > whatever actually ends up adding users. Then who has problems with polling? Transaction won't end until data is received back. > > > 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. > > Because !$%@*! Netscape and MS-IE timeout if their idea of "fast enough" > is not met by the server. You are faced with server push, or you are > faced with polling using "GET", or some silly "send comments" keepalive. Then don't use them for sending the requests for transactions that take 20 minutes to complete. Protocol has absolutely nothing about enforcing response time limits, and for [incompatible] HTTP clients that do it one can build a simple proxy that will fix it by whatever means including polling. I am talking about a protocol, not GUI clients for it (LDAP has nothing better suitable for being an interactive client for this system either). > > 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. > > Ugh. Writing a parser for all this would pretty much suck. There are > good reasons these programs are compartively huge. Parsing HTTP (MIME) is very simple and parsing valid HTML (SGML) is more complex, but again, noninteractive things won't need HTML -- operating on lists requires only parsing lists themselves (in my skipped example it was URL-encoded list), and parser for that is exremely primitive. Generating HTML form of lists for interactive use, again, is simple. Implementing all possible monstrosities of multi-file HTML with frames and layers, scripts and style sheets over HTML, layout with table cells that should self-adjust its size for elements inside that also change the layout depending on boundaries defined by that cell, etc. is something that makes certain HTTP clients that large. > > 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. > > That's the rationale behind LDAP. I can ownload a client from UMICH > right now. The same for all kinds of HTTP clients including libraries, command-line HTTP request utilities, etc. IMHO choice of protocol should be based on something where they differ more than that. > > 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. > > How do you replicate this information to a Sun or NetWare or NT box, > without rewriting the code for Sun or NetWare or NT? I can't with any of those systems -- Sun, Netware and NT has no HTTP or LDAP remote administration implemented. If any of both configuration systems will be portable, it may be possible, however I don't believe that copying Windows registry to Solaris box will do it much good. > > 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. > > Apache times out CGI's that "take too long". How would you deal with > this problem? Not use Apache? Then what? Apache has modules, and I never said that I consider CGI to be suitable for this task. Apache modules IMHO aren't the best choice for that either, and I wrote my own HTTP server just because I wanted to make something that won't impose request procesing model and processes/threads/resource management system, used for the server itself on every program that can be called from it. That server is at least one thing that can handle HTTP in a way suitable for remote administration -- and probably there are others. -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980203154555.29185C-100000>