From owner-freebsd-config Sun Feb 1 11:13:02 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17591 for config-outgoing; Sun, 1 Feb 1998 11:13:02 -0800 (PST) (envelope-from owner-config) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17586; Sun, 1 Feb 1998 11:13:00 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.8/8.8.8) id UAA15937; Sun, 1 Feb 1998 20:10:20 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199802011910.UAA15937@ocean.campus.luth.se> Subject: Re: FreeBSD updated Installation / Adminsitration Kit In-Reply-To: <34D25FB6@smginc.com> from Adam Turoff at "Jan 30, 98 03:19:00 pm" To: AdamT@smginc.com (Adam Turoff) Date: Sun, 1 Feb 1998 20:10:20 +0100 (CET) Cc: mike@smith.net.au, kpielorz@tdx.co.uk, hackers@FreeBSD.ORG, config@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Adam Turoff: > > > 3. We write something that tries to accomplish both the above, > > > hopefully not causing too many compromises. > > > > This would be a major layering mistake. > > I don't know about that. There are two interrelated issues here, as you > point out. First, we need a virgin installer to get FreeBSD on new > hardware. > That should leave a system that can be admined by something more > friendly than cryptic UNIX commands documented over $100 worth > of O'Reilly titles. THAT will help evangelize FreeBSD IMNSHO. Ok... I can't shut up. Here's my fantasy (kinda long). Enjoy! It should be a completely text based installer, much like the current one. There is no need for anything fancier. It should, however, be redesigned a little. I think it would be nice if the installer allowed you to set exactly one "configure thing". The keyboard setting. That should be asked for first thing, without having to be found in a meny. Then it should continue to ask user which kind of install to do. Have an "install" and one "advanced install" button. Choose install, and you get to read some documentation (not to long so people don't care to read it, but with a "tell me more" button), and then choose "normal, express, custom". Generally treat the user gently, and don't assume he knows strange words like "mount point". Take him through an install of the type we have today, but improved where possible. Give lots of recomendations. Choose "advanced install", and get the "ok, you know what you're doing, so help yourself" kind of thing that the current sysinstall provides with it's "custom" choise. In both these cases, let the user choose disks, and label them, set up ethernet/ppp/cdrom/whatever, and then start installing. When done, ask user to remove floppy, FreeBSD will reboot. It should now and run the generic system configuring utility (with option -FirstTime, for "Welcome to your new FreeBSD system. It's time to frob some knobs" message.) on ttyv0 instead of the login prompt. Also while loading kernel, have a nice splashscreen with a welcome pic, and a text like "press ESC to see probing messages", or whatever, down in a corner somewhere. The other virtual screens should be available with a login prompt where you could log in as root without password, so that people like us that's been there before can go in and do stuff on the side. Here you are able to set most things you will want to set, preferably even here with a special "advanced" choise, or having "advanced" choises for each thing you do, where it's needed (just like Win95 does it). Then you select "configuration done", and FreeBSD reboots, comes up again with "the real" splash image, and after booting, displays login prompt. This would allow for more free space on the boot floppy, for more drivers (preferably dynamically loaded in the future for small memory footprint) and more space for other stuff (ppp's libs? :-). Also it would allow for the system config even the first time to be pretty nice, since it can contain any amount of bloat needed. The system is already installed and running when you get to that point. So... Comments on this, anyone? :-) /Mikael From owner-freebsd-config Sun Feb 1 15:39:01 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA28354 for config-outgoing; Sun, 1 Feb 1998 15:39:01 -0800 (PST) (envelope-from owner-config) Received: from cam.grad.kiev.ua (grad-UTC-28k8.ukrtel.net [195.5.25.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA28349 for ; Sun, 1 Feb 1998 15:38:54 -0800 (PST) (envelope-from Ruslan@Shevchenko.kiev.ua) Received: from Shevchenko.kiev.ua (localhost [127.0.0.1]) by cam.grad.kiev.ua (8.8.8/8.8.5) with ESMTP id DAA12634 for ; Sun, 1 Feb 1998 03:37:22 +0200 (EET) Message-ID: <34D3D1D0.A67BE0B8@Shevchenko.kiev.ua> Date: Sun, 01 Feb 1998 03:37:21 +0200 From: Ruslan Shevchenko X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: freebsd-config@freebsd.org Subject: [Fwd: GUI admin tool] Content-Type: multipart/mixed; boundary="------------1947ECFECE716D36841B8FE4" Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------1947ECFECE716D36841B8FE4 Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Hmm, new mail list freebsd-config ? when it was introdused ? -- @= //RSSH mailto://Ruslan@Shevchenko.Kiev.UA --------------1947ECFECE716D36841B8FE4 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from nbki.ipri.kiev.ua (mails.ipri.kiev.ua [194.44.146.18]) by cki.ipri.kiev.ua (8.7.6/8.7.3) with ESMTP id BAA04868 for ; Mon, 2 Feb 1998 01:19:00 +0200 (EET) Received: from word.smith.net.au (ppp5.portal.net.au [202.12.71.105]) by nbki.ipri.kiev.ua (8.8.5/8.8.5) with ESMTP id BAA21460 for ; Mon, 2 Feb 1998 01:19:13 +0200 (EET) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id JAA00410 for ; Mon, 2 Feb 1998 09:42:34 +1030 (CST) Message-Id: <199802012312.JAA00410@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Ruslan Shevchenko Subject: Re: GUI admin tool In-reply-to: Your message of "Sat, 31 Jan 1998 21:56:45 +0200." <34D381FD.E18BF485@Shevchenko.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Feb 1998 09:42:32 +1030 From: Mike Smith > Just set up a web page for my initial sources. > > http://cam.grad.kiev.ua/~rssh/admin/admin.html > > please look. > > P.S. I'm dont shure, what is right place for this announce: hackers or > ports, so, sorry for cross-posting. Neither. Please post to -config. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ --------------1947ECFECE716D36841B8FE4-- From owner-freebsd-config Sun Feb 1 17:51:37 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA14230 for config-outgoing; Sun, 1 Feb 1998 17:51:37 -0800 (PST) (envelope-from owner-config) Received: from word.smith.net.au (ppp11.portal.net.au [202.12.71.111]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA14217 for ; Sun, 1 Feb 1998 17:51:26 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA00990; Mon, 2 Feb 1998 12:13:36 +1030 (CST) Message-Id: <199802020143.MAA00990@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Adam Turoff cc: "'mike@smith.net.au'" , Karl Pielorz , config Subject: Re: FreeBSD updated Installation / Adminsitration Kit In-reply-to: Your message of "Fri, 30 Jan 1998 15:19:00 PST." <34D25FB6@smginc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Feb 1998 12:13:36 +1030 From: Mike Smith Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Get over it. Microsoft spent gobs of money coming up with a set of > > rules that result in an interface that's easy to use. There's nothing > > dishonourable in stealing their ideas. > > After all, they stole most of their ideas, anyway. :-) That's not really fair. They bought at least some of them. 8) > [bobbit] > > > 3. We write something that tries to accomplish both the above, > > > hopefully not causing too many compromises. > > > > This would be a major layering mistake. > > I don't know about that. There are two interrelated issues here, as you > point out. First, we need a virgin installer to get FreeBSD on new > hardware. > That should leave a system that can be admined by something more > friendly than cryptic UNIX commands documented over $100 worth > of O'Reilly titles. THAT will help evangelize FreeBSD IMNSHO. Yes, but the two are not the same thing. Yes, they *will* sport a lot of the same component functionality. > > > SO - Yet again, I'm asking: > > > > > > a) Who's up for this? > > > > Yes. > > Ditto. Thanks; please stay around, and keep bouncing those ideas everyone. > > Read Netscape's LDAP developer pages, and work out how to talk to an > > LDAP server from Netscape. Start thinking (and talking) about how to > > tie all this together. > > OK. I did this in August, and barely made heads or tails out of it. > What I > got out of it was this: LDAP, like XML and SQL is an enabling standard > that makes complex things simpler and more approachable. > > Is that a good soundbite definition? Not really. Look at it this way: LDAP provides an efficient opaque parameter storage mechanism. It is network-friendly, can be secured, and a proven and reliable implementation already exists. An extra bonus with the UMich LDAP server (the one we are likely to use) is that parameters are actually handled by backends which can be added to the server. This means that you can make, say, the parameter space exported by Juliet (which corresponds to stuff scattered over the system's configuration files) appear inside the parameter space managed by the LDAP server. One parameter access method to rule them all, and in the darkness bind them. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-config Sun Feb 1 18:45:19 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18259 for config-outgoing; Sun, 1 Feb 1998 18:45:19 -0800 (PST) (envelope-from owner-config) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18243 for ; Sun, 1 Feb 1998 18:45:18 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA13809; Sun, 1 Feb 1998 19:43:56 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd013794; Sun Feb 1 19:43:55 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA04766; Sun, 1 Feb 1998 19:43:42 -0700 (MST) From: Terry Lambert Message-Id: <199802020243.TAA04766@usr01.primenet.com> Subject: Re: WebAdmin To: mike@smith.net.au (Mike Smith) Date: Mon, 2 Feb 1998 02:43:41 +0000 (GMT) Cc: abelits@phobos.illtel.denver.co.us, mike@smith.net.au, tlambert@primenet.com, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com In-Reply-To: <199802020130.MAA00938@word.smith.net.au> from "Mike Smith" at Feb 2, 98 12:00:37 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > You fail to understand. The entire point that you have missed is that > the 'transaction' that Terry is talking about is a transition whereby a > set of separate parameters assume new values in an atomic fashion. This is exactly what I mean. > HTTP has nothing at all to do with this. HTTP is the language used by > the server to draw the user interface on the client. The server has to > talk to the parameter store, and it is *that* interaction which must > support transactions. It certainly won't be using HTTP. A transaction is an atomic operation on a set of items that you would normally see in a single dialog. In database theory, you would want all of your data in third normal form, and you would have one dialog per database object. The technology used to present the dialog as a set of changes that can be "OK"'ed all at once or "Cancel"'ed all at once is irrelevent. It can be a text form on the console, it can be an HTTP form submission, it can be a JAVAScript client running on a Windows or Mac or Linux box, etc., etc. It doesn't matter. In practice, you can't atomically update the passwd database at the same time you create the user's home directory, etc.. But you can hold them in abeyance until you've done it, so at least you know what's been done and what hasn't after the request comes in. The method I was describing is called "a container object". It's the way you have to do it in LDAP or SNMP, since they don't support any type of transactioning interface. You *could* make "active objects", and write "start" to the "transact" part of the tree, but that's pretty gross, and won't work with all LDAP back ends. Better to work with everything, since you probably want to write a back end that interfaces to the existing databases as a first step. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-config Sun Feb 1 21:02:22 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03080 for config-outgoing; Sun, 1 Feb 1998 21:02:22 -0800 (PST) (envelope-from owner-config) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03071 for ; Sun, 1 Feb 1998 21:02:19 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id VAA20108; Sun, 1 Feb 1998 21:18:50 -0800 Date: Sun, 1 Feb 1998 21:18:49 -0800 (PST) From: Alex Belits To: Mike Smith cc: Terry Lambert , rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199802020130.MAA00938@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Feb 1998, Mike Smith wrote: > > > with the internals of the process exposed to the consumer. > > > > I disagree with that. HTTP is not a user-interface protocol (what, > > say, X protocol is), user interface is one of possible HTTP applications. > > You fail to understand. The entire point that you have missed is that > the 'transaction' that Terry is talking about is a transition whereby a > set of separate parameters assume new values in an atomic fashion. HTTP request with data is exactly the same thing. Implementations often completely defeat this feature, however the protocol allows to define transaction unambiguously, and without any identifier that should be known and supported by both server and client. > HTTP has nothing at all to do with this. HTTP is the language used by > the server to draw the user interface on the client. HTML is. HTTP isn't. Two different things. HTML can be sent from server to the client over HTTP, FTP, NNTP (weird, but possible), SMTP, and, for real perverts, TFTP. HTML form upload can be sent to the server over HTTP or SMTP. Of course, the most practical way is to use HTTP, but it has nothing to do with HTTP being anyhow tied to HTML -- just HTTP is the most practical protocol for the pattern of short upload-then-download or request-then-download cycles that are typical for the access to passivel waiting server with relatively large amount of data to receive (so hundreds of bytes per operation spent on headers are justified). HTTP can be used to send to the client HTML, GIF, plain text, RFC 822 message, comma-separated list, tab-separated list or URL-encoded form list, not ot mention any kind of file format, MIME type exists for. HTTP can be used to upload from the client to the server exactly the same set of data formats that can be downloaded -- there is no special restriction for it in the protocol, however existing _browsers_ (not all HTTP clients are browsers) are interactive programs, and that places restrictions on what they send and use. > The server has to > talk to the parameter store, and it is *that* interaction which must > support transactions. It certainly won't be using HTTP. Server, when talking to the local parameter store should use whatever allows atomic transactions, and transaction may fail for something that will be outside the local transaction mechanism. Ex: local transactions mechanism is file locking and running scripts on completion. Server received the set of parameters, locked the files, changed their content, unlocked, started reconfiguration scripts, scripts returned an error. Transaction, defined as files change, succeeded, but overall transaction that has its meaning for the system configuration, failed. Properly designed administration system should reverse changes and reconfigure system again, because in some case otherwise you will get unreachable system, and the whole idea of remote configuration will be defeated. If server managed to "fix" system to the state that system had before the transaction started, it should report transaction failure to the client. If not, client should receive some error that indicates the transaction failure and impossibility to restore pre-transaction state, and that should be a thing to worry about, however at least it's some situation where in most of cases it's possible to report or detect fatal error cleanly. All that can be implemented easily over HTTP, and the "fatal error" condition in the best case produces the error message to the request, and in the worst case leaves the system unreachable and produces protocol error. However it's possible to do other, more complex things using this transaction without identifier mechanism. Say, the change of configuration should be applied to the group of machines because in its case group acts as the whole -- say, fileserver, authentication server and clients of both. Administration box will issue requests for changes in the order, it (or its sysadmin), considers to be appropriate, and if everything succeeded the whole transaction is succeeded on it. If not, it will be the responsibility of administration box (acting as a client for others) to reverse changes on boxes where their part of transaction failed. It's possible that transaction is done for the group of hundreds of boxes. One administration box will be impractical, and many administration boxes are organized in tree-like fashion, using some protocol (say, HTTP). Then every local administration box has its own transaction that is a part of main transaction, and it may be necessary to have local recovery procedure confined to the local administration box. In this case one should ask local administration box to reverse the already finished transaction, and unless main administration box wants to deal with all changes on all local boxes, it will need to tell local administration box, which transaction to reverse. This is the only case when identifiers that should be known to both server and client are really necesary -- it's the identifier of transaction that should be reversed. However that transaction may contain huge number of objects and in itself it can be a macro, globally or even locally defined for the network ("change nameserver to local nameserver for subnet if it exists, otherwise to the new nameserver"), so main administration box may never know what objects are actually changed. It also can be nested -- once local transactions can be opaque and contain macros, it's possible to nest them over multiple servers, thus making a tree. IMHO this kind of system is more clean and extensible. -- Alex From owner-freebsd-config Sun Feb 1 21:36:02 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA06301 for config-outgoing; Sun, 1 Feb 1998 21:36:02 -0800 (PST) (envelope-from owner-config) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA06280 for ; Sun, 1 Feb 1998 21:35:57 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id VAA20275; Sun, 1 Feb 1998 21:51:09 -0800 Date: Sun, 1 Feb 1998 21:51:08 -0800 (PST) From: Alex Belits To: Terry Lambert cc: Mike Smith , rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199802020243.TAA04766@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Feb 1998, Terry Lambert wrote: > > You fail to understand. The entire point that you have missed is that > > the 'transaction' that Terry is talking about is a transition whereby a > > set of separate parameters assume new values in an atomic fashion. > > This is exactly what I mean. > HTTP has implicit transaction identifier as the representation of request and response to it are tied together at both client and server even though there is no explicit identifier that server and client share. This identifier is replaced by the protocol state in the protocol and exists on client as paired request and received response to it and at the server as the same thing (sometimes in rather primitive form of CGI process id, sometimes as TCP connection, if persistent connections aren't used, sometimes explicitly). -- Alex From owner-freebsd-config Sun Feb 1 22:46:05 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA12443 for config-outgoing; Sun, 1 Feb 1998 22:46:05 -0800 (PST) (envelope-from owner-config) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA12438 for ; Sun, 1 Feb 1998 22:46:04 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id XAA12150; Sun, 1 Feb 1998 23:45:57 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpd012087; Sun Feb 1 23:45:50 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id XAA15364; Sun, 1 Feb 1998 23:45:43 -0700 (MST) From: Terry Lambert Message-Id: <199802020645.XAA15364@usr01.primenet.com> Subject: Re: WebAdmin To: abelits@phobos.illtel.denver.co.us (Alex Belits) Date: Mon, 2 Feb 1998 06:45:43 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com In-Reply-To: from "Alex Belits" at Feb 1, 98 09:51:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > HTTP has implicit transaction identifier as the representation of > request and response to it are tied together at both client and server > even though there is no explicit identifier that server and client share. > This identifier is replaced by the protocol state in the protocol and > exists on client as paired request and received response to it and at the > server as the same thing (sometimes in rather primitive form of CGI > process id, sometimes as TCP connection, if persistent connections aren't > used, sometimes explicitly). This is not terrifically useful for a text-only install on a serial console. Remember that whatever technology is selected must work without http. What you are describing is an implementation detail for a general interface. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-config Sun Feb 1 23:10:47 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA14448 for config-outgoing; Sun, 1 Feb 1998 23:10:47 -0800 (PST) (envelope-from owner-config) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA14442 for ; Sun, 1 Feb 1998 23:10:45 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id XAA20643; Sun, 1 Feb 1998 23:27:30 -0800 Date: Sun, 1 Feb 1998 23:27:29 -0800 (PST) From: Alex Belits To: Terry Lambert cc: mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199802020645.XAA15364@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Feb 1998, Terry Lambert wrote: > > used, sometimes explicitly). > > This is not terrifically useful for a text-only install on a serial > console. Remember that whatever technology is selected must work > without http. > > What you are describing is an implementation detail for a general > interface. I only mean that HTTP protocol provides means for transactions handling implementation that don't need an identifier being passed explicitly. It's definitely possible to use any other protocol or invent new one that will provide the same thing with (your example with LDAP) or without identifier, however I think that HTTP provides exactly what is necessary without increasing the number of protocols involved. As for text console and no network connection, HTTP is perfectly usable over loopback network interface with text-mode client for user interface, so user-interface part (if necessary) can be done through it, too. Again, it can be done through locally running application with any kind of user interface or none at all with nothing related to HTML, or remotely running the same application, or whatever else -- just the possibility of adding HTML user interface without introducing new protocols and authentication systems to existing ones makes HTTP a bit better choice for internal protocol. At least, it will be more manageable, secure, suitable for large network or single non-networked host, and consistent by design than anything NIS-like (network administration) or SMIT-like (local administration). -- Alex From owner-freebsd-config Mon Feb 2 01:07:31 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA28652 for config-outgoing; Mon, 2 Feb 1998 01:07:31 -0800 (PST) (envelope-from owner-config) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA28647; Mon, 2 Feb 1998 01:07:29 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id BAA11071; Mon, 2 Feb 1998 01:07:09 -0800 (PST) To: Mikael Karpberg cc: AdamT@smginc.com (Adam Turoff), mike@smith.net.au, kpielorz@tdx.co.uk, hackers@FreeBSD.ORG, config@FreeBSD.ORG Subject: Re: FreeBSD updated Installation / Adminsitration Kit In-reply-to: Your message of "Sun, 01 Feb 1998 20:10:20 +0100." <199802011910.UAA15937@ocean.campus.luth.se> Date: Mon, 02 Feb 1998 01:07:09 -0800 Message-ID: <11067.886410429@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > So... Comments on this, anyone? :-) Yeah, when do we get to see your prototype? :-) Jordan From owner-freebsd-config Mon Feb 2 07:02:57 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA11128 for config-outgoing; Mon, 2 Feb 1998 07:02:57 -0800 (PST) (envelope-from owner-config) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA11123 for ; Mon, 2 Feb 1998 07:02:55 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id HAA22488; Mon, 2 Feb 1998 07:04:22 -0800 Date: Mon, 2 Feb 1998 07:04:21 -0800 (PST) From: Alex Belits To: Mike Smith cc: Terry Lambert , rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199802020903.TAA02101@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Feb 1998, Mike Smith wrote: > > without increasing the number of protocols involved. > > You have completely and utterly failed to comprehend what is going on > here, in the face of several clear explanations and plenty of > references. Let me try again. > > HTTP is not an *available*option* for talking to a distributed > parameter store, unless you happen to have written one and stashed it > up your sleeve. There are ones that do it -- I wrote one implementation of HTTP backend that handles requests in the manner, required for that, but it's not the only thing of this kind. > Thus, it doesn't matter the slightest whether HTTP supports > transactions; the only available distributed backend that we are likely > to be able to use (LDAP) DOES NOT (at this point in time). > > Are you following me so far? No, I'm incredibly dumb. > OK, about now, you are going to try to > ask about HTTP <-> LDAP gateways. I hope you stop first and consider > how the gateway proposes to guarantee the atomicity of the series of > operations that it has to perform in order to complete the HTTP > transaction. It can't, short of using a container object. Now, what > were we saying about container objects before? If a protocol that does not support transactions in itself is involved, you have to use container object with identifier, known to both server and client and tie transaction to the operation on that object. What I fail to see is the advantage of using LDAP in this case -- just being a directory service hardly can be a sufficient qualification for suitability as remote configuration protocol. > Please. Try to stick vaguely close to reality. If you want to > *implement* your reality, then by all means, go right ahead. I don't have the implementation of configuration editor/manager for FreeBSD and servers hierarchy system that I have described earlier. However requests processing model that I have implemented in my HTTP server can easily be used as the base for such system. I will like to develop it further (generalized parameters store to HTTP interface, configuration update operation that can fail for succeeded store update and require reversing transaction, and servers hierarchy support -- it's all not a rocket science, unless implementation means are crippled by, say, CGI interface). The problem is that if I'm the only person who see it as a possibility, there will be little reason using that for FreeBSD configuration -- it's a large project, and even if I'll write some basic configuration in that, flexibility of it (if it will be implemented right) will be wasted if no one else will want to write parts and extensions for it. -- Alex From owner-freebsd-config Mon Feb 2 08:37:09 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA22688 for config-outgoing; Mon, 2 Feb 1998 08:37:09 -0800 (PST) (envelope-from owner-config) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA22679 for ; Mon, 2 Feb 1998 08:37:05 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.8/8.8.8) id RAA17963; Mon, 2 Feb 1998 17:34:33 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199802021634.RAA17963@ocean.campus.luth.se> Subject: Re: FreeBSD updated Installation / Adminsitration Kit In-Reply-To: <11067.886410429@time.cdrom.com> from "Jordan K. Hubbard" at "Feb 2, 98 01:07:09 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 2 Feb 1998 17:34:33 +0100 (CET) Cc: config@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Jordan K. Hubbard: > > So... Comments on this, anyone? :-) > > Yeah, when do we get to see your prototype? :-) Very funny. Not a very useful comment. I know you're short on email time, but how about: Why do I bother making a prototype when you're not even bothering to say at least something like "sounds very good", before asking for a prototype. :-) And no, I'm not offering to code this. I might be willing to helpa little, test, and give input along the way, but it seems we have enough people interested indoing this, and Mike specifically employed for it, it seems. I don't have time to code it, I'm sad to say, but that doesn't mean good ideas shouldn't be put forward for others to consider, no? /Mikael From owner-freebsd-config Mon Feb 2 11:03:10 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA14057 for config-outgoing; Mon, 2 Feb 1998 11:03:10 -0800 (PST) (envelope-from owner-config) Received: from webserver.smginc.com (webserver.smginc.com [204.170.176.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA14022; Mon, 2 Feb 1998 11:03:07 -0800 (PST) (envelope-from AdamT@smginc.com) Received: from smginc.com ([204.170.177.4]) by webserver.smginc.com (post.office MTA v2.0 0813 ID# 0-13723) with SMTP id AAA280; Mon, 2 Feb 1998 14:05:07 -0500 Received: by smginc.com with Microsoft Mail id <34D6422A@smginc.com>; Mon, 02 Feb 98 14:01:14 PST From: Adam Turoff To: "'hackers@freebsd.org'" , "'config@freebsd.org'" Cc: "'mike@smith.net.au'" Subject: Multi-faced admin Date: Mon, 02 Feb 98 14:03:00 PST Message-ID: <34D6422A@smginc.com> Encoding: 43 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Looking at Mikael Karpberg page on his architecture for admin'ing a FreeBSD box, I came across a link to Caldera's COAS project: http://www.coas.org I'm rather sorry to say that I haven't looked deeply into some of the broad scope ideas that people have been posting to -hackers recently. (I feel rather guilty that I haven't committed my big picture to bits and bytes yet either.) We all know what it means to be spread thin, I guess. :-) Anyway, skimming over COAS, (Caldera Open Adminstration System), it looks like either it's something worth porting, or it's something worth improving upon. All of the standard knobs are there, like curses/X/Java interfaces, etc. (Sorry, I can't post a summary right now. The code is at v0.09, appears to use lots of python and is GPL'd.) --- Reading the post about UMich's LDAP engine, it sounds rather radical. So, as of the moment, here's a concise view of what I'm seeing/hearing for a FreeBSD framework: - httpd type server (easy to plug any client into/write new clients) - standardized CGI interface subset for admin modules - LDAP for config managment by admin modules Five layers (three for glue) to have any random client reconfigure any part of the system. The top glue is pretty dumb; it just standardizes the interface. The middle glue layer is where all the work is done. The bottom glue layer appears rather dumb, but it should hide the complexity of a bazillion different config file formats (if I'm reading what Mike is saying about LDAP correctly). Sound good? I'll start a prototype in my copious free time before the end of the month. :-) -- Adam. PS: Mike, where can I find some docs, etc. on the UMich LDAP server? From owner-freebsd-config Mon Feb 2 11:12:06 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA16051 for config-outgoing; Mon, 2 Feb 1998 11:12:06 -0800 (PST) (envelope-from owner-config) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA16015 for ; Mon, 2 Feb 1998 11:12:02 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA23333; Mon, 2 Feb 1998 12:11:41 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd023301; Mon Feb 2 12:11:39 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id MAA08865; Mon, 2 Feb 1998 12:11:26 -0700 (MST) From: Terry Lambert Message-Id: <199802021911.MAA08865@usr04.primenet.com> Subject: Re: WebAdmin To: abelits@phobos.illtel.denver.co.us (Alex Belits) Date: Mon, 2 Feb 1998 19:11:26 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com In-Reply-To: from "Alex Belits" at Feb 1, 98 11:27:29 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I only mean that HTTP protocol provides means for transactions handling > implementation that don't need an identifier being passed explicitly. It's > definitely possible to use any other protocol or invent new one that will > provide the same thing with (your example with LDAP) or without > identifier, however I think that HTTP provides exactly what is necessary > without increasing the number of protocols involved. OK, I think that you may be missing where I'm putting LDAP. I am not presenting LDAP as a wire protocol, but as an API. This would work better with a whiteboard, but... ,---. ,---------. ,---------. ,---------. ,---------. |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 | `--------------' `-----------------------------------' > As for text console and no network connection, HTTP is perfectly usable > over loopback network interface with text-mode client for user interface, > so user-interface part (if necessary) can be done through it, too. Again, > it can be done through locally running application with any kind of user > interface or none at all with nothing related to HTML, or remotely > running the same application, or whatever else -- just the possibility of > adding HTML user interface without introducing new protocols and > authentication systems to existing ones makes HTTP a bit better choice for > internal protocol. At least, it will be more manageable, secure, suitable > for large network or single non-networked host, and consistent by design > than anything NIS-like (network administration) or SMIT-like (local > administration). 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? Alternately, you could use ACAP. Unfortunately, the only implementation I know of that runs on FreeBSD uses g++ 2.8.0, the Moscow center for SPARC computing's STL with modifications to work with FreeBSD's Draft 4 Pthreads which haven't been upgraded to standard Pthreads yet, libg++ (the templates for which may constitute sufficient code in header files to fall under the "code in headers" clause of LGPL, etc.. Not to mention that Jeremy Allison and I haven't sent our patches back to the CMU folks yet... ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-config Mon Feb 2 11:34:44 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21771 for config-outgoing; Mon, 2 Feb 1998 11:34:44 -0800 (PST) (envelope-from owner-config) Received: from cam.grad.kiev.ua (grad-UTC-28k8.ukrtel.net [195.5.25.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21762; Mon, 2 Feb 1998 11:34:38 -0800 (PST) (envelope-from Ruslan@Shevchenko.kiev.ua) Received: from Shevchenko.kiev.ua (localhost [127.0.0.1]) by cam.grad.kiev.ua (8.8.8/8.8.5) with ESMTP id XAA14431; Sun, 1 Feb 1998 23:32:24 +0200 (EET) Message-ID: <34D4E9DE.3F127D46@Shevchenko.kiev.ua> Date: Sun, 01 Feb 1998 23:32:18 +0200 From: Ruslan Shevchenko X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Adam Turoff CC: "'hackers@freebsd.org'" , "'config@freebsd.org'" , "'mike@smith.net.au'" Subject: Re: Multi-faced admin References: <34D6422A@smginc.com> Content-Type: multipart/alternative; boundary="------------0D9DB95FA17AC9268C1299B7" Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk --------------0D9DB95FA17AC9268C1299B7 Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Adam Turoff wrote: > Looking at Mikael Karpberg page on his architecture for admin'ing a ------------------------------------------------------------------------------- URL ? > FreeBSD > box, I came across a link to Caldera's COAS project: http://www.coas.org > > I'm rather sorry to say that I haven't looked deeply into some of the > broad > scope ideas that people have been posting to -hackers recently. (I feel > rather guilty that I haven't committed my big picture to bits and bytes > yet > either.) We all know what it means to be spread thin, I guess. :-) > > Anyway, skimming over COAS, (Caldera Open Adminstration System), > it looks like either it's something worth porting, or it's something > worth > improving upon. All of the standard knobs are there, like curses/X/Java > interfaces, etc. (Sorry, I can't post a summary right now. The code is > at v0.09, appears to use lots of python and is GPL'd.) And it is very unclean, on first look. > --- > > Reading the post about UMich's LDAP engine, it sounds rather radical. > So, as of the moment, here's a concise view of what I'm seeing/hearing > for a FreeBSD framework: > > - httpd type server (easy to plug any client into/write new clients) (why httpd server ? first-step is cgi. > - standardized CGI interface subset for admin modules > - LDAP for config managment by admin modules > > Five layers (three for glue) to have any random client reconfigure > any part of the system. The top glue is pretty dumb; it just > standardizes the interface. The middle glue layer is where all > the work is done. The bottom glue layer appears rather dumb, > but it should hide the complexity of a bazillion different config file > formats > (if I'm reading what Mike is saying about LDAP correctly). > > Sound good? I'll start a prototype in my copious free time before > the end of the month. :-) > I now work on configuration system for FreeBSD, which have next layers: C++ API --------- Tcl binding ----------------- Tk Interface ------------------ CGI Interface (future) --------- CORBA (future) At now I implemented all READ-CONFIG methods in C++, and write a part of GUI stuff, which looks better, than Linux UserCfg in python. look at http://cam.grad.kiev.ua/~rssh/admin/admin.html for details About General interface with Set-Get/Add-Remove metods under abstract stuff: sounds very good, but, imho, we must have glue API interface on some "real" language (tcl or CORBA ), but not declarative "sheme". > -- Adam. > > PS: Mike, where can I find some docs, etc. on the UMich LDAP server? Altavista on Query +LDAP +UNIX work fine ;) -- @= //RSSH mailto://Ruslan@Shevchenko.Kiev.UA --------------0D9DB95FA17AC9268C1299B7 Content-Type: text/html; charset=x-user-defined Content-Transfer-Encoding: 7bit Adam Turoff wrote:
Looking at Mikael Karpberg page on his architecture for admin'ing a
  -------------------------------------------------------------------------------  URL ?

FreeBSD
box, I came across a link to Caldera's COAS project: http://www.coas.org

I'm rather sorry to say that I haven't looked deeply into some of the
broad
scope ideas that people have been posting to -hackers recently.  (I feel
rather guilty that I haven't committed my big picture to bits and bytes
yet
either.)  We all know what it means to be spread thin, I guess.  :-)

Anyway, skimming over COAS, (Caldera Open Adminstration System),
it looks like either it's something worth porting, or it's something
worth
improving upon.  All of the standard knobs are there, like curses/X/Java
interfaces, etc.  (Sorry, I can't post a summary right now.  The code is
at v0.09, appears to use lots of python and is GPL'd.)

 And it is very unclean, on first look.

 ---

Reading the post about UMich's LDAP engine, it sounds rather radical.
So, as of the moment, here's a concise view of what I'm seeing/hearing
for a FreeBSD framework:

 - httpd type server (easy to plug any client into/write new clients)

   (why httpd server ?     first-step is cgi.
 - standardized CGI interface subset for admin modules
 - LDAP for config managment by admin modules

Five layers (three for glue) to have any random client reconfigure
any part of the system.  The top glue is pretty dumb; it just
standardizes the interface.  The middle glue layer is where all
the work is done.  The bottom glue layer appears rather dumb,
but it should hide the complexity of a bazillion different config file
formats
(if I'm reading what Mike is saying about LDAP correctly).

Sound good?  I'll start a prototype in my copious free time before
the end of the month.  :-)
 

I now work on configuration system for FreeBSD, which have next layers:

 C++ API
               --------- Tcl  binding
                              ----------------- Tk Interface
                              ------------------ CGI Interface  (future)
              ---------  CORBA  (future)

At now I implemented all READ-CONFIG methods in C++,
 and write a part of GUI stuff, which looks better, than Linux UserCfg in python.

look at http://cam.grad.kiev.ua/~rssh/admin/admin.html for details

About General interface with Set-Get/Add-Remove metods under abstract stuff:
 sounds very good, but, imho, we must have glue API interface on some
"real"  language (tcl or CORBA ), but  not declarative "sheme".
 

 -- Adam.

PS: Mike, where can I find some docs, etc. on the UMich LDAP server?

Altavista on Query +LDAP  +UNIX work fine ;) 
-- 

    @=                                   
     //RSSH                              mailto://Ruslan@Shevchenko.Kiev.UA
  --------------0D9DB95FA17AC9268C1299B7-- From owner-freebsd-config Mon Feb 2 11:53:00 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27661 for config-outgoing; Mon, 2 Feb 1998 11:53:00 -0800 (PST) (envelope-from owner-config) Received: from cam.grad.kiev.ua (grad-UTC-28k8.ukrtel.net [195.5.25.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27645; Mon, 2 Feb 1998 11:52:55 -0800 (PST) (envelope-from Ruslan@Shevchenko.kiev.ua) Received: from Shevchenko.kiev.ua (localhost [127.0.0.1]) by cam.grad.kiev.ua (8.8.8/8.8.5) with ESMTP id XAA14455; Sun, 1 Feb 1998 23:50:59 +0200 (EET) Message-ID: <34D4EE40.B4AEB283@Shevchenko.kiev.ua> Date: Sun, 01 Feb 1998 23:50:57 +0200 From: Ruslan Shevchenko X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Adam Turoff CC: "'hackers@freebsd.org'" , "'config@freebsd.org'" , "'mike@smith.net.au'" Subject: Re: Multi-faced admin References: <34D6422A@smginc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At first, sorry if it is my second podt (I just crashed my Netscape, so re-reply message) Adam Turoff wrote: > Looking at Mikael Karpberg page on his architecture for admin'ing a > FreeBSD > Please, can you give URL ? > box, I came across a link to Caldera's COAS project: http://www.coas.org > > I'm rather sorry to say that I haven't looked deeply into some of the > broad > scope ideas that people have been posting to -hackers recently. (I feel > rather guilty that I haven't committed my big picture to bits and bytes > yet > either.) We all know what it means to be spread thin, I guess. :-) > > Anyway, skimming over COAS, (Caldera Open Adminstration System), > it looks like either it's something worth porting, or it's something > worth > improving upon. All of the standard knobs are there, like curses/X/Java > interfaces, etc. (Sorry, I can't post a summary right now. The code is > at v0.09, appears to use lots of python and is GPL'd.) > I look on it -- not very fine. > --- > > Reading the post about UMich's LDAP engine, it sounds rather radical. > So, as of the moment, here's a concise view of what I'm seeing/hearing > for a FreeBSD framework: > > - httpd type server (easy to plug any client into/write new clients) > - standardized CGI interface subset for admin modules > - LDAP for config managment by admin modules > > Five layers (three for glue) to have any random client reconfigure > any part of the system. The top glue is pretty dumb; it just > standardizes the interface. The middle glue layer is where all > the work is done. The bottom glue layer appears rather dumb, > but it should hide the complexity of a bazillion different config file > formats > (if I'm reading what Mike is saying about LDAP correctly). > > Sound good? I'll start a prototype in my copious free time before > the end of the month. :-) > I have the partial realization of the next system: C++ API -------- Command-Line -------- TCL-binding ------------ Tk interface ------------ CGI interface (feauture) --------- CORBA interface (future) ------------- TCL-binding ------------- Java binding for details, look at http://cam.grad.kiev.ua/~rssh/admin/admin.html In principle is good to use some generic Set-Get/Add-Delete interface under abstract classes, but glue must be, IMHO, not declarative "sheme" as in COAS, but have some real API (TCL or CORBA). Of course, we can use sheme-s on some level. > -- Adam. > > PS: Mike, where can I find some docs, etc. on the UMich LDAP server? Altavista. ;) -- @= //RSSH mailto://Ruslan@Shevchenko.Kiev.UA From owner-freebsd-config Mon Feb 2 12:09:28 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00872 for config-outgoing; Mon, 2 Feb 1998 12:09:28 -0800 (PST) (envelope-from owner-config) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA00774; Mon, 2 Feb 1998 12:08:59 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.8/8.8.8) id VAA18349; Mon, 2 Feb 1998 21:05:32 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199802022005.VAA18349@ocean.campus.luth.se> Subject: Re: Multi-faced admin In-Reply-To: <34D4EE40.B4AEB283@Shevchenko.kiev.ua> from Ruslan Shevchenko at "Feb 1, 98 11:50:57 pm" To: Ruslan@Shevchenko.kiev.ua (Ruslan Shevchenko) Date: Mon, 2 Feb 1998 21:05:32 +0100 (CET) Cc: hackers@FreeBSD.ORG, config@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Ruslan Shevchenko: > > Looking at Mikael Karpberg page on his architecture for admin'ing a > > FreeBSD > Please, can you give URL ? Er, cool. I didn't know I had such a page ;-) Seriously, though, I think Alex has his terms all screwed up. Probably silly enough to use a brower to send mails, and mixes up pages and mails. I sent a suggestion to hackers@FreeBSD.ORG and config@FreeBSD.ORG, and that's all I did. /Mikael From owner-freebsd-config Mon Feb 2 12:36:24 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05002 for config-outgoing; Mon, 2 Feb 1998 12:36:24 -0800 (PST) (envelope-from owner-config) Received: from webserver.smginc.com (webserver.smginc.com [204.170.176.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04992; Mon, 2 Feb 1998 12:36:20 -0800 (PST) (envelope-from AdamT@smginc.com) Received: from smginc.com ([204.170.177.4]) by webserver.smginc.com (post.office MTA v2.0 0813 ID# 0-13723) with SMTP id AAA278; Mon, 2 Feb 1998 15:38:12 -0500 Received: by smginc.com with Microsoft Mail id <34D657FB@smginc.com>; Mon, 02 Feb 98 15:34:19 PST From: Adam Turoff To: "'karpen@ocean.campus.luth.se'" , Ruslan Cc: hackers , config Subject: RE: Multi-faced admin Date: Mon, 02 Feb 98 15:36:00 PST Message-ID: <34D657FB@smginc.com> Encoding: 43 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sez Mikael Karpberg: > According to Ruslan Shevchenko: > > > Looking at Mikael Karpberg page on his architecture for admin'ing a > > > FreeBSD > > Please, can you give URL ? > > Er, cool. I didn't know I had such a page ;-) D'OH! I think I lost too many brain cells this weekend. Not only am I using a dain-bread mailer, but I'm doing the job it is supposed to be doing rather poorly. :-) The page I was referring to was actually your's Ruslan: ftp://cam.grad.kiev.ua/pub/admin.tgz That kind of explains why you're not to fond of COAG.... [Now that the topic has been brought up again, let's not misunderstand anymore. I glossed over both Ruslan's page and the COAG page. The COAG page has much more gloss, and upon a cursory examination I thought we should look into it a bit more deeply. I didn't take the time to look at the architecture, but, as Ruslan suggests, if it's a piece of crap, we should at the very least take their architecture as an example and not make the same bugs. :-) ] > Seriously, though, I think Alex has his terms all screwed up. Probably > silly enough to use a brower to send mails, and mixes up pages and mails. > I sent a suggestion to hackers@FreeBSD.ORG and config@FreeBSD.ORG, and > that's all I did. I probably deserve that slip (Don't want to have anyone confuse Alex with me. I'm the one fighting with a stupid mailer! And, no, I'm not using a browser, I'm using the worst mailer in Corporate America - Microsoft Outlook. I'll switch my mailing list subscriptions to Eudora or somesuch when I get enough tuits.) Sorry if I started any confusion here, Mikael and Ruslan. -- Adam. PS: D'OH! From owner-freebsd-config Mon Feb 2 17:01:56 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA21057 for config-outgoing; Mon, 2 Feb 1998 17:01:56 -0800 (PST) (envelope-from owner-config) Received: from phobos.illtel.denver.co.us (root@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA20758 for ; Mon, 2 Feb 1998 17:00:58 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id PAA24836; Mon, 2 Feb 1998 15:56:15 -0800 Date: Mon, 2 Feb 1998 15:56:15 -0800 (PST) From: Alex Belits To: Terry Lambert cc: mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199802021911.MAA08865@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 2 Feb 1998, Terry Lambert wrote: > OK, I think that you may be missing where I'm putting LDAP. I am > not presenting LDAP as a wire protocol, but as an API. > > This would work better with a whiteboard, but... > > ,---. ,---------. ,---------. ,---------. ,---------. > |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? Files as self-contained and unrelated storage?) and two protocols - LDAP (you mentioned network connection -- so it is also internal "wire protocol" and at least one external "wire protocol" -- say, HTTP. Where the authentication is going to be performed? and if in two places, how authentication information and/or credentials will be passed in this system between them? 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? 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? 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? 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? 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, 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. [skipped] > 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. 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. -- Alex From owner-freebsd-config Mon Feb 2 17:53:11 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA29093 for config-outgoing; Mon, 2 Feb 1998 17:53:11 -0800 (PST) (envelope-from owner-config) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA29088 for ; Mon, 2 Feb 1998 17:53:09 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id RAA14504; Mon, 2 Feb 1998 17:53:05 -0800 (PST) To: Mikael Karpberg cc: config@FreeBSD.ORG Subject: Re: FreeBSD updated Installation / Adminsitration Kit In-reply-to: Your message of "Mon, 02 Feb 1998 17:34:33 +0100." <199802021634.RAA17963@ocean.campus.luth.se> Date: Mon, 02 Feb 1998 17:53:05 -0800 Message-ID: <14500.886470785@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I probably should have been more explanatory, but as you say I'm a bit short on email time at the moment. Please don't take this the wrong way, but what motivated my reply was the fact that your message could have been a practical excerpt of conversations that have gone before, some as long as 3 years ago. Not one of the goals or proposed methods you suggested were in any way new - it's all been said before. What would be new is someone actually implementing all that stuff, and hence my reply. :-) I also have fond hopes for Mike Smith's efforts, of course, but it goes without saying that he's not going to be able to add all those creture comfort features alone. I hope that others will be more forthcoming with actual code so that the goals expoused by yourself and many others before you can actually be realized. There's no shortage of ideas on what needs to be done, believe me. :-( Jordan > According to Jordan K. Hubbard: > > > So... Comments on this, anyone? :-) > > > > Yeah, when do we get to see your prototype? :-) > > Very funny. Not a very useful comment. I know you're short on email time, > but how about: > > Why do I bother making a prototype when you're not even bothering to > say at least something like "sounds very good", before asking for a > prototype. :-) > > And no, I'm not offering to code this. I might be willing to helpa little, > test, and give input along the way, but it seems we have enough people > interested indoing this, and Mike specifically employed for it, it seems. > > I don't have time to code it, I'm sad to say, but that doesn't mean good > ideas shouldn't be put forward for others to consider, no? > > /Mikael From owner-freebsd-config Mon Feb 2 18:10:47 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA02565 for config-outgoing; Mon, 2 Feb 1998 18:10:47 -0800 (PST) (envelope-from owner-config) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA02560 for ; Mon, 2 Feb 1998 18:10:44 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA23741; Mon, 2 Feb 1998 19:10:27 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd023720; Mon Feb 2 19:10:25 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA06735; Mon, 2 Feb 1998 19:10:06 -0700 (MST) From: Terry Lambert Message-Id: <199802030210.TAA06735@usr01.primenet.com> Subject: Re: WebAdmin To: abelits@phobos.illtel.denver.co.us (Alex Belits) Date: Tue, 3 Feb 1998 02:10:06 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com In-Reply-To: from "Alex Belits" at Feb 2, 98 03:56:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > ,---. ,---------. ,---------. ,---------. ,---------. > > |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. From owner-freebsd-config Tue Feb 3 07:59:47 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA13599 for config-outgoing; Tue, 3 Feb 1998 07:59:47 -0800 (PST) (envelope-from owner-config) Received: from bb.cc.wa.us (root@aries.bb.cc.wa.us [134.39.181.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA13594; Tue, 3 Feb 1998 07:59:46 -0800 (PST) (envelope-from chris@bb.cc.wa.us) Received: from localhost (chris@localhost) by bb.cc.wa.us (8.8.5/8.6.9) with SMTP id HAA05063; Tue, 3 Feb 1998 07:50:35 -0800 (PST) Date: Tue, 3 Feb 1998 07:50:35 -0800 (PST) From: Chris Coleman To: Mikael Karpberg cc: Adam Turoff , mike@smith.net.au, kpielorz@tdx.co.uk, hackers@FreeBSD.ORG, config@FreeBSD.ORG Subject: Re: FreeBSD updated Installation / Adminsitration Kit In-Reply-To: <199802011910.UAA15937@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > text like "press ESC to see probing messages", or whatever, down in a > corner somewhere. The other virtual screens should be available with a > login prompt where you could log in as root without password, so that > people like us that's been there before can go in and do stuff on the > side. > > Here you are able to set most things you will want to set, preferably > even here with a special "advanced" choise, or having "advanced" choises > for each thing you do, where it's needed (just like Win95 does it). I liked everything up until the reboot. :-( Win95 reboots so many times, that it takes hours of time trying to install. I really like the idea of having an "automated" feature. (wish win95 had one) where you could enter in all the information in a few basic screens and then just leave it. When you come back, its installed and rebooted waiting at the the login prompt. FreeBSD almost does this. (you would have to remove the floppy before leaving). It would stop only on critical errors, and log the rest. Otherwise it would be real easy to install a basic system. > So... Comments on this, anyone? :-) > > /Mikael > > Just my $.02 Christopher J. Coleman (whyareyou@lookingforme.com) Computer Support Analyst I (509)-762-6341 FreeBSD Book Project: http://www.vmunix.com/fbsd-book/ From owner-freebsd-config Tue Feb 3 08:47:13 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA20223 for config-outgoing; Tue, 3 Feb 1998 08:47:13 -0800 (PST) (envelope-from owner-config) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA20211 for ; Tue, 3 Feb 1998 08:47:10 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id KAA07178; Tue, 3 Feb 1998 10:47:00 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199802031542.PAA16355@monoid.cs.tcd.ie> References: Message from Adrian Chadd dated today at 22:57. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Feb 1998 10:45:46 -0600 To: careilly@monoid.cs.tcd.ie, config@FreeBSD.ORG From: Richard Wackerbarth Subject: Re: WebAdmin Cc: Adrian Chadd Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 9:42 AM -0600 2/3/98, Colman Reilly wrote: > the databases useable and stable. >Sure. Now remember we have to assume that people will be attempting to >exploit the admin system as a security hole. We can't trust any state coming >from a HTTP connection. >Look at Mike Smiths juliet stuff. Look at my thoughts on Portia/security >stuff. My only objection to his design is that it is a little too specific. I think that ALL the "back end" modules should appear monolithic and recursively defined. For example, although the password file is organized as a list of records each having fixed entries, it can be modeled as a two level tree. The top level entries are tagged by the name. Within each of those nodes there are entries tagged by , , , , etc. I would do something like [TELL SET user_base..shell = "/bin/sh"] which would get translated to [TELL .user_base. SET shell = "/bin/sh"] and [TELL .user_base INSERT joe AT_END] would work. But [TELL .user_base.joe INSERT expires] [TELL .user_base.joe SET expires [end_of_this_month]] would fail because I cannot insert tags in user records. >Look at the mail archives on this topic. Which archives? I cannot find one for "config". >I'd really like to see people cooperating on this with a well thought out >structure rather than see three sets of people head out into space. Me, too. But doesn't that break the "FreeBSD model" of "implement before you discuss the design?" :-) Richard Wackerbarth From owner-freebsd-config Tue Feb 3 08:56:35 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA22571 for config-outgoing; Tue, 3 Feb 1998 08:56:35 -0800 (PST) (envelope-from owner-config) Received: from inet-user-gw-1.us.oracle.com (inet-user-gw-1.us.oracle.com [192.86.155.82]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA22546 for ; Tue, 3 Feb 1998 08:56:30 -0800 (PST) (envelope-from ACHOWDHU.IN.ORACLE.COM.ofcmail@in.oracle.com) Received: from insun023 (insun023.in.oracle.com [152.69.168.23]) by inet-user-gw-1.us.oracle.com (8.8.5/8.8.5) with SMTP id IAA20255 for ; Tue, 3 Feb 1998 08:54:10 -0800 (PST) Received: by insun023 (SMI-8.6/37.8) id LAA06851; Tue, 3 Feb 1998 11:48:57 -0500 Message-Id: <199802031648.LAA06851@insun023> Date: 03 Feb 98 21:42:30 +0530 From: "Atish" To: config@freebsd.org Subject: Auto-reply: Re: WebAdmin Reply-to: ACHOWDHU.IN.ORACLE.COM.ofcmail@in.oracle.com MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.1.1.3.40) Content-Type: multipart/mixed; boundary="=_ORCL_2324155_0_0" Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk --=_ORCL_2324155_0_0 Content-Transfer-Encoding:quoted-printable Content-Type:text/plain; charset="iso-8859-1" Hi, I am on leave till mid Feb'98. Will try to get back to you as soon as possible. -regards Atish #..........................................................................#= >From : Atish Datta Chowdhury Oracle Software Development Centre India Development Centre 150 Embassy Point Bangalore 560001 Telephone: (088) 2256099 Extn:496/atish e-mail: achowdhu@in.oracle.com #..........................................................................#= --=_ORCL_2324155_0_0 Content-Type:message/rfc822 Date: 03 Feb 98 21:12:11 From:Colman Reilly To:Adrian Chadd Subject:Re: WebAdmin Cc:hackers@FreeBSD.ORG Reply-to:INUNIX2.IN.ORACLE.COM:config@FreeBSD.ORG Received:from inet16.us.oracle.com by insun023 with ESMTP (SMI-8.6/37.8) id KAA06513; Tue, 3 Feb 1998 10:44:10 -0500 Received:from smyrno.sol.net (mail@smyrno.sol.net [206.55.64.117]) by inet16.us.oracle.com (8.8.5/8.8.5) with ESMTP id HAA17698; Tue, 3 Feb 1998 07:51:18 -0800 (PST) Received:from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by smyrno.sol.net (8.8.8/8.8.8/SNNS-1.02) with ESMTP id JAA20506; Tue, 3 Feb 1998 09:50:26 -0600 (CST) Received:from localhost (daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA12614; Tue, 3 Feb 1998 07:50:25 -0800 (PST) (envelope-from owner-freebsd-hackers) Received:by hub.freebsd.org (bulk_mailer v1.6); Tue, 3 Feb 1998 07:46:58 -0800 Received:(from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA12169 for hackers-outgoing; Tue, 3 Feb 1998 07:46:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received:from relay.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA12133 for ; Tue, 3 Feb 1998 07:46:34 -0800 (PST) (envelope-from careilly@monoid.cs.tcd.ie) Received:from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by relay.cs.tcd.ie (8.8.7/8.8.7) with ESMTP id PAA10889; Tue, 3 Feb 1998 15:46:18 GMT Received:from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id PAA16355; Tue, 3 Feb 1998 15:42:13 GMT Message-Id:<199802031542.PAA16355@monoid.cs.tcd.ie> X-Address:Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone:+353-(0)1-6081321 In-reply-to:Message from Adrian Chadd dated today at 22:57. Sender:owner-freebsd-hackers@FreeBSD.ORG X-Loop:FreeBSD.ORG X-To-Unsubscribe:mail to majordomo@FreeBSD.org "unsubscribe hackers" MIME-Version: 1.0 Content-ID:<16350.886520530.1@monoid.cs.tcd.ie> Content-Type:text/plain; charset=us-ascii Content-Transfer-Encoding:7bit [Please redirect this to freebsd-config] On Mon, 2 Feb 1998, Adam Turoff wrote: Depends. ? I've written a couple of web-based SQL databases, and I have been able to sucessfully encode enough state into the webpages themselves to make the databases useable and stable. Sure. Now remember we have to assume that people will be attempting to exploit the admin system as a security hole. We can't trust any state coming from a HTTP connection. > Then there's also the question of security. Running a bunch of scripts > that create users and such against Apache is not secure. Picking a port > other than 80 or 8080 and possibly using SSL on it is marginally better. > Possibly. But then SSL on port 80 would be more than enough. Enough for what? How many bits of SSL? [Lot's of fine talk deleted] Look at Mike Smiths juliet stuff. Look at my thoughts on Portia/security stuff. Look at the mail archives on this topic. I'd really like to see people cooperating on this with a well thought out structure rather than see three sets of people head out into space. Juliet is at: http://www.smith.net.au/~mike/freebsd.html My stuff is at: http://www.cs.tcd.ie/~careilly/Portia/ Colman --=_ORCL_2324155_0_0-- From owner-freebsd-config Tue Feb 3 09:39:37 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA01864 for config-outgoing; Tue, 3 Feb 1998 09:39:37 -0800 (PST) (envelope-from owner-config) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA01843 for ; Tue, 3 Feb 1998 09:39:31 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id JAA28105; Tue, 3 Feb 1998 09:42:29 -0800 Date: Tue, 3 Feb 1998 09:42:29 -0800 (PST) From: Alex Belits Reply-To: Alex Belits To: Terry Lambert cc: mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199802030210.TAA06735@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 From owner-freebsd-config Tue Feb 3 14:25:19 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18822 for config-outgoing; Tue, 3 Feb 1998 14:25:19 -0800 (PST) (envelope-from owner-config) Received: from relay.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18811 for ; Tue, 3 Feb 1998 14:25:08 -0800 (PST) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by relay.cs.tcd.ie (8.8.7/8.8.7) with ESMTP id WAA20444; Tue, 3 Feb 1998 22:24:45 GMT Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id WAA16835; Tue, 3 Feb 1998 22:20:52 GMT Message-Id: <199802032220.WAA16835@monoid.cs.tcd.ie> To: Richard Wackerbarth cc: config@FreeBSD.ORG Subject: Re: WebAdmin X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Message from Richard Wackerbarth dated today at 10:45. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16830.886544451.1@monoid.cs.tcd.ie> Content-Description: text Date: Tue, 03 Feb 1998 22:20:52 +0000 From: Colman Reilly Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 9:42 AM -0600 2/3/98, Colman Reilly wrote: > the databases useable and stable. >Sure. Now remember we have to assume that people will be attempting to >exploit the admin system as a security hole. We can't trust any state com ing >from a HTTP connection. >Look at Mike Smiths juliet stuff. Look at my thoughts on Portia/security >stuff. My only objection to his design is that it is a little too specific. I think that ALL the "back end" modules should appear monolithic and recursively defined. For example, although the password file is organized as a list of records each having fixed entries, it can be modeled as a two level tree. The top level entries are tagged by the name. Within each of those nodes there are entries tagged by , , , , etc. That's an objection to his implementation, not his design. It depends on the maturity of the sub-system really. For password I agree, but for some faster moving targets the more "black-box" approach might be better. In an ideal world you're right. >Look at the mail archives on this topic. Which archives? I cannot find one for "config". Most of the stuff has actually been discussed on hackers as far as I can see. :-) >I'd really like to see people cooperating on this with a well thought out >structure rather than see three sets of people head out into space. Me, too. But doesn't that break the "FreeBSD model" of "implement before you discuss the design?" :-) Oh. I'm sorry. I'm doing research in formal methods and mathematical modeling of software. I get carried away with this design business occasionally. Colman From owner-freebsd-config Tue Feb 3 14:25:51 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18857 for config-outgoing; Tue, 3 Feb 1998 14:25:51 -0800 (PST) (envelope-from owner-config) Received: from relay.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18845 for ; Tue, 3 Feb 1998 14:25:40 -0800 (PST) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by relay.cs.tcd.ie (8.8.7/8.8.7) with ESMTP id WAA20459 for ; Tue, 3 Feb 1998 22:25:37 GMT Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id WAA16848 for ; Tue, 3 Feb 1998 22:21:45 GMT Message-Id: <199802032221.WAA16848@monoid.cs.tcd.ie> To: config@freebsd.org Subject: Testing. X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16843.886544504.1@monoid.cs.tcd.ie> Date: Tue, 03 Feb 1998 22:21:44 +0000 From: Colman Reilly Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Colman, convinced that e-mail to this list is being feasted upon by the mail daemon. From owner-freebsd-config Tue Feb 3 14:52:05 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21873 for config-outgoing; Tue, 3 Feb 1998 14:52:05 -0800 (PST) (envelope-from owner-config) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21831 for ; Tue, 3 Feb 1998 14:51:46 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id QAA27977; Tue, 3 Feb 1998 16:51:18 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199802032220.WAA16835@monoid.cs.tcd.ie> References: Message from Richard Wackerbarth dated today at 10:45. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Feb 1998 16:49:55 -0600 To: Colman Reilly From: Richard Wackerbarth Subject: Re: WebAdmin Cc: config@FreeBSD.ORG Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 4:20 PM -0600 2/3/98, Colman Reilly wrote: > At 9:42 AM -0600 2/3/98, Colman Reilly wrote: > > the databases useable and stable. > >Sure. Now remember we have to assume that people will be attempting to > >exploit the admin system as a security hole. We can't trust any >state com > ing > >from a HTTP connection. > > >Look at Mike Smiths juliet stuff. Look at my thoughts on Portia/security > >stuff. > > My only objection to his design is that it is a little too specific. > I think that ALL the "back end" modules should appear monolithic and > recursively defined. For example, although the password file is organized > as a list of records each having fixed entries, it can be modeled as > a two level tree. The top level entries are tagged by the name. > Within each of those nodes there are entries tagged by , , > , , etc. >That's an objection to his implementation, not his design. It depends on >the maturity of the sub-system really. For password I agree, but for some >faster moving targets the more "black-box" approach might be better. In an >ideal world you're right. However, I think that failure to use the monolithic structural model creates a big problem in that all the intermediate nodes now have to be able to handle information which is case dependent. If we restrict ALL the storage to the same model, then we can greatly leverage things. For example, I COULD store all of the configuration parameters in some DBMS which knows absolutely nothing about the real data structures. With the same primitives, I can FETCH, STORE, LIST, etc. these items. I could even handle things like the introduction of some new data type by encapsulating that data type in a string and sending it along. Only the "real" target needs to know how to format it for external consumption. This data storage model is simply a structured method of addressing data values. I believe that all the structures which we will encounter can be mapped onto it. And, at least for most of them, the mapping is trivial. > But doesn't that break the "FreeBSD model" of "implement before you > discuss the design?" :-) >Oh. I'm sorry. I'm doing research in formal methods and mathematical modeling >of software. I get carried away with this design business occasionally. I happen to belong to the "design top down" school. I've seen too many cases where someone jumps in and implements something without a global design and then cannot change it because it is "legacy". Richard Wackerbarth From owner-freebsd-config Tue Feb 3 14:55:49 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22262 for config-outgoing; Tue, 3 Feb 1998 14:55:49 -0800 (PST) (envelope-from owner-config) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22252 for ; Tue, 3 Feb 1998 14:55:47 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id PAA24992; Tue, 3 Feb 1998 15:55:33 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd024951; Tue Feb 3 15:55:30 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id PAA01679; Tue, 3 Feb 1998 15:55:07 -0700 (MST) From: Terry Lambert Message-Id: <199802032255.PAA01679@usr01.primenet.com> Subject: Re: WebAdmin To: abelits@phobos.illtel.denver.co.us Date: Tue, 3 Feb 1998 22:55:07 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com In-Reply-To: from "Alex Belits" at Feb 3, 98 09:42:29 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Looks like AIX. More like NT' or NetWare, actually. AIX has a lot of seperate, incompatibly formatted files. Both AIX and NeXTStep's niload/nidump also maintain two copies of the data, which must be soft-synchronized (ie: read as "dumb"). > > > 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. 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. The good thing about LDAP is that it is implementation neutral, like this, unlike some private protocol that you won't see running on a Sun system. There are already LDIF's (IETF drafts on the standards track, themselves) for POSIX MIB's... but without transationing in the protocol, they must be revamped in terms of container objects. > > 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. 1) Schemas are transportable; database files are not. Using the protocol abstracts the schema from the implementation. 2) Everyone will eventually support LDAP. Sun does. Netscape does. Novell does. 3) There is already a reference implementation. What you are proposing does not have one. 4) It is already a standard. What you are proposing is not. > > > 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. 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... > > 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"). [ ...more "HTML as a replacement for SQL" ... ] When the only tool you have is an HTTP server, everything looks like a URL. 8-). > > 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. > > 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. > 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. > 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. > 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? > 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? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-config Tue Feb 3 15:17:54 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25126 for config-outgoing; Tue, 3 Feb 1998 15:17:54 -0800 (PST) (envelope-from owner-config) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25107; Tue, 3 Feb 1998 15:17:47 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id QAA01994; Tue, 3 Feb 1998 16:17:35 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd001930; Tue Feb 3 16:17:30 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA02805; Tue, 3 Feb 1998 16:17:18 -0700 (MST) From: Terry Lambert Message-Id: <199802032317.QAA02805@usr01.primenet.com> Subject: Re: FreeBSD updated Installation / Adminsitration Kit To: chris@bb.cc.wa.us (Chris Coleman) Date: Tue, 3 Feb 1998 23:17:18 +0000 (GMT) Cc: karpen@ocean.campus.luth.se, AdamT@smginc.com, mike@smith.net.au, kpielorz@tdx.co.uk, hackers@FreeBSD.ORG, config@FreeBSD.ORG In-Reply-To: from "Chris Coleman" at Feb 3, 98 07:50:35 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I liked everything up until the reboot. :-( Win95 reboots so many times, > that it takes hours of time trying to install. There are three circumstances where Windows 95 will reboot: 1) After the initial install, to be running off the HD This is acceptable; FreeBSD does this now for the network setup. 2) During the initial install, if hardware autodetection "takes too long", the *user* resets the machine so the probe that hung will not be repeated. This is a good thing. It means Windows95 can detect hardware FreeBSD can't. It's a feature. The only time this becomes an annoyance instead of a feature is if you bought cruddy hardware. Then it's pilot error. 3) If during configuration, it asks if you want to reboot, and instead of waiting until you have installed everything, you *foolishly* say "yes". This is pilot error. > before leaving). It would stop only on critical errors, and log the rest. > Otherwise it would be real easy to install a basic system. > > > So... Comments on this, anyone? :-) What about probes that hang the hardware because you wre silly enough to engage in pilot error (#2, above: buying cruddy hardware)? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-config Tue Feb 3 15:31:00 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27098 for config-outgoing; Tue, 3 Feb 1998 15:31:00 -0800 (PST) (envelope-from owner-config) Received: from wcc.wcc.net (wcc.wcc.net [208.6.232.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27093; Tue, 3 Feb 1998 15:30:56 -0800 (PST) (envelope-from piquan@wcc.wcc.net) Received: from detlev.UUCP (ppp116.wcc.net [208.6.232.116]) by wcc.wcc.net (8.8.8/8.8.8) with ESMTP id RAA20875; Tue, 3 Feb 1998 17:24:59 -0600 (CST) Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.7) id RAA01448; Tue, 3 Feb 1998 17:28:34 -0600 (CST) (envelope-from joelh) Date: Tue, 3 Feb 1998 17:28:34 -0600 (CST) Message-Id: <199802032328.RAA01448@detlev.UUCP> To: chris@bb.cc.wa.us CC: karpen@ocean.campus.luth.se, AdamT@smginc.com, mike@smith.net.au, kpielorz@tdx.co.uk, hackers@FreeBSD.ORG, config@FreeBSD.ORG In-reply-to: (message from Chris Coleman on Tue, 3 Feb 1998 07:50:35 -0800 (PST)) Subject: Re: FreeBSD updated Installation / Adminsitration Kit From: Joel Ray Holveck Reply-to: joelh@gnu.org References: Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I liked everything up until the reboot. :-( Win95 reboots so many > times, that it takes hours of time trying to install. I really like > the idea of having an "automated" feature. (wish win95 had one) > where you could enter in all the information in a few basic screens > and then just leave it. They do. It's not very well designed or documented, though... it's designed for OEM's installing Win95 at the factory. -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped From owner-freebsd-config Tue Feb 3 15:57:38 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA00867 for config-outgoing; Tue, 3 Feb 1998 15:57:38 -0800 (PST) (envelope-from owner-config) Received: from wcc.wcc.net (wcc.wcc.net [208.6.232.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA00860; Tue, 3 Feb 1998 15:57:36 -0800 (PST) (envelope-from piquan@wcc.wcc.net) Received: from detlev.UUCP (ppp111.wcc.net [208.6.232.111]) by wcc.wcc.net (8.8.8/8.8.8) with ESMTP id RAA23642; Tue, 3 Feb 1998 17:53:05 -0600 (CST) Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.7) id RAA01559; Tue, 3 Feb 1998 17:56:40 -0600 (CST) (envelope-from joelh) Date: Tue, 3 Feb 1998 17:56:40 -0600 (CST) Message-Id: <199802032356.RAA01559@detlev.UUCP> To: tlambert@primenet.com CC: chris@bb.cc.wa.us, karpen@ocean.campus.luth.se, AdamT@smginc.com, mike@smith.net.au, kpielorz@tdx.co.uk, hackers@FreeBSD.ORG, config@FreeBSD.ORG In-reply-to: <199802032317.QAA02805@usr01.primenet.com> (message from Terry Lambert on Tue, 3 Feb 1998 23:17:18 +0000 (GMT)) Subject: Re: FreeBSD updated Installation / Adminsitration Kit From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199802032317.QAA02805@usr01.primenet.com> Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I liked everything up until the reboot. :-( Win95 reboots so many >> times, that it takes hours of time trying to install. > There are three circumstances where Windows 95 will reboot: > 3) If during configuration, it asks if you want to reboot, and > instead of waiting until you have installed everything, you > *foolishly* say "yes". > This is pilot error. I personally believe that it is design error, since you give the user no information to tell if everything has been detected, so the user doesn't know when to reboot. It's also a documentation error... the fact that 'no' is quicker is not documented. -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped From owner-freebsd-config Tue Feb 3 17:38:34 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15909 for config-outgoing; Tue, 3 Feb 1998 17:38:34 -0800 (PST) (envelope-from owner-config) Received: from relay.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15840 for ; Tue, 3 Feb 1998 17:38:26 -0800 (PST) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by relay.cs.tcd.ie (8.8.7/8.8.7) with ESMTP id BAA22361; Wed, 4 Feb 1998 01:38:12 GMT Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id BAA17337; Wed, 4 Feb 1998 01:34:19 GMT Message-Id: <199802040134.BAA17337@monoid.cs.tcd.ie> To: Richard Wackerbarth cc: config@FreeBSD.ORG, mike@smith.net.au Subject: Re: WebAdmin X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Message from Richard Wackerbarth dated today at 16:49. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17332.886556058.1@monoid.cs.tcd.ie> Content-Description: text Date: Wed, 04 Feb 1998 01:34:18 +0000 From: Colman Reilly Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth said: At 4:20 PM -0600 2/3/98, Colman Reilly wrote: >Richard Wackerbarth said: > At 9:42 AM -0600 2/3/98, Colman Reilly wrote: > >Look at Mike Smiths juliet stuff. Look at my thoughts on Portia/sec urity > >stuff. > > My only objection to his design is that it is a little too specific. > I think that ALL the "back end" modules should appear monolithic and > recursively defined. For example, although the password file is orga nized > as a list of records each having fixed entries, it can be modeled as > a two level tree. The top level entries are tagged by the nam e. > Within each of those nodes there are entries tagged by , , > , , etc. >That's an objection to his implementation, not his design. It depends on >the maturity of the sub-system really. For password I agree, but for some >faster moving targets the more "black-box" approach might be better. In a n >ideal world you're right. However, I think that failure to use the monolithic structural model creat es a big problem in that all the intermediate nodes now have to be able to ha ndle information which is case dependent. If we restrict ALL the storage to the same model, then we can greatly leverage things. For example, I COULD store all of the configuration parameters in some DBMS which knows absolutely nothing a bout the real data structures. With the same primitives, I can FETCH, STORE, LIST, etc. these items. I could even handle things like the introduction of some new data type by encapsulating that data type in a string and sending it along. Only the "real" target needs to know how to format it for external consumption. >From an abstract point of view we can actually look at all the operations in Juliet as having the form of triples: (NODE,OPERATION,ARGS). Intermediate layers only need to know how to deal with these triples. This doesn't seem too onerous. Is storing this information in a DBMS a useful thing to do? I'm not convinced. This data storage model is simply a structured method of addressing data values. I believe that all the structures which we will encounter can be mapped onto it. And, at least for most of them, the mapping is trivial. But quite arbitary. We end up with SNMP, where I reset a hub by setting .hud.restart to 1. That's a pain to type and remember, and not very clean semantically. Colman From owner-freebsd-config Tue Feb 3 19:06:30 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA27546 for config-outgoing; Tue, 3 Feb 1998 19:06:30 -0800 (PST) (envelope-from owner-config) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA27537 for ; Tue, 3 Feb 1998 19:06:23 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id VAA16399; Tue, 3 Feb 1998 21:03:01 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199802040134.BAA17337@monoid.cs.tcd.ie> References: Message from Richard Wackerbarth dated today at 16:49. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Feb 1998 21:02:03 -0600 To: Colman Reilly From: Richard Wackerbarth Subject: Re: WebAdmin Cc: config@FreeBSD.ORG, mike@smith.net.au Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 7:34 PM -0600 2/3/98, Colman Reilly wrote: >From an abstract point of view we can actually look at all the operations in >Juliet as having the form of triples: (NODE,OPERATION,ARGS). Intermediate >layers only need to know how to deal with these triples. This doesn't seem >too onerous. >Is storing this information in a DBMS a useful thing to do? I'm not >convinced. There are two types of activity to be considered. First, and I think primarily, we need to be able to manipulate configuration parameters. Consider the case of "add user". This requires that we add an entry to the master password file and another entry to the "/home" directory. We also need to "set" the value of the "/home//.cshrc" file to its default value, etc. When we "commit" the addition, a command will be executed (passwd ?) if it is on a running system. However, that should not be done for each new entry. As much as possible, this logic should be imbedded in a table driven which belongs to the core of the admin tool. It is quite possible that this is NOT the target machine itself. In general, we need to be able to build "transactions" which are composed of multiple operations which are then taken on an "all or none" basis. The easiest way to do this may be to build a "shadow" of the target system and manipulate that image rather than forcing the target to support the ability to back out partial transactions, etc. In such a case, the "shadow" is really just a DBMS. >But quite arbitary. We end up with SNMP, where I reset a hub by setting >.hud.restart to 1. That's a pain to type and remember, and not very clean >semantically. I agree that SNMP is not a "friendly" communications tool for humans. However, it does have the virtue of "simplicity of implementation" at the machine level. I see no reason why it could not be used for the "back-end" language. However, just as HTML is not the "front-end" language, link adapters would perform the translations. Don't misunderstand. I am not advocating that we use any particular mechanism as the transport layer(s). Rather, I think we need to develop a modular structure that allows us to "mix and match" pieces. The front-end and back-end languages are the connecting pieces. The front-end needs to be sufficiently friendly that it can be used as a command line language. The back-end needs to have simple-to-implement functionality. Richard Wackerbarth From owner-freebsd-config Tue Feb 3 20:22:19 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA08937 for config-outgoing; Tue, 3 Feb 1998 20:22:19 -0800 (PST) (envelope-from owner-config) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA08919 for ; Tue, 3 Feb 1998 20:22:13 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id UAA31134; Tue, 3 Feb 1998 20:26:30 -0800 Date: Tue, 3 Feb 1998 20:26:29 -0800 (PST) From: Alex Belits To: Terry Lambert cc: mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199802032255.PAA01679@usr01.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 From owner-freebsd-config Tue Feb 3 22:19:08 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA24249 for config-outgoing; Tue, 3 Feb 1998 22:19:08 -0800 (PST) (envelope-from owner-config) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA24234; Tue, 3 Feb 1998 22:19:03 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id XAA21440; Tue, 3 Feb 1998 23:19:00 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd021390; Tue Feb 3 23:18:52 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id XAA02370; Tue, 3 Feb 1998 23:18:44 -0700 (MST) From: Terry Lambert Message-Id: <199802040618.XAA02370@usr08.primenet.com> Subject: Re: FreeBSD updated Installation / Adminsitration Kit To: joelh@gnu.org Date: Wed, 4 Feb 1998 06:18:43 +0000 (GMT) Cc: tlambert@primenet.com, chris@bb.cc.wa.us, karpen@ocean.campus.luth.se, AdamT@smginc.com, mike@smith.net.au, kpielorz@tdx.co.uk, hackers@FreeBSD.ORG, config@FreeBSD.ORG In-Reply-To: <199802032356.RAA01559@detlev.UUCP> from "Joel Ray Holveck" at Feb 3, 98 05:56:40 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 3) If during configuration, it asks if you want to reboot, and > > instead of waiting until you have installed everything, you > > *foolishly* say "yes". > > This is pilot error. > > I personally believe that it is design error, since you give the user > no information to tell if everything has been detected, so the user > doesn't know when to reboot. It's also a documentation error... the > fact that 'no' is quicker is not documented. We've travelled this ground before. Make something easier to install than Windows 95, and make it run all their old software, and people will use it. Right now, you haven't even got the first, let alone the second. It may be poor design, but it's better than its competition. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-config Tue Feb 3 23:04:46 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA00756 for config-outgoing; Tue, 3 Feb 1998 23:04:46 -0800 (PST) (envelope-from owner-config) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA00749 for ; Tue, 3 Feb 1998 23:04:43 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id AAA10159; Wed, 4 Feb 1998 00:04:34 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd010099; Wed Feb 4 00:04:24 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id AAA04193; Wed, 4 Feb 1998 00:04:16 -0700 (MST) From: Terry Lambert Message-Id: <199802040704.AAA04193@usr08.primenet.com> Subject: Re: WebAdmin To: abelits@phobos.illtel.denver.co.us (Alex Belits) Date: Wed, 4 Feb 1998 07:04:16 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com In-Reply-To: from "Alex Belits" at Feb 3, 98 08:26:29 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 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. From owner-freebsd-config Tue Feb 3 23:07:12 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA01097 for config-outgoing; Tue, 3 Feb 1998 23:07:12 -0800 (PST) (envelope-from owner-config) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA01077; Tue, 3 Feb 1998 23:07:06 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id AAA10486; Wed, 4 Feb 1998 00:07:04 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd010436; Wed Feb 4 00:06:56 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id AAA04284; Wed, 4 Feb 1998 00:06:47 -0700 (MST) From: Terry Lambert Message-Id: <199802040706.AAA04284@usr08.primenet.com> Subject: Re: FreeBSD updated Installation / Adminsitration Kit To: joelh@gnu.org Date: Wed, 4 Feb 1998 07:06:47 +0000 (GMT) Cc: chris@bb.cc.wa.us, karpen@ocean.campus.luth.se, AdamT@smginc.com, mike@smith.net.au, kpielorz@tdx.co.uk, hackers@FreeBSD.ORG, config@FreeBSD.ORG In-Reply-To: <199802032328.RAA01448@detlev.UUCP> from "Joel Ray Holveck" at Feb 3, 98 05:28:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I liked everything up until the reboot. :-( Win95 reboots so many > > times, that it takes hours of time trying to install. I really like > > the idea of having an "automated" feature. (wish win95 had one) > > where you could enter in all the information in a few basic screens > > and then just leave it. > > They do. It's not very well designed or documented, though... it's > designed for OEM's installing Win95 at the factory. To a apriori known hardware configuration from a small set of possible hardware configuration, of course. A general install must be must more flexible. Consider that Microsoft, even after support overhead, is making money on sales of Windows 95 upgrades. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-config Wed Feb 4 03:29:47 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA02566 for config-outgoing; Wed, 4 Feb 1998 03:29:47 -0800 (PST) (envelope-from owner-config) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA02561; Wed, 4 Feb 1998 03:29:44 -0800 (PST) (envelope-from dag-erli@ifi.uio.no) Received: from yggdrasil.ifi.uio.no (2602@yggdrasil.ifi.uio.no [129.240.64.182]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id MAA03364; Wed, 4 Feb 1998 12:26:35 +0100 (MET) Received: (from dag-erli@localhost) by yggdrasil.ifi.uio.no ; Wed, 4 Feb 1998 12:26:34 +0100 (MET) To: Mikael Karpberg Cc: Ruslan@Shevchenko.kiev.ua (Ruslan Shevchenko), hackers@FreeBSD.ORG, config@FreeBSD.ORG Subject: Re: Multi-faced admin References: <199802022005.VAA18349@ocean.campus.luth.se> Organization: Gutteklubben Terrasse X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: 04 Feb 1998 12:26:34 +0100 In-Reply-To: Mikael Karpberg's message of "Mon, 2 Feb 1998 21:05:32 +0100 (CET)" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg writes: > Seriously, though, I think Alex has his terms all screwed up. Probably > silly enough to use a brower to send mails, and mixes up pages and mails. > I sent a suggestion to hackers@FreeBSD.ORG and config@FreeBSD.ORG, and > that's all I did. Taken from Alex' article: X-Mailer: Microsoft Mail V3.0 :-O -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * RFC1123: "Be liberal in what you accept, and conservative in what you send" From owner-freebsd-config Wed Feb 4 04:16:02 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA09986 for config-outgoing; Wed, 4 Feb 1998 04:16:02 -0800 (PST) (envelope-from owner-config) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA09918 for ; Wed, 4 Feb 1998 04:15:55 -0800 (PST) (envelope-from abelits@phobos.illtel.denver.co.us) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.8/8.6.9) with SMTP id EAA00297; Wed, 4 Feb 1998 04:20:54 -0800 Date: Wed, 4 Feb 1998 04:20:54 -0800 (PST) From: Alex Belits To: Terry Lambert cc: mike@smith.net.au, rivers@dignus.com, capriotti0@hotmail.com, capriotti@geocities.com, config@FreeBSD.ORG, joe.shevland@horizonti.com Subject: Re: WebAdmin In-Reply-To: <199802040704.AAA04193@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 From owner-freebsd-config Wed Feb 4 14:23:23 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25575 for config-outgoing; Wed, 4 Feb 1998 14:23:23 -0800 (PST) (envelope-from owner-config) Received: from relay.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25523 for ; Wed, 4 Feb 1998 14:23:16 -0800 (PST) (envelope-from careilly@monoid.cs.tcd.ie) Received: from monoid.cs.tcd.ie (monoid.cs.tcd.ie [134.226.38.99]) by relay.cs.tcd.ie (8.8.7/8.8.7) with ESMTP id WAA04926; Wed, 4 Feb 1998 22:22:49 GMT Received: from monoid.cs.tcd.ie (localhost.my.domain [127.0.0.1]) by monoid.cs.tcd.ie (8.8.5/8.8.5) with ESMTP id WAA18923; Wed, 4 Feb 1998 22:18:52 GMT Message-Id: <199802042218.WAA18923@monoid.cs.tcd.ie> To: Richard Wackerbarth cc: config@FreeBSD.ORG, mike@smith.net.au Subject: Re: WebAdmin X-Address: Department of Computer Science, Trinity College, Dublin 2, Ireland. X-Phone: +353-(0)1-6081321 In-reply-to: Message from Richard Wackerbarth dated Tuesday at 21:02. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18918.886630731.1@monoid.cs.tcd.ie> Content-Description: text Date: Wed, 04 Feb 1998 22:18:52 +0000 From: Colman Reilly Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Is anyone except me, Richard and Mike getting this?] At 7:34 PM -0600 2/3/98, Colman Reilly wrote: >From an abstract point of view we can actually look at all the operations in >Juliet as having the form of triples: (NODE,OPERATION,ARGS). Intermediate >layers only need to know how to deal with these triples. This doesn't seem >too onerous. >Is storing this information in a DBMS a useful thing to do? I'm not >convinced. [...] In general, we need to be able to build "transactions" which are composed of multiple operations which are then taken on an "all or none" basis. The easiest way to do this may be to build a "shadow" of the target system and manipulate that image rather than forcing the target to support the ability to back out partial transactions, etc. In such a case, the "shadow" is really just a DBMS. When all you have is a hammer ... It's not just a DBMS. I really don't think the model fits the problem. I can't construct a reasonable argument for this opinion right now, and I'd be happy to be convinced otherwise. I'll construct a reasoned argument later. Must try and write some of these responses earlier in the day occasionally. :-) Actually, the problem here is probably a requirements mismatch. I don't believe that the configuration/system management task can be simply reduced to reading/writing parameters. The objects being managed are generally more complex than that, and we need to keep as much of the target specific stuff right at the back end of the system. >But quite arbitary. We end up with SNMP, where I reset a hub by setting >.hud.restart to 1. That's a pain to type and remember, and not very clean >semantically. I agree that SNMP is not a "friendly" communications tool for humans. However, it does have the virtue of "simplicity of implementation" at the machine level. I see no reason why it could not be used for the "back-end" language. However, just as HTML is not the "front-end" language, link adapters would perform the translations. I'm worried that we'll end up translating things into easy to implement too early, with the result that the semantic richness of the system is lost before any of the intermediate layers have a chance to do anything with it. >From the point of access control is is nice to have available the operations like append, restart, create which express the meaning of the transaction in order to make it easier to write (say) ACLs. Would you rather rather write deny "write" on ".hub.controls.reset" to richard or deny "hub reset" to richard I think the latter might make life a litle easier, and that's fairly far into the backend. When you start thinking about expressing rules for a consistency checker it gets even worse. Don't misunderstand. I am not advocating that we use any particular mechani sm as the transport layer(s). Rather, I think we need to develop a modular structure that allows us to "mix and match" pieces. The front-end and back- end languages are the connecting pieces. The front-end needs to be sufficiently friendly that it can be used as a command line language. The back-end needs to have simple-to-implement functionality. Well, I'm very much in favour of the mix-and-match philosophy. Colman From owner-freebsd-config Wed Feb 4 18:20:25 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA08928 for config-outgoing; Wed, 4 Feb 1998 18:20:25 -0800 (PST) (envelope-from owner-config) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA08808 for ; Wed, 4 Feb 1998 18:19:46 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id UAA00512; Wed, 4 Feb 1998 20:19:22 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199802042218.WAA18923@monoid.cs.tcd.ie> References: Message from Richard Wackerbarth dated Tuesday at 21:02. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 4 Feb 1998 20:19:17 -0600 To: Colman Reilly From: Richard Wackerbarth Subject: Re: WebAdmin Cc: config@FreeBSD.ORG, mike@smith.net.au Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 4:18 PM -0600 2/4/98, Colman Reilly wrote: > I agree that SNMP is not a "friendly" communications tool for humans. > However, it does have the virtue of "simplicity of implementation" > at the machine level. I see no reason why it could not be used for the > "back-end" language. However, just as HTML is not the "front-end" >language, > link adapters would perform the translations. >I'm worried that we'll end up translating things into easy to implement too >early, with the result that the semantic richness of the system is lost >before any of the intermediate layers have a chance to do anything with it. > >>From the point of access control is is nice to have available the operations >like append, restart, create which express the meaning of the transaction in >order to make it easier to write (say) ACLs. Would you rather rather write > deny "write" on ".hub.controls.reset" to richard >or > deny "hub reset" to richard Perhaps we are not talking about the same thing here. My model has a number of communicating entities. They are connected by some kind of link. Level 1. The user Connected by screen, keyboard, mouse, etc. Level 2. User interface module (Perhaps a web browser) Connected by "front-end directives" tunneling through http. Level 3. The configuration server Connected by "back-end directives" tunneling through perhaps a SSH link. Level 4. Implementation "glue" on the target machine Connected by system calls Level 5. The actual files that remember configuration parameters Note that this can involve three different systems. The user's workstation, an administration server, and the actual target machine being administered. Now, things are really a bit fuzzy in the description. If you were to use a http front end, a part of the logic would really be in CGI script that resides with the server. However, you might bypass that and simply use a direct set of commands. (Similar to shell scripting). However, the "front-end language" is that language which is common to both of these interface units. Similarly, you might replace the back end with a SNMP system. Again, there would be an adapter that translates the "back-end" language into the appropriate protocol. In the case where the server IS also the target, we would use something like Juliet to directly implement the back-end actions. Note that all validity checking, etc. of the user is handler in the server portion. By the time that we get to the "back-end" language, we are simply sending the elements of a transaction. If the back end does not know how to journal, buffer, or otherwise treat transactions, it would perform the steps as they arrive, just as we might do with a canned "daily" shell script. >Well, I'm very much in favour of the mix-and-match philosophy. I propose that we accomplish this by defining two interfaces to the administration server. The "front" language should be something that is "user friendly". At the same time, it should be something that we can imbed in an http form. (Click the button ==> execute a few "front" commands) The "back" language need not be "user friendly". Rather, it needs to be easy to implement (for minimum configurations such as sysinstall) and mappable onto common protocols (eg. SNMP) Richard Wackerbarth From owner-freebsd-config Wed Feb 4 20:59:25 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28435 for config-outgoing; Wed, 4 Feb 1998 20:59:25 -0800 (PST) (envelope-from owner-config) Received: from wcc.wcc.net (wcc.wcc.net [208.6.232.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA28391; Wed, 4 Feb 1998 20:58:58 -0800 (PST) (envelope-from piquan@wcc.wcc.net) Received: from detlev.UUCP (newip25.wcc.net [206.104.247.25]) by wcc.wcc.net (8.8.8/8.8.8) with ESMTP id WAA08388; Wed, 4 Feb 1998 22:52:59 -0600 (CST) Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.7) id WAA03651; Wed, 4 Feb 1998 22:56:33 -0600 (CST) (envelope-from joelh) Date: Wed, 4 Feb 1998 22:56:33 -0600 (CST) Message-Id: <199802050456.WAA03651@detlev.UUCP> To: tlambert@primenet.com CC: chris@bb.cc.wa.us, karpen@ocean.campus.luth.se, AdamT@smginc.com, mike@smith.net.au, kpielorz@tdx.co.uk, hackers@FreeBSD.ORG, config@FreeBSD.ORG In-reply-to: <199802040706.AAA04284@usr08.primenet.com> (message from Terry Lambert on Wed, 4 Feb 1998 07:06:47 +0000 (GMT)) Subject: Re: FreeBSD updated Installation / Adminsitration Kit From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199802040706.AAA04284@usr08.primenet.com> Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>> I liked everything up until the reboot. :-( Win95 reboots so many >>> times, that it takes hours of time trying to install. I really like >>> the idea of having an "automated" feature. (wish win95 had one) >>> where you could enter in all the information in a few basic screens >>> and then just leave it. >> They do. It's not very well designed or documented, though... it's >> designed for OEM's installing Win95 at the factory. > To a apriori known hardware configuration from a small set of possible > hardware configuration, of course. A general install must be must > more flexible. No, that's the intended use, but since we (the retailer I work for) custom-build all of our systems, we made sure that it would work as a general mechanism as well. > Consider that Microsoft, even after support overhead, is making money > on sales of Windows 95 upgrades. Of course. -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped From owner-freebsd-config Thu Feb 5 12:44:58 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA23192 for config-outgoing; Thu, 5 Feb 1998 12:44:58 -0800 (PST) (envelope-from owner-config) Received: from cam.grad.kiev.ua (grad-UTC-28k8.ukrtel.net [195.5.25.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA23129; Thu, 5 Feb 1998 12:44:34 -0800 (PST) (envelope-from Ruslan@Shevchenko.kiev.ua) Received: from Shevchenko.kiev.ua (localhost [127.0.0.1]) by cam.grad.kiev.ua (8.8.8/8.8.5) with ESMTP id AAA21766; Thu, 5 Feb 1998 00:41:58 +0200 (EET) Message-ID: <34D8EEB0.2AF4C769@Shevchenko.kiev.ua> Date: Thu, 05 Feb 1998 00:41:54 +0200 From: Ruslan Shevchenko X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: config@freebsd.org CC: hackers@freebsd.org Subject: TCL API published. Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just publish TCL API (only realized functions) for my Admin System. (http://cam.grad.kiev.ua/~rssh/admin/admin.html) Question: May be create API-ized versions of tclsh and wish ? Will be this tools usefull for anybody ? Anybody know, is dynamic library loading from Tcl in run-time work in FreeBSD ? if work, how to do it, without generation of Tcl Interpeter for each extension. ? -- @= //RSSH mailto://Ruslan@Shevchenko.Kiev.UA From owner-freebsd-config Thu Feb 5 15:03:20 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18763 for config-outgoing; Thu, 5 Feb 1998 15:03:20 -0800 (PST) (envelope-from owner-config) Received: from dingo.cdrom.com (lapdog.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA18758 for ; Thu, 5 Feb 1998 15:03:18 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id IAA00982; Fri, 6 Feb 1998 08:02:01 +1030 (CST) Message-Id: <199802052132.IAA00982@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: config@FreeBSD.ORG cc: Adrian Chadd Subject: Re: WebAdmin In-reply-to: Your message of "Tue, 03 Feb 1998 15:42:11 -0000." <199802031542.PAA16355@monoid.cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Feb 1998 08:02:00 +1030 From: Mike Smith Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > [Please redirect this to freebsd-config] Done. > Juliet is at: http://www.smith.net.au/~mike/freebsd.html Just to note that while I am in flux, that should probably be ftp://ftp.gsoft.com.au/misc/ -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-config Thu Feb 5 15:05:22 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18915 for config-outgoing; Thu, 5 Feb 1998 15:05:22 -0800 (PST) (envelope-from owner-config) Received: from dingo.cdrom.com (lapdog.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA18910 for ; Thu, 5 Feb 1998 15:05:21 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id HAA00915; Fri, 6 Feb 1998 07:52:21 +1030 (CST) Message-Id: <199802052122.HAA00915@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Richard Wackerbarth cc: config@FreeBSD.ORG Subject: Re: Juliet In-reply-to: Your message of "Tue, 03 Feb 1998 08:24:05 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Feb 1998 07:52:20 +1030 From: Mike Smith Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (cc'd to -config; Richard I hope you don't mind, but I think your points deserve wider coverage.) > I found a little time to look at what you have started with "Juliet". > > Here are my initial observations: > > 1) I like the idea of using an extensible language system such as tcl. > However, if we were to use this for "sysinstall", would the "bloat" of > that package be a problem? Perhaps we will need a stripped down version > to fit on a floppy.... Tcl is moderately compact, but TBH I don't see any of this being on the install floppy. The current install floppy tries to do everything itself, which is a fundamental mistake. Without straying too far from the topic at hand, the install floppy's task is likely to be significantly rightsized fairly soon. > 2) I think that it is a mistake to add ANY extra methods to the primitive > data types. For example, in the case of the "cap" files, you have the concept > of a and, within the tag, and . These are all visable > at the interface. This requires that special methods are required for > adding a , etc. > I think that it would be better to use a unified structure whereby the > are a sub-node of the individual just as the is a sub-node of the > . That would allow the use of the same methods (and, by extension, UI) > to handle either. This design was actually fairly intentional. Juliet doesn't (perhaps unfortunately) hide any of its internal implementation from the consumer interface. It's not actually intended that a consumer work with the primitives. I take your point though. All that would be required in terms of methods would be one one the file to create a tag, and one on the tag to create a cap. TBH, the capabilities database is *not* designed to be automatically managed; the ability to crossreference one tag from within another is a complete nightmare. > 3) I would use a slightly different "method" scheme based on the inherited > concept of classes. Rather than directly implement each method for each node, > I would have each node have an attribute which describes its class of methods. > Further, within the method handler, I would allow inheritance of methods from > another class. Given that the method implementations are not likely to be shared amongst nodes of different types, ie. inheritance is likely to be almost nil, the extra complexity involved in this didn't seem to be worthwhile. > 4) As much as possible, I would keep the data table driven. That way we don't > have to change the engine in order to keep up with changes in the database. In the cases I've looked at so far, most of the methods have been largely procedural. This doesn't bend well to a table-driven approach, unfortunately. > 5) We should be able to use the same interface to access the target > description, the local working store, and reference definitions. That > way, I could implement everything either locally or remotely and reuse > interface modules. At this point in time, it is most likely that Juliet will become a backend for the UMich LDAP server. This prettymuch guarantees a common interface. > *** My conceptual model *** > 1) Everything is processed within the framework of transactions. > We may, or may not, worry about recovery in error conditions. Definitely. With the current discussions regarding implementing transactions via LDAP container objects, the presentation of transactions is likely to be much simpler (as all parameters will be available at the time of the transaction). > 2) The system consists of a number of subsystems: I'd like to see your response to Terry's whiteboard scrawl on this; I can send it to you if you didn't get it (are you on -config)? > I'm quite interested in this overall project and would like to continue > discussion of the design architecture. Thanks! -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-config Thu Feb 5 15:10:05 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19801 for config-outgoing; Thu, 5 Feb 1998 15:10:05 -0800 (PST) (envelope-from owner-config) Received: from dingo.cdrom.com (lapdog.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19794; Thu, 5 Feb 1998 15:10:04 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id WAA00515; Thu, 5 Feb 1998 22:28:18 +1030 (CST) Message-Id: <199802051158.WAA00515@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Adam Turoff cc: "'hackers@freebsd.org'" , "'config@freebsd.org'" , "'mike@smith.net.au'" Subject: Re: Multi-faced admin In-reply-to: Your message of "Mon, 02 Feb 1998 14:03:00 PST." <34D6422A@smginc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Feb 1998 22:28:18 +1030 From: Mike Smith Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Looking at Mikael Karpberg page on his architecture for admin'ing a > FreeBSD > box, I came across a link to Caldera's COAS project: http://www.coas.org COAS is vapourware at this point in time. I wasn't impressed last time I looked; it's a GUI frontend to a pile of specific configuration file editors and completely fails to address the issues of multisystem management. ie. idea for a standalone desktop, but a complete dud for anything that aspires to being a server operating system. > Reading the post about UMich's LDAP engine, it sounds rather radical. I don't know if "radical" is right; all I'm saying is that we need to provide a uniform interface to *all* the parametric information that controls the system, if we want to be able to abstract the "configuration" process from the "interpretation" process. This is where COAS (and others) fall down. > So, as of the moment, here's a concise view of what I'm seeing/hearing > for a FreeBSD framework: > > - httpd type server (easy to plug any client into/write new clients) > - standardized CGI interface subset for admin modules This is only *one* interface stack, but likely to be the most commonly used. > - LDAP for config managment by admin modules Terry's picture describes it much better than I can in words. You are describing the path from "Browser" to "LDAP Server", leaving out a few components, but pointing out that there has to be a shim between "HTTPD" and "LDAP Client API", ie. your CGI interface subset above. > the work is done. The bottom glue layer appears rather dumb, > but it should hide the complexity of a bazillion different config file > formats > (if I'm reading what Mike is saying about LDAP correctly). This is one of the key items; it means that there is no change in the parametric interface if/when we shift from separate configuration files to trusting the LDAP database for everything. > PS: Mike, where can I find some docs, etc. on the UMich LDAP server? Go to /usr/ports/net/ldap, and try "make install". The manpages it splats in are a good starting point, and it has some xrefs as well. There's also a mob called Critical Path (IIRC) that have some UMich LDAP resources (FAQ, etc.) online. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-config Thu Feb 5 16:12:10 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02426 for config-outgoing; Thu, 5 Feb 1998 16:12:10 -0800 (PST) (envelope-from owner-config) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02411 for ; Thu, 5 Feb 1998 16:12:04 -0800 (PST) (envelope-from nash@Jupiter.Mcs.Net) Received: from Jupiter.Mcs.Net (nash@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id RAA23679; Thu, 5 Feb 1998 17:22:00 -0600 (CST) Received: from localhost (nash@localhost) by Jupiter.Mcs.Net (8.8.7/8.8.2) with SMTP id RAA29619; Thu, 5 Feb 1998 17:21:59 -0600 (CST) Date: Thu, 5 Feb 1998 17:21:59 -0600 (CST) From: Alex Nash To: Mike Smith cc: Adam Turoff , "'config@freebsd.org'" Subject: Re: Multi-faced admin In-Reply-To: <199802051158.WAA00515@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 5 Feb 1998, Mike Smith wrote: > Go to /usr/ports/net/ldap, and try "make install". The manpages it > splats in are a good starting point, and it has some xrefs as well. > There's also a mob called Critical Path (IIRC) that have some UMich > LDAP resources (FAQ, etc.) online. Crtitical Angle. http://www.critical-angle.com/ Alex From owner-freebsd-config Thu Feb 5 16:51:25 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11675 for config-outgoing; Thu, 5 Feb 1998 16:51:25 -0800 (PST) (envelope-from owner-config) Received: from dingo.cdrom.com (lapdog.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA11667 for ; Thu, 5 Feb 1998 16:51:24 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA01683; Fri, 6 Feb 1998 11:12:09 +1030 (CST) Message-Id: <199802060042.LAA01683@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Colman Reilly cc: Richard Wackerbarth , config@FreeBSD.ORG, mike@smith.net.au Subject: Re: WebAdmin In-reply-to: Your message of "Wed, 04 Feb 1998 22:18:52 -0000." <199802042218.WAA18923@monoid.cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Feb 1998 11:12:08 +1030 From: Mike Smith Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > [Is anyone except me, Richard and Mike getting this?] I think so. But most of them are dead-set on hitting everything with their own particular hammer. 8( > Actually, the problem here is probably a requirements mismatch. I don't > believe that the configuration/system management task can be simply reduced > to reading/writing parameters. The objects being managed are generally more > complex than that, and we need to keep as much of the target specific stuff > right at the back end of the system. This is a very salient observation. Richard and I have both tried (but I think) failed to make the point that there are *two* things living in the backend; the configuration _data_, and the _procedures_ that consume that data to perform configuration. In Richard's case, he wants to know all the procedures in advance and bury them in a table-based lookup. From my point of view, it'd be easier to codify them in a procedural language-of-choice for the module designer, but either way you look at it it is the combination of the two that's important. > From the point of access control is is nice to have available the operations > like append, restart, create which express the meaning of the transaction in > order to make it easier to write (say) ACLs. Would you rather rather write > deny "write" on ".hub.controls.reset" to richard > or > deny "hub reset" to richard IMHO this is a task for a consumer to achieve. A consumer is either trusted or not trusted. A trusted consumer is expected to exercise discretion, which may involve ACLs, etc. Bearing in mind that it is the *consumer* that actually knows what the logical operations are. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-config Thu Feb 5 17:27:36 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16459 for config-outgoing; Thu, 5 Feb 1998 17:27:36 -0800 (PST) (envelope-from owner-config) Received: from dingo.cdrom.com (lapdog.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA16454 for ; Thu, 5 Feb 1998 17:27:35 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA01807; Fri, 6 Feb 1998 11:49:20 +1030 (CST) Message-Id: <199802060119.LAA01807@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: rkw@dataplex.net cc: config@freebsd.org Subject: Re: Juliet Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Feb 1998 11:49:19 +1030 From: Mike Smith Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (cc'd to -config; Richard I hope you don't mind, but I think your points deserve wider coverage.) > I found a little time to look at what you have started with "Juliet". > > Here are my initial observations: > > 1) I like the idea of using an extensible language system such as tcl. > However, if we were to use this for "sysinstall", would the "bloat" of > that package be a problem? Perhaps we will need a stripped down version > to fit on a floppy.... Tcl is moderately compact, but TBH I don't see any of this being on the install floppy. The current install floppy tries to do everything itself, which is a fundamental mistake. Without straying too far from the topic at hand, the install floppy's task is likely to be significantly rightsized fairly soon. > 2) I think that it is a mistake to add ANY extra methods to the primitive > data types. For example, in the case of the "cap" files, you have the concept > of a and, within the tag, and . These are all visable > at the interface. This requires that special methods are required for > adding a , etc. > I think that it would be better to use a unified structure whereby the > are a sub-node of the individual just as the is a sub-node of the > . That would allow the use of the same methods (and, by extension, UI) > to handle either. This design was actually fairly intentional. Juliet doesn't (perhaps unfortunately) hide any of its internal implementation from the consumer interface. It's not actually intended that a consumer work with the primitives. I take your point though. All that would be required in terms of methods would be one one the file to create a tag, and one on the tag to create a cap. TBH, the capabilities database is *not* designed to be automatically managed; the ability to crossreference one tag from within another is a complete nightmare. > 3) I would use a slightly different "method" scheme based on the inherited > concept of classes. Rather than directly implement each method for each node, > I would have each node have an attribute which describes its class of methods. > Further, within the method handler, I would allow inheritance of methods from > another class. Given that the method implementations are not likely to be shared amongst nodes of different types, ie. inheritance is likely to be almost nil, the extra complexity involved in this didn't seem to be worthwhile. > 4) As much as possible, I would keep the data table driven. That way we don't > have to change the engine in order to keep up with changes in the database. In the cases I've looked at so far, most of the methods have been largely procedural. This doesn't bend well to a table-driven approach, unfortunately. > 5) We should be able to use the same interface to access the target > description, the local working store, and reference definitions. That > way, I could implement everything either locally or remotely and reuse > interface modules. At this point in time, it is most likely that Juliet will become a backend for the UMich LDAP server. This prettymuch guarantees a common interface. > *** My conceptual model *** > 1) Everything is processed within the framework of transactions. > We may, or may not, worry about recovery in error conditions. Definitely. With the current discussions regarding implementing transactions via LDAP container objects, the presentation of transactions is likely to be much simpler (as all parameters will be available at the time of the transaction). > 2) The system consists of a number of subsystems: I'd like to see your response to Terry's whiteboard scrawl on this; I can send it to you if you didn't get it (are you on -config)? > I'm quite interested in this overall project and would like to continue > discussion of the design architecture. Thanks! - -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ - --JAA01046.886719497/dingo.cdrom.com-- ------- End of Forwarded Message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-config Thu Feb 5 17:42:58 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17902 for config-outgoing; Thu, 5 Feb 1998 17:42:58 -0800 (PST) (envelope-from owner-config) Received: from dingo.cdrom.com (lapdog.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17868; Thu, 5 Feb 1998 17:42:43 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA01875; Fri, 6 Feb 1998 12:03:41 +1030 (CST) Message-Id: <199802060133.MAA01875@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Ruslan Shevchenko cc: config@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: TCL API published. In-reply-to: Your message of "Thu, 05 Feb 1998 00:41:54 +0200." <34D8EEB0.2AF4C769@Shevchenko.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Feb 1998 12:03:41 +1030 From: Mike Smith Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Anybody know, is dynamic library loading from Tcl in run-time work in > FreeBSD ? Yes. > if work, how to do it, without generation of Tcl Interpeter for each > extension. ? For an extension called "foo", export a single symbol from your library called "Foo_Init" (casing is important) which defines your new commands/ namespaces/etc. Build a shared library using a Makefile, eg. LIB= foo SRCS= foo.c SHLIB_MAJOR= 1 SHLIB_MINOR= 0 # No static library INTERNALLIB= yes # No profiled library NOPROFILE= yes .include Then load it with the 'load' command, or "package require". -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-config Thu Feb 5 18:22:43 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24864 for config-outgoing; Thu, 5 Feb 1998 18:22:43 -0800 (PST) (envelope-from owner-config) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA24857 for ; Thu, 5 Feb 1998 18:22:40 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id UAA23866; Thu, 5 Feb 1998 20:22:04 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199802060119.LAA01807@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Feb 1998 20:21:59 -0600 To: Mike Smith From: Richard Wackerbarth Subject: Re: Juliet Cc: config@freebsd.org Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 7:19 PM -0600 2/5/98, Mike Smith wrote: >(cc'd to -config; Richard I hope you don't mind, but I think your >points deserve wider coverage.) > >> I found a little time to look at what you have started with "Juliet". >> >> Here are my initial observations: >> >> 1) I like the idea of using an extensible language system such as tcl. >> However, if we were to use this for "sysinstall", would the "bloat" of >> that package be a problem? Perhaps we will need a stripped down version >> to fit on a floppy.... > >Tcl is moderately compact, but TBH I don't see any of this being on the >install floppy. The current install floppy tries to do everything >itself, which is a fundamental mistake. Without straying too far from >the topic at hand, the install floppy's task is likely to be >significantly rightsized fairly soon. Bring up just enough of a kernel to talk to the keyboard/screen and SOME other source for the next stage of the process. If we can get out to a CD or the Net, we've got it made. Actually, with the CD, we might be able to directly boot the next stage which can run from RO store. Now all we have to do is format the first disk so that we have somewhere to really store things. .... :-) >> 2) I think that it is a mistake to add ANY extra methods to the primitive >> data types. For example, in the case of the "cap" files, you have the >>concept >> of a and, within the tag, and . These are all visable >> at the interface. This requires that special methods are required for >> adding a , etc. >> I think that it would be better to use a unified structure whereby the >> >> are a sub-node of the individual just as the is a sub-node >>of the >> . That would allow the use of the same methods (and, by extension, UI) >> to handle either. > >This design was actually fairly intentional. Juliet doesn't (perhaps >unfortunately) hide any of its internal implementation from the >consumer interface. It's not actually intended that a consumer work >with the primitives. I agree. The complaints from others about the "friendlyness" is, IMHO, misplaced. These commands are more like the machine language rather than the high level languages that we humans use to describe algorithms. It has been a long time since I had to enter programs with switches and pushbuttons and decypher hex dumps. >I take your point though. All that would be required in terms of >methods would be one one the file to create a tag, and one on the tag >to create a cap. Precisely. >TBH, the capabilities database is *not* designed to be automatically >managed; the ability to crossreference one tag from within another is a >complete nightmare. I don't propose that the back end have much, if any, semantic knowledge. In this case, all that it would know is that to display a file, it loops over the file's tags. To display the tag, it emits the tag, displays the aliases, and then displays the capabilities. It ends the process with an end-of-line. >> 3) I would use a slightly different "method" scheme based on the inherited >> concept of classes. Rather than directly implement each method for each >>node, >> I would have each node have an attribute which describes its class of >>methods. >> Further, within the method handler, I would allow inheritance of methods >>from >> another class. > >Given that the method implementations are not likely to be shared >amongst nodes of different types, ie. inheritance is likely to be >almost nil, the extra complexity involved in this didn't seem to be >worthwhile. Here, I take exception. As we start building the higher layers, I think that you will see quite a bit more sharing. I think that the capability should be handled in the "engine". Just think about the layers that I will want to add when we consider the multi-machine distributed case. I hope that I can use one engine >> 4) As much as possible, I would keep the data table driven. That way we >>don't >> have to change the engine in order to keep up with changes in the database. > >In the cases I've looked at so far, most of the methods have been >largely procedural. This doesn't bend well to a table-driven approach, >unfortunately. I think that you may have taken a small sample that is looking too deep. Try backing off a bit and you may find more commonality. There will always be those "special cases" simply because some failed to use a common structure and did it differently. >> 5) We should be able to use the same interface to access the target >> description, the local working store, and reference definitions. That >> way, I could implement everything either locally or remotely and reuse >> interface modules. > >At this point in time, it is most likely that Juliet will become a >backend for the UMich LDAP server. This prettymuch guarantees a common >interface. > >> *** My conceptual model *** >> 1) Everything is processed within the framework of transactions. >> We may, or may not, worry about recovery in error conditions. > >Definitely. With the current discussions regarding implementing >transactions via LDAP container objects, the presentation of >transactions is likely to be much simpler (as all parameters will be >available at the time of the transaction). Another transport that has merit is SNMP. I don't think the two are that far apart. If we can keep them unified within our system, we will be able to create a much better network administration tool. >> 2) The system consists of a number of subsystems: > >I'd like to see your response to Terry's whiteboard scrawl on this; I >can send it to you if you didn't get it (are you on -config)? I am now and have been for a day or two. However, I couldn't find any archive to review. :-( Please send a copy. >> I'm quite interested in this overall project and would like to continue >> discussion of the design architecture. > >Thanks! Richard Wackerbarth From owner-freebsd-config Thu Feb 5 18:38:38 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA28949 for config-outgoing; Thu, 5 Feb 1998 18:38:38 -0800 (PST) (envelope-from owner-config) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA28943 for ; Thu, 5 Feb 1998 18:38:36 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id UAA27379; Thu, 5 Feb 1998 20:38:22 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199802060042.LAA01683@dingo.cdrom.com> References: Your message of "Wed, 04 Feb 1998 22:18:52 -0000." <199802042218.WAA18923@monoid.cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Feb 1998 20:38:13 -0600 To: Mike Smith From: Richard Wackerbarth Subject: Re: WebAdmin Cc: Colman Reilly , config@FreeBSD.ORG, mike@smith.net.au Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 6:42 PM -0600 2/5/98, Mike Smith wrote: >This is a very salient observation. Richard and I have both tried (but >I think) failed to make the point that there are *two* things living in >the backend; the configuration _data_, and the _procedures_ that >consume that data to perform configuration. > >In Richard's case, he wants to know all the procedures in advance and >bury them in a table-based lookup. Now, I didn't say that. It is my understanding that it is possible to interpret "codelets" which are shipped down the pipe (ala java, lisp, tcl, etc.) However, there are really very few things that you can do on the back end. You can change a variable, list the tags in some database, execute a system call, etc. They are really pretty basic operations. What I want to abstract into the data tables is the organization of the data. You have already done part of this by having the file_name/method configuration file. I argue that someone who, for example, is editing user permissions does not care that the file has an ordered sequence of ":" separated values. To the person editing, he sees a "User_name", "Account_id", "Group", "Home_Directory", etc. Similarly, the widget that actually reads and writes the "/etc/master.passwd" file does not care what the label is that is attached to the third parameter. Further, this same widget can process a comma or tab delimited file. The mappings COULD be stored in the widget. However, I prefer to place them in a separate, or perhaps embedded, description table. That way we remove the meta data from the target file handlers and can maintain it separately. It is much easier to edit a table rather than change a program. > From my point of view, it'd be >easier to codify them in a procedural language-of-choice for the module >designer, but either way you look at it it is the combination of the >two that's important. I think we need to minimize the "smarts" in the back-end. Make it "lean and mean". Provide just enough capability to maintain the necessary security. Richard Wackerbarth From owner-freebsd-config Thu Feb 5 19:02:34 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04360 for config-outgoing; Thu, 5 Feb 1998 19:02:34 -0800 (PST) (envelope-from owner-config) Received: from dingo.cdrom.com (lapdog.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04342 for ; Thu, 5 Feb 1998 19:02:32 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA02204; Fri, 6 Feb 1998 12:57:32 +1030 (CST) Message-Id: <199802060227.MAA02204@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Richard Wackerbarth cc: config@freebsd.org Subject: Re: Juliet In-reply-to: Your message of "Thu, 05 Feb 1998 20:21:59 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Feb 1998 18:27:31 -0800 From: Mike Smith Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >TBH, the capabilities database is *not* designed to be automatically > >managed; the ability to crossreference one tag from within another is a > >complete nightmare. > > I don't propose that the back end have much, if any, semantic knowledge. > In this case, all that it would know is that to display a file, it loops > over the file's tags. To display the tag, it emits the tag, displays the > aliases, and then displays the capabilities. It ends the process with an > end-of-line. Fair enough. I suspect that I may have reached that conclusion myself; it has been some little time since I worked on that module. > >Given that the method implementations are not likely to be shared > >amongst nodes of different types, ie. inheritance is likely to be > >almost nil, the extra complexity involved in this didn't seem to be > >worthwhile. > > Here, I take exception. As we start building the higher layers, I think > that you will see quite a bit more sharing. I think that the capability > should be handled in the "engine". Just think about the layers that > I will want to add when we consider the multi-machine distributed case. > I hope that I can use one engine In the multisystem case, I see the break occuring at a higher point. Juliet's offspring lives down in the interface between the LDAP server and the system's configuration files, where it is only dealing with one system. > >In the cases I've looked at so far, most of the methods have been > >largely procedural. This doesn't bend well to a table-driven approach, > >unfortunately. > > I think that you may have taken a small sample that is looking too deep. > Try backing off a bit and you may find more commonality. There will > always be those "special cases" simply because some failed to use a > common structure and did it differently. Sure. I can certainly think of a few off the top of my head. I recall you weren't suggesting table-only, which gives us the best of both worlds. > >Definitely. With the current discussions regarding implementing > >transactions via LDAP container objects, the presentation of > >transactions is likely to be much simpler (as all parameters will be > >available at the time of the transaction). > > Another transport that has merit is SNMP. I don't think the two are that > far apart. If we can keep them unified within our system, we will be > able to create a much better network administration tool. You're missing the point with SNMP though; it doesn't have any of the value-add features that make LDAP desirable. There would be nothing stopping you exporting the LDAP space through an SNMP interface of course. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-config Thu Feb 5 19:53:48 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA14340 for config-outgoing; Thu, 5 Feb 1998 19:53:48 -0800 (PST) (envelope-from owner-config) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA14333 for ; Thu, 5 Feb 1998 19:53:46 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from [208.2.87.4] (user4.dataplex.net [208.2.87.4]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id VAA19159; Thu, 5 Feb 1998 21:53:25 -0600 (CST) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199802060227.MAA02204@dingo.cdrom.com> References: Your message of "Thu, 05 Feb 1998 20:21:59 CST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Feb 1998 21:53:23 -0600 To: Mike Smith From: Richard Wackerbarth Subject: Re: Juliet Cc: config@freebsd.org Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 8:27 PM -0600 2/5/98, Mike Smith wrote: >> >TBH, the capabilities database is *not* designed to be automatically >> >managed; the ability to crossreference one tag from within another is a >> >complete nightmare. >> >> I don't propose that the back end have much, if any, semantic knowledge. >> In this case, all that it would know is that to display a file, it loops >> over the file's tags. To display the tag, it emits the tag, displays the >> aliases, and then displays the capabilities. It ends the process with an >> end-of-line. > >Fair enough. I suspect that I may have reached that conclusion myself; >it has been some little time since I worked on that module. > >> >Given that the method implementations are not likely to be shared >> >amongst nodes of different types, ie. inheritance is likely to be >> >almost nil, the extra complexity involved in this didn't seem to be >> >worthwhile. >> >> Here, I take exception. As we start building the higher layers, I think >> that you will see quite a bit more sharing. I think that the capability >> should be handled in the "engine". Just think about the layers that >> I will want to add when we consider the multi-machine distributed case. >> I hope that I can use one engine > >In the multisystem case, I see the break occuring at a higher point. >Juliet's offspring lives down in the interface between the LDAP server >and the system's configuration files, where it is only dealing with one >system. I agree that it is only on one system. However, it is appropriately an engine to build additional layers. In the case of a single user system, I would be inclined to have it be THE engine for the whole thing. I don't see any reason that we should not write the simple user interface > >> >In the cases I've looked at so far, most of the methods have been >> >largely procedural. This doesn't bend well to a table-driven approach, >> >unfortunately. >> >> I think that you may have taken a small sample that is looking too deep. >> Try backing off a bit and you may find more commonality. There will >> always be those "special cases" simply because some failed to use a >> common structure and did it differently. > >Sure. I can certainly think of a few off the top of my head. I recall >you weren't suggesting table-only, which gives us the best of both >worlds. > >> >Definitely. With the current discussions regarding implementing >> >transactions via LDAP container objects, the presentation of >> >transactions is likely to be much simpler (as all parameters will be >> >available at the time of the transaction). >> >> Another transport that has merit is SNMP. I don't think the two are that >> far apart. If we can keep them unified within our system, we will be >> able to create a much better network administration tool. > >You're missing the point with SNMP though; it doesn't have any of the >value-add features that make LDAP desirable. There would be nothing >stopping you exporting the LDAP space through an SNMP interface of >course. Perhaps I don't understand your meaning of the term "LDAP". If you are referring to the semantic structure, I (think that I) agree. However, if you include the actual transport protocol, I want to back up one layer and consider that LDAP is just one of many possible protocols that we might use. SNMP could be another. In the degenerate case, the transport might be nothing more than another call within the Juliet stack. Richard Wackerbarth From owner-freebsd-config Thu Feb 5 20:48:28 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25017 for config-outgoing; Thu, 5 Feb 1998 20:48:28 -0800 (PST) (envelope-from owner-config) Received: from obiwan.creative.net.au (obiwan.creative.net.au [203.56.168.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA24935 for ; Thu, 5 Feb 1998 20:47:55 -0800 (PST) (envelope-from adrian@obiwan.creative.net.au) Received: from localhost (adrian@localhost) by obiwan.creative.net.au (8.8.8/8.8.5) with SMTP id MAA01082; Fri, 6 Feb 1998 12:47:35 +0800 (WST) Date: Fri, 6 Feb 1998 12:47:35 +0800 (WST) From: Adrian Chadd To: Andrew McNaughton cc: freebsd-config@freebsd.org Subject: RE: WebAdmin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 6 Feb 1998, Andrew McNaughton wrote: > > [Adrian] > >Depends. > > ? > > > >I've written a couple of web-based SQL databases, and I have been able > >to sucessfully encode enough state into the webpages themselves to make > >the databases useable and stable. > > I'm new to FreeBSD, but I've spent the past year doing CGI programming, > including a system for administering a database of users (not users in the > sense of being in /etc/passwd though). > > The first time I wrote an authentication system, I used a hidden session > key as suggested above. > > It's messy, mostly because it gets lost any time the user visits a static > page as tends to happen when they go to look at some documentation. If > users are encouraged (or even allowed) to back up using the browser's back > button, then problems occur with form data being resubmitted in order to > view a page again. It's somewhat browser dependent. To prevent this, > session keys should probably be changed whenever data is submitted, though > I haven't yet implemented this. > I like the mini-httpd idea for implementing some form of state in HTTP 1.0 .. The thing is the only pages with HIDDEN tags would be cgi-generated pages. If someone bookmarked, say .. the modify page where you modify the information for a particular user, then the cgi would notice it didn't have any name/value tags passed to it, and would either show an error or (what I prefer) the page that called it. You know you can get the username called from a HTTP authentication session from the CGI's environment? I implemented login/passwords this way, and I never had a problem with caching pages with hidden tags, usernames, etc. In fact the biggest problem I had was getting people to kill their browsers when they walked away, since the browser caches the Authentication username/password :P Adrian From owner-freebsd-config Sat Feb 7 08:25:04 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA27920 for config-outgoing; Sat, 7 Feb 1998 08:25:04 -0800 (PST) (envelope-from owner-config) Received: from cam.grad.kiev.ua (grad-UTC-28k8.ukrtel.net [195.5.25.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA27896; Sat, 7 Feb 1998 08:24:56 -0800 (PST) (envelope-from Ruslan@Shevchenko.kiev.ua) Received: from Shevchenko.kiev.ua (localhost [127.0.0.1]) by cam.grad.kiev.ua (8.8.8/8.8.5) with ESMTP id UAA29823; Fri, 6 Feb 1998 20:22:31 +0200 (EET) Message-ID: <34DB54E2.7940B35@Shevchenko.kiev.ua> Date: Fri, 06 Feb 1998 20:22:28 +0200 From: Ruslan Shevchenko Reply-To: rssh@grad.kiev.ua X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: config@freebsd.org CC: hackers@freebsd.org Subject: core C++ API of User Management System published. Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk core C++ API for my User Management System just published. please, review and send me comments . Thanks. (main web page: http://cam.grad.kiev.ua/~rssh/admin/admin.html) -- @= //RSSH mailto:Ruslan@Shevchenko.Kiev.UA