Todd -
I almost hesitate to respond because you are already so bitter about this,
I don't think you are willing to accept an opposing point of view.
But I will try to answer your concerns as best as I can and from my
perspective, not from Tivoli/IBM's. Remember that these are my opinions
alone and do not necessarily represent those of the company. If you
dislike what I have to say, or if you think I am a jerk for what I have to
say, well so be it. But let's leave it that. Even if I disagree a
little here, I don't want any flaming notes to go to my manager accusing me
of not being customer oriented. I am trying to help, if only by trying to
lessen your frustration a little bit by showing you why things aren't
always done the way you'd have done them.
Rulesets are a programming exercise and what is recommended is that you
create a program which is right for your environment.
There is no canned rulesets (other than forwradall.rs) for forwarding to
TEC because everyone wants something different.
But you are right -- you only get one to use one ruleset to forward to TEC,
if you use the internal adapter, and there is no good way to build a
complex one, except as everyone has already suggested. That is to build it
pieces and then use File--Insert in the ruleset editor to pull them all
into one big one. Yes the result will be complicated. But you should not
be trying to open one on a GUI across a WAN, any more than you should be
trying to open the NetView map that way. We expect direct LAN access to
the server for GUI operations and always have. If you have to administer a
remote machine under other circumstances, then I recommend that you ftp the
ruleset and open it locally. It will work the same way when you ftp it
back.
Why don't we document the ruleset syntax you ask? For the same reason we
don't document the exact syntax of trapd.conf. The great virtue of the
ruleset editor, besides it's ease of use, is that it uses the same
foundation classes as nvcorrd. This guarantees that if you can build the
ruleset with the editor, then you can load it and run it with nvcorrd.
That eliminates a whole host of user problems for us to have to try to
solve. We don't have to write all kinds of fail-safe error checking and
messaging to tell users what they have done wrong in building their
rulesets, and it keeps nvcorrd from coring because of weird inputs. Not
that it doesn't core. I've fixed some beauts. But there are a whole class
of problems it doesn't have that it would have if users just typed their
own syntax. You can still try that if you like. Some people have,
especially on NT, where their is no ruleset editor. And it's not too hard
to figure out if you are willing to build a simple rule, examine the rs
file, change it and examine it again. But ultimately the acid test is
whether you can load your file in the editor without problems. If you can,
great; if you cannot, then it is not supported, and you have to rebuild it
until you can load it.
Now as for using the facilities of NetView to forward to TEC, NetView gives
you tools, but doesn't tell you how you must do it. There are lots of ways
to skin this cat, each with advantages and disadvantages. Different people
like different ones. But basically there are two ways.
(1) You create a single ruleset, perhaps a pretty big one, and you define
that in tecint.conf. The internal TEC adapter insides nvserverd does the
forwarding for you and he adds the slot maps and TEC classes as defined in
trapd.conf. This is easy to set up because it uses the GUIs for
everything. But there are limitations to the architecture and they are not
likely to be changed any time soon. In the ruleset itself, if you don't
like the programming mechanisms provided, you have a roll-your-option
called an Inline action. This is very useful, because nvcorrd can use it
as a pass/don't-pass filter on whether to send the event in question, but
as it holds up all other processing of events by nvcorrd, you will want to
make it both simple and fast. Because as the name implies, inline actions
are done in-line, that is by nvcorrd. When he comes to an inline action,
he stops whatever else he is doing and executes it, so it is up to you to
make it fast, and to tell him how long to wait before continuing if there
is a problem. You can use this to make nvcorrd check anything you want
him to check before continuing. You could have a simple ruleset here --
one which just called your Inline action -- and then was followed by a
Forward. All other events would be blocked. That's why I suggested the
grep, because it would both simple and fast. You could combine it with
other processing, too, of course,but if the idea is to keep your ruleset
simple easily maintainable, this might be what you should do. But the
performance impact depends on your environment. This is something you have
to examine yourself. Like any other programming choice it depends upon
your environment.
(2) Contrast this to the other method. You could use wpostemsg in an
Action Node. Actions in an action node are not executed by nvcorrd but by
actionsvr. You can think of these as "sidestream" because they do not
affect nvcorrd's ability to process the next trap. He just throws the
action over the fence, so to speak, and goes on. A new process is spawned
for every action, so they independent of one another. UNIX is very good at
handling a lot of processes. You are more in control here because you
specify each posting specifically, telling it exactly what to send, and now
you are not dependent on trapd.conf. You can control the whole thing with
your own scripts and files which you move from machine to machine, but
there will be more of them. The plus side is that you can have as many
little rulesets as you like run out of ESE.automation. You don't use a
Forward here at all -- from an event stream with the default action set to
"block", you'd probably just have traps settings, or event attributes, and
possibly thresholds, and then terminate with the action node with your
wpostemsg command or script in it. There are no Forwards because you are
not forwarding anything to another daemon or display. You are simply
calling an external process. Is this better for you?
Your choice. I have seen both methods used successfully by administrators
of multiple NetView machines. You are not alone.
Got questions about ruleset coding? Feel free to ask them here. Lots of
other users are doing it the same way no matter which you choose. Also you
might want to take a look at some of the redbooks which IBM has published
on using rulesets and on integrating with TEC. Go to
http:/www.redbooks.ibm.com and search on NetView. Don't have time for
that? Then ask away. But you will still have to develop your own
preferred method.
Hope this helps.
James Shanks
Level 3 Support
Tivoli NetView for UNIX and NT
Tivoli Software
IBM Software Group
Please note that my new id is jshanks@us.ibm.com
|