Date: Wed, 4 Feb 1998 07:04:16 +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: <199802040704.AAA04193@usr08.primenet.com> In-Reply-To: <Pine.LNX.3.96.980203154555.29185C-100000@phobos.illtel.denver.co.us> from "Alex Belits" at Feb 3, 98 08:26:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? My *personal* idea? Use Kerberos tickets compatible with the next generation of Microsoft products, so you authenticate once. My idea of what could possibly adopted over the "not invented here" protests of the free UNIX clone camps? "Anything that works first". > > 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. Replication is. So is the fact that it's already implemented. So is the fact that the big players are going to use it, with or without your approval, and whatever you implement, if it's not LDAP, then you will *also* have to implement LDAP if you wish to be interoperable. If nothing else, you will need LDAP for ABI compliance with products not native to free UNIX clones. Might as well start ahead of the curve so that when the headstart is lost to a commercial company that throws paid engineering resources at it to work on the unpleasent parts that you are only years from completion instead of decades. > > 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). Yet. > Novell doesn't and even less likely will. An LDAP interface to NDS is indistinguishable to an NDS server from a native NDS client. If you think that compatability with NDS is a valid argument, but that LDAP won't provide it, and therefore it's an argument against LDAP, then you should contact Novell. They will license, for free, their NDS source code to any system vendor. Jordan could get it for you by signing the papers; he'd probably be willing to do it, if you were volunteering to do the port. > Netscape will only if every system its server runs on, will. That's not what it says in the developer section of their www pages. > 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. SNMP. Topologically, it's similar to LDAP. ACAP. Topologically similar as well, and supported by a number of pieces of commercial software, including Eudora. ACAP depends on whre you draw the line between system and software. It could just as easily be used to configure entire OS's. And these are only the ones from the higher numbered RFC's. > > 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. FreeGate. InterJet. Interceptor (OK, that last one is NetBSD). > > 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. LDAP is connection oriented. It is better suited to authentication of connection instead of authentication of request. Connection authentication has many security advantages, as NFS teaches us. > > 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. This is what "Advanced" tabs are for. Being an intellectual elitist will not win you any popularity contests. What is with this idiotic Aristotilian mean "IF NOT A THEN B"? What about C? There is no reason that an interface usable by a new user *must* condenscend to advanced users. That's an artificial restriction that intellectual elitists imply *must* be there; but th restriction lives only in the mind of the elitest. The entire point of an install is to pander to users who will not use the code unless they can install it, not just to users who can install it by typing hex values into the old Microsoft "debug" program after reading the bit patterns visually off of punched paper tapes. > > 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 ;-) How terrible. Something that someones aunt can make work. Next thing you know, just any old fool will be able to run FreeBSD, and then where would we be? > > 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. Storing data which can make the program that uses it puke is bad practice, and should not be tolerated. I can limit input fields to specific values in a UI before I attempt to store them. I think you are confusing "policy" and "property". Consider JAVA byte code as an example. The syntax is enforced before the bytecode is produced. Post-production bytecode is supposed to be portable, and a JRE will not validate against illegal semantic bytecode runs in the "compiled" JAVA class. Microsoft BASIC (the *old* Microsoft BASIC that was licensed to IBM, Apple, Commodore, Atari, and everyone else) was exactly the same way. So was UCSD Pascal. So was LISP code on Symbolics machines. The concept of seperating "policy" and "property" is not new. > > 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. I did. The only restriction I have is atomicity of set operations, and almost every LDAP backend in existance supports that. LDAP was not intended to dicatate semantics (much as I wish that there were a "ldap_transact" in the draft 2 specification). The main expectation here is that the parameter store would be "read-mostly", and atomically updated via LDIF, rather than wire writes. LDIF data input *does* implement shema/page/record atomicity. > > > 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. Netscape and IE will end the transaction before they receive data back; I believe the timout is 60 seconds. What HTTP client software were you thinking of? Before you go off on a tear about the difference between HTML and HTTP, I understand your point. Now you should understand mine: I can download LDAP JNDI classes from Sun, or I can download C client API's from Netscape, or I can download JAVA (non-JNDI) with JNI from NetScape, or I can download C++ from MIT. I can do this today. Where are your HTTP client API's for the same environment? > 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). A proxy is a kludge. How will you authenticate without using HIDDEN or cookies or some other "send the auth data with every request"? How will you guard against spoofing or man-in-the-middle? Will you spec 1.1 instead of 1.0 to gain keepalive? If so, will your client API's implement command streaming, etc., as required by the 1.1 standard? Where will you get your reference implementation, considering Appache still lacks for full support of 1.1? The problems quickly mount. > > 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. What do you do when you are creating a new user and you need to not only create the password file entry, but their home directory, as well? > 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. Maybe. Some MIME types are unwieldy as hell to parse, too, though, as are "Charset=..." autoconversions. One only need look at the sendmail MIME code (which doesn't handle half of what you would probably need) to see that it's unwieldy. You have to start with RFC822 line folding and header seperator, and start from there. > 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. How about "LDAP is a directory access protocol, and administrative data should be stored in a directory and accessed via a directory access protocol"? The best you can argue here is for X.500, SNMP, or NDS instead of LDAP. > > 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. Not replicate the *machine configuration*, replicate the *data defining the machine configuration*. I can replicate data between LDAP servers all day. > 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. Unless you them boot a ROM'ed version of windows and remotely access the dynamic configuration data remotely over the network. Like a bridge, a router, a WebTV box, etc. would want to do. Or a handheld mail client like an IR interfaced PalmPilot. Or a cell phone with a display. Or a pager. Or a producer of boxes with FreeBSD preinstalled, like Rod Grimes. > > 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. How available is your server? 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?199802040704.AAA04193>