On Fri, 2005-10-21 at 15:50 +0200, Turbo Fredriksson wrote:
> For the last two weeks, I've been trying to interface the Bacula
> SQL database with SNMP.
>
> The script is now in such a state that it's actually RELEASABLE
> and USABLE....
> Have a look at http://www.bayour.com/bacula-snmp/ for more
> information, files. Especially the README.txt.
At the risk of being a total pain, can I make a couple of
comments. This README talks about problems with large
values (due to a "missing feature"), and later says:
"The file sizes
and baculaClientRetention{Job,File} etc is in KILO bytes,
not BYTES as the SQL data is in. This is because I can't
use a Counter64 ....
As it is now, the value is a Counter32 which is ok."
If these MIB objects are meant to report "single" values
(such as the size of a file), then you probably don't want
to use Counter32. A counter (whether 32-bit or 64-bit)
is concerned with the *difference* between two readings.
A single counter value is meaningless.
I'd suggest you replace these with Gauge32 or Integer32
syntax objects instead, (preferably before you release
the MIB publicly! :-)), depending on whether you need
unsigned or signed 32-bit values.
I'm not sure whether the same applies to the ClientRetention
objects or not - I didn't find the relevant DESCRIPTIONs
particularly meaningful :-)
It's also not true that Counter64 is the only way to report
large file sizes. There are at least two techniques that
could be used to address the 64-bit limitations. One way
(as I think I mentioned on the net-snmp list), would be to
report the file size using two separate 32-bit objects - one
for the lower 32-bits of the value, and one for the higher.
Another technique would again be to use two objects - one
reporting the size of the file in "blocks", and the other
reporting the size of an individual block. That allows
you to handle larger file sizes (at the cost of a coarser
granularity). See HOST-RESOURCES-MIB::hrStorageTable
for an example of this approach.
I must also correct a misunderstanding over the future of
64-bit handling in Net-SNMP pass-through support. It is
true that this mechanism currently only supports 32-bit
values (due in part to the historical background you refer
to). But it is inappropriate to say that:
"Counter64 isn't (and will not) be
implemented in net-snmp"
Firstly, net-snmp *does* support the Counter64 syntax - it's
just the pass-through mechanism where this is currently
missing. Secondly, I'm fairly sure that at some point, we
*will* extend this mechanism to cope with the SNMPv2 additions.
It's been on my ToDo list for a while now.
My words of caution were just meant to indicate that this
was unlikely to happen in the immediate future - not that
we were refusing to fix it. Sorry if I gave you the wrong
impression.
I'll do a proper hatchet job on your MIB when I have a bit
more time :-)
Dave
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
