Date: Tue, 19 Dec 2000 21:21:33 -0600 (CST)
From: announce-admin@opennms.org
To: announce@www.opennms.org
Subject: [opennms-announce] OpenNMS Update v1.39
OpenNMS Update
Vol 1., Issue 39
In this week's installment...
* Project Status
+ More 0.4.x Info
+ Getting Things Right
+ Coding Projects Underway
* Curious Bostonians?
* New Features En Route
* The Wish List
Project Status
More 0.4.x Info:
Effective today, 0.4.1 has been released, and it incorporates
fixes to a couple of bugs from 0.4.0. If you haven’t gotten it yet,
and you aren’t heavily invested in your 0.4.0 install yet, make
life easier for yourself–download the RPMs for 0.4.1 and install
those.
I also wanted to take a minute and address some of the more
common questions that we’ve been getting. These answers will be
pushed into the FAQ at some point, hopefully sooner than later.
* Minimum System Requirements
P200, 256MB RAM, Linux, JDK 1.3+, OpenNMS
Yeah, it’s a memory pig, but this is effectively an untuned
first release, so we’re looking at that. And don’t forget, this is
intended to scale WAY up, so it’s going to need more system
resources than office apps. Look at the bright side, memory is
cheap
* Starting Things Up
0.4.1 includes the latest and greatest init scripts, which Ben
is quite proud of and embarrassed by, all at the same time. Big
thanks to those of you that contributed code and ideas and fixes
for our earlier scripts.
Also, keep in mind that OpenNMS is expecting the following rough
order for firing stuff up:
+ Postgres 7 is running
+ icmpd is running
+ /opt/OpenNMS/RunSCM.sh
+ /opt/OpenNMS/RunOpenNMS.sh
* Troubleshooting
If it is just not working, you can help everyone out a bit by
enabling a higher level of logging. This is pretty easily
accomplished by mucking with the “bluebird” properties file in
/opt/OpenNMS/data/common/properties/. Find the section on logging,
read the comment block, and then change the “logLevel” entries
appropriately. Also, note that the logs get written to
/var/log/opennms/.
Consider yourself forewarned: We enabled maximum logging on
discovery and let it run over night. In doing continuous discovery
of a small subnet overnight, our log file was over 70MB by the next
morning. Make sure you have plenty of disk space if you decide to
turn this on!
* Typical Errors
Depending on available system resources, we do generate errors
that have become pretty common for us, at least in our little
development testbed.
JSDT Timeouts: Typically indicates that for some reason the JSDT
Channel has gone away. Happens more often when you are constrained
for memory/resources.
JSDT NoSuchChannelException: Typically means that you’ve either
tried to start things out of order or something has mysteriously
gone away while you weren’t looking.
* Buttloads of Java Processes
With the way Linux handles Java’s native threads, every thread
shows up as a separate process to “ps”. In limited testing, it
looks like a lightly loaded system will have around 420-450
processes alive as it runs. You can count yours with a “ps -ef |
grep -i java | wc -l”. It may not be an official count, but since
the electoral college has already voted, it really doesn’t matter
anyway…
And yes, “Buttload” is the scientific term for over 300 and less
than 1000 (in a process-counting context).
Getting Things Right:
This interim “Testdrive” release has proved to be a blessing in
disguise for many of our efforts. It seems that what we’ve been
missing to date is user feedback. Until this release, that was
impossible and now, we’re starting to see some things that we
didn’t consider earlier.
As a result, we’re changing up our development efforts a little
bit to continue to focus on some of the problems inherent to the
Testdrive release that will impact the project moving forward. This
will change our delivery timeframes for the distributed
architecture to some extent, but it also ensures a much sounder
release when distributed architecture is announced.
Some of the things we’re adding back to the development “To-do”
list includes performance data collection, easily customizable
pollers, white papers that provide a HOWTO on writing custom
pollers, and perhaps some further discussions on adding a web
interface. You ask–we deliver. Who could ask for anything more?
(Other than Toyota, of course.)
Coding Projects Underway:
* Servlets — Actively working on building/tuning the
“extractors”.
* SCM — Jason is introducing Pause/Resume functionality for the
schedulers. Once complete, we’ll instrument all SCM processes with
this ability.
* TCP Poller — Mike is working on a generic TCP service poller
that will read an XML file for its configuration (port info, banner
description, etc) and poll based on your configuration. Makes it
easier for you to poll your custom services and applications.
* Maji Prelim Work — Rick is active on the “events” mailing
list.
* Distributed Architecture — Work continues…
Curious Bostonians?
Are you in the Boston area? Are you curious about OpenNMS from a
technical/business/strategic perspective?
Luke “Flip-flops” Rindfuss and I will be in the Boston area and
thanks to our ever-accommodating friends at the airlines, we have
the afternoon free on Thursday, Dec 21, 2000.
We can handle just about anything you’d like to do/know/argue,
so if you are looking for a presentation, a conversation, an excuse
to exercise your expense account, a way to kill the afternoon, or
you simply want to see the winter flip-flops, please advise.
So if you’d like to hook up, let us know. Otherwise, the airport
bars stand to make a killing.
New Features En Route
As mentioned earlier, we’ve got some neato stuff in the works.
Here’s the 50,000 foot view:
* Generic TCP Poller: Poll services running on the port you
configure, looking for the response you configure to expect.
* Portable Agent Technology: We’re early in the process of a
collaborative effort with another open source project to provide an
“agent” that will run on your systems to provide you a means to
remotely gather performance and system “health” information.
* Performance Data Collector: joeSNMP has been around for a
while now, and we’re just about ready to push it into use. We’ll be
building a configurable SNMP poller that will grab the various data
points we (or you) want and will slam them into a back-end
performance database.
* Distributed Architecture: This is a major effort and I didn’t
want to leave it out. But the major buzz we’re hearing now suggest
that some of these other items may be of greater importance to the
community at large, so we’re not abandoning those in lieu of the
Distributed Architecture. It seems our full plates just got
moreso.
* Reporting: The data collection piece doesn’t make a whole lot
of sense without the means to report on that data. This effort has
been underway for a while, but will require a slight dusting off
before we delve back into it. The good news is that some of the
XSLT stuff has revved since we were into this before, so some of
the bugs have likely been addressed.
* Bug Fixes: As you’d likely surmise, with actually having a a
functional product out the door, some people are finding bugs and
we’re doing our best to get those fixes prioritized and into the
system where appropriate. Note that if the bugs are related to some
throw-away piece of the software (e.g., something that was written
to get the Testdrive release out the door and is not there for the
long haul), then there’s a pretty good chance your bug will be
prioritized as “WONTFIX” and you’ll hear very little back. The good
news is that you’ve got the source and you can fix your own bugs if
it comes right down to it. Open Source Rocks!
The Wish List
Given that the entire newsletter was pretty much dedicated to
some of the new efforts/features/fixes we’re working on, a Wish
List seems pretty redundant at this point.
That said, I elect to forego the Wish List this week.
If there are features or fixes you’d like to see incorporated
into upcoming releases that I’ve not mentioned here, please let me
know. You can reach my jam-packed email box directly at
shaneo@opennms.org .
Afterthoughts
I like the thought of Christmas and all, but man, it’s hell on
productivity. And it seems like when I do finally get a little bit
of time to myself, I’m either decorating something or buying
something or going somewhere, all Christmas related.
Here’s an idea: how about we spread Christmas out over a few
months, and let’s get it away from New Years and Thanksgiving–how
about late March. Now there’s a month hurtin’ for a holiday (Work
holiday that is. I’ve been lobbying for March 18th as Hangover Day,
but haven’t gotten far. Although I haven’t approached Teddy Kennedy
yet…but that’s a different story)
Anyway, we move Christmas to late March (OK. Prove it to me that
Jesus was born on 12/25 and I’ll back-off). Then, we put into place
a set of very particular rules about how it is celebrated. First
off, no “Eve” celebrations. Day of. Nothing else. Next, no
decorating allowed. Trees are allowed, but only fake ones. No more
of this “Killin’ trees for Jesus” crap. I’m no tree-hugger, but the
whole tradition does seem rather insane when you think about it.
And finally, all celebrations on the day of New Christmas must be
in one location and one location only. If you have multiple places
to go (your place and your significant other’s place) pick one and
stay there. Tell the other folks that you’ll go there next year and
that they should know the rules.
In my mind, anyway, this buys us back time, productivity, and it
gets us a holiday in late March. Come to think of it, why don’t we
just make it March 18th. We can kill 2 birds with one stone, and a
lot fewer trees.
Color me outta here,
Shane O.
========
Shane O’Donnell
OpenNMS.org
shaneo@opennms.org