It may not be elegant, but you can use the arbitrary extension
directives "exec", which is deprecated, and pass to provide disk status
or anything else you can derive at the command line.
These extensions allow you to run a script and assign its output to an
"arbitrary" OID. So if you have a script, utility, whatever, that can
provide status, you can insert one of these entries into your snmpd.conf
file, then poll that OID to get the current status. Example:
pass .1.3.6.1.4.1.2021.1.2021.250.1 diskStatus
/usr/sbin/checkDiskStatus.ksh
The example above isn't real. You would have to have some code to
display the status. However, if you issue the following snmpget, you
will get whatever your code displays.
snmpget -c public -v 2c yourhost.yourdomain.com
.1.3.6.1.4.1.2021.250.101.1
You can also issue an snmpwalk on this to see how SNMP structures the
output of these directives.
It's not as elegant as what you're trying, but you can collect almost
any type of data via SNMP with using a formal MIB.
Michael Peoples
Senior Systems Manager
AT&T - ATTSI
Office: 614-789-8559
Cell: 614-886-0923
FAX: 614-789-8975
mpeop...@att.com <mailto:mpeop...@att.com>
From: Evgeny Nagaev [mailto:enag...@gmail.com]
Sent: Monday, April 12, 2010 5:32 AM
To: Dave Shield
Cc: net-snmp-users@lists.sourceforge.net
Subject: Re: No OID's for hrDeviceStatus in HOST-RESOURCES-MIB of
net-SNMP agent(RHEL, Solaris)
OK, but can you provide me with info about how to extend your sources to
support my own development of hrDeviceStatus support in net-snmp?
2010/4/12 Dave Shield <d.t.shi...@liverpool.ac.uk>
On 12 April 2010 06:30, Evgeny Nagaev <enag...@gmail.com> wrote:
> But can you tell me what is the reason to do so?
Because at the time that I was writing the original code,
it wasn't clear to me exactly how you would detect the
status of a disk (or most of the other hardware types).
> There is no other OID's in
> HOST-RESOURCES-MIB or UCD-SNMP-MIB to determine status of Disks. The
only
> thing we can pool for disks is their usage, that isn't really so
critical,
> much more critical to see if my disks are operating or some of them
crashed
> and without hrDeviceStatus for Disks it is impossible!
Agreed.
I would agree that hrDeviceStatus is an important object.
Which is why we provide a framework for implementing
this across the various types of device.
And as I said last week, if anyone wishes to provide the
necessary code, we would be happy to include it within
future distributions.
> Are you planning to fix this in future releases of net-SNMP?
Me personally? No - probably not.
If someone offers a suitable patch (or even the basis for one),
then I'll be happy to merge this into the code. But I don't
intend to do a lot of work chasing this sort of thing myself.
I put a lot of work into the original framework for the Host
Resources MIB. And for many years, it was basically ignored.
If people feel this functionality is important - it's up to the
wider community to do something about it.
> Another point is that some people fix this by theirselves
Indeed.
And if they feed such fixes back to the project (e.g. via the
Net-SNMP bug or patches trackers), we do usually try and
include them into the code base.
But if they don't contact us, then we typically never get to
hear about such fixes.
> for example, if you go by this link:
>
>
http://137.138.246.63/cern/slc4X/i386/yum/updates/repodata/repoview/net-
snmp-utils-0-5.1.2-13.el4.html
>
> then you will find out that this guys from CERN fixed it and released
it in
> their rpm build.
But (AFAIK) they didn't tell us about this fix, or say that we can use
it.
(I'm probably wrong about this, and there's a patch report
lurking in the depths of the project tracker :-( )
Remember that this is a volunteer-run project, and most of us work
on it in our spare time - in between other, more important and/or paid
work. I simply don't have the resources (or time or energy) to go
browsing the web in the hope of running into useful patches.
Plus it's not always possible to use such fixes directly anyway.
Anything submitted directly to the project is automatically donated
under BSD-style licensing, so we can safely use it. But code
retrieved from elsewhere might potentially be subject to other,
possibly incompatible licensing terms. The project is of sufficient
size, and widespread usage, that we can't simply ignore such legal
niceties. (Tempting as it might be at times)
The bottom line: If you (general) can't be bothered to tell us
about fixes, then we can't be bothered either!
> But the problem is that is for RHEL 4(I have RHEL 4 and 5
> in my infrastructure), and more - it can't be ported to Solaris, where
I
> have the same problems.
And that's definitely an issue for this particular package.
We tend to delve more deeply into the grubby internals of the operating
system than most software does, and rely on very O/S-specific stuff.
So the code for one system is often little or no use on a different one.
The support within the agent tends to be best for systems that
we use ourself. I provided a lot of the early HP support, because
that was the environment we used at the time. We're now primarily
Linux-based, so that tends to be where I do most development.
While I do have access to some Solaris kit, it's not something I use
every day (or even particualrly convenient), so I'll tend to leave
Solaris
stuff for others to work on.
> At the end of the day, can you contact with the guy who fixed this
> problem(in this link there is a contact of him -
jsafranek{%}redhat{*}com )
> and ask for this code to include it in future releases of sources and
> rpm/pkg builds?
Hmmm.... Jan Safranek? I'm sure that name sounds familiar.
But I can't quite place it....
Sorry - I'm teasing you.
Jan has recently become much more involved with the project. And one
of my tasks (once we get the next releases out of the door), is to sit
down
with him and work out some plans for re-working the hrDisk support.
But the fundamental issue remains the same.
In order for the agent to support a particular feature on a given
architecture, somebody needs to take responsibility for providing
the necessary code.
It can't all fall on a small group of two or three people.
Jan and I can probably come up with a framework to make it easier
to support the hrDisk information on a wider range of systems. But
we're both essentially Linux men, so it's unlikely that we can provide
code ourselves for all of the other systems that people might want
to use this on.
>From the FAQ entry on Bug Reports:
But remember that this is basically an unsupported package.
It's Open Source, so if you need something fixing badly
enough, fundamentally it's up to you to do the work.
Dave
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
