Database Testing

Jeff Weisberg jaw+arguslist at
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
| least).

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:
| 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 mailing list