I am using some SNMP traps for monitoring of applications. Now I was told that some monitoring systems might have problems if the order of the attributes within the the traps was not the same as defined in the MIB. From the Complexity of the OIDs that could easily be used to re-order the attributes I was surprised by this, so I tried to find the relevant section of the RFC, but I could neither find something that said any ordering is allowed nor anything that said it is important. In other secondary documentation about SNMP I was not able to find anything usefull either.
So this is more a curiosity question, that could however also help in further projects using SNMP. Could anyone point me to the correct documentation as far as this problem is concerned. Or is this something that one software might handle while other software might not handle this and I should check the actual documentation for that software?
I found the relevant document.
Section 3.1.2 specifies:
The VARIABLES clause, which need not be present, defines the
ordered sequence of MIB objects which are contained within
every instance of the trap type. Each variable is placed, in
order, inside the variable-bindings field of the SNMP Trap-
PDU. Note that at the option of the agent, additional
variables may follow in the variable-bindings field.
Thanks to the person who pointed this out to me.
Related
The Problem:
I'm trying to have Puppet manage some of the details of several scheduled tasks without managing whether those tasks are enabled. To that end, I declare scheduled_task resources without any explicit enabled attributes, with the intention of communicating that whether the tasks are enabled is not to be altered by Puppet. Puppet, however, is persistent in re-enabling the tasks on every run, just as if I had specified enabled => true for each of them. How can I make it stop doing that?
Already Tried:
I've considered setting the attributes for each datacenter via hiera, but the reality is that this makes failovers and switches more complicated than necessary. I don't want to change my puppet code every time that needs to happen. I also can't shut-off the puppet-agent runs. I need to maintain the integrity of our rolling deployment system.
Providers?
I've read a little about providers, seems like I can handle the behavior there. However, I'm having a hard time figuring out where there is (if any) documentation that explains how to use them to override specific resource properties.
Notify/Subscribe:
I've thought about using notify/subscribe to only set the triggers to enabled on creation. I'm not thinking this is the right solution, because it's not one resource subscribing to/notifying another, it's properties being set on a single resource. If there's some magical way of doing this or something similar, I'd love to know.
Bottom-line: I just need puppet to create disabled tasks, and let me turn them on/off without changing the state in subsequent runs.
Is there a way to ignore resource attribute defaults in Puppet entirely?
Only by explicitly declaring a value for every attribute of every resource.
But that doesn't seem to be the question you really wanted to ask. You seem to be exploring ways to assign attribute values without specifying them as literals in your resource declarations, and I guess you're looking for some kind of layered approach, with the bottom layer replacing or overriding types' and providers' built-in defaults.
As you thought, you could conceivably do this at least in part via providers. You would need to write a custom provider for your resource type and specify that it be used by each resource instance. But don't. This way is complicated to implement and confusing to anyone who later has to read your manifests (maybe including future you).
Notify / subscribe, on the other hand, are simply the wrong tools for the job. They do not do what you seem to think they do, or perhaps you just haven't thought that idea through.
I think you're selling Hiera short and / or inappropriately minimizing the complexity of the task. Probably a mixture of both -- I'm inclined to guess that Hiera can do more for you than you appreciate, but also that the complications you envision will manifest to some extent, in some form, no matter what you do.
Nevertheless, there is an approach that seems to match pretty closely what I think you want: resource default declarations (I link to the latest docs, but this feature is present, in substantially the same form, in every Puppet version released in at least the last nine years). Thus, you might cause all scheduled_task resources to be disabled unless you explicitly say otherwise by putting this resource default declaration at an appropriate place:
Scheduled_task {
enabled => false
}
When choosing where to put such a statement, do note that, unlike anything else in modern Puppet, resource default statements have dynamic scope. The manual discusses that in somewhat more detail.
Revisited:
In light of the clarification of the question, I'll clarify that resource types' providers are where resource management behavior lives. Therefore, if Puppet's behavior on target machines is not what you want in the event of an altogether missing property declaration, then modifying the provider or writing your own are pretty much your only alternatives. Of course, if you have a support contract then perhaps you don't have to do that in-house.
If you don't want to hack on providers -- an altogether reasonable position -- then you're left with managing the properties to their desired values. Supposing that you employ Hiera effectively, however, you should not need to modify any manifests to control which servers have their tasks enabled.
I am trying to make a snmp trap receiver, that can capture all the incoming snmp trap from UDP 162 port and translate them into meaningful alarms. The image I attached is a sample trap that I captured using wireshark.
My script can capture and parse all different parts of the packet, but I got stuck in the variable binding section. Im not sure how I can re-present this section into some user friendly information (that I can show in the user interface). How do I know these sequences are sending something alarming or just some general information regarding the agent node? are these sequences independent information each or together they are forming one piece of information?
As with any incoming data, it is important to know what kind of info you are getting. The variable bindings of an SNMP trap is basically a hierarchical piece of data. Every object or element represents it's own data. If you take the first element (1.3.6.1.2.1.1.3.0) you will find that this contains the sysUpTime (see link), which is pretty general.
Most of the other elements seem to start with 1.3.6.1.4.1.4421 which appears to be object from a specific vendor; Santera systems (see link). You might want to try and contact them in order to obtain their MIB (Management Information Base), which should have details on what kind of data is shown in these fields.
It might be possible to find info like this online, have a look at the XML-files on this link.
I'm investigating HL7-FHIR for use in a decision support context and was trying to find out how to extract accident information for a given patient. I had assumed this would be a resource type but I can't find anything that fits.
We don't have a specific resource for this information. Mostly, this sounds like a series of observations, and perhaps a context linking them together. It's the context piece that we haven't yet got (our initial focus was on PHR). That will definitely be in the next version, but for now, I guess you just use the observations directly
I have developed a Linux/Umbutu program running on what will be an imbedded P-based device. I wish for that piece of code to be able to send and receive the SNMP data for the entire product. So, I know the OID down to the company level, 1.3.6.1.4.1.34843, and I further know that the two SNMP enabled products we sell are 1.3.6.1.4.1.34843.1 and 1.3.6.1.4.1.34843.2. Pretty sure mine will be .3.
The question is, is there a known structure/convention for the nodes below this point? What I read seems to imply that I can use whatever structure I want. Would ...34843.1.0 exist? Is it a node to fetch (get) the list or max-count of same-level nodes? Would ...34843.1.0.0 exist? Would it make any sense? The guy who developed the first two MIBs is out of town for a while and I can't really ask him, and I'd like to make sure I understand his answer when he gives it to me.
Is there a document that describes the required/suggested organization? Probably some RFC, right. So, is there a document in a language spoken by humans?
Thanks in advance.
The most popular resource is the understanding SNMP MIBs book by Perkins and McGinnis. It describes MIBs in a more readable format. The Net-SNMP tutorials online might be helpful too, as they discuss a lot about MIBs. If you want the RFC, then RFC2578 is the right thing to read.
The quick hierarchy guidance would be something along the lines of:
Use 3 sections: one for objects, one for notifications, and one for conformance information
For notifications, root them at the .0 (see RFC3584 for details on why)
For each table, you might want a scalar showing the number of objects in a table and potentially a LastChanged object for showing how frequently configuration within the table might have changed).
There is a lot more guidance that can be found in the books and other sources listed above than can be repeated here, of course. RFCs 4181, and 5249 may be helpful as well.
I know a little about SNMP, but not enough. I need to develop an application that can read standard SNMP MIBs and read/write the various properties. The network end is no problem, but the actual MIBs and exactly what they may contain is something of a black art to me.
I believe I should be able to use LIBSMI to 'parse' the MIBs, but I don't really understand what the output of the 'parser' is going to be, and how best to use it.
All suggestions welcome...
At the risk of throwing you in the deep end, you might want to take a look at net-snmp. The default installation contains a number of standard mibs with their associated implementation. It also contains a utility (mib2c) that will generate boilerplate code from your mib files.
Once you've read your way through a couple of mibs you should have no trouble familiarising yourself with the way that snmp does things.
Most standard MIB documents were defined in corresponding RFCs published at IETF.
http://www.ietf.org/
Please go to this site to find more details.
Muonics Mib Smithy User Guide provides a good overview of how to build a MIB, which can help you understand the necessary elements for parsing.
You should also look at the ASN.1 ITU specification X.690, because that is the language SNMP is defined in. It also helps if you scour the SNMP RFCs for any Bachus-Naur formatting in the SNMP RFCs. I'm going to suggest you start with RFC3642 and RFC2252.