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
