Date: Tue, 27 Oct 1998 11:05:00 -0800 From: Terry Lambert <terry@whistle.com> To: Andrzej Bialecki <abial@nask.pl> Cc: small@FreeBSD.ORG Subject: Re: Unified Configuration Interface Message-ID: <3636195C.535@whistle.com> References: <Pine.BSF.4.02A.9810271312340.3398-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... transactional, possible to expose via standard protocol ... ] Andrzej Bialecki wrote: > 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). Mine too; I wasn't thinking in terms of a server, necessarily, though, since I could see the following from an embedded system: 1) SLP request: where is the LDAP server? 2) LDAP request: where is my configuration data? 3) <OTHER> request: Please manage me via data changes in the LDAP data store, and tell me when changes have taken place so I can reconfigure myself. That would make it most probably a client implementation only. I mention ACAP because it's a fairly small client implementation as well. The main issue is that there needs to be someone, somewhere, to "be the king"; whether this just means a machine to export an NIS+ service, or whether this means SNMP or LDAP is undefined. [ ... List of ?RFC's specifying MIB's ... ] ] 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... We should make an early distinction here between "schema" and "implementation". A MIB specifies elements and hierarchical relationships between the elements. You don't have to use SNMP to be able to use a MIB. Anything capable of implementing a hierarchy, including a file system, could be used. So could LDAP, ACAP, SNMP, or mySQL. I think the most important part of the process at this point is a definition of schema for the things you want to be able to manage; from personal experience, I have to say that it's always the thing that falls by the wayside that makes the resulting code either not work, or work in some standards non-conformant way that doesn't play well with others. From my poerspective, either one of these would be a loss, and either one of these wold prevent the results from scaling to either clustes of embedded machines, or large FreeBSD (or other) boxes. > > 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. If you need the reference implementation patches after you get the reference implementation (from Sun; the email address is <Charles.Perkins@Eng.Sun.COM>), I can give them to you. The license says: Users may copy or modify Sun Linux SLP without charge, but are not authorized to license or distribute it to anyone else except as part of a product or program developed by the user. I take this to read that if I had a program I could give you, that I could give you the code. I don't, but I believe that Pico/FreeBSD would qualify in terms of being able to give the code out to someone else. > > 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? My current SLAPD (LDAP server) is 160k, linked shared against libc_r and libcrypt, so I think for a static version, the answer is probably "no" (but it could be crunched, and I don't know the impact of libc_r vs. libc on a crunched disk). But the point of mentioning RFC 2307 wasn't to specifically advocate LDAP; it was to point at a MIB that defines most of the things needed for storing all NIS+ data. The MIB is, as above, schema information, totally seperate from implementation. -- Terry Lambert -- Whistle Communications, Inc. -- terry@whistle.com 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?3636195C.535>