Database Testing

[Jeff Weisberg]

| 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).
| http://www.jeremykister.com/jeremy/code/argus/arguscgi-3.3_RC-20040217.expand_debugging.patch

if the field is large, you can use argusctl to fetch it
	argusctl getparam object=Top:Foo:Bar param=db::rbuffer
or
	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


	--jeff