From: announce-admin@opennms.org To: announce@opennms.org Subject: [OpenNMS-Announce] OpenNMS Update v2.18 Date: Tue, 1 May 2001 23:58:49 -0400 (EDT) ==================== OpenNMS Update ==================== Vol 2., Issue 18 ==================== May 1, 2001 ==================== In this week's installment... * Project Status + New Team Member + Have Brain, Will Travel? + 0.7.4 -- Crouching Tiger, Hidden Release + A Peek inside the SCM Configuration File + Coding Projects Underway * Upcoming Road Shows * Early Adopter Program Status * The Wish List ============== Project Status ============== New Team Member: It's with great excitement that we announce the addition of Seth Leger to the OpenNMS team. Seth comes to us battle-scarred-but-wiser from the dot-bomb fiasco (which while it was upsetting for the economy, it has certainly helped recruiting efforts). Seth has previously done Java/C/C++/XML work at another local used-to-be business, and has done some QA work for everyone's faves Rational, as well. For someone reasonably fresh out of academia, Seth brings some good experience, lots of hands-on with Linux, and bagels all week next week. A big ol' Hee-Haw salute to Seth: Sa-Lute! Have Brain, Will Travel?: For anyone interested, it appears that the "Help Wanted" sign is going back in the window for a consultant-type. If you are willing to travel, know network management, know Linux, and can perform miracles under extreme pressure (or caffeine-induced hallucinations), send your resume to me at shaneo@opennms.org. If you've submitted a resume previously, you will be considered. If you don't get a call, it's strictly because we have very poor resume-screening skills and/or we can't read. It has nothing to do with you at all. If you want to call to apply, don't. Just send a resume. I'm reasonably good at email, and most generally reply if I get something from you. For priority consideration, print your name and phone number on a fifty dollar bill and send it via snail mail. This offer valid in 49 states (sorry Tennessee). 0.7.4 -- Crouching Tiger, Hidden Release: As promised 0.7.4 was assembled and built late last week. However, if you feel like you missed the announcement, it's because there was none. 0.7.4 ended up being a synch point for the internal team moreso than a release prepared for distribution. While there were some new features that could have been released, there were also some half-baked features that would have caused more problems than they would have solved, and the confusion factor would likely have gone through the roof. Hell, I'm still confused about part of it. So instead of publicly releasing 0.7.4 (which you can still get via CVS, if you are so inclined), we'll be resting on the laurels of 0.7.3 (which is currently the release installed by the web installer) for a little while, allowing us time to finish up the features we are working on, as well as do a little more testing. So why all the hub-bub about something that isn't? Sowmya is now officially on vacation, living it up on the sunny streets of Madras. But before she left, she did some significant reconstructive surgery on the RTCVCM that we've been testing. While her efforts were necessary, they were "Stage 1" efforts in a sub-project that improves our ability to calculate availability and provides better information via the user interfaces. So we need her stuff in and settled down before we proceeded. It's now in and settled down, so now we shall proceed. A Peek Inside the SCM Configuration File: Since we've discussed some of the dependencies of the start-up process (see http://www.opennms.org/sections/updates/update0217.xml), I figured that now was a good time to see what's happening behind the scenes with the cryptic "./opennms.sh scm start" command. So to explore this, let's look at the file that drives it -- scmconfig.xml Before anything else, a tip of the hat to the author--Weave. SCM is a marvel in its abstraction of its complexities, and it's configuration file continues those ideas in turn. Once we get into it a little bit, you should start to see some of the subtleties that make this thing so cool. But enough on how cool it is. Let's see what the file does. As with all of our config files, scmconfig.xml is in the /opt/OpenNMS/data/common/conf directory and is in (big surprise) XML format, with a DTD included at the top of the file. The main building block of the configuration file is the <service> element. A <service> block is made up of several subelements: * <svcid> This element defines the ID that is used by SCM to uniquely identify the service. You've probably seen this value as part of the output of the "./opennms.sh scm status" command. You can also use this value to issue commands directly to services from the command line. But that's another topic for another Update... * <svcname> This element serves as a descriptive name and was implemented for future use in a graphical SCM manager. There is no real programmatic use of the svcname today, and both null and duplicate values are currently acceptable. * <description> You hereby are given the benefit of the doubt, and I won't explain what this element is. I will note that this element is optional within a service block. * <exec> This is where things start to get interesting. The exec element defines a block which indicates whether the process is a native Java process (jproc) or an external, non-Java process (extproc), although support for external processes is not yet implemented. Another interesting thing is that the jproc element carries an attribute of "jvmid", which allows you to specify a specific Java Virtual Machine (JVM) in which to run this process. SCM is smart enough to discern, by the names associated with the various jvmid attributes, how many JVMs will need to be started to facilitate the start-up of all the Java processes. Pretty slick. The jproc block contains up to four elements: + <class> The class name which serves as the entry point for the service to be fired up + <classpath> This is a shell-style ${variable} which gets substituted by the corresponding value from a property file. An interesting way to abstract away the jar file path and name. + <parameter> A simple mechanism to pass any parms that the respective process might need. + <property> The relative path (from the OpenNMS install directory) of the property file used by the process, including the values that will be substituted into the classpath element above. * <service> What?!? A recursive XML element?!? Basically, yes. This is how Weave constructed the ability for processes to be interdependent. By listing the process earlier in the file, you are guaranteed that the process will receive a "start" message prior to one listed later--everything is started serially. However, by nesting processes, you now have the concept of "peers", or processes that will be started even if others at the same level fail. And services that are nested within other services won't be started if the process at the higher level fails. It makes sense, trust me. So with all this mentioned, why then does it matter? If it is set up right at install time, why should you have to mess with it? Good question, with a simple answer--most of you won't. However, if you choose to write your own poller or add a configuration around a TCPPoller, you'll need to be able to add it. Sure, you can copy a pre-existing config and morph it to work for you, but as with anything, it's much easier if you know what you're doing. Or so that's what people that know what they are doing tell me... Hope this helps, and as always, take your questions and comments to the [discuss] list. Coding Projects Underway: * CDP/L2/Mapping -- Pete is alive and well and getting into CIM and DEN. Neat technologies that are dying for someone to implement them. Pete's the man! * Snort Integration -- Good news: Matthew is back from vacation. Bad news: still hasn't had time to brain dump. * Solaris Port -- Ben's got everything working with Solaris8 on Intel, but no formalized pkgadd kind of stuff (nor should you expect anything soon). If you have questions, take them to the new [install] mailing list. Details below. * NT/2K Port -- No update. The concerns are still with some of our dependencies. * SNMP Poller/Data Collection -- Some updates to DataCollection.xml to handle 3Com and the HostResources MIBs. * Logging (Conversion to Log4J) -- Seth is on this like a cheap suit. * User Interfaces -- This is the week for Jacinta to shine. She is now generating PDF based availability reports that will be available in the Web UI with the 0.7.5 release. Woo-hoo! * Configuration -- Jason is working on an event configurator that will plug into the Web UI. When he's not fixing Admin GUI bugs... * Discovery/CAPSD/Database Review -- Mike's dreading Sowmya's vacation. Enough so to schedule his own vacation over the same timeframe. Just not for the same length... * Agent Technologies -- The update is that Scoreboard has "re-deployed" Craig for the next few weeks, putting the agent effort on ice in the interim. * Reporting -- See note on Jacinta above. Anybody done any graphs in FOP? * Development Environment -- Ben is starting to work on Tinderbox and LXR again. =================== Upcoming Road Shows =================== In case you've never seen us live and in person, here's your chance: * May 4th - Shane's free for the evening in the Twin Cities - Anybody interest in dinner/drinks? * May 5th - Twin Cities LUG, Minneapolis, MN * May 10th - Boulder LUG, Boulder, CO * June 1st - GNU/Linux BBQ!! Drink good beer and eat fire. * June 2nd - Northern Virginia LUG (NOVALUG), Alexandria, VA * June 13-14 - OpenView Forum 2001, New Orleans, LA * July 25 - O'Reilly Open Source Convention, San Diego, CA * August 28-30 - Linux World Expo, San Francisco, CA (BOOTH) For additional details on these appearances and others, check out the web site at http://www.opennms.org/sections/opennms/events ====================================================== Early Adopter Program Status - Courtesy Jeff Schneider ====================================================== A slow week in the Early Adopter world, but there is one thing to mention. We now have a report of some specialized equiptment not responding well to our Capability Scan (No, it's not a fancy name for a reboot call). We're currently reviewing possibilites for handling this while we wait for more information. The most likely candidates are methods to exclude certain devices from capability rescans. Note to Bill: Please pass along a network trace of just why your boxes are going south. We're guessing it's a spinning ifTable, but we can't know for sure without the trace. Thanks! Tip of the week: Log file "verbosity" can currently be set in the $BB_HOME/data/common/properties/bluebird properties file. There are entries for all the processes located toward the bottom of the file. To put a process in "debug" mode, you would set the logLevel to 5. Soon, the "verbosity" will be moved to individual properties files for the process, for example, $BB_HOME/data/common/properties/rtc. In the comments, you'll find new logging levels, the highest being "debug". ============= The Wish List ============= And now, on with the list... * Help with doc. Help with doc. Help with doc. * In the 0.7.x release (and CVS), checkout the TODO file * Testing on notification * New Data Collection configs wanted for the DataCollection.xml * Build some event configurations. * Any interest in more TCP pollers? Let us know (or better yet, build one yourself...) * LDAP/POP3/nmap Pollers * Documentation and development your game? How about a white paper on how to extend OpenNMS with custom pollers, custom configs, and/or your own scripts/code. * Any additional help we can get proving our documentation either right or wrong is appreciated. Thanks. * Got any creative applications for OpenNMS that we haven't considered? Let us know! * A Security analysis of OpenNMS? ============= Afterthoughts ============= As promised last week, the mailing lists are changing and we are adding an [install] list. An ideal place to separate out installation specific questions from configuration and use questions, this list will be dedicated as a support forum. Your help in providing this support is always appreciated. And will somebody please tell Jason that if you decide to cut your hair exactly like Shemp Howard, you can't blame people for noting that you've cut your hair exactly like Shemp Howard. And of course, I've got a shiny new haircut as well. Not quite as much Shemp as it is... Lee Harvey ========== Shane O'Donnell OpenNMS.org shaneo@opennms.org ================== -- Shane O. ======== Shane O'Donnell OpenNMS.org shaneo@opennms.org ================== _______________________________________________ announce mailing list (announce@opennms.org) To subscribe, unsubscribe, or change your list options, go to: http://www.opennms.org/mailman/listinfo/announce