From owner-freebsd-small Sun Oct 25 19:56:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21254 for freebsd-small-outgoing; Sun, 25 Oct 1998 19:56:10 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from force.stwing.upenn.edu (FORCE.STWING.UPENN.EDU [130.91.120.95]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA21247 for ; Sun, 25 Oct 1998 19:56:08 -0800 (PST) (envelope-from seichert@force.stwing.upenn.edu) Received: from force.stwing.upenn.edu (CHAOS.STWING.UPENN.EDU [130.91.188.193]) by force.stwing.upenn.edu (8.8.8/STWing/8.8.8) with ESMTP id WAA17075 for ; Sun, 25 Oct 1998 22:55:32 -0500 (EST) Message-ID: <3633F2DC.E5E5D5DA@force.stwing.upenn.edu> Date: Mon, 26 Oct 1998 03:56:12 +0000 From: Stuart Eichert Reply-To: Stuart.Eichert.wh99@wharton.upenn.edu Organization: Science and Technology Wing X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i686) MIME-Version: 1.0 To: freebsd-small@FreeBSD.ORG Subject: subscribe Stuart.Eichert.wh99@wharton.upenn.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscribe Stuart.Eichert.wh99@wharton.upenn.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Mon Oct 26 14:34:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA01591 for freebsd-small-outgoing; Mon, 26 Oct 1998 14:34:28 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA01574 for ; Mon, 26 Oct 1998 14:34:24 -0800 (PST) (envelope-from terry@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA11807 for ; Mon, 26 Oct 1998 14:23:31 -0800 (PST) Received: from tlambert.whistle.com(207.76.205.208) via SMTP by alpo.whistle.com, id smtpdJ11786; Mon Oct 26 22:23:23 1998 Message-ID: <3634F5CF.373F@whistle.com> Date: Mon, 26 Oct 1998 14:21:03 -0800 From: Terry Lambert Organization: Whistle Communications X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: small@FreeBSD.ORG Subject: Re: Unified Configuration Interface References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Attached is a draft of the Unified Configuration Interface > project, partialy based on our discussions on freebsd-small. > Please read it, think of it, and make any suggestions you > seem appropriate (I'd prefer you send them to freebsd-small, > instead of only me directly). > > I hope this will help to coordinate our efforts, and give us > some initial framework... I have a number of comments; most of them have to do with organizational policy, and not the particular management implementation technology. 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. 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. 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. 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. FYI: SLP is the basis for peer integration in the SunSoft "JINI" framework. A reference implementation is available on request, and operates on FreeBSD with minor patches to avoid certain Linux'isms. The code is available under Sun public license (standard "hold harmless", NOT GPL). 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. -- 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 From owner-freebsd-small Tue Oct 27 04:20:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA12644 for freebsd-small-outgoing; Tue, 27 Oct 1998 04:20:18 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA12639 for ; Tue, 27 Oct 1998 04:20:16 -0800 (PST) (envelope-from skywise@wxs.nl) Received: from po02.wxs.nl ([195.121.6.41]) by smtp02.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA73C9 for ; Tue, 27 Oct 1998 13:19:37 +0100 Received: from webmail ([195.121.6.34]) by po02.wxs.nl (Netscape Messaging Server 3.54) with SMTP id AAA6667 for ; Tue, 27 Oct 1998 12:19:34 +0000 From: Jeroen Ruigrok/Asmodai To: small@FreeBSD.ORG Subject: Some problems X-Mailer: Netscape Messenger Express 3.5 [Mozilla/4.05 [en] (Win95; I ;Nav)] Date: Tue, 27 Oct 1998 12:19:34 +0000 Message-ID: <7718A0B878E.AAA6667@po02.wxs.nl> Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I would love to comment on yer mails Andrzej and the rest, but at the moment my CURRENT installation has problems executing ppp, keeps giving me these libdes.so.3.0 not found errors. So I am going to /stand/sysinstall the DES distribution tonight and see if that works. I have to say that library linkage/dependency under CURRENT or FreeBSD in general can be a bitch to keep alive when not careful. Any hints or tips are GREATLY appreciated. regards and hopefully mailing my comments soon using XFMail instead of this shitty webbased mailer, Jeroen Ruigrok picoBSD: the power to serve in even the smallest of setups... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Tue Oct 27 04:31:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA13406 for freebsd-small-outgoing; Tue, 27 Oct 1998 04:31:07 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA13400 for ; Tue, 27 Oct 1998 04:31:01 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id NAA22245; Tue, 27 Oct 1998 13:35:57 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Tue, 27 Oct 1998 13:35:56 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Terry Lambert cc: small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: <3634F5CF.373F@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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). > 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... > > 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 -------------------- ++-------++ ------------------------------------- ||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 From owner-freebsd-small Tue Oct 27 11:14:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA15269 for freebsd-small-outgoing; Tue, 27 Oct 1998 11:14:52 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15264 for ; Tue, 27 Oct 1998 11:14:50 -0800 (PST) (envelope-from terry@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA14090; Tue, 27 Oct 1998 11:06:53 -0800 (PST) Received: from tlambert.whistle.com(207.76.205.208) via SMTP by alpo.whistle.com, id smtpdR14088; Tue Oct 27 19:06:52 1998 Message-ID: <3636195C.535@whistle.com> Date: Tue, 27 Oct 1998 11:05:00 -0800 From: Terry Lambert Organization: Whistle Communications X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Andrzej Bialecki CC: small@FreeBSD.ORG Subject: Re: Unified Configuration Interface References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ ... 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) 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 ), 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 From owner-freebsd-small Wed Oct 28 03:18:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA17995 for freebsd-small-outgoing; Wed, 28 Oct 1998 03:18:29 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA17990 for ; Wed, 28 Oct 1998 03:18:27 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.58.14]) by smtp01.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA6A82; Wed, 28 Oct 1998 12:17:46 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3636195C.535@whistle.com> Date: Wed, 28 Oct 1998 12:21:23 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Terry Lambert Subject: Re: Unified Configuration Interface Cc: small@FreeBSD.ORG, Andrzej Bialecki Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Oct-98 Terry Lambert wrote: > [ ... 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) 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. Have to read up on SLP, but afaik SLP will be/is used by Novell in NetWare 5 with Native IP to replace SAP. So if I may base my conclusions on SAP, it will request per a broadcast certain servers/services, get a reply back and then use those services via SLP or just by making TCP connections or just dumping UDP datagrams? Correct me if I am wrong, but I don't have the time at the moment to dig through that RFC. > That would make it most probably a client implementation only. > I mention ACAP because it's a fairly small client implementation > as well. Having used ACAP I can say it's a fun protocol ;) > 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. Well, ye mean here the MAster server that is the general backup provider shouldst departemental/floor servers not be reachable? Or am I thinking in way the wrong direction? > [ ... 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... Ok, but basing on the equipment we use at work (HP OpenView) I tend to prefer SNMP in use with MIBs. Although we also write out own shellscripts for that. >> 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). As far as I can see in future, we are going to have to make major modifications to kernel sources and the likes... > 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. Heh, schema sounds so alike to Novell's NDS schema ;) --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Wed Oct 28 08:00:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA13438 for freebsd-small-outgoing; Wed, 28 Oct 1998 08:00:09 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA13376 for ; Wed, 28 Oct 1998 08:00:00 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id RAA07672; Wed, 28 Oct 1998 17:05:06 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Wed, 28 Oct 1998 17:05:05 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Terry Lambert cc: small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: <3636195C.535@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-390227750-909590705=:6616" Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-390227750-909590705=:6616 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Ok, your remarks convinced me that the document I sent needed a lot of clarification. So, here's the corrected version. How about that? Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- --0-390227750-909590705=:6616 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="UCI.html" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="UCI.html" PGh0bWw+DQo8ISAkSWQkID4NCjxib2R5Pg0KPGgxPjxjZW50ZXI+CQlVbmlm aWVkIENvbmZpZ3VyYXRpb24gSW50ZXJmYWNlIFByb2plY3QNCjwvY2VudGVy PjwvaDE+DQoNCjxwPiBIZXJlJ3MgYSBwcmVsaW1pbmFyeSBhdHRlbXB0IHRv IG9yZ2FuaXplIGFsbCAod2VsbCwgbW9zdCkNCmNvbmZpZ3VyYXRpb24gdGFz a3MgYW5kIHBhcmFtZXRlcnMgb2YgUGljb0JTRCBzeXN0ZW0gaW4gaGllcmFy Y2h5DQpvZiBjYXRlZ29yaWVzLiA8L3A+DQoNCjxwPiBUaGlzIGZvcm1zIGEg c29ydCBvZiBmcmFtZXdvcmssIGJhc2luZyBvbiB3aGljaCBvbmUgY2FuIGlt cGxlbWVudA0KY29uc2lzdGVudCBjb25maWd1cmF0aW9uIGZpbGUocyksIGFu ZCBjb25maWd1cmF0aW9uIHV0aWxpdGllcy4gPC9wPg0KDQo8cD4gSG93ZXZl ciwgdGhlIGlkZWEgYmVoaW5kIHRoaXMgcHJvamVjdCBpcyB0byBjb21wbGV0 ZWx5IHJlcGxhY2UgY3VycmVudGx5DQp1c2VkIGNvbmZpZ3VyYXRpb24gYXBw cm9hY2gsIHdoaWNoIGlzIGJhc2VkIG9uIHNldmVyYWwgc2hlbGwgc2NyaXB0 cywgYW5kIHRvDQpwcm92aWRlIGFiaWxpdHkgdG8gY2hhbmdlIHN5c3RlbSBi ZWhhdmlvdXIgYmFzaW5nIG9uIHNldCBvZiB3ZWxsLWRlZmluZWQNCnBhcmFt ZXRlcnMnIGhpZXJhcmNoeS4gVGhpcyBhcHByb2FjaCBtYWtlcyBpdCByZWxh dGl2ZWx5IGVhc3kgdG8gd3JpdGUNCmNvbnNpc3RlbnQgdXNlciBpbnRlcmZh Y2VzLCBlaXRoZXIgY29tbWFuZC1saW5lIG9yIHdpdGggR1VJIGZyb250LWVu ZHMuPC9wPg0KDQo8cD4gQWxsIGl0ZW1zIGFyZSBncm91cGVkIGludG8gc3Vi LWNhdGVnb3JpZXMuIEVhY2ggaXRlbSBpcyBzaG9ydGx5DQpkZXNjcmliZWQs IGFuZCBpdHMgZGVwZW5kZW5jaWVzIGFyZSBsaXN0ZWQuIFBlcmhhcHMgZWFj aCBpdGVtIHNob3VsZA0KaGF2ZSBhIHVuaXF1ZSBudW1iZXIsIHdoaWNoIGRl c2lnbmF0ZXMgb3JkZXIgaW4gd2hpY2ggZ2l2ZW4NCmNvbmZpZ3VyYXRpb24g dGFzayBpcyBwZXJmb3JtZWQgb24gc3RhcnR1cC4uLiBPciwgdGhlIHN5c3Rl bSBzdGFydHVwDQpyb3V0aW5lcyBzaG91bGQgdW53aW5kIGRlcGVuZGVuY2ll cyBpbnRvIGxpbmVhciwgb3JkZXJlZCBsaXN0LiA8L3A+DQoNCjxwPjxpPjxi PlRoaXMgaXMgd29yayBpbiBwcm9ncmVzczwvYj4gLSBJJ20gYXdhcmUgdGhh dCBtYW55IHBpZWNlcw0KYXJlIGVpdGhlciBjb21wbGV0ZWx5IG1pc3Npbmcg b3IgbWlzcGxhY2VkLiBQbGVhc2Ugc2VuZCBhbnkgY29tbWVudHMgYW5kDQpj aGFuZ2VzIHlvdSBzZWVtIGFwcHJvcHJpYXRlIGVpdGhlciBkaXJlY3RseSB0 byBtZSwgb3IgYmV0dGVyIHRvDQpmcmVlYnNkLXNtYWxsQGZyZWVic2Qub3Jn LiBJJ2xsIGdsYWRseSB3ZWxjb21lIGFueW9uZSB3aG8gY2FuIGhlbHAgd2l0 aA0KZGVzaWduIGFuZC9vciBpbXBsZW1lbnRhdGlvbi48L2k+PC9wPg0KDQoN Cjxocj4NCg0KPGgxPjxjZW50ZXI+CQlVbmlmaWVkIENvbmZpZ3VyYXRpb24g SGllcmFyY2h5IChwcm9wb3NhbCkNCjwvY2VudGVyPjwvaDE+DQoNCjx1bD4N CjxsaT4NCjxwPkxldCdzIGZpcnN0IGludHJvZHVjZSBkaXN0aW5jdGlvbiBi ZXR3ZWVuIHRoZSBmb2xsb3dpbmcgdGVybXM6DQo8dWw+DQo8bGk+DQo8Yj5t YW5hZ2VtZW50IGJhc2U8L2I+IC0gdGhlIGFjdHVhbCBzdHJ1Y3R1cmUgaG9s ZGluZyBjb25maWd1cmF0aW9uIGFuZA0KaW5mb3JtYXRpb24gZGF0YSBhY2Nv cmRpbmcgdG8gZGVmaW5lZCBzdHJ1Y3R1cmUuIFRoaXMgc3RydWN0dXJlIHdp bGwgbW9zdA0KcHJvYmFibHkgaGF2ZSBhIGZvcm0gb2YgdHJlZSAocG9zc2li bHkgd2l0aCBjcm9zcy1icmFuY2ggbGlua3Mgb3Igc29tZSBvdGhlcg0KbWVj aGFuaXNtIHJlcHJlc2VudGluZyBtdXR1YWwgZGVwZW5kZW5jaWVzKSAtIHRo ZSB3YXkgaXQncyBzdG9yZWQgaXMgYWxzbw0Kc29tZXRoaW5nIHdoaWNoIG5l ZWRzIHRvIGJlIGRpc2N1c3NlZC4NCjwvbGk+DQo8bGk+DQo8Yj51c2VyIGlu dGVyZmFjZTwvYj4gLSBhIG1ldGhvZCAoYW5kIGFnZW50KSBmb3IgcHJlc2Vu dGluZyBkYXRhIHN0b3JlZCBpbg0KbWFuYWdlbWVudCBiYXNlIGluIHN1Y2gg YSB3YXkgdGhhdCBpdCBjYW4gYmUgdmlld2VkIGFuZCBtb2RpZmllZCBieQ0K bGVnaXRpbWF0ZSB1c2Vycy4NCjwvbGk+DQo8bGk+DQo8Yj5jb25maWd1cmF0 aW9uIGFnZW50PC9iPiAtIGFuIGVudGl0eSBwZXJmb3JtaW5nIGFjdHVhbCBj b25maWd1cmF0aW9uDQp0YXNrcywgZnJvbSBvbmUgc2lkZSBkZWFsaW5nIHdp dGggbWFuYWdlbWVudCBiYXNlLCBhbmQgZnJvbSB0aGUgb3RoZXINCmRlYWxp bmcgd2l0aCB0aGUgc3lzdGVtIHJlc291cmNlcywgYW5kIGZyb20geWV0IGFu b3RoZXIgZGVhbGluZyBlaXRoZXINCmRpcmVjdGx5IHdpdGggdGhlIHVzZXIg KHRodXMgYWN0aW5nIGFzIGEgdXNlciBpbnRlcmZhY2UpLA0Kb3IgcGFzc2lu ZyByZXF1ZXN0cyB0byBvdGhlciBlbnRpdHkgd2hpY2ggYWN0cyBhcyB1c2Vy IGludGVyZmFjZS4NCjwvbGk+DQo8L3VsPg0KPC9saT4NCjxsaT4NCjxwPk9u ZSBwb3NzaWJsZSBhcHByb2FjaCB0byBzdG9yaW5nIHRoZSBtYW5hZ2VtZW50 IGRhdGEgaXMgdG8gdXNlIGFscmVhZHkNCmV4aXN0aW5nIGZyYW1ld29yayBr bm93biBhcyBNSUIsIGFzIGRlZmluZWQgaW4gYXBwbGljYWJsZSBSRkNzLjwv cD4NCg0KPHA+VGhpcyBhcHByb2FjaCBoYXMgc2V2ZXJhbCBhZHZhbnRhZ2Vz OiBpdCByZXByZXNlbnRzIHdlbGwgdGhvdWdodC1vdXQgd29yaw0Kb2YgbWFu eSBleHBlcmllbmNlZCBpbmRpdmlkdWFscyBhbmQgdGVhbXMsIGl0IGhhcyBh bHJlYWR5IHByb3ZlbiB0byBiZQ0KdXNlZnVsLCBpdCdzIHdpZGVseSB1c2Vk IGFuZCBhY2NlcHRlZCwgaXQncyBlYXNpbHkgZXh0ZW5zaWJsZSwgaXQncyBh YmxlIHRvDQpyZXByZXNlbnQgcXVpdGUgY29tcGxpY2F0ZWQgb2JqZWN0cywg ZXRjLjwvcD4NCg0KPHA+SXQgaGFzIHNvbWUgZHJhd2JhY2tzLCBhcyB3ZWxs OiBlLmcuIHRoZXJlIGlzIG5vIHN0YW5kYXJkIG1lY2hhbmlzbSBmb3INCnJl cHJlc2VudGluZyBldmVudHMgYW5kIGluZGlyZWN0bHkgcmVsYXRlZCBvYmpl Y3RzLCBpdCB0ZW5kcyB0byBjcmVhdGUNCmRlZXAgYW5kIG5hcnJvdyB0cmVl cyB3aGljaCByZXF1aXJlIHRvIGRlc2NlbnQgc2V2ZXJhbCBsZXZlbHMgdG8g Y2hhbmdlIHNvbWUNCmNvbW1vbmx5IHVzZWQgcGFyYW1ldGVycywgaXQgZG9l c24ndCBzYXkgYW55dGhpbmcgYWJvdXQgdGhlIG11dHVhbA0KZGVwZW5kZW5j aWVzIGJldHdlZW4gb2JqZWN0cyBhbmQgcGFyYW1ldGVycyAoZXhjZXB0IHBh cmVudC1jaGlsZC1zaWJsaW5nKSwNCmFuZCBhYm91dCByZXF1aXJlZCBzZXF1 ZW5jZSB0byBwcm9wZXJseSBzZXQgdGhlaXIgcGFyYW1ldGVycywgZXRjLjwv cD4NCg0KPHA+VGhlc2UgaXNzdWVzIGFyZSBub3QgZGlyZWN0bHkgYWRkcmVz c2VkIGluIHN0YW5kYXJkcywgYW5kIHJlYWwNCmltcGxlbWVudGF0aW9ucyAo a25vd24gdG8gbWUpIGhhdmUgdG8gaW1wbGVtZW50IHRoZXNlIGFkZGl0aW9u YWwgbWVjaGFuaXNtcw0KImJlaGluZCB0aGUgc2NlbmVzIiwgc28gdGhhdCB0 aGVpciB3b3JraW5ncyBhcmUgbm90IG9idmlvdXMgbm9yIGVhc2lseQ0KYWNj ZXNzaWJsZSAobGV0IGFsb25lIGNoYW5nZWFibGUpLjwvcD4NCg0KPHA+U28s IGlmIHdlIGRlY2lkZSB0byB1c2UgaXQsIHdlIG5lZWQgdG8gYWRkcmVzcyB0 aGVzZSBpc3N1ZXMgc29tZWhvdy48L3A+DQo8L2xpPg0KPGxpPg0KPHA+QWN0 dWFsIHVzZXIgaW50ZXJmYWNlIGlzIHN0aWxsIHF1aXRlIGFub3RoZXIgc3Rv cnk6IEkndmUgc2VlbiBVSXMgd2hpY2gNCm1lcmVseSBmb2xsb3dlZCB0aGUg c3RhbmRhcmQgTUlCcywgYW5kIG1lbnVzIHdlcmUgY29tcG9zZWQgb2YgYWN0 dWFsIE9JRA0KbnVtYmVycyBwbHVzIERFU0NSSVBUSU9OIGZpZWxkLiBJbiBt eSBleHBlcmllbmNlLCB0aGV5IGFyZSAoYmFyZWx5KQ0KYWNjZXB0YWJsZSwg dGhvdWdoIGR1ZSB0byB0aGUgdXN1YWwgd2lkdGggYW5kIGRlcHRoIG9mIE1J QiB0cmVlcyB5b3UgaGFkIHRvDQp0cmF2ZXJzZSBzZXZlcmFsIGxldmVscyBk b3duIGFuZCB1cCBpbiBvcmRlciB0byBjaGFuZ2Ugc29tZSAocHJvdG9jb2wt d2lzZSkNCnJlbGF0ZWQgcGFyYW1ldGVycy48L3A+DQoNCjxwPk1vcmUgYWNj ZXB0YWJsZSBVSSB3b3VsZCBjb2xsZWN0IGludGVycmVsYXRlZCBpdGVtcyB1 bmRlciBjb21tb24gbWVudQ0KZW50cmllcywgaXJyZXNwZWN0aWJseSBvZiB0 aGVpciBhY3R1YWwgcG9zaXRpb24gaW4gdGhlIE1JQiB0cmVlLjwvcD4NCg0K PHA+QSB3b3J0aHdoaWxlIGdvYWwgdG8gcHVyc3VlIGlzIHRvIGNyZWF0ZSBz dWNoIGFuIFVJIHdoaWNoIGNvdWxkIGd1aWRlDQp5b3UgdGhyb3VnaCB0aGUg bW9zdCBjb21tb24gY29uZmlndXJhdGlvbiB0YXNrcywgd2hpbGUgYXQgdGhl IHNhbWUgdGltZQ0KYWxsb3dpbmcgZm9yIHVucmVzdHJpY3RlZCBhbmQgcXVp Y2sgdXNlIGJ5IHBvd2VyIHVzZXJzLiBUaGlzIGNhbiBiZSBkb25lDQplaXRo ZXIgYXMgYSBzZXQgb2YgY29uZmlndXJhdGlvbiAid2l6YXJkcyIgb3IgZXh0 ZW5zaXZlIGhpbnRpbmcsIGNvbW1hbmQNCmNvbXBsZXRpb24sIGV0Yy48L3A+ DQo8L2xpPg0KPGxpPg0KPHA+VGhlIG1hbmFnZW1lbnQgZGF0YWJhc2Ugc2hv dWxkIGJlIGVhc2lseSBleHBvcnRhYmxlIHZpYSBzdGFuZGFyZA0KcHJvdG9j b2xzLCBzdWNoIGFzIFNOTVAgb3IgTERBUC48L3A+DQoNCjxwPk1vc3Qga25v d24gdG8gbWUgKGlmIG5vdCBhbGwpIGltcGxlbWVudGF0aW9ucyBvZiBhZ2Vu dHMgZm9yIHRoZXNlDQpwcm90b2NvbHMgYXJlIChjb250cmFyeSB0byB0aGVp ciBuYW1lKSBxdWl0ZSBoZWF2eS13ZWlnaHQgLSBzbyB0aGVpciB1c2UNCnNo b3VsZCBiZSBlaXRoZXIgb3B0aW9uYWwsIG9yIHJlcGxhY2VkIHdpdGggc29t ZSBvdGhlciBsaWdodC13ZWlnaHQNCnByb3RvY29sIGFuZCBhIHByb3h5IGFn ZW50IHJ1bm5pbmcgb24gb3RoZXIgbWFjaGluZS48L3A+DQoNCjxwPkl0J3Mg d29ydGh3aGlsZSB0byBjb25zaWRlciBhbHNvIHVzZSBvZiBvdGhlciBwcm90 b2NvbHMgc3VjaCBhcw0KREhDUCAoYW5kIEJPT1RQKSwgU2VydmljZSBMb2Nh dGlvbiBQcm90b2NvbCAoU0xQIC0gUkZDMjE2NSkgZm9yIGVhc3kNCmludGVn cmF0aW9uIHdpdGggTEFOIHJlc291cmNlcywgZWFzeSBpbml0aWFsIGNvbmZp Z3VyYXRpb24sIGFuZCBwZWVyDQpkaXNjb3ZlcnkuPC9wPg0KPC9saT4NCjxs aT4NCjxwPkFsbCBvcGVyYXRpb25zIHBlcmZvcm1lZCBieSBjb25maWd1cmF0 aW9uIGFnZW50IHNob3VsZCBiZSB0cmFuc2FjdGlvbmFsLA0KaS5lLiBpdCBz aG91bGQgYmUgcG9zc2libGUgdG8gY29tbWl0IGEgc2V0IG9mIGNoYW5nZXMg YXMgb25lIGxvZ2ljYWwgZW50aXR5LA0KYW5kIGJlIHN1cmUgdGhhdCBlaXRo ZXIgaXQncyBhcHBsaWVkIGluIHdob2xlLCBvciBub3QgYXQgYWxsLiBUaGlz IGluY2x1ZGVzDQphbHNvIGFiaWxpdHkgdG8gYWJvcnQgcHJvY2Vzc2luZyBp biB0aGUgbWlkZGxlLjwvcD4NCg0KPHA+T3BlcmF0aW9ucyBzaG91bGQgYmUg dmVyaWZpZWQgYWdhaW5zdCBhbGxvd2VkIHZhbHVlcywgYXMgd2VsbCBhcyBh Z2FpbnN0DQphbGxvd2VkIGNyZWRlbnRpYWxzLCBhbmQgYmFzaW5nIG9uIHRo aXMgZWl0aGVyIGNvbW1pdHRlZCBvciBhYm9ydGVkLjwvcD4NCjwvbGk+DQo8 bGk+DQo8cD5BIGZldyBub3RlcyBvbiBwb3NzaWJsZSBpbXBsZW1lbnRhdGlv biBvZiBjb25maWd1cmF0aW9uIGFnZW50OjwvcD4NCjx1bD4NCjxsaT4NCmxl dCdzIGFzc3VtZSB0aGF0IGFsbCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9u IGlzIHJlYWQgb24gc3RhcnR1cA0KYnkgc29tZSBzcGVjaWFsaXplZCBkYWVt b24gKHRoaXMgY2FuIGJlIHBhcnQgb2YgaW5pdCg4KSBhcyB3ZWxsKSwNCndo aWNoIHRoZW4gcGVyZm9ybXMgcm9sZSBvZiBjb21tdW5pY2F0aW9uIGFnZW50 IHRocm91Z2ggd2hpY2ggcGFzc2VzDQphbGwgY29uZmlndXJhdGlvbiBpbmZv cm1hdGlvbiwgYmUgaXQgcmVxdWVzdCBmb3IgY2hhbmdlLCByZXF1ZXN0DQpm b3IgaW5mbywgcmVxdWVzdCBmb3Igc3RhcnQgLyBzaHV0ZG93biwgb3Igbm90 aWZpY2F0aW9uIGFib3V0IHRoZSBjaGFuZ2UuDQo8L2xpPg0KPGxpPg0KY29u ZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBpdHNlbGYgaXMgc3RvcmVkIGVpdGhl ciBpbiBiaW5hcnkgZGF0YWJhc2UsIG9yIGFzDQphIGZpbGVzeXN0ZW0gaGll cmFjaHkgbWltaWNraW5nIGNvbmZpZ3VyYXRpb24gaXRlbXMgaGllcmFyY2h5 Lg0KPC9saT4NCjxsaT4NCmVhY2ggdXNlci1sZXZlbCBwcm9ncmFtIHBlcmZv cm1pbmcgc29tZSB0YXNrIChzdWNoIGFzIHJvdXRpbmcgZGFlbW9uLCBpbmV0 ZA0KZXRjKSBpcyBlaXRoZXIgZXF1aXBwZWQgd2l0aCB0aGUgYWJpbGl0eSB0 byBjb21tdW5pY2F0ZSB3aXRoIGNvbmZpZyBhZ2VudCwgb3INCmlzIHJlbGlu a2VkIHdpdGggc3BlY2lhbCBzdHViIHdoaWNoIGZha2VzIHRvIHRoZSBwcm9n cmFtIG5lY2Vzc2FyeSBjb25maWcNCmZpbGVzIGFuZCBldmVudHMgKHN1Y2gg YXMgc2lnbmFscyB0byByZXJlYWQgY29uZmlndXJhdGlvbikuDQo8cD5UaGlz IHByb2JhYmx5IG1lYW5zIGFsc28gdGhhdCBzb21lIGxpYmMgcm91dGluZXMg d291bGQgaGF2ZSB0byBiZSByZXBsYWNlZCwNCmJlY2F1c2UgdGhleSBhc3N1 bWUgcmVhZGluZyBjb25maWd1cmF0aW9uIGZyb20gY2VydGFpbiBkaXNrIGZp bGVzLjwvcD4NCjwvbGk+DQo8bGk+DQplYWNoIHVzZXItbGV2ZWwgcHJvZ3Jh bSBwZXJmb3JtaW5nIHNvbWUgdGFzayByZXF1ZXN0cyBpdHMgaW5pdGlhbCBj b25maWcgZGF0YQ0KZnJvbSBjb25maWcgYWdlbnQsIGF0IHRoZSBzYW1lIHRp bWUgcmVnaXN0ZXJpbmcgd2l0aCBpdCB0byByZWNlaXZlDQpjb25maWd1cmF0 aW9uIGV2ZW50cywgc3VjaCBhcyByZXF1ZXN0IHRvIHJlLXJlYWQgZGF0YSwg dG8gcHJvdmlkZSBjdXJyZW50bHkNCnVzZWQgY29uZmlnIGRhdGEsIHJldHVy biBzdGF0dXMsIHJlYWN0IGZvciBzaWduYWxzLCByZXN0YXJ0cywgZXRjLi4u DQo8L2xpPg0KPGxpPg0KdXNlciBpbnRlcmZhY2UgaXMgdGhlbiBqdXN0IG9u ZSBvZiBjbGllbnRzIG9mIGNvbmZpZyBhZ2VudCwgYWxiZWl0IHBvc3Nlc3Np bmcNCnNwZWNpYWwgcHJpdmlsZWdlcy4NCjwvbGk+DQo8L3VsPg0KPC9saT4N CjwvdWw+DQoNCjxocj4NCg0KPHA+SGVyZSBpcyBteSBpbml0aWFsIHByb3Bv c2FsLCB3aGljaCBwZXJoYXBzIGNhbiBiZSB1c2VkIGFzIGEgbW9kZWwgZm9y DQp1c2VyIGludGVyZmFjZSBoaWVyYXJjaHksIGlmIG5vdCBmb3IgdGhlIG1h bmFnZW1lbnQgYmFzZSBpdHNlbGYuPC9wPg0KDQo8dWw+DQo8bGk+DQpTeXN0 ZW0gY29uZmlndXJhdGlvbi4NCgk8b2w+DQoJPGxpPg0KCUJvb3QgZGV2aWNl IGFuZCBmaWxlIDxicj4NCgk8c21hbGw+TmFtZSBvZiB0aGUgYm9vdCBkZXZp Y2UgKHBvc3NpYmx5IG5ldHdvcmtlZCkgYW5kIGJvb3QNCglpbWFnZS48L3Nt YWxsPg0KCQk8b2w+DQoJCTxsaT4NCgkJKEVudW1lcmF0aW9uIG9mIGF2YWls YWJsZSBkZXZpY2VzKQ0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJKEVudW1lcmF0 aW9uIG9mIGF2YWlsYWJsZSBmaWxlcykNCgkJCTwvbGk+DQoJCQk8L29sPg0K CQk8L2xpPg0KCQk8L29sPg0KCTwvbGk+DQoJPGxpPg0KCUNvbmZpZyBmaWxl IDxicj4NCgk8c21hbGw+Q29uZmlndXJhdGlvbiBmaWxlIG1hbmFnZW1lbnQg LSBsb2FkaW5nIGFuZCBzYXZpbmcsIGVpdGhlcg0KCWxvY2FsIG9yIHJlbW90 ZSAoaWYgYXBwbGljYWJsZSkuIDwvc21hbGw+DQoJCTxvbD4NCgkJPGxpPg0K CQlMb2FkIC8gU2F2ZQ0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJU291cmNlIC8g RGVzdGluYXRpb24gPGJyPg0KCQkJKEVudW1lcmF0aW9uIG9mIGF2YWlsYWJs ZSBzdG9yYWdlIHBsYWNlcywgcG9zc2libHkNCgkJCW5ldHdvcmtlZCkNCgkJ CTwvbGk+DQoJCQk8L29sPg0KCQk8L2xpPg0KCQk8bGk+DQoJCUVkaXQgZGly ZWN0bHkgKGdlZWsgbW9kZSkNCgkJPC9saT4NCgkJPC9vbD4NCgk8L2xpPg0K CTxsaT4NCglMb2FkYWJsZSBtb2R1bGVzIDxicj4NCgk8c21hbGw+T3B0aW9u YWwgaGFyZHdhcmUsIHNlcnZpY2VzIGFuZCBwcm90b2NvbCBtb2R1bGVzIG1h bmFnZW1lbnQuDQoJPC9zbWFsbD4NCgkJPG9sPg0KCQk8bGk+DQoJCShFbnVt ZXJhdGlvbiBvZiBhdmFpbGFibGUgbG9hZGFibGUgbW9kdWxlcykNCgkJCTxv bD4NCgkJCTxsaT4NCgkJCUxvYWQgLyB1bmxvYWQgLyBzdGF0dXMNCgkJCTwv bGk+DQoJCQk8L29sPg0KCQk8L2xpPg0KCQk8L29sPg0KCTwvbGk+DQoJPGxp Pg0KCVJlc291cmNlIG1hbmFnZW1lbnQNCgkJPG9sPg0KCQk8bGk+DQoJCU1l bW9yeSBjb25zdW1wdGlvbg0KCQk8L2xpPg0KCQk8bGk+DQoJCVRhc2sgcHJp b3JpdGllcw0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJTGlzdCAvIE1vZGlmeQ0K CQkJPC9saT4NCgkJCTwvb2w+DQoJCTwvbGk+DQoJCTwvb2w+DQoJPC9saT4N Cgk8bGk+DQoJU3lzdGVtIGNvbnNvbGUNCgk8L2xpPg0KCTxsaT4NCglWaXJ0 dWFsIGNvbnNvbGVzIChpZiBhcHBsaWNhYmxlKQ0KCTwvbGk+DQoJPGxpPg0K CVN5c3RlbSBEYXRlIC8gVGltZSBab25lDQoJPC9saT4NCgk8bGk+DQoJQmFu bmVyDQoJPC9saT4NCgk8bGk+DQoJTG9nZ2luZw0KCQk8b2w+DQoJCTxsaT4N CgkJTG9jYWwgbG9nZ2luZw0KCQk8L2xpPg0KCQk8bGk+DQoJCVJlbW90ZSBs b2dnaW5nDQoJCTwvbGk+DQoJCTwvb2w+DQoJPC9saT4NCgk8L29sPg0KPC9s aT4NCjxsaT4NCk5ldHdvcmsgY29uZmlndXJhdGlvbi4NCgk8b2w+DQoJPGxp Pg0KCUhvc3RuYW1lIGFuZCBEb21haW4NCgk8L2xpPg0KCTxsaT4NCglJbnRl cmZhY2VzDQoJCTxvbD4NCgkJPGxpPg0KCQkoRW51bWVyYXRpb24gb2YgcGh5 c2ljYWwgaW50ZXJmYWNlcykgPGJyPg0KCQkoRW51bWVyYXRpb24gb2Ygdmly dHVhbCBpbnRlcmZhY2VzLCBpZiBhcHBsaWNhYmxlKQ0KCQkoT3B0aW9ucyBm b3IgY3JlYXRpbmcgdmlydHVhbCBpbnRlcmZhY2VzLCBpZiBhcHBsaWNhYmxl KQ0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJSW50ZXJmYWNlIG9wdGlvbnMgKHNw ZWVkLCBtZWRpYSwgZW5jYXBzdWxhdGlvbiwNCgkJCWRlc2NyaXB0aW9uLCBl dGMuKQ0KCQkJPC9saT4NCgkJCTxsaT4NCgkJCUFSUA0KCQkJPC9saT4NCgkJ CTxsaT4NCgkJCUJyaWRnaW5nDQoJCQk8L2xpPg0KCQkJPGxpPg0KCQkJSVAN CgkJCQk8b2w+DQoJCQkJPGxpPg0KCQkJCUFkcmVzcyAvIG5ldG1hc2sgLyBh bGlhcw0KCQkJCTwvbGk+DQoJCQkJPC9vbD4NCgkJCTwvbGk+DQoJCQk8bGk+ DQoJCQlJUFgNCgkJCTwvbGk+DQoJCQk8bGk+DQoJCQlBcHBsZVRhbGsNCgkJ CTwvbGk+DQoJCQk8L29sPg0KCQk8L2xpPg0KCQk8L29sPg0KCTwvbGk+DQoJ PGxpPg0KCVByb3RvY29sIE9wdGlvbnMNCgkJPG9sPg0KCQk8bGk+DQoJCUlQ LCBVRFAsIFRDUCwgQVJQLCBJUFgsIEFUTSAuLi4gPGJyPg0KCQkoRW51bWVy YXRpb24gb2YgYXZhaWxhYmxlIHByb3RvY29scykNCgkJCTxvbD4NCgkJCTxs aT4NCgkJCShFbnVtZXJhdGlvbiBvZiBwcm90b2NvbCBzcGVjaWZpYyBvcHRp b25zLCBzdWNoIGFzDQoJCQlidWZmZXIgc2l6ZXMsIGFsZ29yaXRobXMsIEFS UCB0YWJsZXMgZXRjKQ0KCQkJCTxvbD4NCgkJCQk8bGk+DQoJCQkJTGlzdCAv IEFkZCAvIERlbGV0ZSAvIE1vZGlmeSAvIFNldCAod2hlcmUNCgkJCQlhcHBs aWNhYmxlKQ0KCQkJCTwvbGk+DQoJCQkJPC9vbD4NCgkJCTwvbGk+DQoJCQk8 L29sPg0KCQk8L2xpPg0KCQk8L29sPg0KCTwvbGk+DQoJPGxpPg0KCVJvdXRl cw0KCQk8b2w+DQoJCTxsaT4NCgkJTGlzdA0KCQk8L2xpPg0KCQk8bGk+DQoJ CVN0YXRpYw0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJQWRkIC8gRGVsZXRlIC8g TGlzdA0KCQkJCTxvbD4NCgkJCQk8bGk+DQoJCQkJKHJvdXRlIGV4cHJlc3Np b24pDQoJCQkJPC9saT4NCgkJCQk8L29sPg0KCQkJPC9saT4NCgkJCTwvb2w+ DQoJCTwvbGk+DQoJCTxsaT4NCgkJT1NQRg0KCQk8L2xpPg0KCQk8L29sPg0K CTwvbGk+DQoJPGxpPg0KCU5ldHdvcmsgc2VydmljZXMNCgkJPG9sPg0KCQk8 bGk+DQoJCUROUw0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJSG9zdHMNCgkJCQk8 b2w+DQoJCQkJPGxpPg0KCQkJCUFkZCAvIERlbGV0ZSAvIExpc3QNCgkJCQkJ PG9sPg0KCQkJCQk8bGk+DQoJCQkJCShob3N0cyBkZWZpbml0aW9ucykNCgkJ CQkJPC9saT4NCgkJCQkJPC9vbD4NCgkJCQk8L2xpPg0KCQkJCTwvb2w+DQoJ CQk8L2xpPg0KCQkJPGxpPg0KCQkJUmVzb2x2ZXJzDQoJCQkJPG9sPg0KCQkJ CTxsaT4NCgkJCQlBZGQgLyBEZWxldGUgLyBMaXN0DQoJCQkJCTxvbD4NCgkJ CQkJPGxpPg0KCQkJCQkoaG9zdHMgYWRkcmVzc2VzKQ0KCQkJCQk8L2xpPg0K CQkJCQk8L29sPg0KCQkJCTwvbGk+DQoJCQkJPC9vbD4NCgkJCTwvbGk+DQoJ CQk8bGk+DQoJCQlMb2NhbCBETlMgc2VydmVyIGNvbmZpZw0KCQkJPC9saT4N CgkJCTwvb2w+DQoJCTwvbGk+DQoJCTxsaT4NCgkJUFBQDQoJCQk8b2w+DQoJ CQk8bGk+DQoJCQlTZXJ2ZXINCgkJCTwvbGk+DQoJCQk8bGk+DQoJCQlDbGll bnQNCgkJCTwvbGk+DQoJCQk8L29sPg0KCQk8L2xpPg0KCQk8bGk+DQoJCU5G Uw0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJU2VydmVyDQoJCQk8L2xpPg0KCQkJ PGxpPg0KCQkJQ2xpZW50DQoJCQk8L2xpPg0KCQkJPC9vbD4NCgkJPC9saT4N CgkJPGxpPg0KCQlOSVMNCgkJPC9saT4NCgkJPGxpPg0KCQlESENQDQoJCTwv bGk+DQoJCTxsaT4NCgkJU05NUA0KCQk8L2xpPg0KCQk8bGk+DQoJCVByaW50 aW5nDQoJCQk8b2w+DQoJCQk8bGk+DQoJCQlMb2NhbCAvIFJlbW90ZQ0KCQkJ PC9saT4NCgkJCTwvb2w+DQoJCTwvbGk+DQoJCTxsaT4NCgkJU01CIHNlcnZp Y2VzDQoJCTwvbGk+DQoJCTxsaT4NCgkJTmV0d29yayBBZGRyZXNzIFRyYW5z bGF0aW9uDQoJCTwvbGk+DQoJCTxsaT4NCgkJUGFja2V0IGZpbHRlcnMNCgkJ PC9saT4NCgkJPGxpPg0KCQlCYW5kd2lkdGggTWFuYWdlcg0KCQk8L2xpPg0K CQk8bGk+DQoJCU5UUA0KCQk8L2xpPg0KCQk8bGk+DQoJCVJlbW90ZSBBY2Nl c3MNCgkJPC9saT4NCgkJPC9vbD4NCgk8L2xpPg0KCTwvb2w+DQo8bGk+DQpV c2VyIG1hbmFnZW1lbnQuDQoJPG9sPg0KCTxsaT4NCglVc2VyIGFjY291bnRz DQoJCTxvbD4NCgkJPGxpPg0KCQlBZGQgLyBEZWxldGUgLyBNb2RpZnkgLyBM aXN0DQoJCQk8b2w+DQoJCQk8bGk+DQoJCQlOYW1lIC8gUGFzc3dvcmQgLyBB Q0wNCgkJCTwvbGk+DQoJCQk8L29sPg0KCQk8L2xpPg0KCQk8L29sPg0KCTwv bGk+DQoJPGxpPg0KCVVzZXIgcHJvZmlsZXMNCgkJPG9sPg0KCQk8bGk+DQoJ CUFjY2VzcyBDb250cm9sIExpc3RzLg0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJ QWRkIC8gRGVsZXRlIC8gTW9kaWZ5IC8gTGlzdA0KCQkJCTxvbD4NCgkJCQk8 bGk+DQoJCQkJTmFtZSAvIFRlbXBsYXRlIC8gRGVmaW5pdGlvbg0KCQkJCTwv bGk+DQoJCQkJPC9vbD4NCgkJCTwvbGk+DQoJCQk8L29sPg0KCQk8L2xpPg0K CQk8bGk+DQoJCUFDTCBUZW1wbGF0ZXMNCgkJCTxvbD4NCgkJCTxsaT4NCgkJ CUFkZCAvIERlbGV0ZSAvIE1vZGlmeSAvIExpc3QNCgkJCQk8b2w+DQoJCQkJ PGxpPg0KCQkJCU5hbWUNCgkJCQkJPG9sPg0KCQkJCQk8bGk+DQoJCQkJCUNv bW1hbmQgcmVzdHJpY3Rpb25zIGxpc3QNCgkJCQkJPC9saT4NCgkJCQkJPGxp Pg0KCQkJCQlMb2NhdGlvbiByZXN0cmljdGlvbnMgbGlzdA0KCQkJCQk8L2xp Pg0KCQkJCQk8bGk+DQoJCQkJCVJlc291cmNlcyByZXN0cmljdGlvbnMgbGlz dA0KCQkJCQk8L2xpPg0KCQkJCQk8bGk+DQoJCQkJCVRpbWUgcmVzdHJpY3Rp b25zIGxpc3QNCgkJCQkJPC9saT4NCgkJCQkJPGxpPg0KCQkJCQlBdXRoZW50 aWNhdGlvbiBtZXRob2RzDQoJCQkJCTwvbGk+DQoJCQkJCTwvb2w+DQoJCQkJ PC9saT4NCgkJCQk8L29sPg0KCQkJPC9saT4NCgkJCTwvb2w+DQoJCTwvbGk+ DQoJCTwvb2w+DQoJPC9saT4NCgk8L29sPg0KPC9saT4NCjxsaT4NCk90aGVy IHNlcnZpY2VzDQoJPG9sPg0KCTxsaT4NCglDcm9uIHRhc2tzDQoJPC9saT4N Cgk8L29sPg0KPC9saT4NCjxsaT4NCkZpbGVzeXN0ZW1zLg0KCTxvbD4NCgk8 bGk+DQoJTG9jYWwgLyBSZW1vdGUNCgkJPG9sPg0KCQk8bGk+DQoJCShFbnVt ZXJhdGlvbiBvZiBhdmFpbGFibGUgRlMtcykNCgkJCTxvbD4NCgkJCTxsaT4N CgkJCUZTIC8gTW91bnRpbmcgcG9pbnQgLyBPcHRpb25zDQoJCQk8L2xpPg0K CQkJPC9vbD4NCgkJPC9saT4NCgkJPGxpPg0KCQlTd2FwIFBhcnRpdGlvbiAv IFN3YXAgRmlsZQ0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJQ3JlYXRlIC8gVHVy biBvbg0KCQkJPC9saT4NCgkJCTwvb2w+DQoJCTwvb2w+DQoJPC9saT4NCgk8 L29sPg0KPC9saT4NCjxsaT4NCkVudmlyb25tZW50DQoJPG9sPg0KCTxsaT4N CglTZXQgLyBVbnNldCAvIExpc3QNCgk8L2xpPg0KCTwvb2w+DQo8L2xpPg0K PGxpPg0KU3lzdGVtIHN0YXR1cw0KCTxvbD4NCgk8bGk+DQoJKEVudW1lcmF0 aW9uIG9mIGF2YWlsYWJsZSBzdGF0dXMgaXRlbXMpDQoJPC9saT4NCgk8L29s Pg0KPC9saT4NCjxsaT4NCkRpYWdub3N0aWNzDQoJPG9sPg0KCTxsaT4NCglE ZWJ1Zw0KCQk8b2w+DQoJCTxsaT4NCgkJKEVudW1lcmF0aW9uIG9mIHN1YnN5 c3RlbXMgaGllcmFyY2h5LCB0aG9zZSBvZiB3aGljaCBjYW4NCgkJcHJvdmlk ZSBkZWJ1Z2dpbmcgZGF0YSkNCgkJCTxvbD4NCgkJCTxsaT4NCgkJCVNldCAv IENsZWFyIC8gTGV2ZWwNCgkJCTwvbGk+DQoJCQk8L29sPg0KCQk8L2xpPg0K CQk8L29sPg0KCTwvbGk+DQoJPGxpPg0KCVN5c3RlbSBtZXNzYWdlcw0KCTwv bGk+DQoJPGxpPg0KCVBpbmcgLyB0cmFjZXJvdXRlIC8gcnRxdWVyeQ0KCTwv bGk+DQoJPC9vbD4NCjwvbGk+DQo8L3VsPg0KDQo8aHI+DQo8aT4NCjxwPlBs ZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gPEEgSFJFRj0ibWFpbHRvOmFi aWFsQGZyZWVic2Qub3JnIj4NCkFuZHJ6ZWogQmlhbGVja2k8L2E+PC9wPg0K PHA+TGFzdCBtb2RpZmllZDoNClNhdCBPY3QgMjQgMTk6MzM6NDUgQ0VTVCAx OTk4DQo8L3A+DQo8L2k+DQoNCjwvYm9keT4NCjwvaHRtbD4NCg== --0-390227750-909590705=:6616-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Wed Oct 28 11:25:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03432 for freebsd-small-outgoing; Wed, 28 Oct 1998 11:25:58 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA03426 for ; Wed, 28 Oct 1998 11:25:56 -0800 (PST) (envelope-from terry@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA27300; Wed, 28 Oct 1998 11:21:35 -0800 (PST) Received: from tlambert.whistle.com(207.76.205.208) via SMTP by alpo.whistle.com, id smtpdf27271; Wed Oct 28 19:21:22 1998 Message-ID: <36376E33.20DB@whistle.com> Date: Wed, 28 Oct 1998 11:19:15 -0800 From: Terry Lambert Organization: Whistle Communications X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Jeroen Ruigrok/Asmodai CC: small@FreeBSD.ORG Subject: Re: Unified Configuration Interface References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeroen Ruigrok/Asmodai wrote: ] Have to read up on SLP, but afaik SLP will be/is used by Novell ] in NetWare 5 with Native IP to replace SAP. Actually, SAP was obsolete the day NDIS shipped; the only reason it stuck around is Bindery emulation for older clients and servers that weren't upgraded to uses NDIS. The process that replaced it is the NDIS "pull model", called "skulking" (like NIS's push model, but without the dependency on a single master, but with the potential for replicate desynchronization for the period of time between a boot after outage and a "skulk"). ] So if I may base my conclusions on SAP, it will request per ] a broadcast certain servers/services, get a reply back and ] then use those services via SLP or just by making TCP ] connections or just dumping UDP datagrams? Correct me if I ] am wrong, but I don't have the time at the moment to dig ] through that RFC. RFC 2165, Service Location Protocol, Standards Track. Actually, SLP uses multicast and DHCP. I. There is a directory agent Scenario A (most desirable): 1) Client boots 2) Client gets IP and other information, including address of directory agent, via DHCP 3) Client unicasts requests to the directory agent Scenario B: 1) Client makes multicast request to directory agent discovery address to get address of directory agent 2) Directory agent responds to client 3) Client unicasts requests to the directory agent Scenario C (least desirable): 1) Client is preconfigured with knowledge of the address of the directory agent 2) Client unicasts requests to the directory agent II. There is not a directory agent Scenario A: 1) Client multicasts a request to the service-specific multicast address, to which the service it wishes to locate will respond. 2) All service agents listening to this multicast address will respond, provided they can satisfy the request. Scenario B (the pick-list): 1) Client wishes to obtain a list of all services. 2) Client applies a retransmission/convergence algorithm (everyone respond, except you, you, and you) to get all late/avoidance responses. So basically, it's not succeptible to "SAP storms", and it's scalable to the enterprise level because it has the capability of a directory agent to act as a well-known proxy responder for the service agents. In a small network, a directory agent isn't necessary. In a larger network, a directory agent (or DA) reduces the amount of network traffic. In a very large network where a single central repository is unfeasible, or in the case where you want to administratively restrict access to service clusters, you define a "scope", which can apply to the services advertised by service agents and by proxy, by directory agents. Think of a color printer that only wants to be used by the marketing department. 8-). ] > That would make it most probably a client implementation only. ] > I mention ACAP because it's a fairly small client implementation ] > as well. ] ] Having used ACAP I can say it's a fun protocol ;) Yes, but it fails the transaction test, and if you wanted to use it to configure an appliance (which is a server), then you have to run the protocol backwards. It also won't compile with the GNU toolchain without a number of modifications, and won't run on FreeBSD without STL modifications for FreeBSD's pthreads, and pthreads implementation modifications (currently, to drop pthreads *back down* to the Draft 4 level to avoid confusing the STL and the ACAP code). I'm pretty sure that we have the only ACAP that runs on FreeBSD, and will until FreeBSD upgrades to the G++ 2.8.1 + Jeremy Allison's per-thread exception stack code changes to libgcc, and FreeBSD supports the Moscow center for SPARC computing's STL implemetnation. ] > 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. ] ] Well, ye mean here the MAster server that is the general backup ] provider shouldst departemental/floor servers not be reachable? ] Or am I thinking in way the wrong direction? Think in terms of where you would store credential information for 500 accounts for a printer booting FreeBSD diskless out of ROM. ] > ] What worries me, though, is that the only one (free) ] > ] implementation of snmp agent that I'm aware of is, well, more ] > ] than bulky... ] ] Ok, but basing on the equipment we use at work (HP OpenView) I ] tend to prefer SNMP in use with MIBs. Although we also write ] out own shellscripts for that. Actually, the IBM SNMPv2 reference implementation is pretty small, and allows registration of subtrees by other programs. This goes a long way towards a "manage me" API. But it's a Streams MUX implementation; in theory, you could use dlopen and .so's with a minor redesign of the net interface code to make it work the same way as a daemon. But again, the point of MIBs is to get standards compliant schema for exposed tunables, and the method of exposure is much less interesting. ] > 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. ] ] Heh, schema sounds so alike to Novell's NDS schema ;) The word "schema" in the context of database design means only "record contents without specifying ordering or indices"; it's easier to say "schema". 8-). -- 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 From owner-freebsd-small Wed Oct 28 11:28:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03922 for freebsd-small-outgoing; Wed, 28 Oct 1998 11:28:24 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA03913 for ; Wed, 28 Oct 1998 11:28:15 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.59.218]) by smtp03.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA5F5F; Wed, 28 Oct 1998 20:27:31 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 28 Oct 1998 20:31:11 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Andrzej Bialecki Subject: Re: Unified Configuration Interface Cc: small@FreeBSD.ORG, Terry Lambert Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 28-Oct-98 Andrzej Bialecki wrote: > Hi, > > Ok, your remarks convinced me that the document I sent needed a lot of > clarification. > > So, here's the corrected version. How about that? We're well on the way I must say ;) I have also added some tree/branches not fully opened by Andrzej, either because he had no desire of filling them all in or he just had no idea what to fill them with. I have taken the liberty to collapse some of them to get more and more an idea of the command hierarchy and at the same time providing a means of establishing a commonly accepted command syntax/hierarchy that is less prone to break or be otherwise severly messed up in comparison to IOS, ShivOS (Shiva's OS) or EmbeddedNT (have any of you even seen this?). Some requested changes to the updated lay-out (ye care to version the HTML-page Andrzej?) : Numbering of the topmost headers as to ease reference to particular entries in the commandtree (e.g. let's say network configuration is 2, 2.2.4.1 would mean the IP address for a physical or virtual networkinterface) System configuration 4.Resource management 1.Memory consumption 2.Task priorities 1.List / Modify I think we would need a 3rd option under Resource management that will tell us how our different tables are doing. Might also be an option under 1.Memory Consumption. Because we have had to replace switches and routers at work before their MAC-table and Routing-table were reaching their limit. Network configuration 4.Routes 1.List 2.Static 1.Add / Delete / List 1.(route expression) 3.Dynamic 1.IS-IS 1.Add / Delete / List 1.(route expression) 2.NLSP 1.Add / Delete / List 1.(route expression) 3.OSPF 1.Add / Delete / List 1.(route expression) 4. .. Else we're going to shoot ourselves in the foot when we need to extend our dynamic route capabilities. 5.Network services 5.DHCP 1.Add / Delete / List 1.(ip range #) 2.Reserve IP Address(es) 6.SNMP 1.Add / Delete / List 1.(community string) 7.Printing 1.Local / Remote 1.Printer 1.Add 2.Configuration 1.Modify / List 3.Delete 2.Printerqueue 1.View jobs 2.Delete jobs 2.ACL Templates 1.Add / Delete / Modify / List 1.Name 5.Authentication methods +->TACACS, RADIUS and the likes? --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Wed Oct 28 12:10:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA12068 for freebsd-small-outgoing; Wed, 28 Oct 1998 12:10:58 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA12060 for ; Wed, 28 Oct 1998 12:10:55 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id VAA01466; Wed, 28 Oct 1998 21:16:10 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Wed, 28 Oct 1998 21:16:09 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Jeroen Ruigrok/Asmodai cc: small@FreeBSD.ORG, Terry Lambert Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Oct 1998, Jeroen Ruigrok/Asmodai wrote: > On 28-Oct-98 Andrzej Bialecki wrote: > > Hi, > > > > Ok, your remarks convinced me that the document I sent needed a lot of > > clarification. > > > > So, here's the corrected version. How about that? > Some requested changes to the updated lay-out (ye care to version the > HTML-page Andrzej?) : What do you mean? If you mean the $Id$ it will be filled once the file is in CVS, and I'll put it soon, let's say on more round of comments on general layout.. :-) > Numbering of the topmost headers as to ease reference to particular > entries in the commandtree (e.g. let's say network configuration is 2, > 2.2.4.1 would mean the IP address for a physical or virtual > networkinterface) It's easy to change, but the numbers will shift when we add or delete topmost branches until we settle with plausible set... > System configuration > > 4.Resource management > 1.Memory consumption > 2.Task priorities > 1.List / Modify > > I think we would need a 3rd option under Resource management that will tell us > how our different tables are doing. Might also be an option under 1.Memory > Consumption. Because we have had to replace switches and routers at work before > their MAC-table and Routing-table were reaching their limit. Hmmm... The "status" tree is for telling us how well we're doing. My intent here was that this subtree allow to _assign_ some resource limits. This should be fairly big tree (just see how many R/W items are in sysctl tree), but I went out of steam before I filled it in.. :-) > > Network configuration > > 4.Routes > 1.List > 2.Static > 1.Add / Delete / List > 1.(route expression) > 3.Dynamic > 1.IS-IS > 1.Add / Delete / List > 1.(route expression) > 2.NLSP > 1.Add / Delete / List > 1.(route expression) > 3.OSPF > 1.Add / Delete / List > 1.(route expression) > 4. .. > > Else we're going to shoot ourselves in the foot when we need to extend our > dynamic route capabilities. Well, more generally: 3. Dynamic (Enumeration of available protocols) 1.ADd /Delete /List because not always will a given box implement all of them. > 5.Network services > > 5.DHCP > 1.Add / Delete / List > 1.(ip range #) > 2.Reserve IP Address(es) > > 6.SNMP > 1.Add / Delete / List > 1.(community string) Whoa! This is certainly much, much more than this... If we use SNMP, it will be most probably ucd-snmp, which implements SNMPv2, and we'll need to add options for specifying what part of the tree are visible for which clients. > 7.Printing > 1.Local / Remote > 1.Printer > 1.Add > 2.Configuration > 1.Modify / List > 3.Delete 4. Disable / Enable > 2.Printerqueue > 1.View jobs > 2.Delete jobs > > 2.ACL Templates > 1.Add / Delete / Modify / List > 1.Name > 5.Authentication methods > +->TACACS, RADIUS and the likes? Yes. I didn't name them, but that's what I had in mind. Thanks for the comments! Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||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 From owner-freebsd-small Wed Oct 28 12:54:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA16980 for freebsd-small-outgoing; Wed, 28 Oct 1998 12:54:22 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA16762 for ; Wed, 28 Oct 1998 12:51:59 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from diabolique.ninth-circle.org ([195.121.58.176]) by smtp03.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA35F7; Wed, 28 Oct 1998 21:51:12 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 28 Oct 1998 21:54:53 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Andrzej Bialecki Subject: Re: Unified Configuration Interface Cc: Terry Lambert , small@FreeBSD.ORG Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 28-Oct-98 Andrzej Bialecki wrote: > On Wed, 28 Oct 1998, Jeroen Ruigrok/Asmodai wrote: > >> On 28-Oct-98 Andrzej Bialecki wrote: >> Some requested changes to the updated lay-out (ye care to version the >> HTML-page Andrzej?) : > > What do you mean? If you mean the $Id$ it will be filled once the file is > in CVS, and I'll put it soon, let's say on more round of comments on > general layout.. :-) Ahh ok, problem solved ;) >> Numbering of the topmost headers as to ease reference to particular >> entries in the commandtree (e.g. let's say network configuration is 2, >> 2.2.4.1 would mean the IP address for a physical or virtual >> networkinterface) > > It's easy to change, but the numbers will shift when we add or delete > topmost branches until we settle with plausible set... Yeah, I know, just wanted to express a handy X-reference idea ;) >> I think we would need a 3rd option under Resource management that will tell >> us >> how our different tables are doing. Might also be an option under 1.Memory >> Consumption. Because we have had to replace switches and routers at work >> before >> their MAC-table and Routing-table were reaching their limit. > > Hmmm... The "status" tree is for telling us how well we're doing. My > intent here was that this subtree allow to _assign_ some resource limits. > This should be fairly big tree (just see how many R/W items are in sysctl > tree), but I went out of steam before I filled it in.. :-) Talk about low pressure *G* Djeez, I missed the Status tree? Hmm *looking again* >> Else we're going to shoot ourselves in the foot when we need to extend our >> dynamic route capabilities. > > Well, more generally: > 3. Dynamic > (Enumeration of available protocols) > 1.ADd /Delete /List > > because not always will a given box implement all of them. 100% right Andrzej, I forgot about ennumeration ;) >> 5.Network services >> >> 5.DHCP >> 1.Add / Delete / List >> 1.(ip range #) >> 2.Reserve IP Address(es) >> >> 6.SNMP >> 1.Add / Delete / List >> 1.(community string) > > Whoa! This is certainly much, much more than this... If we use SNMP, it > will be most probably ucd-snmp, which implements SNMPv2, and we'll need to > add options for specifying what part of the tree are visible for which > clients. Exactly, I think we're going to need multiple documents ;) Btw I have holiday next 2 weeks or so, I will work on the dutch docs along with some technical propositional documents like the UCI.html document. > Yes. I didn't name them, but that's what I had in mind. OK, then I know we're on the same wavelength =) > Thanks for the comments! Thanks for starting picoBSD ;) Let's conquer the world now... LOL! --- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl Junior Network/Security Specialist FreeBSD & picoBSD: The Power to Serve... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Wed Oct 28 13:00:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17807 for freebsd-small-outgoing; Wed, 28 Oct 1998 13:00:39 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from chaco.whistle.com (s205m9.whistle.com [207.76.205.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17800 for ; Wed, 28 Oct 1998 13:00:37 -0800 (PST) (envelope-from bmann@whistle.com) Received: from chaco.whistle.com (chaco.whistle.com [207.76.205.9]) by chaco.whistle.com (8.8.7/8.6.12) with SMTP id MAA12280; Wed, 28 Oct 1998 12:59:42 -0800 (PST) Date: Wed, 28 Oct 1998 12:59:42 -0800 (PST) From: Bryan Mann To: Andrzej Bialecki cc: Terry Lambert , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 > > -------------------- ++-------++ ------------------------------------- > ||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 From owner-freebsd-small Wed Oct 28 13:40:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22455 for freebsd-small-outgoing; Wed, 28 Oct 1998 13:40:55 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22430 for ; Wed, 28 Oct 1998 13:40:44 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id WAA22746; Wed, 28 Oct 1998 22:46:03 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Wed, 28 Oct 1998 22:46:03 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Bryan Mann cc: Terry Lambert , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Oct 1998, Bryan Mann wrote: > On Tue, 27 Oct 1998, Andrzej Bialecki wrote: > > > On Mon, 26 Oct 1998, Terry Lambert wrote: [..both agree it should be transactional..] > 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. That's an interesting issue. The key thing here is the protocol, because we can already obtain this info without placing almost any load on the system - the problem is how to notify whoever is listening about the status changes. If I understand you correctly, you mean something similar to the part of "convenience MIB" of UCD-SNMP which allows to send traps when given set of processes behaves such and such, right? > [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. No, this is directly related - I wrote about it in the UCI document, in section on implementation of configuration agent. But there's one thing here which is still unclear: objects can have multiple dependencies, and in reality it matters which one of them is followed first. We need some ordering mechanism here as well. > > 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. AFAIK, SNMPv2 addresses this issue quite acceptably. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||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 From owner-freebsd-small Wed Oct 28 15:02:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29340 for freebsd-small-outgoing; Wed, 28 Oct 1998 15:02:36 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29322; Wed, 28 Oct 1998 15:02:30 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id PAA00835; Wed, 28 Oct 1998 15:01:40 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810282301.PAA00835@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: small@FreeBSD.ORG cc: bde@FreeBSD.ORG Subject: MFS_ROOT and picobsd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Oct 1998 15:01:40 -0800 From: Mike Smith Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hiya, just want to run something past you here. I note you're having problems with the MFS root stuff printing "mfs_mountroot: can't find rootvp" and the root mount failing. This seems to be related to the changes in rev 1.167 of kern/vfs_subr.c which is now returning ENXIO for MFS because MFS doesn't have a block major number. I'm hoping that Bruce will have an answer for this; perhaps mfs_mount shouldn't be trying to convert a bdev into a vp for its mount, or bdevvp needs to be more lenient in some cases. -- \\ 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. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Wed Oct 28 17:17:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA01920 for freebsd-small-outgoing; Wed, 28 Oct 1998 17:17:43 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from chaco.whistle.com (s205m9.whistle.com [207.76.205.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA01911 for ; Wed, 28 Oct 1998 17:17:39 -0800 (PST) (envelope-from bmann@whistle.com) Received: from chaco.whistle.com (chaco.whistle.com [207.76.205.9]) by chaco.whistle.com (8.8.7/8.6.12) with SMTP id RAA12618; Wed, 28 Oct 1998 17:17:12 -0800 (PST) Date: Wed, 28 Oct 1998 17:17:12 -0800 (PST) From: Bryan Mann To: Andrzej Bialecki cc: Terry Lambert , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Oct 1998, Andrzej Bialecki wrote: > > Bryan Mann previiously wrote: > > 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. > > That's an interesting issue. The key thing here is the protocol, because > we can already obtain this info without placing almost any load on the > system - the problem is how to notify whoever is listening about the > status changes. If I understand you correctly, you mean something similar > to the part of "convenience MIB" of UCD-SNMP which allows to send traps > when given set of processes behaves such and such, right? > I will look at UCD-SNMP. We've been experimenting with snmpd from SNMP Research. So in answer ... possibly. [deleted] > > > > 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. > > No, this is directly related - I wrote about it in the UCI document, in > section on implementation of configuration agent. Ok I missed it. Sorry. > > But there's one thing here which is still unclear: objects can have > multiple dependencies, and in reality it matters which one of them is > followed first.. We need some ordering mechanism here as well. > So perhaps this is faulty logic on my part but here goes... Suppose that you don't order anything per se but rather define that each sub-system is in some state similar to processes in the kernel. Example states: INIT - perform initialization tasks START - to perform start-up tasks STOP - perform stop related tasks RUN - the primary work phase IDLE - for objects that are waiting on some external event CHECK - performs self consistency check useful to test config changes prior to commit. READY - ready to start but not yet started. UPGRADE - perform upgrade tasks DOWNGRADE- run downgrade tasks MONITOR - to connect for monitoring NOTIFY - out-of-band notification of state change [out-of-band notification means that the client opens a rendezvous point for the server to connect to upon completion of the STATE/object in question] ERROR - actions performed in error state, note that errors are propagated up the object hierarchy until an error action can be invoked on the object in question. [includes success/fail messages to be emitted on the success/fail of a particular state. Note that for localized messages the response is simply an UUOID for a message in a locale specific catalog] SHARE - actions to be performed when replicating this entry. EXT_{UserDefined} - user defined extensions but how do you specify where they go in the state machine ? For this discussion then a sub-system is like basic networking, routing etc. Then have a single proccess that manages the bootstrap by going through the "services" sub-tree and executes each subsystem's INIT method. Could be a script or command line parameter to the daemon or whatever. Then each daemon's INIT code registers the events that it wants to monitor like "Notify me of 'routed started'" or whatever. This means that the daemon must wait IDLE on it's dependencies to be in place before it can complete it's INIT state and move onto RUN. And to some degree means that the system's startup is dependent on what is installed or 'active'. Additionally, each daemon would be capable of reporting it's state to the bootstrapper so that it could be interegated or debugged in the case of deadlock etc. > > > 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. > > AFAIK, SNMPv2 addresses this issue quite acceptably. > Ok, but there may be some reason to auth to a particular node in the tree can SNMPv2 do this? > > Andrzej Bialecki > > -------------------- ++-------++ ------------------------------------- > ||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 > ---------------------------------------------------------------------- "A University without students is like an ointment without a fly." -- Ed Nather, professor of astronomy at UT Austin (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 From owner-freebsd-small Thu Oct 29 02:47:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA07308 for freebsd-small-outgoing; Thu, 29 Oct 1998 02:47:55 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl ([148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA07294 for ; Thu, 29 Oct 1998 02:47:51 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id LAA23693; Thu, 29 Oct 1998 11:53:03 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Thu, 29 Oct 1998 11:53:02 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Bryan Mann cc: Terry Lambert , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Oct 1998, Bryan Mann wrote: > On Wed, 28 Oct 1998, Andrzej Bialecki wrote: > > But there's one thing here which is still unclear: objects can have > > multiple dependencies, and in reality it matters which one of them is > > followed first.. We need some ordering mechanism here as well. [snip] [This is nice approach - I think I'll add it to the proposal. :-) ] > This means that the daemon must wait IDLE on it's dependencies > to be in place before it can complete it's INIT state and > move onto RUN. > > And to some degree means that the system's startup is dependent > on what is installed or 'active'. Additionally, each daemon > would be capable of reporting it's state to the bootstrapper > so that it could be interegated or debugged in the case of > deadlock etc. Perhaps Terry can look at it from theoretical point of view (I've heard him once discussing graph theories and the likes :-) - but common sense tells me that when you have several objects with mutual dependencies, there is good chance that they will create loops (resulting in deadlocks). So, I think we need to address this issue from start, so that later, when we start implementing it, we know how to avoid them and how to unwind such loops when we create them by some configuration action. Deadlock detector is a good thing, but deadlock avoider is still better... :-) > > > Tracking MIBs raises issues of access control lists, security etc. > > > So far LDAP and SNMP v2, v3 seem to be lacking in these areas. > > > > AFAIK, SNMPv2 addresses this issue quite acceptably. > > > > Ok, but there may be some reason to auth to a particular node > in the tree can SNMPv2 do this? Yes, it can. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||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 From owner-freebsd-small Thu Oct 29 03:52:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA13703 for freebsd-small-outgoing; Thu, 29 Oct 1998 03:52:39 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA13695; Thu, 29 Oct 1998 03:52:30 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id WAA03845; Thu, 29 Oct 1998 22:52:25 +1100 Date: Thu, 29 Oct 1998 22:52:25 +1100 From: Bruce Evans Message-Id: <199810291152.WAA03845@godzilla.zeta.org.au> To: mike@smith.net.au, small@FreeBSD.ORG Subject: Re: MFS_ROOT and picobsd Cc: bde@FreeBSD.ORG Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I note you're having problems with the MFS root stuff printing >"mfs_mountroot: can't find rootvp" and the root mount failing. > >This seems to be related to the changes in rev 1.167 of kern/vfs_subr.c >which is now returning ENXIO for MFS because MFS doesn't have a block >major number. > >I'm hoping that Bruce will have an answer for this; perhaps mfs_mount >shouldn't be trying to convert a bdev into a vp for its mount, or bdevvp >needs to be more lenient in some cases. It needs to me more lenient (until someone fixes kludges in mfs). Fixed. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Thu Oct 29 04:36:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA18486 for freebsd-small-outgoing; Thu, 29 Oct 1998 04:36:23 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl ([148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA18454; Thu, 29 Oct 1998 04:36:15 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id NAA22384; Thu, 29 Oct 1998 13:35:38 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Thu, 29 Oct 1998 13:35:37 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Bruce Evans cc: mike@smith.net.au, small@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: MFS_ROOT and picobsd In-Reply-To: <199810291152.WAA03845@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Oct 1998, Bruce Evans wrote: > >I'm hoping that Bruce will have an answer for this; perhaps mfs_mount > >shouldn't be trying to convert a bdev into a vp for its mount, or bdevvp > >needs to be more lenient in some cases. > > It needs to me more lenient (until someone fixes kludges in mfs). > > Fixed. Thanks. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||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 From owner-freebsd-small Thu Oct 29 05:48:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA24624 for freebsd-small-outgoing; Thu, 29 Oct 1998 05:48:08 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl ([148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA24615 for ; Thu, 29 Oct 1998 05:48:05 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id OAA07577; Thu, 29 Oct 1998 14:52:54 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Thu, 29 Oct 1998 14:52:53 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Bryan Mann cc: Terry Lambert , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Oct 1998, Bryan Mann wrote: > Example states: > > > INIT - perform initialization tasks > START - to perform start-up tasks > STOP - perform stop related tasks > RUN - the primary work phase > IDLE - for objects that are waiting on some external event > CHECK - performs self consistency check > useful to test config changes prior to commit. > READY - ready to start but not yet started. I have no comments to the above, but... > UPGRADE - perform upgrade tasks > DOWNGRADE- run downgrade tasks If I understand you correctly, I'd call this COMMIT and ROLLBACK. I think that each object should have space for two sets of its parameters: one currently used, and other, currently being supplied. This fits nicely to our transactional model, because after you supplied new values, you didn't change anything yet - first, you do a CHECK, and then COMMIT. If we assume that old parameters are copied back to the "new" buffer, we can also perform a ROLLBACK to restore previously used parameters. > MONITOR - to connect for monitoring > > NOTIFY - out-of-band notification of state change > [out-of-band notification means that the client > opens a rendezvous point for the server to connect > to upon completion of the STATE/object in question] Hmmm... I wouldn't call them states - they are just one of (many) parameters. In this case, if I set a parameter called MONITOR, the object hooks up itself to some monitoring agent, but doesn't change its FSM state. In fact, if it were to do it, it should be highly undesirable, because ti would change its behaviour. Similarly, NOTIFY is just a hook-up to send events to specified party. > SHARE - actions to be performed when replicating this entry. Hmph... I dunno I understand this in terms of a "state". This is rather an action for specific event. > > EXT_{UserDefined} > - user defined extensions but how do you specify > where they go in the state machine ? It depends on how the FSM is built into the given subsystem - I've seen some FSM's which simply read their definition from configuration file (Merit Radius is such an example). Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||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 From owner-freebsd-small Thu Oct 29 07:25:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA06272 for freebsd-small-outgoing; Thu, 29 Oct 1998 07:25:33 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl ([148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA06265 for ; Thu, 29 Oct 1998 07:25:27 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id QAA03885; Thu, 29 Oct 1998 16:30:26 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Thu, 29 Oct 1998 16:30:25 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Bryan Mann cc: Terry Lambert , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1492107055-909675025=:20293" Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1492107055-909675025=:20293 Content-Type: TEXT/PLAIN; charset=US-ASCII Ok, guys, here is the "release candidate" version of UCI document. I think it's complete enough to expose it to wider public - I'm going to put it on WWW and in picobsd docs. Thanks for excellent comments and ideas! Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- --0-1492107055-909675025=:20293 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="UCI.html" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="UCI.html" PGh0bWw+DQo8ISAkSWQkID4NCjxib2R5Pg0KPGgxPjxjZW50ZXI+CQlVbmlm aWVkIENvbmZpZ3VyYXRpb24gSW50ZXJmYWNlIFByb2plY3QNCjwvY2VudGVy PjwvaDE+DQoNCjxwPiBIZXJlJ3MgYSBwcmVsaW1pbmFyeSBhdHRlbXB0IHRv IG9yZ2FuaXplIGFsbCAod2VsbCwgbW9zdCkNCmNvbmZpZ3VyYXRpb24gdGFz a3MgYW5kIHBhcmFtZXRlcnMgb2YgUGljb0JTRCBzeXN0ZW0gaW4gaGllcmFy Y2h5DQpvZiBjYXRlZ29yaWVzLiA8L3A+DQoNCjxwPiBUaGlzIGZvcm1zIGEg c29ydCBvZiBmcmFtZXdvcmssIGJhc2luZyBvbiB3aGljaCBvbmUgY2FuIGlt cGxlbWVudA0KY29uc2lzdGVudCBjb25maWd1cmF0aW9uIGZpbGUocyksIGFu ZCBjb25maWd1cmF0aW9uIHV0aWxpdGllcy4gPC9wPg0KDQo8cD4gSG93ZXZl ciwgdGhlIGlkZWEgYmVoaW5kIHRoaXMgcHJvamVjdCBpcyB0byBjb21wbGV0 ZWx5IHJlcGxhY2UgY3VycmVudGx5DQp1c2VkIGNvbmZpZ3VyYXRpb24gYXBw cm9hY2gsIHdoaWNoIGlzIGJhc2VkIG9uIHNldmVyYWwgc2hlbGwgc2NyaXB0 cywgYW5kIHRvDQpwcm92aWRlIGFiaWxpdHkgdG8gY2hhbmdlIHN5c3RlbSBi ZWhhdmlvdXIgYmFzaW5nIG9uIHNldCBvZiB3ZWxsLWRlZmluZWQNCnBhcmFt ZXRlcnMnIGhpZXJhcmNoeS4gVGhpcyBhcHByb2FjaCBtYWtlcyBpdCByZWxh dGl2ZWx5IGVhc3kgdG8gd3JpdGUNCmNvbnNpc3RlbnQgdXNlciBpbnRlcmZh Y2VzLCBlaXRoZXIgY29tbWFuZC1saW5lIG9yIHdpdGggR1VJIGZyb250LWVu ZHMuPC9wPg0KDQo8cD4oQlRXLiB0aGlzIGVmZm9ydCBpcyBjYWxsZWQgVUNJ UCBmb3Igc2hvcnQsIHdoaWNoIGlzIHByb25vdW5jZWQNCiJZb3UgU2VlIElQ IiBhbmQgcmVsYXRlcyB0byBpbnR1aXRpdmUgd2F5IHlvdSBjYW4gY29uZmln dXJlIHlvdXIgSVANCnNlcnZpY2VzIHdpdGggdGhpcyBhcHByb2FjaC4uIDot KSk8L3A+DQoNCjxwPjxpPjxiPlRoaXMgaXMgd29yayBpbiBwcm9ncmVzczwv Yj4gLSBJJ20gYXdhcmUgdGhhdCBtYW55IHBpZWNlcw0KYXJlIGVpdGhlciBj b21wbGV0ZWx5IG1pc3Npbmcgb3IgbWlzcGxhY2VkLiBQbGVhc2Ugc2VuZCBh bnkgY29tbWVudHMgYW5kDQpjaGFuZ2VzIHlvdSBzZWVtIGFwcHJvcHJpYXRl IGVpdGhlciBkaXJlY3RseSB0byBtZSwgb3IgYmV0dGVyIHRvDQpmcmVlYnNk LXNtYWxsQGZyZWVic2Qub3JnLiBJJ2xsIGdsYWRseSB3ZWxjb21lIGFueW9u ZSB3aG8gY2FuIGhlbHAgd2l0aA0KZGVzaWduIGFuZC9vciBpbXBsZW1lbnRh dGlvbi48L2k+PC9wPg0KDQoNCjxocj4NCg0KPGgxPjxjZW50ZXI+CQlVbmlm aWVkIENvbmZpZ3VyYXRpb24gSGllcmFyY2h5IChwcm9wb3NhbCkNCjwvY2Vu dGVyPjwvaDE+DQoNCjx1bD4NCjxsaT4NCjxwPkxldCdzIGZpcnN0IGludHJv ZHVjZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSBmb2xsb3dpbmcgdGVybXM6 DQo8dWw+DQo8bGk+DQo8Yj5tYW5hZ2VtZW50IGJhc2U8L2I+IC0gdGhlIGFj dHVhbCBzdHJ1Y3R1cmUgaG9sZGluZyBjb25maWd1cmF0aW9uIGFuZA0KaW5m b3JtYXRpb24gZGF0YSBhY2NvcmRpbmcgdG8gZGVmaW5lZCBzdHJ1Y3R1cmUu IFRoaXMgc3RydWN0dXJlIHdpbGwgbW9zdA0KcHJvYmFibHkgaGF2ZSBhIGZv cm0gb2YgdHJlZSAocG9zc2libHkgd2l0aCBjcm9zcy1icmFuY2ggbGlua3Mg b3Igc29tZSBvdGhlcg0KbWVjaGFuaXNtIHJlcHJlc2VudGluZyBtdXR1YWwg ZGVwZW5kZW5jaWVzKSAtIHRoZSB3YXkgaXQncyBzdG9yZWQgaXMgYWxzbw0K c29tZXRoaW5nIHdoaWNoIG5lZWRzIHRvIGJlIGRpc2N1c3NlZC4NCjwvbGk+ DQo8bGk+DQo8Yj51c2VyIGludGVyZmFjZTwvYj4gLSBhIG1ldGhvZCAoYW5k IGFnZW50KSBmb3IgcHJlc2VudGluZyBkYXRhIHN0b3JlZCBpbg0KbWFuYWdl bWVudCBiYXNlIGluIHN1Y2ggYSB3YXkgdGhhdCBpdCBjYW4gYmUgdmlld2Vk IGFuZCBtb2RpZmllZCBieQ0KbGVnaXRpbWF0ZSB1c2Vycy4NCjwvbGk+DQo8 bGk+DQo8Yj5jb25maWd1cmF0aW9uIGFnZW50PC9iPiAtIGFuIGVudGl0eSBw ZXJmb3JtaW5nIGFjdHVhbCBjb25maWd1cmF0aW9uDQp0YXNrcywgZnJvbSBv bmUgc2lkZSBkZWFsaW5nIHdpdGggbWFuYWdlbWVudCBiYXNlLCBhbmQgZnJv bSB0aGUgb3RoZXINCmRlYWxpbmcgd2l0aCB0aGUgc3lzdGVtIHJlc291cmNl cywgYW5kIGZyb20geWV0IGFub3RoZXIgZGVhbGluZyBlaXRoZXINCmRpcmVj dGx5IHdpdGggdGhlIHVzZXIgKHRodXMgYWN0aW5nIGFzIGEgdXNlciBpbnRl cmZhY2UpLA0Kb3IgcGFzc2luZyByZXF1ZXN0cyB0byBvdGhlciBlbnRpdHkg d2hpY2ggYWN0cyBhcyB1c2VyIGludGVyZmFjZS4NCjwvbGk+DQo8L3VsPg0K PC9saT4NCjxsaT4NCjxwPk9uZSBwb3NzaWJsZSBhcHByb2FjaCB0byBzdG9y aW5nIHRoZSBtYW5hZ2VtZW50IGRhdGEgaXMgdG8gdXNlIGFscmVhZHkNCmV4 aXN0aW5nIGZyYW1ld29yayBrbm93biBhcyBNSUIsIGFzIGRlZmluZWQgaW4g YXBwbGljYWJsZSBSRkNzLjwvcD4NCg0KPHA+VGhpcyBhcHByb2FjaCBoYXMg c2V2ZXJhbCBhZHZhbnRhZ2VzOiBpdCByZXByZXNlbnRzIHdlbGwgdGhvdWdo dC1vdXQgd29yaw0Kb2YgbWFueSBleHBlcmllbmNlZCBpbmRpdmlkdWFscyBh bmQgdGVhbXMsIGl0IGhhcyBhbHJlYWR5IHByb3ZlbiB0byBiZQ0KdXNlZnVs LCBpdCdzIHdpZGVseSB1c2VkIGFuZCBhY2NlcHRlZCwgaXQncyBlYXNpbHkg ZXh0ZW5zaWJsZSwgaXQncyBhYmxlIHRvDQpyZXByZXNlbnQgcXVpdGUgY29t cGxpY2F0ZWQgb2JqZWN0cywgZXRjLjwvcD4NCg0KPHA+SXQgaGFzIHNvbWUg ZHJhd2JhY2tzLCBhcyB3ZWxsOiBlLmcuIHRoZXJlIGlzIG5vIHN0YW5kYXJk IG1lY2hhbmlzbSBmb3INCnJlcHJlc2VudGluZyBldmVudHMgYW5kIGluZGly ZWN0bHkgcmVsYXRlZCBvYmplY3RzLCBpdCB0ZW5kcyB0byBjcmVhdGUNCmRl ZXAgYW5kIG5hcnJvdyB0cmVlcyB3aGljaCByZXF1aXJlIHRvIGRlc2NlbnQg c2V2ZXJhbCBsZXZlbHMgdG8gY2hhbmdlIHNvbWUNCmNvbW1vbmx5IHVzZWQg cGFyYW1ldGVycywgaXQgZG9lc24ndCBzYXkgYW55dGhpbmcgYWJvdXQgdGhl IG11dHVhbA0KZGVwZW5kZW5jaWVzIGJldHdlZW4gb2JqZWN0cyBhbmQgcGFy YW1ldGVycyAoZXhjZXB0IHBhcmVudC1jaGlsZC1zaWJsaW5nKSwNCmFuZCBh Ym91dCByZXF1aXJlZCBzZXF1ZW5jZSB0byBwcm9wZXJseSBzZXQgdGhlaXIg cGFyYW1ldGVycywgZXRjLjwvcD4NCg0KPHA+VGhlc2UgaXNzdWVzIGFyZSBu b3QgZGlyZWN0bHkgYWRkcmVzc2VkIGluIHN0YW5kYXJkcywgYW5kIHJlYWwN CmltcGxlbWVudGF0aW9ucyAoa25vd24gdG8gbWUpIGhhdmUgdG8gaW1wbGVt ZW50IHRoZXNlIGFkZGl0aW9uYWwgbWVjaGFuaXNtcw0KImJlaGluZCB0aGUg c2NlbmVzIiwgc28gdGhhdCB0aGVpciB3b3JraW5ncyBhcmUgbm90IG9idmlv dXMgbm9yIGVhc2lseQ0KYWNjZXNzaWJsZSAobGV0IGFsb25lIGNoYW5nZWFi bGUpLjwvcD4NCg0KPHA+U28sIGlmIHdlIGRlY2lkZSB0byB1c2UgaXQsIHdl IG5lZWQgdG8gYWRkcmVzcyB0aGVzZSBpc3N1ZXMgc29tZWhvdy4NClRoZSBu ZXh0IHBvaW50IHByZXNlbnRzIG9uZSBwb3NzaWJsZSBhcHByb2FjaCB0byB0 aGlzIGRpbGVtbWEuPC9wPg0KPC9saT4NCjxsaT4NCjxwPlRoZSB0ZXJtICJv YmplY3QiIHVzZWQgaW4gdGhlIGZvbGxvd2luZyBkaXNjdXNzaW9uIHJlcHJl c2VudHMgYSBmdW5jdGlvbmFsDQpzdWJzeXN0ZW0sIHN1Y2ggYXMgc3lzdGVt IHNlcnZpY2UsIHVzdWFsbHkgcGVyZm9ybWVkIGJ5IHNvbWUgc3BlY2lmaWMN CnByb2Nlc3MgKG9yLCBhIHNldCBvZiBnbG9iYWwgc3lzdGVtIHBhcmFtZXRl cnMsIGluIHdoaWNoIGNhc2UgdGhlIGNvbmZpZ3VyYXRpb24NCmFnZW50IGlz IHRoZSBzZXJ2aWNlIGl0c2VsZikuIDwvcD4NCg0KPHA+RWFjaCBvYmplY3Qg c3RvcmVkIGluIG1hbmFnZW1lbnQgYmFzZSBjYW4gYmUgY2hhcmFjdGVyaXpl ZCBieQ0KZm9sbG93aW5nIHByb3BlcnRpZXM6DQo8dWw+DQo8bGk+DQppdHMg aW50ZXJuYWwgc3RhdGUsIHBvc3NpYmx5IGNvbnNpc3Rpbmcgb2Ygc2V2ZXJh bCBwYXJhbWV0ZXJzIGFuZCBjdXJyZW50bHkNCnBlcmZvcm1lZCBmdW5jdGlv bnMsIGJ1dCByZXByZXNlbnRlZCB0byB0aGUgcmVzdCBvZiB0aGUgc3lzdGVt IGFzIGEgc3ltYm9saWMNCnN0YXRlLCBvbmUgb2Ygc2V0IG9mIHN0YXRlcyBj b21tb24gdG8gYWxsIG9iamVjdHMuDQo8L2xpPg0KPGxpPg0KYSB0ZW1wb3Jh cnkgc3BhY2UgZm9yIG5ldyBzZXRzIG9mIHBhcmFtZXRlcnMsIHdoaWNoIGFy ZSBiZWluZyBzdXBwbGllZCBieQ0Kb3RoZXIgc3Vic3lzdGVtcywgcHJpb3Ig dG8gdGhlaXIgYWN0dWFsIGFwcGxpY2F0aW9uLA0KPC9saT4NCjxsaT4NCkZT TSBkZWZpbml0aW9uLCBkZXNjcmliaW5nIHN0YXRlIHRyYW5zaXRpb25zIGlu IHJlYWN0aW9uIHRvIHJlY2VpdmVkIGV2ZW50cywNCjwvbGk+DQo8bGk+DQps aXN0IG9mIGV2ZW50cyBpdCBjYW4gZ2VuZXJhdGUgYW5kIGFjY2VwdCwNCjwv bGk+DQo8bGk+DQpsaXN0IG9mIGRlcGVuZGVuY2llcyBvbiBvdGhlciBvYmpl Y3RzJyBzdGF0ZXMsDQo8L2xpPg0KPGxpPg0KbGlzdCBvZiBwYXJhbWV0ZXJz IGl0IGNhbiBhY2NlcHQgYW5kL29yIHByb3ZpZGUsIHdpdGggdGhlaXIgdmFs aWQgcmFuZ2VzLg0KPC9saT4NCjwvdWw+DQo8L3A+DQoNCjxwPkEgZmV3IHdv cmRzIG9uIHN5c3RlbSBzdGFydHVwOiB0aGUgc3lzdGVtIHN0YXJ0dXAgcm91 dGluZXMgc2hvdWxkIGVuc3VyZQ0KdGhhdCBkZXBlbmRlbmNpZXMgY2FuIGJl IHVud291bmQgaW50byBsaW5lYXIsIG9yZGVyZWQgbGlzdC4gSWYgaXQncyBu b3QNCnBvc3NpYmxlLCB0aGV5IHNob3VsZCBkZXRlY3QgcG9zc2libGUgZGVh ZGxvY2tzIGF0IHJ1bnRpbWUsIGFuZCBhY3QgYXMgYW4NCmFyYml0ZXIgYmV0 d2VlbiBjb25mbGljdGluZyBwYXJ0aWVzIChvciBzaWduYWwgYW4gZXJyb3Ip LjwvcD4NCg0KPHA+VGhlIHNldCBvZiBzeW1ib2xpYyBzdGF0ZXMgbWF5IGNv bnNpc3Qgb2YgdGhlIGZvbGxvd2luZyBzdGF0ZXMsIGRlcGljdGluZw0Kb2Jq ZWN0J3MgY3VycmVudCBpbnRlcm5hbCBzdGF0ZSAoYXMgZGVzY3JpYmVkIGJ5 IGl0cyBGU00pOg0KDQo8Y2VudGVyPjx0YWJsZSBib3JkZXI+DQo8dHI+PGI+ PGNlbnRlcj48dGQ+TmFtZTwvdGQ+PHRkPk1lYW5pbmc8L3RkPjwvY2VudGVy PjwvYj48L3RyPg0KPHRyPg0KPHRkPklOSVQ8L3RkPjx0ZD5pbml0aWFsaXph dGlvbiByb3V0aW5lczwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkPkNIRUNLPC90 ZD48dGQ+cGVyZm9ybWluZyBjb25zaXN0ZW5jeSBjaGVjayBvbiBuZXdseSBz dXBwbGllZCBwYXJhbWV0ZXIgdmFsdWVzPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQ+UkVBRFk8L3RkPjx0ZD5yZWFkeSB0byBzdGFydCBwZXJmb3JtaW5nIGl0 cyBwcmltYXJ5IGZ1bmN0aW9uLCBidXQgbm90IHN0YXJ0ZWQ8L3RkPg0KPC90 cj4NCjx0cj4NCjx0ZD5TVEFSVDwvdGQ+PHRkPnN0YXJ0LXVwIHRhc2tzIChy ZWxhdGVkIHRvIGl0cyBwcmltYXJ5IGZ1bmN0aW9uLCBhcyBvcHBvc2VkDQp0 byBJTklUIHdoaWNoIGlzIHJlbGF0ZWQgdG8gaXRzIG93biBpbml0aWFsaXph dGlvbik8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZD5TVE9QPC90ZD48dGQ+c3Rv cCAoc2h1dGRvd24pIHRhc2tzICh3aGVuIHRoZSBvYmplY3QgaW50ZW5kcyB0 byBzdG9wDQpwZXJmb3JtaW5nIGl0cyBmdW5jdGlvbik8L3RkPg0KPC90cj4N Cjx0cj4NCjx0ZD5SVU48L3RkPjx0ZD5wcmltYXJ5ICh3b3JrKSBwaGFzZTwv dGQ+DQo8L3RyPg0KPHRyPg0KPHRkPklETEU8L3RkPjx0ZD53YWl0aW5nIGZv ciBzb21lIGV4dGVybmFsIGV2ZW50IHRvIGhhcHBlbjwvdGQ+DQo8L3RyPg0K PHRyPg0KPHRkPkNPTU1JVDwvdGQ+PHRkPmNvbW1pdCBjaGFuZ2VzIHN1cHBs aWVkIGluIGxhc3QgdHJhbnNhY3Rpb24gdG8gY3VycmVudGx5DQp1c2VkIHNl dCBvZiBwYXJhbWV0ZXJzPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQ+Uk9MTEJB Q0s8L3RkPjx0ZD5yZXZlcnQgbGFzdCBjb21taXQ8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZD5FUlJPUjwvdGQ+PHRkPnRoaXMgb2JqZWN0IGlzIGVpdGhlciBp bXByb3Blcmx5IGNvbmZpZ3VyZWQsIG9yDQpkeXNmdW5jdGlvbmFsPC90ZD4N CjwvdHI+DQo8dHI+DQo8dGQ+KG90aGVyLi4uKTwvdGQ+PHRkPihvdGhlci4u Lik8L3RkPg0KPC90cj4NCjwvdGFibGU+PC9jZW50ZXI+DQoNCjxwPklkZWFs bHksIHRoZSBjb25maWd1cmF0aW9uIGFnZW50IHdpbGwgYmUgZXF1aXBwZWQg d2l0aCByb3V0aW5lcyB0bw0Kc2VyaWFsaXplIHRoaXMgZGF0YSBpbnRvIGh1 bWFuLXJlYWRhYmxlIGZvcm0sIHNvIHRoYXQgaXQncyBlYXNpbHkgc3RvcmVk LA0KYmFja2VkIHVwLCBhbmQgcmVwYWlyZWQgaW4gY2FzZSBvZiBpbmNvbnNp c3RlbmNpZXMuPC9wPg0KPC9saT4NCjxsaT4NCjxwPkFjdHVhbCB1c2VyIGlu dGVyZmFjZSBpcyBzdGlsbCBxdWl0ZSBhbm90aGVyIHN0b3J5OiBJJ3ZlIHNl ZW4gVUlzIHdoaWNoDQptZXJlbHkgZm9sbG93ZWQgdGhlIHN0YW5kYXJkIE1J QnMsIGFuZCBtZW51cyB3ZXJlIGNvbXBvc2VkIG9mIGFjdHVhbCBPSUQNCm51 bWJlcnMgcGx1cyBERVNDUklQVElPTiBmaWVsZC4gSW4gbXkgZXhwZXJpZW5j ZSwgdGhleSBhcmUgKGJhcmVseSkNCmFjY2VwdGFibGUsIHRob3VnaCBkdWUg dG8gdGhlIHVzdWFsIHdpZHRoIGFuZCBkZXB0aCBvZiBNSUIgdHJlZXMgeW91 IGhhZCB0bw0KdHJhdmVyc2Ugc2V2ZXJhbCBsZXZlbHMgZG93biBhbmQgdXAg aW4gb3JkZXIgdG8gY2hhbmdlIHNvbWUgKHByb3RvY29sLXdpc2UpDQpyZWxh dGVkIHBhcmFtZXRlcnMuPC9wPg0KDQo8cD5Nb3JlIGFjY2VwdGFibGUgVUkg d291bGQgY29sbGVjdCBpbnRlcnJlbGF0ZWQgaXRlbXMgdW5kZXIgY29tbW9u IG1lbnUNCmVudHJpZXMsIGlycmVzcGVjdGlibHkgb2YgdGhlaXIgYWN0dWFs IHBvc2l0aW9uIGluIHRoZSBNSUIgdHJlZS48L3A+DQoNCjxwPkEgd29ydGh3 aGlsZSBnb2FsIHRvIHB1cnN1ZSBpcyB0byBjcmVhdGUgc3VjaCBhbiBVSSB3 aGljaCBjb3VsZCBndWlkZQ0KeW91IHRocm91Z2ggdGhlIG1vc3QgY29tbW9u IGNvbmZpZ3VyYXRpb24gdGFza3MsIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUN CmFsbG93aW5nIGZvciB1bnJlc3RyaWN0ZWQgYW5kIHF1aWNrIHVzZSBieSBw b3dlciB1c2Vycy4gVGhpcyBjYW4gYmUgZG9uZQ0KZWl0aGVyIGFzIGEgc2V0 IG9mIGNvbmZpZ3VyYXRpb24gIndpemFyZHMiIG9yIGV4dGVuc2l2ZSBoaW50 aW5nLCBjb21tYW5kDQpjb21wbGV0aW9uLCBldGMuPC9wPg0KPC9saT4NCjxs aT4NCjxwPlRoZSBtYW5hZ2VtZW50IGRhdGFiYXNlIHNob3VsZCBiZSBlYXNp bHkgZXhwb3J0YWJsZSB2aWEgc3RhbmRhcmQNCnByb3RvY29scywgc3VjaCBh cyBTTk1QIG9yIExEQVAuPC9wPg0KDQo8cD5Nb3N0IGtub3duIHRvIG1lIChp ZiBub3QgYWxsKSBpbXBsZW1lbnRhdGlvbnMgb2YgYWdlbnRzIGZvciB0aGVz ZQ0KcHJvdG9jb2xzIGFyZSAoY29udHJhcnkgdG8gdGhlaXIgbmFtZSkgcXVp dGUgaGVhdnktd2VpZ2h0IC0gc28gdGhlaXIgdXNlDQpzaG91bGQgYmUgZWl0 aGVyIG9wdGlvbmFsLCBvciByZXBsYWNlZCB3aXRoIHNvbWUgb3RoZXIgbGln aHQtd2VpZ2h0DQpwcm90b2NvbCBhbmQgYSBwcm94eSBhZ2VudCBydW5uaW5n IG9uIG90aGVyIG1hY2hpbmUuPC9wPg0KDQo8cD5JdCdzIHdvcnRod2hpbGUg dG8gY29uc2lkZXIgYWxzbyB1c2Ugb2Ygb3RoZXIgcHJvdG9jb2xzIHN1Y2gg YXMNCkRIQ1AgKGFuZCBCT09UUCksIFNlcnZpY2UgTG9jYXRpb24gUHJvdG9j b2wgKFNMUCAtIFJGQzIxNjUpIGZvciBlYXN5DQppbnRlZ3JhdGlvbiB3aXRo IExBTiByZXNvdXJjZXMsIGVhc3kgaW5pdGlhbCBjb25maWd1cmF0aW9uLCBh bmQgcGVlcg0KZGlzY292ZXJ5LjwvcD4NCjwvbGk+DQo8bGk+DQo8cD5BbGwg b3BlcmF0aW9ucyBwZXJmb3JtZWQgYnkgY29uZmlndXJhdGlvbiBhZ2VudCBz aG91bGQgYmUgdHJhbnNhY3Rpb25hbCwNCmkuZS4gaXQgc2hvdWxkIGJlIHBv c3NpYmxlIHRvIGNvbW1pdCBhIHNldCBvZiBjaGFuZ2VzIGFzIG9uZSBsb2dp Y2FsIGVudGl0eSwNCmFuZCBiZSBzdXJlIHRoYXQgZWl0aGVyIGl0J3MgYXBw bGllZCBpbiB3aG9sZSwgb3Igbm90IGF0IGFsbC4gVGhpcyBpbmNsdWRlcw0K YWxzbyBhYmlsaXR5IHRvIGFib3J0IHByb2Nlc3NpbmcgaW4gdGhlIG1pZGRs ZS48L3A+DQoNCjxwPlRoaXMgcHJvYmFibHkgbWVhbnMgdGhhdCBlYWNoIG9i amVjdCAoc3Vic3lzdGVtKSBzaG91bGQgYmUgYWJsZSB0byBzdG9yZQ0Kbm90 IG9ubHkgaXRzIGN1cnJlbnQgY29uZmlndXJhdGlvbiBkYXRhLCBidXQgYWxz byB0aGUgbmV3bHkgc3VwcGxpZWQgY29uZmlnDQpkYXRhIHRoYXQgYXJlIHRv IGJlIGFwcGxpZWQgYWZ0ZXIgdGhlIHRyYW5zYWN0aW9uIGVuZHMgc3VjY2Vz c2Z1bHkuPC9wPg0KDQo8cD5PcGVyYXRpb25zIHNob3VsZCBiZSB2ZXJpZmll ZCBhZ2FpbnN0IGFsbG93ZWQgdmFsdWVzLCBhcyB3ZWxsIGFzIGFnYWluc3QN CmFsbG93ZWQgY3JlZGVudGlhbHMsIGFuZCBiYXNpbmcgb24gdGhpcyBlaXRo ZXIgY29tbWl0dGVkIG9yIGFib3J0ZWQuPC9wPg0KPC9saT4NCjxsaT4NCjxw PkEgZmV3IG5vdGVzIG9uIHBvc3NpYmxlIGltcGxlbWVudGF0aW9uIG9mIGNv bmZpZ3VyYXRpb24gYWdlbnQ6PC9wPg0KPHVsPg0KPGxpPg0KbGV0J3MgYXNz dW1lIHRoYXQgYWxsIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gaXMgcmVh ZCBvbiBzdGFydHVwDQpieSBzb21lIHNwZWNpYWxpemVkIGRhZW1vbiAodGhp cyBjYW4gYmUgcGFydCBvZiBpbml0KDgpIGFzIHdlbGwpLA0Kd2hpY2ggdGhl biBwZXJmb3JtcyByb2xlIG9mIGNvbW11bmljYXRpb24gYWdlbnQgdGhyb3Vn aCB3aGljaCBwYXNzZXMNCmFsbCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9u LCBiZSBpdCByZXF1ZXN0IGZvciBjaGFuZ2UsIHJlcXVlc3QNCmZvciBpbmZv LCByZXF1ZXN0IGZvciBzdGFydCAvIHNodXRkb3duLCBvciBub3RpZmljYXRp b24gYWJvdXQgdGhlIGNoYW5nZS4NCjwvbGk+DQo8bGk+DQpjb25maWd1cmF0 aW9uIGluZm9ybWF0aW9uIGl0c2VsZiBpcyBzdG9yZWQgZWl0aGVyIGluIGJp bmFyeSBkYXRhYmFzZSwgb3IgYXMNCmEgZmlsZXN5c3RlbSBoaWVyYWNoeSBt aW1pY2tpbmcgY29uZmlndXJhdGlvbiBpdGVtcyBoaWVyYXJjaHkuDQo8L2xp Pg0KPGxpPg0KZWFjaCB1c2VyLWxldmVsIHByb2dyYW0gcGVyZm9ybWluZyBz b21lIHRhc2sgKHN1Y2ggYXMgcm91dGluZyBkYWVtb24sIGluZXRkDQpldGMp IGlzIGVpdGhlciBlcXVpcHBlZCB3aXRoIHRoZSBhYmlsaXR5IHRvIGNvbW11 bmljYXRlIHdpdGggY29uZmlnIGFnZW50LCBvcg0KaXMgcmVsaW5rZWQgd2l0 aCBzcGVjaWFsIHN0dWIgd2hpY2ggZmFrZXMgdG8gdGhlIHByb2dyYW0gbmVj ZXNzYXJ5IGNvbmZpZw0KZmlsZXMgYW5kIGV2ZW50cyAoc3VjaCBhcyBzaWdu YWxzIHRvIHJlcmVhZCBjb25maWd1cmF0aW9uKS4NCjxwPlRoaXMgcHJvYmFi bHkgbWVhbnMgYWxzbyB0aGF0IHNvbWUgbGliYyByb3V0aW5lcyB3b3VsZCBo YXZlIHRvIGJlIHJlcGxhY2VkLA0KYmVjYXVzZSB0aGV5IGFzc3VtZSByZWFk aW5nIGNvbmZpZ3VyYXRpb24gZnJvbSBjZXJ0YWluIGRpc2sgZmlsZXMuPC9w Pg0KPC9saT4NCjxsaT4NCmVhY2ggc3Vic3lzdGVtIHBlcmZvcm1pbmcgc29t ZSB0YXNrIHJlcXVlc3RzIGl0cyBpbml0aWFsIGNvbmZpZyBkYXRhDQpmcm9t IGNvbmZpZyBhZ2VudCwgYXQgdGhlIHNhbWUgdGltZSByZWdpc3RlcmluZyB3 aXRoIGl0IHRvIHJlY2VpdmUNCmNvbmZpZ3VyYXRpb24gZXZlbnRzLCBzdWNo IGFzIHJlcXVlc3QgdG8gcmUtcmVhZCBkYXRhLCB0byBwcm92aWRlIGN1cnJl bnRseQ0KdXNlZCBjb25maWcgZGF0YSwgcmV0dXJuIHN0YXR1cywgcmVhY3Qg Zm9yIHNpZ25hbHMsIHJlc3RhcnRzLCBldGMuLi4NCjwvbGk+DQo8bGk+DQpj b25maWd1cmF0aW9uIGFnZW50IGFjdHMgYXMgbWVldGluZyBwb2ludCBmb3Ig YWxsIHByb2R1Y2VycyBhbmQgY29uc3VtZXJzDQpvZiBldmVudHMgYW5kIGNv bmZpZyBkYXRhLiBJdCBuZWVkcyB0byBtYWludGFpbiBhIHRhYmxlIG9mIHJl Z2lzdGVyZWQNCnN1YnN5c3RlbXMsIHNldCBvZiBldmVudHMgdGhleSBwcm92 aWRlLCBzZXQgb2YgZXZlbnRzIHRoZXkgd2FudCB0byByZWNlaXZlLA0KZXRj Li4gQmFzaW5nIG9uIHRoaXMgdGFibGUsIGl0ICBwYXNzZXMgYXBwcm9wcmlh dGUgaW5mb3JtYXRpb24gdG8NCmFwcHJvcHJpYXRlIHBhcnRpZXMuDQo8L2xp Pg0KPGxpPg0KdXNlciBpbnRlcmZhY2UgaXMgdGhlbiBqdXN0IG9uZSBvZiBj bGllbnRzIG9mIGNvbmZpZyBhZ2VudCwgYWxiZWl0IHBvc3Nlc3NpbmcNCnNw ZWNpYWwgcHJpdmlsZWdlcy4NCjwvbGk+DQo8bGk+DQpvbmUgb2YgaW1wb3J0 YW50IHRhc2tzIG9mIGNvbmZpZ3VyYXRpb24gYWdlbnQsIGluIGNhc2UgZ2l2 ZW4NCm9iamVjdCAoc3Vic3lzdGVtKSByZWdpc3RlcnMgd2l0aCBpdCB0byBi ZSBub3RpZmllZCBhYm91dCBjZXJ0YWluIGV2ZW50cywgaXMNCnRvIGVuc3Vy ZSB0aGF0IHN1Y2ggdHlwZSBvZiBldmVudCBjYW4gYmUgcG9zc2libHkgZ2Vu ZXJhdGVkLiBUaGlzIGlzIHRvDQpwcmV2ZW50IHN1YnN5c3RlbXMgZnJvbSB3 YWl0aW5nIGZvciBldmVudHMgY29taW5nIGZyb20gb3RoZXIgbm9uLWV4aXN0 ZW50DQpzdWJzeXN0ZW1zLg0KPC9saT4NCjwvdWw+DQo8aT48cD5OT1RFOiB0 aGlzIGlzIG9uZSBwb3NzaWJsZSBhcHByb2FjaCAtIGEgY2VudHJhbGl6ZWQg b25lLiBJdCdzIHdvcnRoIHRvDQpjb25zaWRlciBvdGhlciBhcHByb2FjaCwg ZGlzdHJpYnV0ZWQsIGluIHdoaWNoIGNhc2UgZWFjaCBvYmplY3QgKHN1YnN5 c3RlbSkNCnNlbmRzIGFuZCBsaXN0ZW5zIHRvIHRoZSBkYXRhIGF0IGEgbWVl dGluZyBwb2ludCBzcGVjaWZpYyB0byBlYWNoIG90aGVyDQpvYmplY3QuIFRo aXMgZWxpbWluYXRlcyAob3IgZHJhc3RpY2FsbHkgbWluaW1pemVzKSB0aGUg cm9sZSBvZiBjb25maWd1cmF0aW9uDQphZ2VudCB3aGljaCBpcyBhIHNpbmds ZSBwb2ludCBvZiBmYWlsdXJlIGluIGNlbnRyYWxpemVkIGNhc2UuPC9wPjwv aT4NCjwvbGk+DQo8L3VsPg0KDQo8aHI+DQoNCjxwPkhlcmUgaXMgbXkgaW5p dGlhbCBwcm9wb3NhbCwgd2hpY2ggcGVyaGFwcyBjYW4gYmUgdXNlZCBhcyBh IG1vZGVsIGZvcg0KdXNlciBpbnRlcmZhY2UgaGllcmFyY2h5LCBpZiBub3Qg Zm9yIHRoZSBtYW5hZ2VtZW50IGJhc2UgaXRzZWxmLjwvcD4NCg0KPHVsPg0K PGxpPg0KU3lzdGVtIGNvbmZpZ3VyYXRpb24uDQoJPG9sPg0KCTxsaT4NCglC b290IGRldmljZSBhbmQgZmlsZSA8YnI+DQoJPHNtYWxsPk5hbWUgb2YgdGhl IGJvb3QgZGV2aWNlIChwb3NzaWJseSBuZXR3b3JrZWQpIGFuZCBib290DQoJ aW1hZ2UuPC9zbWFsbD4NCgkJPG9sPg0KCQk8bGk+DQoJCShFbnVtZXJhdGlv biBvZiBhdmFpbGFibGUgZGV2aWNlcykNCgkJCTxvbD4NCgkJCTxsaT4NCgkJ CShFbnVtZXJhdGlvbiBvZiBhdmFpbGFibGUgZmlsZXMpDQoJCQk8L2xpPg0K CQkJPC9vbD4NCgkJPC9saT4NCgkJPC9vbD4NCgk8L2xpPg0KCTxsaT4NCglD b25maWcgZmlsZSA8YnI+DQoJPHNtYWxsPkNvbmZpZ3VyYXRpb24gZmlsZSBt YW5hZ2VtZW50IC0gbG9hZGluZyBhbmQgc2F2aW5nLCBlaXRoZXINCglsb2Nh bCBvciByZW1vdGUgKGlmIGFwcGxpY2FibGUpLiA8L3NtYWxsPg0KCQk8b2w+ DQoJCTxsaT4NCgkJTG9hZCAvIFNhdmUNCgkJCTxvbD4NCgkJCTxsaT4NCgkJ CVNvdXJjZSAvIERlc3RpbmF0aW9uIDxicj4NCgkJCShFbnVtZXJhdGlvbiBv ZiBhdmFpbGFibGUgc3RvcmFnZSBwbGFjZXMsIHBvc3NpYmx5DQoJCQluZXR3 b3JrZWQpDQoJCQk8L2xpPg0KCQkJPC9vbD4NCgkJPC9saT4NCgkJPGxpPg0K CQlFZGl0IGRpcmVjdGx5IChnZWVrIG1vZGUpDQoJCTwvbGk+DQoJCTwvb2w+ DQoJPC9saT4NCgk8bGk+DQoJTG9hZGFibGUgbW9kdWxlcyA8YnI+DQoJPHNt YWxsPk9wdGlvbmFsIGhhcmR3YXJlLCBzZXJ2aWNlcyBhbmQgcHJvdG9jb2wg bW9kdWxlcyBtYW5hZ2VtZW50Lg0KCTwvc21hbGw+DQoJCTxvbD4NCgkJPGxp Pg0KCQkoRW51bWVyYXRpb24gb2YgYXZhaWxhYmxlIGxvYWRhYmxlIG1vZHVs ZXMpDQoJCQk8b2w+DQoJCQk8bGk+DQoJCQlMb2FkIC8gdW5sb2FkIC8gc3Rh dHVzDQoJCQk8L2xpPg0KCQkJPC9vbD4NCgkJPC9saT4NCgkJPC9vbD4NCgk8 L2xpPg0KCTxsaT4NCglSZXNvdXJjZSBtYW5hZ2VtZW50DQoJCTxvbD4NCgkJ PGxpPg0KCQlNZW1vcnkgY29uc3VtcHRpb24gPGJyPg0KCQk8c21hbGw+VGhp cyBpcyBlbnRyeSBwb2ludCB0byBhIHN1YnRyZWUsIHdoaWNoIGFsbG93cyB0 byBzZXQNCgkJdXAgdmFyaW91cyByZXNvdXJjZSBsaW1pdHMgZm9yIHN1YnN5 c3RlbXMsIHNlcnZpY2VzIGFuZA0KCQlwcm9jZXNzZXMuPC9zbWFsbD4NCgkJ PC9saT4NCgkJPGxpPg0KCQlUYXNrIHByaW9yaXRpZXMNCgkJCTxvbD4NCgkJ CTxsaT4NCgkJCUxpc3QgLyBNb2RpZnkNCgkJCTwvbGk+DQoJCQk8L29sPg0K CQk8L2xpPg0KCQk8L29sPg0KCTwvbGk+DQoJPGxpPg0KCVN5c3RlbSBjb25z b2xlDQoJPC9saT4NCgk8bGk+DQoJVmlydHVhbCBjb25zb2xlcyAoaWYgYXBw bGljYWJsZSkNCgk8L2xpPg0KCTxsaT4NCglTeXN0ZW0gRGF0ZSAvIFRpbWUg Wm9uZQ0KCTwvbGk+DQoJPGxpPg0KCUJhbm5lcg0KCTwvbGk+DQoJPGxpPg0K CUxvZ2dpbmcNCgkJPG9sPg0KCQk8bGk+DQoJCUxvY2FsIGxvZ2dpbmcNCgkJ PC9saT4NCgkJPGxpPg0KCQlSZW1vdGUgbG9nZ2luZw0KCQk8L2xpPg0KCQk8 L29sPg0KCTwvbGk+DQoJPC9vbD4NCjwvbGk+DQo8bGk+DQpOZXR3b3JrIGNv bmZpZ3VyYXRpb24uDQoJPG9sPg0KCTxsaT4NCglIb3N0bmFtZSBhbmQgRG9t YWluDQoJPC9saT4NCgk8bGk+DQoJSW50ZXJmYWNlcw0KCQk8b2w+DQoJCTxs aT4NCgkJKEVudW1lcmF0aW9uIG9mIHBoeXNpY2FsIGludGVyZmFjZXMpIDxi cj4NCgkJKEVudW1lcmF0aW9uIG9mIHZpcnR1YWwgaW50ZXJmYWNlcywgaWYg YXBwbGljYWJsZSkgPGJyPg0KCQkoT3B0aW9ucyBmb3IgY3JlYXRpbmcgdmly dHVhbCBpbnRlcmZhY2VzLCBpZiBhcHBsaWNhYmxlKQ0KCQkJPG9sPg0KCQkJ PGxpPg0KCQkJSW50ZXJmYWNlIG9wdGlvbnMgKHNwZWVkLCBtZWRpYSwgZW5j YXBzdWxhdGlvbiwNCgkJCWRlc2NyaXB0aW9uLCBldGMuKQ0KCQkJPC9saT4N CgkJCTxsaT4NCgkJCUFSUA0KCQkJPC9saT4NCgkJCTxsaT4NCgkJCUJyaWRn aW5nDQoJCQk8L2xpPg0KCQkJPGxpPg0KCQkJSVANCgkJCQk8b2w+DQoJCQkJ PGxpPg0KCQkJCUFkcmVzcyAvIG5ldG1hc2sgLyBhbGlhcw0KCQkJCTwvbGk+ DQoJCQkJPC9vbD4NCgkJCTwvbGk+DQoJCQk8bGk+DQoJCQlJUFgNCgkJCTwv bGk+DQoJCQk8bGk+DQoJCQlBcHBsZVRhbGsNCgkJCTwvbGk+DQoJCQk8L29s Pg0KCQk8L2xpPg0KCQk8L29sPg0KCTwvbGk+DQoJPGxpPg0KCVByb3RvY29s IE9wdGlvbnMNCgkJPG9sPg0KCQk8bGk+DQoJCUlQLCBVRFAsIFRDUCwgQVJQ LCBJUFgsIEFUTSAuLi4gPGJyPg0KCQkoRW51bWVyYXRpb24gb2YgYXZhaWxh YmxlIHByb3RvY29scykNCgkJCTxvbD4NCgkJCTxsaT4NCgkJCShFbnVtZXJh dGlvbiBvZiBwcm90b2NvbCBzcGVjaWZpYyBvcHRpb25zLCBzdWNoIGFzDQoJ CQlidWZmZXIgc2l6ZXMsIGFsZ29yaXRobXMsIEFSUCB0YWJsZXMgZXRjKQ0K CQkJCTxvbD4NCgkJCQk8bGk+DQoJCQkJTGlzdCAvIEFkZCAvIERlbGV0ZSAv IE1vZGlmeSAvIFNldCAod2hlcmUNCgkJCQlhcHBsaWNhYmxlKQ0KCQkJCTwv bGk+DQoJCQkJPC9vbD4NCgkJCTwvbGk+DQoJCQk8L29sPg0KCQk8L2xpPg0K CQk8L29sPg0KCTwvbGk+DQoJPGxpPg0KCVJvdXRlcw0KCQk8b2w+DQoJCTxs aT4NCgkJTGlzdA0KCQk8L2xpPg0KCQk8bGk+DQoJCVN0YXRpYw0KCQkJPG9s Pg0KCQkJPGxpPg0KCQkJQWRkIC8gRGVsZXRlIC8gTGlzdA0KCQkJCTxvbD4N CgkJCQk8bGk+DQoJCQkJKHJvdXRlIGV4cHJlc3Npb24pDQoJCQkJPC9saT4N CgkJCQk8L29sPg0KCQkJPC9saT4NCgkJCTwvb2w+DQoJCTwvbGk+DQoJCTxs aT4NCgkJRHluYW1pYw0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJKEVudW1lcmF0 aW9uIG9mIGF2YWlsYWJsZSByb3V0aW5nIHByb3RvY29scykNCgkJCQk8b2w+ DQoJCQkJPGxpPg0KCQkJCUFkZCAvIERlbGV0ZSAvIExpc3QNCgkJCQkJPG9s Pg0KCQkJCQk8bGk+DQoJCQkJCShyb3V0ZSBleHByZXNzaW9uKQ0KCQkJCQk8 L2xpPg0KCQkJCQk8L29sPg0KCQkJCTwvbGk+DQoJCQkJPC9vbD4NCgkJCTwv bGk+DQoJCQk8L29sPg0KCQk8L2xpPg0KCQk8L29sPg0KCTwvbGk+DQoJPGxp Pg0KCU5ldHdvcmsgc2VydmljZXMNCgkJPG9sPg0KCQk8bGk+DQoJCUROUw0K CQkJPG9sPg0KCQkJPGxpPg0KCQkJSG9zdHMNCgkJCQk8b2w+DQoJCQkJPGxp Pg0KCQkJCUFkZCAvIERlbGV0ZSAvIExpc3QNCgkJCQkJPG9sPg0KCQkJCQk8 bGk+DQoJCQkJCShob3N0cyBkZWZpbml0aW9ucykNCgkJCQkJPC9saT4NCgkJ CQkJPC9vbD4NCgkJCQk8L2xpPg0KCQkJCTwvb2w+DQoJCQk8L2xpPg0KCQkJ PGxpPg0KCQkJUmVzb2x2ZXJzDQoJCQkJPG9sPg0KCQkJCTxsaT4NCgkJCQlB ZGQgLyBEZWxldGUgLyBMaXN0DQoJCQkJCTxvbD4NCgkJCQkJPGxpPg0KCQkJ CQkoaG9zdHMgYWRkcmVzc2VzKQ0KCQkJCQk8L2xpPg0KCQkJCQk8L29sPg0K CQkJCTwvbGk+DQoJCQkJPC9vbD4NCgkJCTwvbGk+DQoJCQk8bGk+DQoJCQlM b2NhbCBETlMgc2VydmVyIGNvbmZpZw0KCQkJPC9saT4NCgkJCTwvb2w+DQoJ CTwvbGk+DQoJCTxsaT4NCgkJUFBQDQoJCQk8b2w+DQoJCQk8bGk+DQoJCQlT ZXJ2ZXINCgkJCTwvbGk+DQoJCQk8bGk+DQoJCQlDbGllbnQNCgkJCTwvbGk+ DQoJCQk8L29sPg0KCQk8L2xpPg0KCQk8bGk+DQoJCU5GUw0KCQkJPG9sPg0K CQkJPGxpPg0KCQkJU2VydmVyDQoJCQk8L2xpPg0KCQkJPGxpPg0KCQkJQ2xp ZW50DQoJCQk8L2xpPg0KCQkJPC9vbD4NCgkJPC9saT4NCgkJPGxpPg0KCQlO SVMNCgkJPC9saT4NCgkJPGxpPg0KCQlESENQDQoJCQk8b2w+DQoJCQk8bGk+ DQoJCQlBZGQgLyBEZWxldGUgLyBSZXNlcnZlIC8gTGlzdA0KCQkJCTxvbD4N CgkJCQk8bGk+DQoJCQkJKElQIGFkZHJlc3MgZXhwcmVzc2lvbnMpDQoJCQkJ PC9saT4NCgkJCQk8L29sPg0KCQkJPC9saT4NCgkJCTwvb2w+DQoJCTwvbGk+ DQoJCTxsaT4NCgkJU05NUA0KCQkJPG9sPg0KCQkJPGxpPg0KCQkJUHJvdG9j b2wgdmVyc2lvbg0KCQkJPC9saT4NCgkJCTxsaT4NCgkJCVNlbmQgdHJhcHMg dG8uLi4NCgkJCTwvbGk+DQoJCQk8bGk+DQoJCQlBY2Nlc3MgQ29udHJvbCBM aXN0cyA8YnI+DQoJCQk8c21hbGw+KFRoaXMgaXMgZWl0aGVyIGZ1bGwtYmxv d24gQUNMIHN5c3RlbSBpbiBjYXNlDQoJCQlvZiBTTk1QdjIsIG9yIGEgY29t bXVuaXR5IHN0cmluZyBmb3IgU05NUHYxLik8L3NtYWxsPg0KCQkJPC9saT4N CgkJCTwvb2w+DQoJCTwvbGk+DQoJCTxsaT4NCgkJUHJpbnRpbmcNCgkJCTxv bD4NCgkJCTxsaT4NCgkJCUxvY2FsIC8gUmVtb3RlDQoJCQkJPG9sPg0KCQkJ CTxsaT4NCgkJCQlQcmludGVycw0KCQkJCQk8b2w+DQoJCQkJCTxsaT4NCgkJ CQkJQWRkIC8gTW9kaWZ5IC8gRGVsZXRlIC8gTGlzdA0KCQkJCQk8L2xpPg0K CQkJCQk8L29sPg0KCQkJCTwvbGk+DQoJCQkJPGxpPg0KCQkJCVF1ZXVlcw0K CQkJCQk8b2w+DQoJCQkJCTxsaT4NCgkJCQkJUHJpb3JpdHkgLyBEZWxldGUg LyBMaXN0DQoJCQkJCTwvbGk+DQoJCQkJCTwvb2w+DQoJCQkJPC9saT4NCgkJ CQk8L29sPg0KCQkJPC9saT4NCgkJCTwvb2w+DQoJCTwvbGk+DQoJCTxsaT4N CgkJU01CIHNlcnZpY2VzDQoJCTwvbGk+DQoJCTxsaT4NCgkJTmV0d29yayBB ZGRyZXNzIFRyYW5zbGF0aW9uDQoJCTwvbGk+DQoJCTxsaT4NCgkJUGFja2V0 IGZpbHRlcnMNCgkJPC9saT4NCgkJPGxpPg0KCQlCYW5kd2lkdGggTWFuYWdl cg0KCQk8L2xpPg0KCQk8bGk+DQoJCU5UUA0KCQk8L2xpPg0KCQk8bGk+DQoJ CVJlbW90ZSBBY2Nlc3MNCgkJPC9saT4NCgkJPC9vbD4NCgk8L2xpPg0KCTwv b2w+DQo8bGk+DQpVc2VyIG1hbmFnZW1lbnQuDQoJPG9sPg0KCTxsaT4NCglV c2VyIGFjY291bnRzDQoJCTxvbD4NCgkJPGxpPg0KCQlBZGQgLyBEZWxldGUg LyBNb2RpZnkgLyBMaXN0DQoJCQk8b2w+DQoJCQk8bGk+DQoJCQlOYW1lIC8g UGFzc3dvcmQgLyBBQ0wNCgkJCTwvbGk+DQoJCQk8L29sPg0KCQk8L2xpPg0K CQk8L29sPg0KCTwvbGk+DQoJPGxpPg0KCVVzZXIgcHJvZmlsZXMNCgkJPG9s Pg0KCQk8bGk+DQoJCUFjY2VzcyBDb250cm9sIExpc3RzLg0KCQkJPG9sPg0K CQkJPGxpPg0KCQkJQWRkIC8gRGVsZXRlIC8gTW9kaWZ5IC8gTGlzdA0KCQkJ CTxvbD4NCgkJCQk8bGk+DQoJCQkJTmFtZSAvIFRlbXBsYXRlIC8gRGVmaW5p dGlvbg0KCQkJCTwvbGk+DQoJCQkJPC9vbD4NCgkJCTwvbGk+DQoJCQk8L29s Pg0KCQk8L2xpPg0KCQk8bGk+DQoJCUFDTCBUZW1wbGF0ZXMNCgkJCTxvbD4N CgkJCTxsaT4NCgkJCUFkZCAvIERlbGV0ZSAvIE1vZGlmeSAvIExpc3QNCgkJ CQk8b2w+DQoJCQkJPGxpPg0KCQkJCU5hbWUNCgkJCQkJPG9sPg0KCQkJCQk8 bGk+DQoJCQkJCUNvbW1hbmQgcmVzdHJpY3Rpb25zIGxpc3QNCgkJCQkJPC9s aT4NCgkJCQkJPGxpPg0KCQkJCQlMb2NhdGlvbiByZXN0cmljdGlvbnMgbGlz dA0KCQkJCQk8L2xpPg0KCQkJCQk8bGk+DQoJCQkJCVJlc291cmNlcyByZXN0 cmljdGlvbnMgbGlzdA0KCQkJCQk8L2xpPg0KCQkJCQk8bGk+DQoJCQkJCVRp bWUgcmVzdHJpY3Rpb25zIGxpc3QNCgkJCQkJPC9saT4NCgkJCQkJPGxpPg0K CQkJCQlBdXRoZW50aWNhdGlvbiBtZXRob2RzDQoJCQkJCQk8b2w+DQoJCQkJ CQk8bGk+DQoJCQkJCQlVbml4IHBhc3N3ZA0KCQkJCQkJPC9saT4NCgkJCQkJ CTxsaT4NCgkJCQkJCVMvS2V5DQoJCQkJCQk8L2xpPg0KCQkJCQkJPGxpPg0K CQkJCQkJS2VyYmVyb3MNCgkJCQkJCTwvbGk+DQoJCQkJCQk8bGk+DQoJCQkJ CQlSYWRpdXMNCgkJCQkJCTwvbGk+DQoJCQkJCQk8bGk+DQoJCQkJCQlUQUNB Q1MNCgkJCQkJCTwvbGk+DQoJCQkJCQk8L29sPg0KCQkJCQk8L2xpPg0KCQkJ CQk8L29sPg0KCQkJCTwvbGk+DQoJCQkJPC9vbD4NCgkJCTwvbGk+DQoJCQk8 L29sPg0KCQk8L2xpPg0KCQk8L29sPg0KCTwvbGk+DQoJPC9vbD4NCjwvbGk+ DQo8bGk+DQpPdGhlciBzZXJ2aWNlcw0KCTxvbD4NCgk8bGk+DQoJQ3JvbiB0 YXNrcw0KCTwvbGk+DQoJPC9vbD4NCjwvbGk+DQo8bGk+DQpGaWxlc3lzdGVt cy4NCgk8b2w+DQoJPGxpPg0KCUxvY2FsIC8gUmVtb3RlDQoJCTxvbD4NCgkJ PGxpPg0KCQkoRW51bWVyYXRpb24gb2YgYXZhaWxhYmxlIEZTLXMpDQoJCQk8 b2w+DQoJCQk8bGk+DQoJCQlGUyAvIE1vdW50aW5nIHBvaW50IC8gT3B0aW9u cw0KCQkJPC9saT4NCgkJCTwvb2w+DQoJCTwvbGk+DQoJCTxsaT4NCgkJU3dh cCBQYXJ0aXRpb24gLyBTd2FwIEZpbGUNCgkJCTxvbD4NCgkJCTxsaT4NCgkJ CUNyZWF0ZSAvIFR1cm4gb24NCgkJCTwvbGk+DQoJCQk8L29sPg0KCQk8L29s Pg0KCTwvbGk+DQoJPC9vbD4NCjwvbGk+DQo8bGk+DQpFbnZpcm9ubWVudA0K CTxvbD4NCgk8bGk+DQoJU2V0IC8gVW5zZXQgLyBMaXN0DQoJPC9saT4NCgk8 L29sPg0KPC9saT4NCjxsaT4NClN5c3RlbSBzdGF0dXMNCgk8b2w+DQoJPGxp Pg0KCShFbnVtZXJhdGlvbiBvZiBhdmFpbGFibGUgc3RhdHVzIGl0ZW1zKQ0K CTwvbGk+DQoJPC9vbD4NCjwvbGk+DQo8bGk+DQpEaWFnbm9zdGljcw0KCTxv bD4NCgk8bGk+DQoJRGVidWcNCgkJPG9sPg0KCQk8bGk+DQoJCShFbnVtZXJh dGlvbiBvZiBzdWJzeXN0ZW1zIGhpZXJhcmNoeSwgdGhvc2Ugb2Ygd2hpY2gg Y2FuDQoJCXByb3ZpZGUgZGVidWdnaW5nIGRhdGEpDQoJCQk8b2w+DQoJCQk8 bGk+DQoJCQlTZXQgLyBDbGVhciAvIExldmVsDQoJCQk8L2xpPg0KCQkJPC9v bD4NCgkJPC9saT4NCgkJPC9vbD4NCgk8L2xpPg0KCTxsaT4NCglTeXN0ZW0g bWVzc2FnZXMNCgk8L2xpPg0KCTxsaT4NCglQaW5nIC8gdHJhY2Vyb3V0ZSAv IHJ0cXVlcnkNCgk8L2xpPg0KCTwvb2w+DQo8L2xpPg0KPC91bD4NCg0KPGhy Pg0KPGk+DQo8cD5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIDxBIEhS RUY9Im1haWx0bzphYmlhbEBmcmVlYnNkLm9yZyI+DQpBbmRyemVqIEJpYWxl Y2tpPC9hPjwvcD4NCjxwPkxhc3QgbW9kaWZpZWQ6DQpTYXQgT2N0IDI0IDE5 OjMzOjQ1IENFU1QgMTk5OA0KPC9wPg0KPC9pPg0KDQo8L2JvZHk+DQo8L2h0 bWw+DQo= --0-1492107055-909675025=:20293-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Thu Oct 29 09:13:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18154 for freebsd-small-outgoing; Thu, 29 Oct 1998 09:13:07 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from chaco.whistle.com (s205m9.whistle.com [207.76.205.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18148 for ; Thu, 29 Oct 1998 09:13:06 -0800 (PST) (envelope-from bmann@whistle.com) Received: from chaco.whistle.com (chaco.whistle.com [207.76.205.9]) by chaco.whistle.com (8.8.7/8.6.12) with SMTP id JAA13446; Thu, 29 Oct 1998 09:12:43 -0800 (PST) Date: Thu, 29 Oct 1998 09:12:43 -0800 (PST) From: Bryan Mann To: Andrzej Bialecki cc: Terry Lambert , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Oct 1998, Andrzej Bialecki wrote: > On Wed, 28 Oct 1998, Bryan Mann wrote: > [deleted] > > UPGRADE - perform upgrade tasks > > DOWNGRADE- run downgrade tasks > > If I understand you correctly, I'd call this COMMIT and ROLLBACK. I think > that each object should have space for two sets of its parameters: one > currently used, and other, currently being supplied. This fits nicely to > our transactional model, because after you supplied new values, you didn't > change anything yet - first, you do a CHECK, and then COMMIT. If we assume > that old parameters are copied back to the "new" buffer, we can also > perform a ROLLBACK to restore previously used parameters. > Hmmm, no I really meant upgrade/downgrade as in a short list of things that the code might be able to do if told to enter that state like service manager/bootstrapper says enter state UPGRADE then service does: a) listen on port 6060 for tar ball b) after receiving tar ball and md5 checksum check package c) deinstall old package saving away that copy d) install and verify new package e) enter state IDLE or READY But you are correct we do need COMMIT and ROLLBACK as you have described. Perhaps it doesn't make sense to think of putting a sub-system/service in UPGRADE or DOWNGRADE state. > > MONITOR - to connect for monitoring > > > > NOTIFY - out-of-band notification of state change > > [out-of-band notification means that the client > > opens a rendezvous point for the server to connect > > to upon completion of the STATE/object in question] > > Hmmm... I wouldn't call them states - they are just one of (many) > parameters. In this case, if I set a parameter called MONITOR, the object > hooks up itself to some monitoring agent, but doesn't change its FSM > state. In fact, if it were to do it, it should be highly undesirable, > because ti would change its behaviour. > > Similarly, NOTIFY is just a hook-up to send events to specified party. > I was thinking in terms of bootstrapper/service manager wanting to know who had MONITORs or NOTIFYs outstanding so ok I agree. This makes more sense. Then they are attributes. > > SHARE - actions to be performed when replicating this entry. > > Hmph... I dunno I understand this in terms of a "state". This is rather > an action for specific event. > Yes see above. You are correct. > > > > EXT_{UserDefined} > > - user defined extensions but how do you specify > > where they go in the state machine ? > > It depends on how the FSM is built into the given subsystem - I've seen > some FSM's which simply read their definition from configuration file > (Merit Radius is such an example). > That would be very good. Thanks for listening. Bryan. ---------------------------------------------------------------------- Churchill's Commentary on Man: Man will occasionally stumble over the truth, but most of the time he will pick himself up and continue on. (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 From owner-freebsd-small Thu Oct 29 11:54:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12579 for freebsd-small-outgoing; Thu, 29 Oct 1998 11:54:23 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12574 for ; Thu, 29 Oct 1998 11:54:21 -0800 (PST) (envelope-from terry@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA12417; Thu, 29 Oct 1998 11:53:44 -0800 (PST) Received: from tlambert.whistle.com(207.76.205.208) via SMTP by alpo.whistle.com, id smtpdC12412; Thu Oct 29 19:53:34 1998 Message-ID: <3638C745.39FD@whistle.com> Date: Thu, 29 Oct 1998 11:51:33 -0800 From: Terry Lambert Organization: Whistle Communications X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: "Andrzej Bialecki terry@whistle.com" CC: Bryan Mann , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrzej Bialecki wrote: [ ... dependency ordering enforcement ... ] ] Perhaps Terry can look at it from theoretical point of view ] (I've heard him once discussing graph theories and the likes ] :-) - but common sense tells me that when you have several ] objects with mutual dependencies, there is good chance that ] they will create loops (resulting in deadlocks). ] ] So, I think we need to address this issue from start, so that ] later, when we start implementing it, we know how to avoid ] them and how to unwind such loops when we create them by some ] configuration action. Deadlock detector is a good thing, but ] deadlock avoider is still better... :-) I think the missing piece here is that the dependency relationship enforcement implies a "natural order" in which things are to occur. I don't think this is more complicated than dealing with "make depend" and/or "make -j8". You *could* replace the entire rc file system with /etc/startup/Makefile, and everything you install that need startup gets a subdir, as in somthing like /etc/startup/smtp/Makefile, and there is an implied recursive descent into subdirectories. This is way overkill, of course; if you had flat files, you could do the same thing with scripting using tsort. 8-). I think the important point is hidden in my naming the subdir "smtp" instead of naming it "sendmail". The roundevous point has got to be the definition of what is exported by a server, and what is imported, not the server name, and not the definition. For example, sendmail exports "smtp", and it imports "dns"... so you don't want to start sendmail until its imports are satisfied. We could also see a sendmail-with-ldap-patches-applied (since such patches are currently publically available), which would mean that, in addition to "dns", it required "ldap". It's rather irrelevent that the service "dns" is exported by bind, or that the service "ldap" is exported by slapd (or that we may be importing the service "ldap" over the network from another host because we don't have a disk to store user data other than hard-coded bootstrap information). The point is that each server has a list of dependencies. Now consider a server that exports "dns", and wants to send out usage reports via "smtp". There is a dependency of this server on "smtp", and there is a dependency of the server that supplies "smtp" on "dns". But there is a distinction: the dependency to send reports is *soft*, while the dependence of the "smtp" exporting server is *hard*. We can think of the "dns" exporting server as actually being in the business of prividing *two* services: the hard service "dns", and the abstract service "dns usage reports". These are seperate, and the "dns" service can be brought up before the "dns usage reports" service. We can also see that both these servers will probably have other dependencies, like "syslog", a service that needs to be defined as existing defacto, if it is on another server (we can say the same thing of "smtp" and "dns"; nothing states that these services must all reside on the same host). So I think the problem is resolvable; it's just an issue of establishing that you're really dependent on services, not daemons, and then using a sufficient granularity for your definition of services to avoid starvation deadlocks. Of course, we are ignoring the real issue here, which is that most services only exist in the first place because we insist on having a procedurally abstracted configuration space. Why do you need to restart a daemon that needs the host name; why doesn't it call gethostname(3) each time, or why doesn't the hostname live in a read-only mmap'ed configuration space, so that the cached copy is the real copy, and is always up to date? But that's a different discussion... 8-). -- 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 From owner-freebsd-small Thu Oct 29 14:38:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA03722 for freebsd-small-outgoing; Thu, 29 Oct 1998 14:38:11 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA03637 for ; Thu, 29 Oct 1998 14:37:58 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id XAA10344; Thu, 29 Oct 1998 23:43:50 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Thu, 29 Oct 1998 23:43:50 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Bryan Mann cc: Terry Lambert , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Oct 1998, Bryan Mann wrote: > On Thu, 29 Oct 1998, Andrzej Bialecki wrote: > > > On Wed, 28 Oct 1998, Bryan Mann wrote: > > > [deleted] > > > UPGRADE - perform upgrade tasks > > > DOWNGRADE- run downgrade tasks > > > > If I understand you correctly, I'd call this COMMIT and ROLLBACK. I think > Hmmm, no I really meant upgrade/downgrade as in a short list of things > that the code might be able to do if told to enter that state like > service manager/bootstrapper says enter state UPGRADE then service does: > a) listen on port 6060 for tar ball > b) after receiving tar ball and md5 checksum check package > c) deinstall old package saving away that copy > d) install and verify new package > e) enter state IDLE or READY Ah, you meant something like a field-upgrade! Nice idea. Nonetheless, I'd treat it as certain action, though it can be so lengthy as to justify a separate state. I've been thinking about it just after I sent the last version of UCI document. I need to make more clear the distinction between a state and an action. I think the FSM could be reduced to very few states, namely: * INIT * CHECK (this is really an action, but it can be lengthy) * READY * STARTUP * SHUTDOWN * RUN * IDLE (blocked) * BUSY - performing some non-interruptible task (such as software version upgrade) * ERROR The rest would be actions, and each object would have to implement some minimal set of actions. > But you are correct we do need COMMIT and ROLLBACK as you have described. > Perhaps it doesn't make sense to think of putting a sub-system/service > in UPGRADE or DOWNGRADE state. The BUSY state will serve this role. > > It depends on how the FSM is built into the given subsystem - I've seen > > some FSM's which simply read their definition from configuration file > > (Merit Radius is such an example). > > That would be very good. Now, when I come to think about it... Perhaps FSM would be pretty standard, but the set of actions and events implemented in each object would be different.. Then the actual implementation would define these sets (possibly basing on some user-settable parameters), and one of mandatory actions would be to return the list of actually provided services/parameters' tree. > Thanks for listening. Hey, thank you for interesting ideas! :-) Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||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 From owner-freebsd-small Thu Oct 29 15:06:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA08840 for freebsd-small-outgoing; Thu, 29 Oct 1998 15:06:23 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08769 for ; Thu, 29 Oct 1998 15:06:13 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id AAA26860; Fri, 30 Oct 1998 00:12:13 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Fri, 30 Oct 1998 00:12:12 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Terry Lambert cc: Bryan Mann , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: <3638C745.39FD@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Oct 1998, Terry Lambert wrote: > I don't think this is more complicated than dealing with "make > depend" and/or "make -j8". You *could* replace the entire rc > file system with /etc/startup/Makefile, and everything you > install that need startup gets a subdir, as in somthing like > /etc/startup/smtp/Makefile, and there is an implied recursive > descent into subdirectories. Hehe.. So, we think similar sometimes... :-) This idea also occured to me when I started thinking about dependencies. > I think the important point is hidden in my naming the subdir > "smtp" instead of naming it "sendmail". Yes, definitely. I don't care what is the name of such and such process, as long as *someone* provides this particular service for me. > The roundevous point has got to be the definition of what is > exported by a server, and what is imported, not the server > name, and not the definition. > > For example, sendmail exports "smtp", and it imports "dns"... > so you don't want to start sendmail until its imports are > satisfied. Now, yet another idea occured to me: in fact, the initial startup could just try to start some highest level function of the system, and this function (since it has multiple dependencies) would try to satisfy its needs by requesting an "INIT" action from all service providers it is dependent upon. This is a nice picture, indeed.. it also means that if for some reason one of these providers stops working properly, the higher level function requests from it a restart procedure, which it can pass to the next level down, which it knows is not working properly, etc... > Now consider a server that exports "dns", and wants to send > out usage reports via "smtp". There is a dependency of this > server on "smtp", and there is a dependency of the server > that supplies "smtp" on "dns". > > But there is a distinction: the dependency to send reports > is *soft*, while the dependence of the "smtp" exporting > server is *hard*. I'd call them "critical" and "non-critical" to distinguish between the situation when subsystem is still able to function (though perhaps impaired) and the situation when such lack of provider is so severe that the service cannot possibly be performed. > We can think of the "dns" exporting server as actually being > in the business of prividing *two* services: the hard service > "dns", and the abstract service "dns usage reports". These > are seperate, and the "dns" service can be brought up before > the "dns usage reports" service. > > > We can also see that both these servers will probably have > other dependencies, like "syslog", a service that needs to > be defined as existing defacto, if it is on another server > (we can say the same thing of "smtp" and "dns"; nothing states > that these services must all reside on the same host). > > > So I think the problem is resolvable; it's just an issue of > establishing that you're really dependent on services, not > daemons, and then using a sufficient granularity for your > definition of services to avoid starvation deadlocks. Hmmm... I don't think this resolves the issue of deadlocks - it just moves it to more abstract level of services, instead of real objects/processes. The real problem (i.e. mutual "critical" dependency, like depends on 1<----------2<--------3 | /|\ +---------------------+ ) still exists. > Of course, we are ignoring the real issue here, which is that > most services only exist in the first place because we insist > on having a procedurally abstracted configuration space. Why ??? I can't parse it... Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||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 From owner-freebsd-small Thu Oct 29 17:29:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA00264 for freebsd-small-outgoing; Thu, 29 Oct 1998 17:29:39 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from hsw.generalresources.com ([203.79.17.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA00249 for ; Thu, 29 Oct 1998 17:29:27 -0800 (PST) (envelope-from hsw@email.generalresources.com) Received: from hsw.generalresources.com (localhost.generalresources.com [127.0.0.1]) by hsw.generalresources.com (8.9.1/8.9.1) with ESMTP id QAA06031 for ; Thu, 29 Oct 1998 16:57:18 +0800 (CST) (envelope-from hsw@hsw.generalresources.com) Message-Id: <199810290857.QAA06031@hsw.generalresources.com> To: small@FreeBSD.ORG From: Christopher Hall Reply-to: Christopher Hall Subject: Out of inodes for custom build X-Operating-System: FreeBSD 3.0 X-Mailer: exmh 2.0 Date: Thu, 29 Oct 1998 16:57:17 +0800 Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just tried to build a version of dial without ssh and received an out of inodes message. I did "cp -Rp dial dial2"; edit out ssh stuff and ./build with custom, dial2. Just in case my edits were wrong I retried custom but entered /usr/src/release/picobsd/dial ... Same message. If I choose 'n' at the main menu to build dial then it builds the tree without getting this error. Router built without any problem, but also gets same error if I try to build it as custom. Here is the Error Message: [hsw:...se/picobsd/build]# ./build ...Stuff-Skipped... mtree -deU -f mfs.mtree -p /mnt (cd /mnt/dev; /dev/MAKEDEV std sysmouse tun2 cuaa0 cuaa1 cuaa2 vty10 fd0 pty0; /dev/MAKEDEV psm0; /dev/MAKEDEV wd0s1h wd0s2 wd0s3 wd0s4 wd1s1h wd1s2 wd1s3 wd1s4) /mnt: create/symlink failed, no inodes free /sbin/mknod: tun2: No space left on device /sbin/mknod tun2 *** Error code 2 Stop. -> ERROR while making "custom" hierarchy in /mnt... -> Aborting ./populate [hsw:...se/picobsd/build]# df -k /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vn0c 1551 40 1511 3% /mnt This is on FreeBSD -current cvsup and make world as of yesterday The only thing I can see that is different for custom is in stage1: INODES=16000 dial gets INODES=4096 Tried building router as custom, but with MFS=6400 i.e. 4 times dial MFS size as custom wants 4 times INODES This builds OK. Perhaps the INODES should be settable for custom builds? or is the a simple calculation for INODES from MFS size? Also when populate terminated with error the vn device is left mounted. I can see there is some error trapping code in ./build to dismount it. --- Christopher Hall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message From owner-freebsd-small Thu Oct 29 22:24:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA05257 for freebsd-small-outgoing; Thu, 29 Oct 1998 22:24:17 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA05248 for ; Thu, 29 Oct 1998 22:24:12 -0800 (PST) (envelope-from terry@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id WAA04195; Thu, 29 Oct 1998 22:23:49 -0800 (PST) Received: from tlambert.whistle.com(207.76.205.208) via SMTP by alpo.whistle.com, id smtpdpq4191; Fri Oct 30 06:23:46 1998 Message-ID: <36395AF4.7614@whistle.com> Date: Thu, 29 Oct 1998 22:21:40 -0800 From: Terry Lambert Organization: Whistle Communications X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: "Andrzej Bialecki terry@whistle.com" CC: Bryan Mann , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrzej Bialecki wrote: [ ... ] ] Now, yet another idea occured to me: in fact, the initial ] startup could just try to start some highest level function ] of the system, and this function (since it has multiple ] dependencies) would try to satisfy its needs by requesting ] an "INIT" action from all service providers it is dependent ] upon. Yes. You could, in fact, define a "service" that consisted only of dependencies, for example "run_state_three", and then "ask for run_state_three". A "service cluster". ] > So I think the problem is resolvable; it's just an issue of ] > establishing that you're really dependent on services, not ] > daemons, and then using a sufficient granularity for your ] > definition of services to avoid starvation deadlocks. ] ] Hmmm... I don't think this resolves the issue of deadlocks - ] it just moves it to more abstract level of services, instead ] of real objects/processes. ] The real problem (i.e. mutual "critical" dependency, like ] ] depends on ] 1<----------2<--------3 ] | /|\ ] +---------------------+ ] ] ) still exists. Yes; but this abstract level has a lot less clutter in it, and even though it's an O(3) problem, you can detect loops in "critical dependencies" rather quickly. In fact, if you go to /usr/src/usr.bin/yacc/warshall.c, you can see the code you would need to link in to make this work. 8-). > > Of course, we are ignoring the real issue here, which is that > > most services only exist in the first place because we insist > > on having a procedurally abstracted configuration space. Why > > ??? I can't parse it... OK; I'll elaborate... it's a fun topic, anyway. 8-). The reason you have a lot of these dependencies is because the services you depend upon have some information you need, and they have to be there for you to ask them. You have other dependencies that need monitoring (or SNMP traps, etc.) because most programs are written to call a function to get configuration data at startup, and if you make changes after that, you have to signal them that the information has changed, and that their cached copy of the data is stale (for example, "the hostname has changed", or "the IP address assigned to interface ed0 has changed", etc.). The configuration data is stale because the programs operate on a cached copy of the configuration space, instead of on the real configuration space. A good example of this is errno. In FreeBSD-current, it's defined as a dereference of a integer pointer return from a function that gets called when you reference "errno". Consider if the hostname, or any other information that could become stale was accessed the same way. If it was, you would never need to restart your daemons because when they referenced the data *it would always be the right data*. Now say you don't want to take the procedure call hit every time you reference "hostname". How do you accomplish this? One way you could accomplish this is by defining hostname to be something like this: #define hostname ((char *)(*(baseaddress)[ HOSTNAME])) Where baseaddress is the base address of a memory mapped file that contained your configuration space, and starting at position 0 in the file, you have an array of void * pointers that point to the configuration data, somewhere else in the memory mapped file. When I access "hostname", what I get is a char * pointer to wherever the hostname is in the memory mapped file (we just need to agree that the void * pointer that points to the hostname is at offset 3, and that HOSTNAME is defined to be 3 -- or whatever agreed upon offset). Like the IRQ vector table in low memory. Yeah, I take a pointer dereference overhead that I wouldn't have on a cached copy, but I never have to take a restart overhead from getting signalled. So crt0.o or a CTOR (runtime constructor function) mmap's this file for me magically when my program starts up, and I just access things as if they're local variables. When I want to change something, I call a function that changes the copy in the real file, with whatever necessary interlocks to make sure no one is modifying the same thing at the same time. A configuration space. This gets rid of the need to monitor most of the things you would ever want to monitor, since the reason you are trying to monitor them is to catch changes so you can update your cached copy (i.e., you are doing an awful lot of work once in a while to avoid having to do a little work each time, but those aren't your only choices for solving the problem you want to solve, which is to avoid function call overhead each time you want to use some configuration data that may have changed on you). -- 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 From owner-freebsd-small Fri Oct 30 01:55:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA12384 for freebsd-small-outgoing; Fri, 30 Oct 1998 01:55:09 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA12379 for ; Fri, 30 Oct 1998 01:55:05 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id LAA06383; Fri, 30 Oct 1998 11:01:03 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Fri, 30 Oct 1998 11:01:02 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Terry Lambert cc: Bryan Mann , small@FreeBSD.ORG Subject: Re: Unified Configuration Interface In-Reply-To: <36395AF4.7614@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Oct 1998, Terry Lambert wrote: > Andrzej Bialecki wrote: > > > Of course, we are ignoring the real issue here, which is that > > > most services only exist in the first place because we insist > > > on having a procedurally abstracted configuration space. Why > > > > ??? I can't parse it... > > OK; I'll elaborate... it's a fun topic, anyway. 8-). [...] > A configuration space. [...] Ah, now I understand. Thanks for explaining. Yes, it's a nice approach, I'll think about it... Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||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 From owner-freebsd-small Fri Oct 30 02:24:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA14885 for freebsd-small-outgoing; Fri, 30 Oct 1998 02:24:23 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA14880 for ; Fri, 30 Oct 1998 02:24:19 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id LAA22671; Fri, 30 Oct 1998 11:29:48 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Fri, 30 Oct 1998 11:29:47 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Christopher Hall cc: small@FreeBSD.ORG Subject: Re: Out of inodes for custom build In-Reply-To: <199810290857.QAA06031@hsw.generalresources.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 29 Oct 1998, Christopher Hall wrote: > > Just tried to build a version of dial without ssh > and received an out of inodes message. > > I did "cp -Rp dial dial2"; edit out ssh stuff and > > ./build with custom, dial2. > > Just in case my edits were wrong I retried custom but entered > /usr/src/release/picobsd/dial ... Same message. > > If I choose 'n' at the main menu to build dial then it > builds the tree without getting this error. The number of inodes should probably be set up not in the stage1 script, but in some file specific to given setup, i.e. in ${TYPE}/ subdirs. As it is now, it's counter-intuitive... :-( > The only thing I can see that is different for custom is in stage1: > INODES=16000 > > dial gets INODES=4096 Yes, that's the culprit. > Perhaps the INODES should be settable for custom builds? Yes. > or is the a simple calculation for INODES from MFS size? No. It's chosen basing on experience. > Also when populate terminated with error the vn device is left mounted. > I can see there is some error trapping code in ./build to dismount > it. Hmmm.. This is intentional. Usually, you want it mounted to check what really failed. When you restart the build process, it's unmounted anyway. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||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