Date: Wed, 28 Oct 1998 12:59:42 -0800 (PST) From: Bryan Mann <bmann@whistle.com> To: Andrzej Bialecki <abial@nask.pl> Cc: Terry Lambert <terry@whistle.com>, small@FreeBSD.ORG Subject: Re: Unified Configuration Interface Message-ID: <Pine.BSI.3.95.981028123928.12256B-100000@chaco.whistle.com> In-Reply-To: <Pine.BSF.4.02A.9810271312340.3398-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 Oct 1998, Andrzej Bialecki wrote: > On Mon, 26 Oct 1998, Terry Lambert wrote: > > > Here is my one comment on the management implementation > > technology: > > > > It should be transactional, such that you can engage > > in all-or-nothing commits, doing inter-record field > > validation to deny/allow a commit as a whole, and it > > should be possible to expose via a standard protocol, > > such as LDAP or SNMPv2, and less desirable, ACAP. > > Sounds like a good idea (I mean, the transactional model). Also, I would > stress the word "possible" in the above statement - thus far all > implementations of LDAP or SNMP agents I've seen are heavy-weight (from my > point of view). To pile on ... I agree that there should be a transactional model and stress that there are as yet uninvented protocols that might be light weight enough. The important piece of each of the mentioned protocols that is missing from a management point of view is "realtime" monitoring. Something we've been faced with as time goes by here at Whistle is the need to have UI be capable of monitoring processes in a 'light weight' way. We don't currently have this solved and I consider it an area of research. I'd offer that whatever management implementation freebsd-small use should support this 'monitoring' capability. Yes I know you could use SNMP traps but they're pretty heavy weight if they're happening every second say to show the install progress of new software for example.. [maybe not related but ...] On the implementation side it's pretty simple to have a 'container' for all things that depend on each other and to borrow from object oriented methodology a better way to think about dependencies might be to push that out to the objects themselves. Example: If your web-server daemon needs to know about hostname changes it should register itself as wanting to receive "Hostname changed" events. Rather than the other way around, which is: if I'm managing the hostname let me kill and restart any daemon that might need to make configuration changes based on the new hostname. > > > Here are my comments on the organizational policy: > > > > 1) Do not reinvent the wheel. There are existing MIB > > standards for organization of configuration data; > > leverage them to reduce the size of the task: > > > > RFC 1902, which defines the SMI, the mechanisms > > used for describing and naming objects for > > the purpose of management. > > RFC 2248, the Network Services Monitoring MIB > > RFC 2249, the Mail Monitoring MIB > > RFC 2233, the Interfaces Group MIB using SMIv2 > > RFC 2096, the IP Forwarding Table MIB > > RFC 2047, the Remote Network Monitoring MIB Protocol > > Identifiers > > RFC 2039, the Applicability of Standards Track MIBs > > to Management of World Wide Web Servers > > RFC 2037, the ntity MIB using SMIv2 > > RFC 1749, the Printer MIB > > RFC 1697, the Relational Database Management System > > (RDBMS) Management Information Base (MIB) > > using SMIv2 > > RFC 1696, the Modem Management Information Base (MIB) > > using SMIv2 > > RFC 1612, the DNS Resolver MIB Extensions > > RFC 1611, the DNS Server MIB Extensions > > RFC 1514, the Host Resources MIB > > RFC 1414, the Identification MIB > > RFC 1369, the Implementation Notes and Experience > > for the Internet Ethernet MIB > > RFC 1354, the IP Forwarding Table MIB > > > > In particular, RFC 2248 defines a framework for exposing > > controls for all network aware applications/servers. > > Ugh.. Yeah.... This is pretty extensive list. But you make a good point... > > What worries me, though, is that the only one (free) implementation of > snmp agent that I'm aware of is, well, more than bulky... > Tracking MIBs raises issues of access control lists, security etc. So far LDAP and SNMP v2, v3 seem to be lacking in these areas. > > > > 2) I understand that this is supposed to be "lightweight", > > an thus will most likely contain a subset of the above > > MIB configuration data. > > > > Let me request that if a subset is to be used, that > > it be a true logical subset, i.e., for managed items, > > they must conform to the MIB items, such that a full > > implementation set at some later date for FreeBSD > > proper dill not have a conflicting arrangement for > > the same data. > > That's reasonable. > > > > > 3) If the intent is small, standalone servers/devices > > (one of the stated intents of the freebsd-small list > > is to explore embedded systems, so this is appropriate), > > it is probably worth while to consider an implementation > > of SLP (Service Location Protocol, RFC 2165) for peer > > discovery and integration. > > Thanks for the pointer - I'll look at it. > > > Also, although currently classed "experimental", consideration > > should be given to RFC 2307, An Approach for Using LDAP as a > > Network Information Service, since it addresses most NIS+ > > configuration information, including bootp and machine > > information. > > I'm not familiar with LDAP that much... Is there any implementation of > it which takes less than, say, 200kB? > > Andrzej Bialecki > > -------------------- ++-------++ ------------------------------------- > <abial@nask.pl> ||PicoBSD|| FreeBSD in your pocket? Go and see: > Research & Academic |+-------+| "Small & Embedded FreeBSD" > Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ > -------------------- ~-+==---+-+ ------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-small" in the body of the message > ---------------------------------------------------------------------- Mother is the invention of necessity. (This signature brought to you courtesy of fortune(6) and cron(8).) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.981028123928.12256B-100000>