Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
12-28-2014, 08:36 AM
|
#1
|
LQ Newbie
Registered: Dec 2014
Posts: 3
Rep: 
|
net-snmp contextName vs a complex index
Hello,
I have a general net-snmp question. We are implementing a kind of 'generic' MIB, to be used by 'generic' NMSs. The general structure of the MIB is a table of NEs (Network Elements), each has its own unique name, and then a table of MOs (Manageable Objects) of each NE.
We are considering 2 alternatives:
1. The access to the MO table will be carried via a net-snmp contextName determines by the NE's name. i.e. the index of the MO table will only be its ID (MO ID, a integer), while having to create and register to each MOs table a contextName.
2. The access to the MO table will take place via a index which is a bit more complex (NE ID, MO ID, both are integers)
Thanks,
Gonen
|
|
|
12-29-2014, 10:21 PM
|
#2
|
Senior Member
Registered: Jan 2009
Location: RHELtopia....
Distribution: Solaris 11.2/Slackware/RHEL/
Posts: 1,491
Rep: 
|
Gonen,
Did you have a question?
I'm not a fan of random folks just deciding to re-write underlying environmental structure because they decided it looked like a thing they'd like to do. Oddly enough, the rest of us invariably don't share that feeling, however, if you have a question, we do answer those.
|
|
|
12-30-2014, 03:10 AM
|
#3
|
LQ Newbie
Registered: Dec 2014
Posts: 3
Original Poster
Rep: 
|
Dijetlo,
I can't remember a rude response like yours,frankly.
Yes, I have a question, and it was stated very clear, the need to choose between 2 coding options, why don't you just anser it if you can contribute ?
TRhanks,
Gonen
|
|
|
12-30-2014, 07:00 AM
|
#4
|
Senior Member
Registered: Jan 2009
Location: RHELtopia....
Distribution: Solaris 11.2/Slackware/RHEL/
Posts: 1,491
Rep: 
|
Quote:
I can't remember a rude response like yours,frankly
|
That actually has more to do with your memory than my response.
Quote:
...why don't you just answer it if you can contribute ?
|
OK.
Don't waste the time.
The fact that MIBs are named in a non-intuitive manner is really only a problem for noobs who haven't figured out that you don't have to remember the MIB addresses, you can load them in a spread sheet and reference them that way.
Honestly Gonen. If all you're doing is renaming MIBs, why bother?
|
|
|
12-31-2014, 12:16 AM
|
#5
|
LQ Newbie
Registered: Dec 2014
Posts: 3
Original Poster
Rep: 
|
I been writing SW for almost 30 years, at least some of it around snmp.
The new stuff for me here is using contextName, I'm implementing this specific MIB using mib2c, and it seems that things tend to be complicated when a table is accessed using a contextName.
Therefore I'm considering if it worth using a bit more complex index to the table rather than a contextName.
Can you help with that?
Thanks,
Gonen
|
|
|
12-31-2014, 04:56 AM
|
#6
|
Senior Member
Registered: Jan 2009
Location: RHELtopia....
Distribution: Solaris 11.2/Slackware/RHEL/
Posts: 1,491
Rep: 
|
Probably, since I've worked with networks, servers and SNMP as long as you've been developing software.
However, my suggestion remains the same.
I think the point your missing here, Gong, probably because you are a developer and not an engineer, is in the world of the engineer, most people don't ever see the MIB name, much less the table designation for the MIB. What they see is a little red ball lighting up on their monitor beside a server name. I have to figure out exactly why, so I have to know the OID/MIB designation, but in a staff of a hundred plus folks, there aren't 10 who even realize that what makes the red ball light up is an snmp trap popping on the server.
What I'm saying is you can do it, it's certainly not hard to come up with a naming convention less counter-intuitive than the one UC Davis picked but to what end? A LOT of software relies on the SNMP OID/MIB structure remaining relatively unchanged.
Besides, the naming convention is not the primary problem with SNMP ( for my money, if you want to fix SNMP, figure out a way around the connection less nature of the SNMP trap alert)
|
|
|
All times are GMT -5. The time now is 02:17 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|