Thursday, November 18, 2010

Simulating OpenView Events With Net-SNMP SNMP Traps

Simulating OpenView Events With via Net-SNMP
SNMP Traps

HP OpenView Network Node Manager used to be the industry standard network management tool. Net-SNMP is the standard SNMP stack used on most operating systems, such as Solaris. There is still a need to simulate the platform for migration of infrastructure. One common way to simulate the HP OpenView Network Node Manager environment is through the use of OpenView Events (ovevent) and Net-SNMP SNMP Traps (snmptrap) commands.

OpenView Events
The HP OpenView Node Down Event can be simulated through a guaranteed transport via the "ovevent" command.
ovevent $Severity $NMS \ .$Event \ . Integer 14 \ . OctetString ${Node}

NMS = IP or Resolvable Name of Network Management Station
Node = IP or Resolvable Name of the Managed Device
Severity = Critical, Major, Minor, Info
Event = 58916865 [OV_Node_Down], 58916864 [OV_Node_Up]
Simulate Using Net-SNMP via SNMP V1 Trap
An SNMP V1 trap can be produced to closel simulate this Node Down event. Note, this is not the exact representation, nor is the delivery of the event guaranteed. An SNMP Trap Receiver must receive this.
snmptrap -v 1 -c $Community $NMS \
. ${Node} 6 58916865 0

Community= SNMP Community String on used on Network Managment Station
Simulate Using Net-SNMP via SNMP V2c Trap
An SNMP V2c trap can be produced to closel simulate this Node Down event. Note, this is not the exact representation, nor is the delivery of the event guaranteed. An SNMP Trap Receiver must receive this.
snmptrap -v 2c -c $Community $NMS \
0 . \
. i 14 \
. s $Node
Simulate Using Net-SNMP via SNMP V2c Trap Test Tool
An SNMP V2c trap can be produced to closel simulate this Node Down event. Note, this is not the exact representation, nor is the delivery of the event guaranteed. An SNMP Trap Receiver must receive this.
snmptest -v 2c -c $Community $NMS:162 \<\<\!

Common events from HP OpenView Network Node Manager, the former "gold standard" in Network Management, can be simulated under stock Solaris 10 and Solaris 11 with simple available OS commands.

Monday, November 8, 2010

Graphical User Interfaces: X and Beyond

Graphical User Interfaces: X and Beyond


There has been much discussion lately regarding the core of Desktop User Interfaces. Mark Shuttleworth has been guiding the Ubuntu Community to move toward Wayland. Long time X community contributor Allen Coopersmith had added some clarification of his own, regarding X11 long time stability and future viability. It is healthy to go through the discussion of display systems occasionally, for the newer programmer.


The disucssion of desktop systems for UNIX is a re-occurring theme. This is in no way an exhaustive history, nor is it ment to be 100% accurate in comparing features of one system against another- not all desktops are created equal in capability or sophistication. Many of these systems relied upon X11, while others did not.

Most UNIX systems used TTY for access on early systems.

Terminals leveraged curses libraries for full screen usage. Various UNIX System V platforms built menuing systems upon the curses library through Form and Menu Language Interpreter or FMLI and enhanced the user experience through Framed Access Command Environment or FACE.

Solaris started with SunView, moved to OpenWindows, used NeWS with Display Postscript, and evetually started down the course of converging to a 100% open-source X11 system. The windowing system was based upon olwm and appeared on AT&T UNIX as well as Solaris.

There is a virtualized window manager based upon OpenWindows called OLVWM, which conforms to the OPEN LOOK standard, but Solaris had decided to abandon Open Look Window Manager or olwm in a later unification effort.

As X Windows became more popular, some vendors of UNIX offered graphical augmented enhancements, such as NCR's XFMLI. Sun received an infusion of cash from AT&T and AT&T purchased NCR. The use of FMLI within AT&T was phenominal by it's user community and the use of XFMLI by NCR was used to modernize the desktop without the necessity to change the investment of FMLI from the System V code base. Solaris even added an FMLI interface to the Live Upgrade OS feature.

Solaris started the process of abandoning FMLI and FACE, for enhanced terminal based user experience, in the mid 2000's, citing internationalization overhaul as a primary motivation.

A group of vendors aligned against Sun and AT&T (who standardized on OPENLOOK) with an alternative GUI referred to as Motif. It was basically a copy of an IBM standard, which IBM followed for OS/2 and Microsoft copied with Window 3.1. There was an open-source version attempted called Open Motif. This was later abandoned with a later unification effort.

Next's NextStep brought a new level of competition to Sun Solaris. A move was made to converge with OpenStep. An open-source version was attepted with GNUstep. Next was founded by former Apple CEO, Steve Jobs, and Next was re-purchased by Apple. The usage of PDF instead of Postscript was used at the heart of the environment. At this point, the NextStep & OpenStep environments were implemented in Apple hardware, from the desktop, to the server, laptop, notebook, and handheld environments.

Vendors dug in their heels, in what is now sometimes referred to as the UNIX Wars. Eventually, concensus was derived between most vendors with the consolidation of OPEN LOOK and MOTIF to Common Desktop Environment or CDE. The tools from Sun's original SunView, which were ported to OPEN LOOK, were ported, using the look and feel of MOTIF. Solaris has since decided to abandon CDE in the mid 2000's.

During the time of UNIX vendors were working towards a new standard desktop, some other desktops have been receiving activity. GNOME was a very important project. GNOME was adopted by various Linux vendors as a default desktop. Solaris adopted a varient of GNOME, called Java Desktop Environment as their standard going-forward environment in mid 2000's.

There was another competing open source environment to GNOME called KDE. KDE was offered as a secondary option on various Linux vendor desktops. Solaris offered KDE as a freeware add-on.

There was a very forward looking attempt at an open-source modern desktop environment written in Java by Sun called Project Looking Glass. The project seemed to die in mid 2000's, possibly from a threatened lawsuit by Apple. Many features later appeared in MacOSX. Other features were later copied into Windows 7.


With so much of the Open Systems community based upon remote devices and servers, it seems incomprehensible that mechanisms to allow simple administration (via TTY, FMLI, XFMLI, and X11) to be replaced by multiple levels of complexity (web server, web browser, XML, AJAX, HTML#, CSS, etc.) HTML was basically a static-page serving system which had been hacked together to become more dynamic, but the efficiency is no where near TTY of X as far as overhead is concerned.

This being said, there seems to be a drive in this community to move towards better user experience, on the desktop, at the expense of their core-constituency on the server and embedded devices.

  • How much of Looking Glass could be reused?
    (The project focus shifted to Project Wonderland, which is now OpenWonderand.)
  • Wasn't there already a significant effort to build OpenStep that could be leveraged?
  • How much of the GUI and Drivers associated with Darwin under MacOSX are OpenSource and could be leveraged?
Since there is a popular and fairly well documented API [for desktops, mobile, and semi-mobile systems], one might think taking an older [OpenStep] code base [from, arguably, the most popular user-facing UNIX systems in the world], and making it an excellent option.

Since Java runs everywhere and it is maintained by major corporations, as well as a fledgling open source project, Looking Glass would bring tremendous revoution to the Open Systems Desktop, and make it current with open source MacOSX as well as propriatery Windows 7.

Architecture Process Proposal:

If this author were involved in the management of this project, a table of access methods would be built (TTY, X11, Display Postscript, PDF, HTTP/HTML, Direct Frame Buffer), table of raw features (line, circle, arc, font, cursor, box, etc.), table of derived features (window, menu, window manager, table wiget, etc.), and design a meta-languge that is both forwards & backwards compatible across the access methods.

This does not mean that every more complex feature would be suppoted by a simpler access method, but at least there should be a correlary to most and a universal benefit to all communities. Resources could then be leveraged from the core-constuency of the Open Systems markets and everyone could take away a benefit to their perspective community & commercial company.


By the way, I love X. The older X based applications were always fast, in comparison to modern toolkit based X applications. Applications built in X ran phenominally fast when ported [without the X protocol] to Microsoft Windows [in comparison to native MS developed GUI's.] Developers made a significant mistake by not concentrating on simplicity & speed when generating newer user experience environments. Every generation of desktop from SunView to OpenWindows, CDE, and GNOME became substantially heavier. Working with NextStep next to a SunView system made the Next platform much more appealing, from a performance perspective as a user.

The lack of decent TTY based GUI interfaces extended to X Windows by Open Vendors created a problem of system administration of servers, routers, firewalls, storage servers, network switches, wireless access points, kiosks, cash registers, etc. These platforms are the core-constituency of the Open Systems world. All of the vendors need to create proprietary menuing systems because of these holes, while they could be spending more time on developing Open Systems instead of this code which should be written once.

Companies like Sun, AT&T, Next, and Apple capitalized on simplifying the user interface [SunView, OpenLook, NextStep, Aqua] in the UNIX world. Newer graphics cards and CPU instruction set enhancements should be make our lives EASIER by removing code, instead of adding code, from the supportable code-base. The fact that people are considering re-writing the entire stack of code from the ground-up to replace X is a key factor that should tell us that something is deeply wrong with our current thinking, understanding of history, and understanding our current customer base.