From owner-freebsd-small Wed Oct 7 13:23:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12901 for freebsd-small-outgoing; Wed, 7 Oct 1998 13:23:08 -0700 (PDT) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from smtp04.wxs.nl (smtp04.wxs.nl [195.121.6.59]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12882 for ; Wed, 7 Oct 1998 13:23:00 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from diabolique ([195.121.59.122]) by smtp04.wxs.nl (Netscape Messaging Server 3.6) with SMTP id AAB41E8; Wed, 7 Oct 1998 22:22:44 +0200 X-Sender: skywise@pop.wxs.nl X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo Date: Wed, 07 Oct 1998 22:24:38 +0200 To: Andrzej Bialecki From: Jeroen Ruigrok/Asmodai Subject: Re: picoBSD Goals Cc: FreeBSD Small In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <771898F08C1.AAB41E8@smtp04.wxs.nl> Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 09:39 07-10-98 , Andrzej Bialecki wrote: >On Tue, 6 Oct 1998, Jeroen Ruigrok/Asmodai wrote: > >> Clear goals and ideas for picoBSD: >> >> 1) Small OS with emphasis on networking and all related to networking such >> as routing, bridging & dial solutions, but not limited to those afore >> mentioned topics. > >I understand "small" as "limited and predictable resource consumption". >With this definition, a system which uses 40MB flash disk running on a 4MB >SBC also fits within our interests... My idea of small is as in small memory footprint, small code yer powerful and strong. >> 2) Use of the FreeBSD STABLE, RELEASE and CURRENT/BETA kernels for picoBSD >> basis. > >Yes. > >BTW. If anyone wants to take care of producing -STABLE floppies, step up, >please :-) - all machines within my reach are running -current... Lemme finish up my other partition for STABLE then... Then I can work on both CURRENT as well as STABLE (2.2.7 declared STABLE yet?) >> 3) Addition of wide accepted routing protocols at first, maybe expanded >> with lesser used protocols in traditional *NIX environments, IPX/SPX, XNS, >> X.25 and what else spring to mind. > >Your point 2) contradicts with 3), unless you are willing to resurrect >support for these protocols in the standard FreeBSD kernel... I already raised my voice for that on the Networking list. Except it's hard to get documentation about XNS and X.25 without paying, any pointers are welcome, or at least where I can order them. IPX/SPX is still widely used... >Do we have enough people to work exclusively on making a _PICO_ BSD >specific kernel? I don't think so. Let's better stick with the standard >/sys (providing necessary patches and features, of course). Dunno, do we? Could we open a seperate CVS directory in which we could put stripped down versions of the /sys-sources? Just a suggestion... >So, for the nearest future we'll stick with IP (perhaps IPX and ATM). IP sounds good =) > > 4) Security is a prerequisite for configuration safeguarding. > >Wellll... yes (though I'm not sure I understand the above... :-) Let me >rephrase it. > >4) Security measures should be such that prevent unauthorized users to >either change it's configuration and/or operation, or gain access to >sensitive data (passwords, SNMP community strings etc..), while at the >same time allowing for convenient access for authorized users. That's what I said ;) >Well, but I'd say it's true in every situation, isn't it? Here's what I >think should be added, and what's specific to our target "market": Aye, but often the most obvious things that stare us in the face are forgotten... >4a) Use of widely accepted protocols for distributed authentication (such >as Radius, Tacacs, Kerberos). Yeah been scoping up some docs about them. Got any more reference URL's? I have two RFCs about TACACS, plus a draft from Cisco about XTACACS. Also isn't Kerberos resticted? Radius? Know the name, there ends my understanding =) >> 5) Hierarchical grouping structure of command set that allows for clear >> and useful configuration. Starting from toplevel generic classifications >> down to very specific configurations. Also, command set versioning >> independant from kernel versioning. >> >> E.g.: --- Dialing >> | >> --- User >> | >> --- Networking >> | | >> | --- IP >> | | >> | --- IPX >> | >> --- Miscellaneous >Yes, definitely. The above describes only how it could look from the >user's perspective, and doesn't say anything about how to translate the UI >commands to the actual configuration requests for the underlying >subsystems. Indeed, it's just a global cut. As far as I see it, certain commands alter certain files for the reasons I stated in another mail (too long a config file/one command needs to rewrite the whole file) [reply to point 6, WWW interface] >Well, I think we can keep in mind that perhaps some day we will want to >present the config data via WWW. But we need to resolve the more basic >issues first... My idea exactly. >> 7) Deletion of many subdirectories and commands and a restructuring of the >> remaining directories in order to create some order for the picoBSD kernel. > >s/kernel/userland/. With this change - yes. But it's natural consequence >of different configuration scheme. Offcourse, yet again, the obvious might have to be restated for all to know the how and what. >> 8) Make online configuration easy to retrieve info from, not like IOS' >> list of data, but instead grouped and formatted. >> >> 9) Decide on configuration file formats, filenames and directories. >> >> 10) Getting rid of *sh's and implement own UI/shell for configuration. > >I think 8 and 9 are just consequences of 10. Aye, I realized that as I wrote it, but I felt the need to split them up so they wouldn't be too crowded... Btw, if people want me to, I could write a text file that carries these point and to which we could draft other ideas/goals as to make it publicaly available to allow 'outsiders' to see what we are up to, apart from our secret missions offcourse ;) Imagine the Linux people getting air of the revolution we are planning *G* =) Jeroen Ruigrok van der Werven / Asmodai ICQ-UIN: 1564317 .:. Ninth Circle Enterprises Network/Security Specialist /==|| FreeBSD and picoBSD, the Power to Serve ||==\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message