10 More Discussions You Might Find Interesting
1. UNIX for Beginners Questions & Answers
I need to configure snmptrap on rhel 8 server and send trap to nimsoft for file system , memory and cpu load and network diconnection status.
please help me, if any one configured. (1 Reply)
Discussion started by: yash_message
1 Replies
2. Solaris
Hi,
I've installed Solaris 11.3(live media) and configured DNS. Everytime I reboot the server, resolv.conf got deleted and it created a new nsswitch.conf.
I used below to configure both settings:
# svccfg -s dns/client
svc:/network/dns/client> setprop config/nameserver = (xx.xx.xx.aa... (1 Reply)
Discussion started by: flexihopper18
1 Replies
3. Shell Programming and Scripting
Hello all,
Newbie here.
I'm currently tasked with updating rsyslog.conf and auditd.conf on a large set of servers. I know the exact logging configurations that I want to enable. I have updated both files on on a server and hope to use the updated files as a template for the rest of the... (3 Replies)
Discussion started by: Mide
3 Replies
4. UNIX for Advanced & Expert Users
I have configured snmptrapd to log the traps to log file. the traps received and logged ok based on the mib file definition.
there is only one problem.
the value of one of the variables seems to be truncated due to end of line or some special char.
linux is centos 6.2
snmp software... (4 Replies)
Discussion started by: ahmad.zuhd
4 Replies
5. UNIX for Advanced & Expert Users
Hi everybody,
I'm trying to run a SNMP supervisor on Debian Lenny to supervise Uninteruptible Power Systems which support SNMP. I've installed snmp and snmpd debian packages for NET-SNMP 5.4.1 et i've configured /etc/snmp file with the snmpconf perl script :
file /etc/snmp/snmp.conf
#... (0 Replies)
Discussion started by: dedibox
0 Replies
6. Solaris
Hello Guys,
Do we need to configure this file only if we add SAN disk or even if we add local disk, do we need to modify? (4 Replies)
Discussion started by: mokkan
4 Replies
7. UNIX for Dummies Questions & Answers
Hello all,
Below what I saw on my solaris 10 box :
$ prstat
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU
PROCESS/NLWP
683 root 4082M 91M run 10 0 41:45:39 96% snmptrapd/1
syslog gives a lot of :
snmptrapd: illegal
data attempted to be added to table nlmLogVariableTable... (0 Replies)
Discussion started by: Gino_75
0 Replies
8. UNIX for Advanced & Expert Users
HI,
I want a help for Configuring snmpd.conf and snmptrapd.conf (i.e Configuring SNMP)
for receiving
TRAPS in my networks. I am using RHEL4.0 OS.
Please tell me How I can configure above two files in a proper way and at an
advanced level.
Especially I am getting... (2 Replies)
Discussion started by: jagdish.machhi@
2 Replies
9. UNIX for Dummies Questions & Answers
i tried this to get snmptrapd.conf bt unable...
# snmpconf
The following installed configuration files were found:
1: /etc/snmp/snmp.conf
2: /etc/snmp/snmpd.conf
3: /usr/share/snmp/snmp.conf
4: /usr/share/snmp/snmpd.conf
Would you like me to read them in? Their... (0 Replies)
Discussion started by: jeenat
0 Replies
10. UNIX for Dummies Questions & Answers
Hi All
Can anybody tell me how to configure snmptrapd.conf ?
Thanx (0 Replies)
Discussion started by: jeenat
0 Replies
SNMPTRAPD.CONF(5) Net-SNMP SNMPTRAPD.CONF(5)
NAME
snmptrapd.conf - configuration file for the Net-SNMP notification receiver
DESCRIPTION
The Net-SNMP notification receiver (trap daemon) uses one or more configuration files to control its operation and how incoming traps (and
INFORM requests) should be processed. This file (snmptrapd.conf) can be located in one of several locations, as described in the snmp_con-
fig(5) manual page.
IMPORTANT
Previously, snmptrapd would accept all incoming notifications, and log them automatically (even if no explicit configuration was provided).
Starting with release 5.3, access control checks will be applied to incoming notifications. If snmptrapd is run without a suitable configu-
ration file (or equivalent access control settings), then such traps WILL NOT be processed. See the section ACCESS CONTROL for more
details.
As with the agent configuration, the snmptrapd.conf directives can be divided into four distinct groups.
TRAPD BEHAVIOUR
snmpTrapdAddr [<transport-specifier>:]<transport-address>[,...]
defines a list of listening addresses, on which to receive incoming SNMP notifications. See the section LISTENING ADDRESSES in the
snmpd(8) manual page for more information about the format of listening addresses.
The default behaviour is to listen on UDP port 162 on all IPv4 interfaces.
doNotRetainNotificationLogs yes
disables support for the NOTIFICATION-LOG-MIB. Normally the snmptrapd program keeps a record of the traps received, which can be
retrieved by querying the nlmLogTable and nlmLogvariableTable tables. This directive can be used to suppress this behaviour.
See the snmptrapd(8) manual page and the NOTIFICATION-LOG-MIB for details.
doNotLogTraps yes
disables the logging of notifications altogether. This is useful if the snmptrapd application should only run traphandle hooks and
should not log traps to any location.
doNotFork yes
do not fork from the calling shell.
pidFile PATH
defines a file in which to store the process ID of the notification receiver. By default, this ID is not saved.
ACCESS CONTROL
Starting with release 5.3, it is necessary to explicitly specify who is authorised to send traps and informs to the notification receiver
(and what types of processing these are allowed to trigger). This uses an extension of the VACM model, used in the main SNMP agent.
There are currently three types of processing that can be specified:
log log the details of the notification - either in a specified file, to standard output (or stderr), or via syslog (or similar).
execute
pass the details of the trap to a specified handler program, including embedded perl.
net forward the trap to another notification receiver.
In the following directives, TYPES will be a (comma-separated) list of one or more of these tokens. Most commonly, this will typically be
log,execute,net to cover any style of processing for a particular category of notification. But it is perfectly possible (even desirable)
to limit certain notification sources to selected processing only.
authCommunity TYPES COMMUNITY [SOURCE [OID | -v VIEW ]]
authorises traps (and SNMPv2c INFORM requests) with the specified community to trigger the types of processing listed. By default,
this will allow any notification using this community to be processed. The SOURCE field can be used to specify that the configura-
tion should only apply to notifications received from particular sources - see snmpd.conf(5) for more details.
authUser TYPES [-s MODEL] USER [LEVEL [OID | -v VIEW ]]
authorises SNMPv3 notifications with the specified user to trigger the types of processing listed. By default, this will accept
authenticated requests. (authNoPriv or authPriv). The LEVEL field can be used to allow unauthenticated notifications (noauth), or
to require encryption (priv), just as for the SNMP agent.
With both of these directives, the OID (or -v VIEW) field can be used to retrict this configuration to the processing of particular
notifications.
Note: Unlike the VACM processing described in RFC 3415, this view is only matched against the snmpTrapOID value of the incoming
notification. It is not applied to the payload varbinds held within that notification.
authGroup TYPES [-s MODEL] GROUP [LEVEL [OID | -v VIEW ]]
authAccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]
setAccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES
authorise notifications in the specified GROUP (configured using the group directive) to trigger the types of processing listed.
See snmpd.conf(5) for more details.
createUser username (MD5|SHA) authpassphrase [DES|AES]
See the snmpd.conf(5) manual page for a description of how to create SNMPv3 users. This is roughly the same, but the file name
changes to snmptrapd.conf from snmpd.conf.
disableAuthorization yes
will disable the above access control checks, and revert to the previous behaviour of accepting all incoming notifications.
LOGGING
format1 FORMAT
format2 FORMAT
specify the format used to display SNMPv1 TRAPs and SNMPv2 notifications respectively. Note that SNMPv2c and SNMPv3 both use the
same SNMPv2 PDU format.
See snmptrapd(8) for the layout characters available.
ignoreAuthFailure yes
instructs the receiver to ignore authenticationFailure traps.
Note: This currently only affects the logging of such notifications. authenticationFailure traps will still be passed to trap han-
dler scripts, and forwarded to other notification receivers. This behaviour should not be relied on, as it is likely to
change in future versions.
logOption string
specifies where notifications should be logged - to standard output, standard error, a specified file or via syslog. See the sec-
tion LOGGING OPTIONS in the snmpcmd(1) manual page for details.
outputOption string
specifies various characteristics of how OIDs and other values should be displayed. See the section OUTPUT OPTIONS in the snm-
pcmd(1) manual page for details.
MySQL Logging
There are two configuration variables that work together to control when queued traps are logged to the MySQL database. A non-zero value
must be specified for sqlSaveInterval to enable MySQL logging.
sqlMaxQueue max
specifies the maximum number of traps to queue before a forced flush to the MySQL database.
sqlSaveInterval seconds
specified the number of seconds between periodic queue flushes. A value of 0 for will disable MySQL logging.
NOTIFICATION PROCESSING
As well as logging incoming notifications, they can also be forwarded on to another notification receiver, or passed to an external program
for specialised processing.
traphandle OID|default PROGRAM [ARGS ...]
invokes the specified program (with the given arguments) whenever a notification is received that matches the OID token. For
SNMPv2c and SNMPv3 notifications, this token will be compared against the snmpTrapOID value taken from the notification. For SNMPv1
traps, the generic and specific trap values and the enterprise OID will be converted into the equivalent OID (following RFC 2576).
Typically, the OID token will be the name (or numeric OID) of a NOTIFICATION-TYPE object, and the specified program will be invoked
for notifications that match this OID exactly. However this token also supports a simple form of wildcard suffixing. By appending
the character notification based within subtree rooted at the specified OID. For example, an OID token of .1.3.6.1.4.1* would match
any enterprise specific notification (including the specified OID itself). An OID token of .1.3.6.1.4.1.* would would work in much
the same way, but would not match this exact OID - just notifications that lay strictly below this root. Note that this syntax does
not support full regular expressions or wildcards - an OID token of the form oid.*.subids is not valid.
If the OID field is the token default then the program will be invoked for any notification not matching another (OID specific)
traphandle entry.
Details of the notification are fed to the program via its standard input. Note that this will always use the SNMPv2-style notification
format, with SNMPv1 traps being converted as per RFC 2576, before being passed to the program. The input format is as follows, one entry
per line:
HOSTNAME
The name of the host that sent the notification, as determined by gethostbyaddr(3).
IPADDRESS
The IP address of the host that sent the notification.
VARBINDS
A list of variable bindings describing the contents of the notification, one per line. The first token on each line (up
until a space) is the OID of the varind, and the remainder of the line is its value. The format of both of these are con-
trolled by the outputOption directive (or similar configuration).
The first OID should always be SNMPv2-MIB::sysUpTime.0, and the second should be SNMPv2-MIB::snmpTrapOID.0. The remaining
lines will contain the payload varbind list. For SNMPv1 traps, the final OID will be SNMPv2-MIB::snmpTrapEnterprise.0.
Example:
A traptoemail script has been included in the Net-SNMP package that can be used within a traphandle directive:
traphandle default /usr/bin/perl /usr/bin/traptoemail -s mysmtp.somewhere.com -f admin@somewhere.com me@somewhere.com
forward OID|default DESTINATION
forwards notifications that match the specified OID to another receiver listening on DESTINATION. The interpretation of OID (and
default) is the same as for the traphandle directive).
See the section LISTENING ADDRESSES in the snmpd(8) manual page for more information about the format of listening addresses.
NOTES
o The daemon blocks while executing the traphandle commands. (This should be fixed in the future with an appropriate signal catch and
wait() combination).
o All directives listed with a value of "yes" actually accept a range of boolean values. These will accept any of 1, yes or true to
enable the corresponding behaviour, or any of 0, no or false to disable it. The default in each case is for the feature to be
turned off, so these directives are typically only used to enable the appropriate behaviour.
FILES
/etc/snmp/snmptrapd.conf
SEE ALSO
snmp_config(5), snmptrapd(8), syslog(8), variables(5), snmpd.conf(5), read_config(3).
4th Berkeley Distribution 29 Jun 2005 SNMPTRAPD.CONF(5)