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
