From owner-freebsd-config Thu Jan 29 18:47:38 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA20827 for config-outgoing; Thu, 29 Jan 1998 18:47:38 -0800 (PST) (envelope-from owner-config) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA20614; Thu, 29 Jan 1998 18:46:48 -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 NAA00844; Fri, 30 Jan 1998 13:06:34 +1030 (CST) Message-Id: <199801300236.NAA00844@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Karl Pielorz cc: hackers@FreeBSD.ORG, config@FreeBSD.ORG Subject: Re: FreeBSD updated Installation / Adminsitration Kit In-reply-to: Your message of "Fri, 30 Jan 1998 01:20:52 -0000." <34D12AF4.80043C1B@tdx.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jan 1998 13:06:33 +1030 From: Mike Smith Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > It has been decided that FreeBSD could do with a 'replacement' to sysinstall, > preferably something graphical, and 'portable'. We have a choice of 3 > alternatives, I don't want to rain on your parade just yet, but you might want to take this up with me. Seeing as Jordan has mentioned it publically now, it's probably safe to make it generally known that next week I am moving to the Concord area to work for Walnut Creek CDROM. My first task is to develop the replacement for the current installer and packaging system, with the intention of having these ready for the 3.0 release. Not inconsiderable thought (not to mention work) has been expended on the form that these will take over the last couple of years; if you have a chance to browse the list archives for a while it might be informative. > 1. We write something that will 'install' FreeBSD with emphasis on ease of > use, size, and the fact it will run very nicely on FreeBSD and let people > install it (I hate to use the words 'Like windows 95'). 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. > 2. We write something that will maintain FreeBSD - again with emphasis on ease > of use, but including portability (i.e. we want to be able to run this from > Windows, other Unix platforms, Alpha workstations, X-servers etc. This is more > akin to the Admin tools for something like SCO OpenDesktop etc. - but done > properly ;-) Here you lump together a great number of iterrelated issues. I don't think that you're really thought this one through. Terry is much closer to the mark with his summary, which comes reasonably close to condensing most of the conclusions that've been reached over the years. Bottom line: LDAP is the way to go, however we do it. It is the distributed parametric database system that we basically need. > 3. We write something that tries to accomplish both the above, hopefully not > causing too many compromises. This would be a major layering mistake. > The main areas of abstraction I can see after looking through things briefly > are: > > 1. The client, abstracts itself from the actual unix commands somehow (i.e. > the client doesn't actually issue things like 'adduser -batch ...' etc. - most > popular theory so far is it uses MIB like structures etc. (see 2.) > > 2. The commands / administration is abstracted through the use of something > similar to MIB's etc. (i.e. little modules that describe what fields the > 'adduser v1.2' command needs, what they should contain) - through this we can > hopefully keep the client up to date without too much trouble, and build a > nice area with all the MIB's (for want of a better word) living in... > > The above 2 points mean that we should be able to carve things up a bit > amongst ourselves... You haven't played with juliet yet: ftp://ftp.gsoft.com.au/misc/juliet.tar.gz The name parsing will probably change in order to fit into the Distinguished Name schema that LDAP uses, but the basically modular and method-based design will remain. With a little tinkering this will let people write backend modules in almost any language they like. I know it works with Tcl and C (although I removed the shared library code for rework), Perl would be a trivial addition, etc. > SO - Yet again, I'm asking: > > a) Who's up for this? Yes. > b) How do we get organized? (Divide and conquer always seems to work for me > ) If I may make a suggestion; given that I'm claiming the installer, I would recommend that you look at the umich LDAP server (/usr/ports/net/ldap) and juliet, and start making rude remarks about the module interface for the backend. 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. And subscribe (and post) to config@freebsd.org. -- \\ 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 Jan 29 18:56:56 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA22411 for config-outgoing; Thu, 29 Jan 1998 18:56:56 -0800 (PST) (envelope-from owner-config) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA22394 for ; Thu, 29 Jan 1998 18:56:49 -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 NAA00906; Fri, 30 Jan 1998 13:19:54 +1030 (CST) Message-Id: <199801300249.NAA00906@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Adam Turoff cc: config@freebsd.org Subject: Re: WebAdmin (was: RE: /usr/src/release/sysinstall needs YOU. :-)) In-reply-to: Your message of "Wed, 28 Jan 1998 11:16:00 PST." <34D0D540@smginc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jan 1998 13:19:53 +1030 From: Mike Smith Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > OK. Enough goading. :-) OK. 8) I saved this mesasge because it's a good place to start plugging Juliet again. 8) > I don't feel qualified enough to start down this path alone. There > are a lot of nontrivial security issues to deal with, and a lot of > nontrivial configuration issues to deal with, too. This becomes easier when you layer the security issues. I would stop worrying about them for starters. > Here are a few things I'd like to see in a web-based admin tool: > - DNS administration > - user config > - NFS config > - mounting > - mirroring Each of these can be considered in two parts; the backend which manipulates the current configuration "database", and the frontend which provides the window-dressing for the user. The backend for any of the above can be trivially implemented as a module inside the juliet framework. The frontend is up to the HTML people out there. 8) > - apache config (?) > - samba config (admin-loadable module? :-) ) Modules can come from anywhere, even packages. > - lynx friendly This is an issue for frontend design. It means that you need to rule out any client-side smarts at all in the frontend. > - config replication (act like that machine there) LDAP makes this *very* easy. > - ports management That's really just another module. > My questions to -hackers at large would be: > - any other admin type things that should be included? > - any other security issues that should be considered? > - ideas for extensibility? > > Hopefully I should have something started in a few weeks. Please don't start until you've looked at what's already on the table; it'd be nice to coordinate things. I'd suggest subscribing to -config and brawling it out there where it's meant to be. > Rhythm deficient bassist for Necessity & the Mothers of Invention Argh. More musicians. 8) -- \\ 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 Jan 29 21:20:58 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA16480 for config-outgoing; Thu, 29 Jan 1998 21:20:58 -0800 (PST) (envelope-from owner-config) Received: from vnode.vmunix.com (vnode.vmunix.com [209.112.4.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA16354; Thu, 29 Jan 1998 21:20:51 -0800 (PST) (envelope-from mark@vnode.vmunix.com) Received: (from mark@localhost) by vnode.vmunix.com (8.8.8/8.8.8) id AAA10610; Fri, 30 Jan 1998 00:23:12 -0500 (EST) (envelope-from mark) Message-ID: <19980130002312.53242@vmunix.com> Date: Fri, 30 Jan 1998 00:23:12 -0500 From: Mark Mayo To: Mike Smith Cc: Karl Pielorz , hackers@FreeBSD.ORG, config@FreeBSD.ORG Subject: Re: FreeBSD updated Installation / Adminsitration Kit References: <34D12AF4.80043C1B@tdx.co.uk> <199801300236.NAA00844@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199801300236.NAA00844@word.smith.net.au>; from Mike Smith on Fri, Jan 30, 1998 at 01:06:33PM +1030 X-Operating-System: FreeBSD 2.2.5-STABLE i386 Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Jan 30, 1998 at 01:06:33PM +1030, Mike Smith wrote: [SNIP] > > It has been decided that FreeBSD could do with a 'replacement' to sysinstall, > > preferably something graphical, and 'portable'. We have a choice of 3 > > alternatives, [SNIP] > > 2. We write something that will maintain FreeBSD - again with emphasis on ease > > of use, but including portability (i.e. we want to be able to run this from > > Windows, other Unix platforms, Alpha workstations, X-servers etc. This is more > > akin to the Admin tools for something like SCO OpenDesktop etc. - but done > > properly ;-) > > Here you lump together a great number of iterrelated issues. I don't > think that you're really thought this one through. Terry is much > closer to the mark with his summary, which comes reasonably close to > condensing most of the conclusions that've been reached over the years. I agree. > Bottom line: LDAP is the way to go, however we do it. It is the > distributed parametric database system that we basically need. Once again, I agree. As I mentioned before, I've played with the idea of a FreeBSD management system in the past, but never had the time to implement one. I'm not really that interested in writing something that can be used to install the system - more like something to manage it effectively when it's up and running. For me, this means a GUI of some sort, ultimately. IMHO, installing the system and admining it are two distinct tasks (at least from the user point of view) and shouldn't necessarily have the same limitations/conditions... Background, which will lead to a proposal: (sorry this is long, but it will be necesary to establish the motives behind the proposal....) ----------------------------------------- I go to school at the unviversity of Guelph. Rick Maclem, the NFS guru for 4.4BSD is the sysadmin here. Rick's hard to get motivated - until his boss (the chair of th department) tells him to get his ass in gear. Such was the case with the NFS work Rick did (and VFS stuff). The nifty development: The Chair of the department has decided that Guelph should return to the BSD limelight again, and wants to do this by "sponsoring" the creation of some sort of "information infrastructure" system ontop of FreeBSD (he's an academic, so don't ask). I was recently repsonsible for ridding the department of the evils of Linux and we have now returned to our roots with a complete switch to FreeBSD (thanks go out to Jordan and Walnut Creek for donating the hordes of CDROMS it took to bribe the faculty ;-)) I met with the chair this morning to ask if I and a friend (Pat Wardrop) could get involved with the creation of a FreeBSD admin system and get a credit out of it (we have a few project courses available for 4th year students). In short, Jim (the chair) loved the idea, and lectured us about how this would be a perfect example of "information infrastructure" ontop of UNIX.. He wants to start this now, and has offered us any resources the department has. To date this includes: 1. Two dual PII-333 PCs loaded to the teeth for people to work on 2. Rick Maclem. Rick knows protocols, and the BSD guts inside out. 3. A facult member of our choice, and his/her grad students 4. 2 credits for me and Pat :-) 5. Money to attend USENIX in June, to have a "live" discussion with anybody who might want to participate in this project So, basically, I'm offering to host mailing lists, development accounts, or whatever people need to sit down and come up with a real, cool FreeBSD admin infrastructure. What do people think of this idea? We need coordination, and I guess "The University of Guelph Computer Science Department" is offering to donate whatever it takes to coordinate this effort and crank out some code. [SNIP] > > b) How do we get organized? (Divide and conquer always seems to work for me > > ) > > If I may make a suggestion; given that I'm claiming the installer, I > would recommend that you look at the umich LDAP server > (/usr/ports/net/ldap) and juliet, and start making rude remarks about > the module interface for the backend. > > 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. My idea all along has been a "protocol" based approach, where you define a MIB-like server protocol that performs tasks, and write the GUI of your choice to talk to that admin server. I actually was leaning away from a httpd approach in favour of client/server type stuff, with Java "programs", not applets.. (or Tcl clients, or Win32, or whatever the hell someone wanted write). The idea being a solid server protocol the clients talk to.. I haven't looked at the LDAP stuff, or how it would fit in, but it sounds very appropriate for storing and distributing the "blobs" of stuff that would encapsulate a task performed by the system. Time to do some reading! :-) That's all I'll say for now. There seems to be lots of interest in this type of thing, and hopefully we can all capitalize on it and come up with some neat stuff. Any comments very much welcome. -Mark > > -- > \\ 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. \\ > -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ Win95/NT - 32 bit extensions and a graphical shell for a 16 bit patch to an an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition. -UGU From owner-freebsd-config Fri Jan 30 02:36:53 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA04903 for config-outgoing; Fri, 30 Jan 1998 02:36:53 -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 CAA04895; Fri, 30 Jan 1998 02:36:50 -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 CAA19435; Fri, 30 Jan 1998 02:37:13 -0800 (PST) To: config@freebsd.org cc: nate@freebsd.org Subject: Something I was forwarded... Date: Fri, 30 Jan 1998 02:37:13 -0800 Message-ID: <19432.886156633@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk http://www.ddj.com/ftp/1997/1997.09/javatui.zip A text UI for Java. Jordan From owner-freebsd-config Fri Jan 30 06:47:13 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA11899 for config-outgoing; Fri, 30 Jan 1998 06:47:13 -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 GAA11892 for ; Fri, 30 Jan 1998 06:47:10 -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 OAA02496; Fri, 30 Jan 1998 14:47:00 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 OAA08247; Fri, 30 Jan 1998 14:43:24 GMT Message-Id: <199801301443.OAA08247@monoid.cs.tcd.ie> To: config@freebsd.org cc: Adam Turoff Subject: Re: WebAdmin (was: RE: /usr/src/release/sysinstall needs YOU. :-)) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8242.886171403.1@monoid.cs.tcd.ie> Date: Fri, 30 Jan 1998 14:43:24 +0000 From: Colman Reilly Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In-reply-to: Your message of "Wed, 28 Jan 1998 11:16:00 PST." <34D0D540@smginc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Jan 1998 13:19:53 +1030 From: Mike Smith > OK. Enough goading. :-) OK. 8) I saved this mesasge because it's a good place to start plugging Juliet again. 8) > I don't feel qualified enough to start down this path alone. There > are a lot of nontrivial security issues to deal with, and a lot of > nontrivial configuration issues to deal with, too. This becomes easier when you layer the security issues. I would stop worrying about them for starters. I've written up and published a summary of the architectural discussions as I understand them together with some of my thoughts on the security issues at http://www.cs.tcd.ie/~careilly/portia/ArchNotes. The network here has been a bit unstable over the last week or two so it may be a bit unreliable. (Something to do with ATM switches I believe. What a suprise.) It's only a draft that I knocked up over the last hour, so excuse the quality. I'll try and keep it up to date as the discussion progresses and I'll try to write up a comprehensible explanation of what I mean by a "layered access control system" (LAX) over the weekend. Apologies in advance if I've mis-interpreted any of the discussion. Note that I am entirely agnostic about which languages we implement in. I see no reason that different layers shouldn't have different implementation languages. Colman From owner-freebsd-config Fri Jan 30 09:10:52 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA04436 for config-outgoing; Fri, 30 Jan 1998 09:10:52 -0800 (PST) (envelope-from owner-config) Received: from elvis.vnet.net (root@elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA04317; Fri, 30 Jan 1998 09:10:34 -0800 (PST) (envelope-from rivers@dignus.com) Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id MAA20055; Fri, 30 Jan 1998 12:10:49 -0500 (EST) Received: from lakes.dignus.com (lakes [10.0.0.3]) by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id LAA29081; Fri, 30 Jan 1998 11:07:20 -0500 (EST) Received: (from rivers@localhost) by lakes.dignus.com (8.8.7/8.6.9) id KAA29212; Fri, 30 Jan 1998 10:50:32 -0500 (EST) Date: Fri, 30 Jan 1998 10:50:32 -0500 (EST) From: Thomas David Rivers Message-Id: <199801301550.KAA29212@lakes.dignus.com> To: mark@vmunix.com, mike@smith.net.au Subject: Re: FreeBSD updated Installation / Adminsitration Kit Cc: config@FreeBSD.ORG, hackers@FreeBSD.ORG, kpielorz@tdx.co.uk Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mark Mayo writes: > > On Fri, Jan 30, 1998 at 01:06:33PM +1030, Mike Smith wrote: > > [SNIP] > > > > It has been decided that FreeBSD could do with a 'replacement' to sysinstall, > > > preferably something graphical, and 'portable'. We have a choice of 3 > > > alternatives, > [SNIP] > > > 2. We write something that will maintain FreeBSD - again with emphasis on ease > > > of use, but including portability (i.e. we want to be able to run this from > > > Windows, other Unix platforms, Alpha workstations, X-servers etc. This is more > > > akin to the Admin tools for something like SCO OpenDesktop etc. - but done > > > properly ;-) > > > > Here you lump together a great number of iterrelated issues. I don't > > think that you're really thought this one through. Terry is much > > closer to the mark with his summary, which comes reasonably close to > > condensing most of the conclusions that've been reached over the years. > > I agree. > > > Bottom line: LDAP is the way to go, however we do it. It is the > > distributed parametric database system that we basically need. > > Once again, I agree. As I mentioned before, I've played with the idea > of a FreeBSD management system in the past, but never had the time to > implement one. I'm not really that interested in writing something that > can be used to install the system - more like something to manage it > effectively when it's up and running. For me, this means a GUI of > some sort, ultimately. IMHO, installing the system and admining it > are two distinct tasks (at least from the user point of view) and > shouldn't necessarily have the same limitations/conditions... > > Background, which will lead to a proposal: > (sorry this is long, but it will be > necesary to establish the motives behind > the proposal....) Ok - just to provide more information on my questionable LDAP reference a while back: The article comes from Computer Reseller News, and is titled: VARs cite LDAP woes -- De factor standard is not enough to ease interoperability snafus. You should be able to find it by looking for LDAP references at http://www.crn.com or http://www.varbiz.com I'm not necessarily suggesting LDAP is "bad" - just providing information... - Dave Rivers - From owner-freebsd-config Fri Jan 30 12:20:13 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09654 for config-outgoing; Fri, 30 Jan 1998 12:20:13 -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 MAA09644; Fri, 30 Jan 1998 12:20:08 -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 AAA192; Fri, 30 Jan 1998 15:21:52 -0500 Received: by smginc.com with Microsoft Mail id <34D25FB6@smginc.com>; Fri, 30 Jan 98 15:18:14 PST From: Adam Turoff To: "'mike@smith.net.au'" , Karl Pielorz Cc: hackers , config Subject: RE: FreeBSD updated Installation / Adminsitration Kit Date: Fri, 30 Jan 98 15:19:00 PST Message-ID: <34D25FB6@smginc.com> Encoding: 91 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike writes: > > 1. We write something that will 'install' FreeBSD with emphasis on ease of > > use, size, and the fact it will run very nicely on FreeBSD and let people > > install it (I hate to use the words 'Like windows 95'). > > 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. :-) [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. Here's the way I see it, as concisely as possible: improve sysinstall, and leave that config available for later allow a system to be reconfiged later with good tools prevent tool-implementation lock in by allowing multiple tools to do the day-to-day admin, local or remote In short, sysinstall and/or it's successor should dovetail nicely with some new config framework, probably using LDAP. > You haven't played with juliet yet: > ftp://ftp.gsoft.com.au/misc/juliet.tar.gz I plead guilt to that charge as well. :-) > The name parsing will probably change in order to fit into the > Distinguished Name schema that LDAP uses, but the basically modular and > method-based design will remain. > > With a little tinkering this will let people write backend modules in > almost any language they like. I know it works with Tcl and C > (although I removed the shared library code for rework), Perl would be > a trivial addition, etc. This is along the lines of what I'm seeing as well. It's just that I tend not to put the letters L, D, A and P together in a sentence. > > SO - Yet again, I'm asking: > > > > a) Who's up for this? > > Yes. Ditto. > > b) How do we get organized? (Divide and conquer always seems to work for me > > ) > > If I may make a suggestion; given that I'm claiming the installer, I > would recommend that you look at the umich LDAP server > (/usr/ports/net/ldap) and juliet, and start making rude remarks about > the module interface for the backend. OK. > 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? > And subscribe (and post) to config@freebsd.org. OK. I'll start here. :-) -- Adam. From owner-freebsd-config Fri Jan 30 20:59:51 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA13850 for config-outgoing; Fri, 30 Jan 1998 20:59:51 -0800 (PST) (envelope-from owner-config) Received: from tolstoy.mpd.ca (mpd.ca [206.123.11.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA13845 for ; Fri, 30 Jan 1998 20:59:50 -0800 (PST) (envelope-from wlloyd@mpd.ca) Received: from galt.mpd.ca (galt.mpd.ca [206.123.11.40]) by tolstoy.mpd.ca (8.8.8/8.8.8) with ESMTP id AAA13009 for ; Sat, 31 Jan 1998 00:00:03 -0500 (EST) (envelope-from wlloyd@mpd.ca) From: William Lloyd Received: (from wlloyd@localhost) by galt.mpd.ca (8.8.8/8.8.7) id XAA15749 for freebsd-config@freebsd.org; Fri, 30 Jan 1998 23:59:18 -0500 (EST) (envelope-from wlloyd@mpd.ca) Date: Fri, 30 Jan 1998 23:59:18 -0500 (EST) Message-Id: <199801310459.XAA15749@galt.mpd.ca> To: freebsd-config@freebsd.org Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk subscribe From owner-freebsd-config Sat Jan 31 03:18:25 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA28264 for config-outgoing; Sat, 31 Jan 1998 03:18:25 -0800 (PST) (envelope-from owner-config) Received: from word.smith.net.au (ppp10.portal.net.au [202.12.71.110]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA28259 for ; Sat, 31 Jan 1998 03:18: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 VAA03258; Sat, 31 Jan 1998 21:38:39 +1030 (CST) Message-Id: <199801311108.VAA03258@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Alex Belits 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: Your message of "Sat, 31 Jan 1998 02:29:04 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 Jan 1998 21:38:39 +1030 From: Mike Smith Sender: owner-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I will ask again; would people *PLEASE* take this conversation to -config, where it belongs. > On Sat, 31 Jan 1998, Terry Lambert wrote: > > > I think that the atomicity of the transaction for HTML is an implementation > > detal; a detail best served by defineing how a transaction is to take place. > > > > That the HTML post is a "transaction" is seperate from "what to do when > > an HTML post is seen and you are an HTML server". > > Of course, implementation can treat it as a transaction or not. I only > mean that HTTP protocol with forms uploaf provides a mechanism that allows > HTTP server to use transactions regardless of the model used by client for > its actions as long as the client uses HTTP. HTTP has *nothing* to do with the parameter store. HTTP is an abstraction within the presentation layer ("user interface"). If you are using HTTP in the presentation layer, it is the actions performed by the "server" side of the HTTP interface which need to be grouped in a transaction. Terry's 'container object' technique is about the only way to do it; in fact it *is* a transaction technique with the internals of the process exposed to the consumer. -- \\ 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 Sat Jan 31 09:59:57 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11784 for config-outgoing; Sat, 31 Jan 1998 09:59:57 -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 JAA11778 for ; Sat, 31 Jan 1998 09:59:55 -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 RAA11812 for ; Sat, 31 Jan 1998 17:59:50 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 RAA11219 for ; Sat, 31 Jan 1998 17:56:10 GMT Message-Id: <199801311756.RAA11219@monoid.cs.tcd.ie> To: config@freebsd.org Subject: Re: WebAdmin (was: RE: /usr/src/release/sysinstall needs YOU. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11214.886269369.1@monoid.cs.tcd.ie> Date: Sat, 31 Jan 1998 17:56:10 +0000 From: Colman Reilly Sender: owner-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [I'm resending this. I think I managed to misaddress this the first time.] Mike said: > OK. Enough goading. :-) OK. 8) I saved this mesasge because it's a good place to start plugging Juliet again. 8) > I don't feel qualified enough to start down this path alone. There > are a lot of nontrivial security issues to deal with, and a lot of > nontrivial configuration issues to deal with, too. This becomes easier when you layer the security issues. I would stop worrying about them for starters. I've written up and published a summary of the architectural discussions as I understand them together with some of my thoughts on the security issues at http://www.cs.tcd.ie/~careilly/portia/ArchNotes. The network here has been a bit unstable over the last week or two so it may be a bit unreliable. (Something to do with ATM switches I believe. What a suprise.) It's only a draft that I knocked up over the last hour, so excuse the quality. I'll try and keep it up to date as the discussion progresses and I'll try to write up a comprehensible explanation of what I mean by a "layered access control system" (LAX) over the weekend. Apologies in advance if I've mis-interpreted any of the discussion. Colman From owner-freebsd-config Sat Jan 31 18:13:04 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25274 for config-outgoing; Sat, 31 Jan 1998 18:13:04 -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 SAA25269 for ; Sat, 31 Jan 1998 18:13:02 -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 SAA13339; Sat, 31 Jan 1998 18:14:26 -0800 Date: Sat, 31 Jan 1998 18:14:24 -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: <199801311108.VAA03258@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 Sat, 31 Jan 1998, Mike Smith wrote: > I will ask again; would people *PLEASE* take this conversation to > -config, where it belongs. ok > > On Sat, 31 Jan 1998, Terry Lambert wrote: > > > > > I think that the atomicity of the transaction for HTML is an implementation > > > detal; a detail best served by defineing how a transaction is to take place. > > > > > > That the HTML post is a "transaction" is seperate from "what to do when > > > an HTML post is seen and you are an HTML server". > > > > Of course, implementation can treat it as a transaction or not. I only > > mean that HTTP protocol with forms uploaf provides a mechanism that allows > > HTTP server to use transactions regardless of the model used by client for > > its actions as long as the client uses HTTP. > > HTTP has *nothing* to do with the parameter store. HTTP is an > abstraction within the presentation layer ("user interface"). > > If you are using HTTP in the presentation layer, it is the actions > performed by the "server" side of the HTTP interface which need to be > grouped in a transaction. Terry's 'container object' technique is > about the only way to do it; in fact it *is* a transaction technique > 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. HTTP has means that define the boundaries of transaction, and container object in HTTP-based implementation may exist only in the memory of the program that serves requests while client (not necessarily one that uses HTML -- HTTP can be used without HTML, and even without URL-encoded form upload -- one can encapsulate into HTTP whatever one pleases as long as it can have some atomic transmission that can have MIME header added to it) only groups some data into single form (or comma-separated list, or encapsulated into HTTP set of SQL requests, or whatever else) thus having completely unrelated object (say, list of strings, prepared for form upload) that doesn't have to make its identifier known to anyone else -- the result of transaction will be associated with it because it will be the answer to the HTTP request containing it. I agree that HTTP is not the only thing that can be used there, I only think that it's more appropriate as the protocol because it leaves consistency relying on the server and not on the client's behavior. -- Alex