jaw+arguslist at tcp4me.com
Thu Mar 4 16:13:50 EST 2004
| Interestingly, when i did use the incorrect password to connect, the service
| showed as down (as expected), but Argus did not show me the reason (ie: bad
| credentials) -- even though i have 'showreason: yes' in the config.
hmmm. I'll look into that.
| which are only some of the values. since db::rbuffer is displaying these
| values in a different order than my perl is, i cooked up a quick patch to
| arguscgi that expands the debug info when ". . ." is placed on the end of
| the string, when you hover your mouse over the debug text (using MSIE, at
if the field is large, you can use argusctl to fetch it
argusctl getparam object=Top:Foo:Bar param=db::rbuffer
argusctl about object=Top:Foo:Bar
| the entire db::rbuffer contains:
| mysql.example.net user 3306 60 host1-bin.002 276511 host23-relay-bin.001
| 3096735 host1-bin.002 Yes Yes dns,isp 0 0 276511 3096735~x0A
| Without having the key/value pairs to test against, and since it is safe to
| assume that the values i am looking for will no doubtedly shift around for
| one reason or another (such as one of the values being null unless there was
| an error at some point), i am weary in using "expect: Yes Yes"... are my
| concerns founded?
argus should be keeping them in the order that the database
returns them, but I don't know how consistent mysql is.
I'm open to suggestions for argus doing something differently
More information about the Arguslist