Pete Wilson : C Consultant Software Engineering : Ephemera : http://www.pwilson.net/

Pete Wilson : Consultant Software Engineer

24 nov 02

CSS-only dropdowns

Working on the nav menu to learn CSS-only rollover dropdowns. No Javascript. Good newsgroup discussion: comp.infosystems.www.authoring.stylesheets, Subject: Re: Multilevel menus uwing css ?. Reading and following Mark Newhouse.

The New England Ephemeris

| | +----+----+ +----+----+ +----+----+ +----+----+ | NMS | | Managed | | Managed | | Managed | | with | | Node | | Bridge | | Node | | Manager | | w/Agent | | w/Agent | | w/Agent | +---------+ +---------+ +----+----+ +---------+ | +-------------+-------------+------+-------------+ | | | | +----+----+ +----+----+ +----+----+ +----+----+ | Managed | | Managed | | Managed | | NMS | | Node | | Node | | Node | | with | | w/Agent | | w/Agent | | w/Agent | | Manager | +---------+ +----+----+ +---------+ +---------+ Figure 1 Relationship of Agent to Network Management Stations The SNMP manager-agent partnership operates in two concurrent modes. In the first mode, the manager initiates transactions: it either requests the agent to get and return the states of certain variables -- counters, threshold values, and the like -- or commands the agent to set the states of those variables. Several hundred variables may be read and written in this way. In the other mode of operation, the agent may initiate transactions: under certain predefined conditions -- the managed node is restarting, say -- the agent sends unsolicited trap messages to the manager. The manager's ability, with the help of the responsive cooperating agent, to examine and modify conditions in any remote network-connected device is the key to effective and proactive network management. 2.2 SNMP-Agent Development The SNMP mechanism has since 1990 proven itself a management protocol of great power, utility, generality, and elegance. It is installed on hundreds of device types; it will certainly be installed on several thousands more. SNMP is arguably the network-management scheme of choice for the next several years at the least. But the development from scratch of an SNMP agent is a frightening prospect for several reasons: First, SNMP-agent development, while straightforward in concept, is complex in execution: the correct design, coding, debugging, testing, and documentation of an SNMP agent is a formidable task which can easily engulf many hundreds of man-hours. Second, because SNMP is relatively new and narrowly-understood technology with its attendant learning curve, SNMP-agent development is difficult to schedule accurately and often requires an open-ended commitment of time and resources. The adoption of the SNMP Version 2 standard makes the task even more difficult. Third, for reasons that are completely accidental and historical, SNMP remains closely associated with the TCP/IP protocol stack; the great majority of current available implementations of SNMP do, in fact, depend upon TCP/IP (or, more properly, UDP/IP). But the result is that we often mistakenly perceive TCP/IP as a prerequisite for SNMP. Fourth, because of the misperception that SNMP depends upon TCP/IP, we sometimes think that SNMP naturally requires all of the elaborate LAN hardware and software that TCP/IP seems to need. Finally, again principally because of misperceptions about transport-layer requirements, it's often thought that SNMP must be installed under some version of the Unix operating system. These five considerations must give us pause when we consider developing an SNMP agent. 3 THE OPEN SNMP AGENT The Open SNMP Agent was developed to meet the needs of customers who require SNMP capability in a variety of hardware platforms, operating systems, communications frameworks, and network arrangements; and all at a reasonable, predictable cost. The Agent helps ensure timely, correct, cost-effective implementation. 3.1 Correct Implementation The Agent is delivered to the customer as a complete, correct, RFC-compliant, fully-tested body of source or object code. Source code is orthogonal and highly modular. 3.2 Agent Extensibility Agent extensibility -- the ability easily to add MIBs written by users and third parties -- is a vital feature of the Agent. It is arguably the most important capability after correctness and is certainly the feature that is currently most visible and most in demand. The Agent easily accomodates the need for extensi- bility. MIBs and MIB fragments prepared by others are integrated handily at any of four stages: First, MIBs and MIB fragments can be compiled directly into the Agent. The resulting object file comprises the complete Agent with all appropriate MIBs. Second, whatever MIBs and MIB fragments are wanted for a particular Agent-MIB configuration can be compiled separately from the Agent and then linked with the Agent object files to produce the Agent with access to the desired MIBs. Third, the Agent can be configured to load and incorporate MIB object files at Agent startup time. Fourth, the Agent can be commanded to load, activate, deactivate, or unload MIB object files at any time after the Agent has started and while the Agent is running. 3.3 Modularity and Independence in the Agent The Agent -- in both portable-source form and extensible-binary forms -- is made to be completely free of any constraints which might be imposed by any environment in which the Agent will compile, link, install, and run. For example: 3.3.1 Compiler Independence The portable-source Agent is developed to compile correctly the first time with any ANSI or non-ANSI compiler: it's been compiled successfully with many C compilers on both Unix platforms and on PC-class machines. 3.3.2 Library and Link-Time Independence The Agent was developed with an eye to library independence: the Agent makes very few calls to library functions, and these few calls are straightforward. The installer doesn't have to worry about library functions which might differ from the usual. 3.3.3 Transport-Layer Independence Both forms of the Agent -- the portable-source form and the extensible-binary form -- are completely decoupled from the transport layer the user has planned or has in place. The Agent neither knows nor cares how the transport layer is implemented. The Agent is simply passed two pointers: the first to a received SNMP request, the other to a buffer in which the Agent will construct a response. 3.3.4 Communications-Medium Independence Neither form of the Agent imposes any requirements whatever on the underlying communications medium. The Agent is designed to use whatever medium the customer chooses. 3.3.5 Operating-System Independence Neither form of the Agent makes any assumptions about the operating system under which it will run. The Agent is designed to be installed under a variety of operating systems. It's been installed under many variations of Unix on many workstations; and under MS-DOS, Windows V3, and OS/2 V2 on many PC-class machines. The Agent is also being installed successfully under user- developed operating systems. 3.4 Predictable Installation Schedule We encourage the customer to port and install the SNMP Agent because history shows us that's the best way to bring the Agent up quickly. Or we can install the Agent and, if we are asked to, we will do so in no more than three calendar weeks. 3.5 Open and Extensible Binary Agent The Agent is also availably in binary form, and Agent offers a very cost-effective solution to network-node management. The extensible-binary Agent is a realization of the portable-source Agent aimed at a particular environment. The extensible-binary form of the Agent is available for these systems: Solaris 2.4 (either platform) (MIB-II module in prep) SVR4/386, including MIB-II Windows 3.x; Host-Resources MIB module Windows NT Host-Resources MIB Extension Agent Windows 95 Host-Resources MIB module 4 DELIVERABLES 4.1 Customer Responsibilities The customer takes responsibility for four of the items outlined in this section. If the customer wishes, we will implement any or all of these items at a rate separate from and in addition to the fixed Agent price. The customer-supplied modules are these: 4.1.1 MIBs: The customer undertakes the preparation of as many MIBs as are needed in the application. The Agent will accomodate any number of MIBs. We supply example MIB implementations for several MIBs, including MIB2. We also distribute a publicly- available MIB compiler to help with MIB preparation. The complete, production-quality implementation of MIB2 for SVR4 is distributed to customers at no charge. Other MIBs under development will be distributed to customers on that same basis. 4.1.2 Configuration module: The customer must modify a single short source module to perform certain configuration tasks and initialize the MIB interface at Agent compile, link, and startup time. We supply example code for this function. 4.1.3 Trap module: The customer implements a code segment to notice when a trap is indicated and to call the SNMP Agent to construct a trap packet. 4.1.4 Transport layer: The customer supplies the transport layer. 4.2 Example Source Code We supply several modules as examples or templates for the customer's guidance in preparing the modules for which he is responsible. The example and template modules are these: 4.2.1 MIBs: We deliver several example MIB implementations, including MIB2, and the MIB under development for Uninterruptible Power Supplies. A complete realization of MIB2 for SVR4 is delivered as part of the Agent package. 4.2.2 Configuration module: Provides facilities for initial configuration, and possible on-the-fly reconfiguration, for the MIB interface, access verification, and authentication-trap modules. This module is provided as a template. 4.2.3 Trap module: Provides network entity with the ability to send any SNMP traps. This module is provided as template. 4.2.4. Working example: Finally, we also supply a complete, working example implementation of the Agent over the Unix UDP/IP stack. 4.3 Core Agent Code 4.3.1 Portable-Source Agent For the Agent in portable-source form, we deliver modular Agent sources as about 3000 lines of C-language code in machine-readable form. The orthogonal Agent consists of several modules with minimal links and interdependencies among them. The customer need make no changes whatever in these modules. The core Agent modules are these: 4.3.1.1 Agent module: Performs input-packet decomposition and analysis, processes packet variables using a service provided by the customer-supplied variable-interface module. 4.3.1.2 Access verification module: Provides mapping of a community string and packet source onto one of an unlimited number of possible views. 4.3.1.3 Authentication trap module: Constructs an authentication- failed trap packet when the access verification module is unable to map an authentication datum; calls the customer-supplied transport layer to send the packet. 4.3.1.4 Codec module: Provides the Agent with facilities for encoding and decoding ASN.1 SNMP packets. 4.3.1.5 Miscellaneous-facilities module: Provides the Agent with miscellaneous basic services required. For example, this module holds the function to compare two object identifiers. 4.3.1.6 Supplemental module: Provides basic C library services; intended for use in an environment lacking a standard C library. 4.3.2 Extensible-Binary Agent For the extensible-binary form of the Agent, we deliver source code for the configuration module and object files for all of the modules listed for the portable-source form of the Agent. 4.4 Tools As part of the Agent package, we supply a publicly-available tool kit: a MIB compiler and a test subsystem. Makefiles are also included with the Agent. 4.5 Documentation We supply a porting guide to support installation of the Agent. The porting guide describes in detail what the Agent does; and how and why the Agent does it. The porting guide is complete, clear and correct. 5 ORGANIZATION OF THE OPEN SNMP AGENT The core code proper of the Open SNMP Agent is furnished as a collection of functions designed to be called by the user's Transport-Layer code which, conceptually, resides within the user's main program. The Agent, in turn, calls user-supplied functions to read and write variables which correspond to MIB object instances in the several MIBs the user may implement. Any number of MIBs may be implemented. An overview of the inter- action among the user's main program, the user's MIB-access code, and the Agent is shown in Figure 2. +------------------+ +------------------+ +------------------+ | USER | | AGENT | | USER | | Main-line Code | | Core Code | | Access to MIBs | +------------------+ +------------------+ +------------------+ | main () | | | | | | Initialization. | | | | | | Configuration. | | | | | | Transport-Layer | | | | | | receive packet; | | | | | | if SNMP packet, | | | | | | then call Agent ---> Parse and decode | | | | | | ASN.1-coded pkt, | | | | | | check authori- | | | | | | zation; if auth | | | | | | OK, call User | | | | | | MIB-access func ---> Check access | | | | | | rights to, then | | | | | | read/write, MIB | | | | | | object instances | | | | | | and return vals | | | | Code and build <--- to Agent core. | | | | ASN.1 auth-trap | | | | | | or response pkt, | | | | | | return the pkt | | | | Transport-Layer: <--- to User. | | | | send returned | | | | | | auth-trap or | | | | | | response pkt. | | | | | +------------------+ +------------------+ +------------------+ Figure 2 Data and Control Flow in User and Agent Code 6 INSTALLATION PROCESS Agent installation is straightforward and consists of a few well- defined steps. These are described below as if the customer were performing the entire installation himself. The order in which the steps are treated is of no particular significance. All the steps but the last can be taken in parallel. 6.1 Compile Agent Sources First, the Agent sources proper, as we deliver them, are compiled and linked. Compilation and linking is straightforward using our supplied makefiles. 6.2 Prepare MIBs and MIB-Access Code Second, the MIBs that the application requires are prepared. We supply MIB templates to help with this. 6.3 Implement Trap-Initiation Functions The Agent handles authentication-failed traps on its own, but cannot know when traps are to be sent, so we ask the customer to implement functions that notice when a trap message should be delivered and then call the function in the Agent which constructs the trap packet. We supply example code to guide the implementor. 6.4 Implement Initialization and Configuration Functions When the Agent is started, some function needs to set up the initial configuration and to initialize the MIBs. We supply example code for this function to guide the implementor. 6.5 Implement Transport-Layer Interface As the final implementation step, the interface to the transport layer needs to be prepared. We supply example code for this, as well. 6.7 Load and Run When the implementation steps above are done, the now-complete ported Agent is ready for testing and use. 7 WARRANTY AND SUPPORT If, within a period of six months of purchase, the functionality of the Agent proves unsatisfactory we will either fix the Agent or, at the customer's option, remove it and refund the purchase price. We offer e-mail support for the Agent on an annual contract basis. 8 REFERENCES 8.1 SNMP Version 1 1. Marshall T. Rose and Keith McCloghrie, "Structure and Identification of Management Information for TCP/IP based Internets," RFC 1155, May 1990. The SMI description. 2. Jeffrey D. Case, Mark S. Fedor, Martin L. Schoffstall, and James R. Davin, "A Simple Network Management Protocol (SNMP)," RFC 1157, May 1990. The rules of the SNMP Version 1 scheme. 3. Marshall T. Rose, editor, "Management Information Base Network Management of TCP/IP based internets: MIB-II," RFC 1158, May 1990. The first MIB-II description. 4. Marshall T. Rose and Keith McCloghrie, editors, "Concise MIB Definitions," RFC 1212, March 1991. 5. Keith McCloghrie and Marshall T. Rose, "Management Information Base Network Management of TCP/IP based Internets: MIB-II," RFC 1213, March 1991. The memorandum defines the second version of the Management Information Base (MIB-II) and supersedes RFC 1158. 6. James M. Galvin, Keith McCloghrie, and James R. Davin, "SNMP Security Protocols," RFC 1352, July 1992. 7. Marshall T. Rose, "The Simple Book: An Introduction to Management of TCP/IP-based internets," Prentice-Hall, 1991. The commentary on the RFCs and the best introduction to SNMP. Rose has strong opinions and doesn't mind sharing them, so the book can be entertaining, as well. 8. Douglas E. Comer and David L. Stevens, "Internetworking with TCP/IP," 3 volumes, Prentice-Hall, 1991-1993. 8.2 SNMP Version 2 1. SNMPv2 Working Group, "Introduction to Community-based SNMPv2," RFC 1901, January 1996. 2. SNMPv2 Working Group, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)," RFC 1902, January 1996. 3. SNMPv2 Working Group, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)," RFC 1903. 4. SNMPv2 Working Group, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)," RFC 1904. 5. SNMPv2 Working Group, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)," RFC 1905. 6. SNMPv2 Working Group, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)," RFC 1906. 7. SNMPv2 Working Group, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)," RFC 1907. 8. SNMPv2 Working Group, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework," RFC 1908.