Date: Wed, 4 Feb 1998 04:20:54 -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.980204005855.32150A-100000@phobos.illtel.denver.co.us> In-Reply-To: <199802040704.AAA04193@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Feb 1998, Terry Lambert wrote: > > > 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". No, no, no -- I'm talking not about authentication implementation. Just about the way, authentication information from "wire protocol", access restrictions and authentication information that used for LDAP are related. > > > 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. In the very worst case I can replicate FreeBSD box configuration now using tar. Agreed, not nice at all even though but with right set of inclusion/exclusion files it's possible to write a shell script that will produce valid configuration on large number of boxes, connected to the same network. Replication the configuration handled by HTTP when server can always produce a configuration dump in the form of URL-encoded lists mapped to known set of URLs (see my example with passwd) makes replication simple. I send requests to set of URLs at the source box asking for configuration download in URL-encoded format, receive encoded lists and send them to corresponding URLs of the destination box with upload operation in parameters list. Or adding/merging instead of upload. Then process errors if any happened (and if they did, server will be smart enough to reverse the upload that caused errors). IMHO doesn't look any worse than LDAP. > 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. Interoperability with what? System-dependent configuration? I will take Windows registry, AIX object database and Solaris configuration with LDAP and put it to the FreeBSD boxes, then turn those Windows, AIX and solaris boxes off, place FreeBSD ones instead of them, and users can continue editing their ASP files, running telephony software on AIX-specific X.25 link and running the latest release of JDK for Sparc Solaris? System administration means most likely will remain different for a long time -- if not for any other reason then because LDAP doesn't cover all needs for system administration just like Windows registry manipulation doesn't cover everything that can be done with NT system (and they tried very hard and succeeded in a lot of places with it). If you are talking about database interface compatibility, HTTP is also very compatible, and dump of its download looks the same on all of those systems, and can be accessed in the same way. The only thing that can't be done with HTTP and can with LDAP is operating on configuration data stored on some other system, then using it fro configuration of FreeBSD box. I see two problems with it. First, it's unlikely to be necessary -- after all, all FreeBSD boxes are capable of being servers, and there can't be any licensing issues. Second, update of the database and update of configuration of the running box are two different things, and second one, as I have mentioned before (later about that) can fail for its own reasons. Having update procedure producing errors with no one to report them to won't be too helpful. > 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. I am not against having support for LDAP -- it already exists anyway. I just don't think that LDAP is useful for this specific purpose, and see no indication that anyone else is going to use it as the only remote administration mean. > > > 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. Everybody has some LDAP server implementation on their system. FreeBSD has one (umich), too. What I don't see is anyone trying to make such complex administration framework over it. > 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. To be honest, I don't really care. NDS probably is something worth to be implemented, but I don't think that it's an administration tool. > > 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. They say "We are going to make all system administration tasks on supported OS handled through our LDAP server"? I never heard that, and honestly I doubt that they are capable of such undertaking. They barely made the world's third largest (by the amount of memory used) browser, and it's nothing compared to the ultimate administration tool for all OS they support. > > 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. I have serious doubt about complete host configuration through SNMP, and I haven't seen ACAP, but having a client for them doesn't automatically make those system capable of doing remote administration of FreeBSD system -- you need to at least somehow place client part of your transactions support over those clients. I can't imagine adding it to Eudora. > > > 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). Complete administration, not just limited set of options with very restrictive base configuration and standard "templates"? If not, I will really like to see sendmail-smtp-uucp part in work. > > > 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. I always thought that NFS teaches us that Sun never does anything right the first time, rarely second one and never when protocol design is concerned. Actually HTTP 1.1 persistent connection (as opposed to HTTP 1.0 Keep-Alive connections) are authenticated once per connection, however AFAIK no one supports them at the client side that way. > > > 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. "Advanced" tab may have "wizard" standard reconfiguration script (say, "change DNS server for the subnet", "Renumber the whole network", "Change everybody to use NIS", "Select POP servers and assign clients to them", etc., and one entry for adding custom scripts. > 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. I'm talking about just the opposite! Interface that can be used by new user shouldn't place any advanced user outside the framework completely. It should allow extensions to be placed into it, not reject or break every attempt of doing anything "smart". If I will want to replace "zillions of files" on my system I should be absolutely sure that whatever will take their place will allow me to do administration *through* it, not fighting with it just because it's trying to be smarter than I am. People consider RedHat to be restrictive in administration (I have put it into unusable state more than once when did valid changes but not cosidered RedHat configuration tools' opinion about them), and framework over LDAP if done this way is something significantly more intrusive for system administration than their few Tcl scripts that edit some shell scripts and configuration files. > 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. Installation program should allow any user to make something that can boot and be used. But thing that will perform all system administration work should be suitable for doing complex things. Making "nice" interface for new user and then giving sysadmin the choices "keep everything as preconfigured" and "handle with every field and variable manually and see how they will mess up when simple interface tried to handle them" will be rather... unfriendly. > > > 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? Umm... you probably misunderstood me. I mean that one can have pre-made scripts in "Wizards" menu that ones aunt can choose, set and they will do predefined reasonable things. Like, "Install this box as POP3 server", and then operation "Configure mail distribution on the whole network" will use script that will treat that box as known to it cnfiguration of POP3 server. If sysadmin will do things by himself instead of letting his aunt configure mail, he can write very clever script that will know about some UUCP users that come through modems and TCP, complex system of mail servers, not to mention "double-accounting" in DNS and NAT, and produce reasonable mail-related configuration. Running old "Wizard" script will break his work badly, but new one will do exactly what is necessary, and when he will add/move hosts he will just use it on them instead of first running very friendly "make bare bones, then some defaults" script, then manually selectively copy right parts of configuration from right boxes and then add host-specific ones (that otherwise can be easily calculated by the script, but friendly configuration system doesn't have scripts). > > > 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". The problem is, programs produce errors, no matter how nicely you check parameters. Say, I have 30 boxes on 100Mbps Ethernet. 28 of them have 3Com ethernet cards, and two have Digital. I haven't seen those 2 boxes for half a year because this is when I first installed them and given to users as X terminals, so they never asked me for any kind of configuration on them. Suddently I have to renumber the subnet. Thinking that all boxes have only one Ethernet interface I ask every box to change IP address and routing, using the same interface name because it's a key that is used on my box for ethernet interface. It's a valid request from the point of view of my box, and it's sent everywhere. 27 boxes renumber successfully and restart everything that should be restarted by clever parameter-change monitoring, 28th is my administration box, so I renumber it the last, then thinking that everything is ok, change router's configuration. But two boxes have interfaces with different names! They made entries with requested name successfully, tried to reconfigure and ifconfig returned an error, but no one seen it and no one did anything to fix it. Now I have two boxes with nonworking configuration, no usable networking, and those boxes, being remote X terminals, don't even have complete set of utilities to edit the configuration database locally (they are stripped-down X terminals with every unnecessary for them bit of system removed to make place for huge local fonts database). Of course, it's an extreme example, and one can do something "clever" in the admin box -- say, always check proposed change against entries, downloaded from the target box and ask the user if the entry I'm setting is originally set to "no interface" or "down", but then it will make replication of configuration rather difficult, and if I want to have it applied to the subnet as transaction, it will require additional transaction mechanism over it, too (so will HTTP, but if it's a script, one can make generic operation "treat script as single transaction", and separately every box will handle every request that is coming from administrative server as single reversed on local failure local atomic transaction). In this specific case of network interfaces reconfiguration it's even more complex because even successfully reconfigured box will have no means of returning the result in the case of successful reconfiguration, and local check should follow receiving update but precede actual change, but that check should be done against interfaces known to kernel, not just database (database may have nonexistent interfaces marked as unconfigured, and it's a valid operation to bring them up after the physical configuration change). And in any case logic of the initial check will be extremely complex and prone to becoming out of date when configurable programs are upgraded, and valid combination of options are changed. In my proposal transaction has the return value that can be either "successful, configuration data updated, actions taken", "successful, configuration updated, can't take actions before rebooting" (better not ot have ones, but kernel upgrade probably will forever remain in this category), "unsuccessful, system returned to the original state" (plain failure, errors are returned, everything is like it was before except some things restarted) and "unsiccessful, can't reverse changes" (that means that system is in real trouble, and without human sysadmin reading errors in logs not much can be done). > 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. That never prevented internally very consistent and valid bytecode to have all kinds of bugs in it. [skiped] > > 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. My concern is mostly about external errors that happen when changes take effect on real programs. It just doesn't fit right into the database update model. > > > > 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? Subset of CERN library if nothing else. Even though I can write one that supports specific subset of possible for this system requests in few days (if no browsers are involved client is symmetric, it sends URL-encoded lists and expects URL-encoded lists). > > 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"? HTTP Basic authentication, if necessary forwarded over ssh. > How will > you guard against spoofing or man-in-the-middle? If I'm in the "secure" local subnet and don't want to use any encryption, I won't. If I'm using SSL, it will use encryption, and if I use ssh forwarding and URL mapping or encryption proxy I can use authentication over encrypted channel between localhost interfaces that in its turn was authenticated when established using host keys, so man in the middle won't work. > 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. Keep-Alive is an extension for HTTP 1.0, persistent connections of HTTP 1.1 differ from it (IIRC authentication per connection and asynchronously sent requests), and honestly I'm not the person who is going to implement complete standards-compliant HTTP 1.1 client in any form. It won't hurt to implement it later if the need arises. > > > 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? Make them a part of one transaction -- I can perform actions as a part of transaction. After all, adduser script does it, why shouldn't I? > > 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. Umm... I have already mentioned that interactions with HTTP client specific for this system will be limited to the MIME Content-type, requested by it, and for lists manipulation I proposed url-encoded lists, so they can be passed unchanged for upload. As for sendmail... it does a lot of things in a smart way that can be kept transparent. > > 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. Again, this data is not only stored -- it's applied when configuring programs, and reconfiguration or remote update can be a part of transaction, too. > > > 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. Once I have lists and any kind of addressing system for those lists (LDAP directory or URLs), and can download data in the form it can be uloaded in, I can do it in any protocol. HTTP with symmetrically used Content-type will do the same thing (if I want a storage that won't actually configure anything, I will have to use PUT instead of POST). > > 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. I believe, Pilot will be unable to take the configuration of FreeBSD box directly, and just possibility pf downloading local configuration from somewhere in the form of tree-like organized lists with references can be done in any protocol that supports such semantics. The way, such configutarion update will be performed and update errors handled, especially in "mass-reconfiguration" on the network will differ with different protocols, and what is acceptable for Pilot will be unreliable for a cable box and too restrictive for FreeBSD host. > > > 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? Last released version 0.3.2 is at http://phobos.illtel.denver.co.us/pub/fhttpd/, server itself is GPL'ed, but API has BSDish license (to avoid contamination by GPL), I use it myself for various devices control that can't be done otherwise without ugly kludges. Code has places that can be and probably should be and will be written better, but nothing that can't be allowed to run as root on a system with reasonably high security requirements. -- Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.96.980204005855.32150A-100000>