Date: Fri, 30 Jan 1998 13:06:33 +1030 From: Mike Smith <mike@smith.net.au> To: Karl Pielorz <kpielorz@tdx.co.uk> Cc: hackers@FreeBSD.ORG, config@FreeBSD.ORG Subject: Re: FreeBSD updated Installation / Adminsitration Kit Message-ID: <199801300236.NAA00844@word.smith.net.au> In-Reply-To: Your message of "Fri, 30 Jan 1998 01:20:52 -0000." <34D12AF4.80043C1B@tdx.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 > <g>) 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. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801300236.NAA00844>