This article describes the new support to audit SNMPv3 requests. Additional SNMP enhancements exist for the system description, storage pool descriptions, and storage pool block sizes. These enhancements are available via PTFs.
Auditing SNMPv3 messages is similar to the auditing that's done for SNMPv1. The same mechanism is used to control the auditing of all SNMP Get or Set requests. Audit messages by changing the system-wide SNMP attributes with the Change SNMP Attributes command. The Log Get requests LOGGET parameter and the Log Set requests LOGSET parameter control whether all Get (Get, GetNext, GetBulk) or Set requests and their associated responses are logged in the QUSRSYS/QSNMP journal. This now includes both SNMPv1 and SNMPv3 messages.
For SNMPv1, auditing requests for a specific community can be done by turning off the system-wide SNMP audit settings and then changing the LOGGET and LOGSET parameters for the community with the Change Community for SNMP command.
For SNMPv3, there is now a LOGGET and LOGSET parameter on the Add User for SNMP and Change User for SNMP commands which control the auditing of a specific SNMPv3 user.
SNMPv3 engine ID discovery takes place when an SNMP manager sends a Get request that specifies either a zero length user name or the user name initial and an authoritative engine ID consisting of all zeros. Auditing of engine ID discovery requests will always be done if LOGGET(*YES) is specified in the system-wide SNMP attributes.
Note: When the PTFs are installed, any existing SNMP users will have their auditing attributes set to LOGGET(*SNMPATR) and LOGSET(*SNMPATR) which means that the system-wide SNMP attributes will initially control auditing for all the existing users.
The format and contents of an audit entry are described in the IBM i support document QSNMP audit journal layout changes after applying PTFs.
Appending Text to the System Description
It’s now possible to specify additional text to be appended to the standard text description that’s returned. The standard text identifies the system as an IBM i and also includes the version and release of the system. The System description SYSD parameter of the CHGSNMPA command had no effect on the standard text that was returned. A new parameter Additional information is now available on the CHGSNMPA command. Specifying ADLINF(*SYSD) will cause any user specified text entered for the SYSD parameter to be appended to the standard text returned for sysDescr.
For example, if the command
CHGSNMPA SYSD('Application Test System') ADLINF(*SYSD) is run, the text returned by a GET request for sysDescr will be “IBM OS/400 V7R3M0 Application Test System.”
ASP Numbers for Storage Pool Descriptions
It’s also now possible to have the ASP number appended to the descriptive text hrStorageDescr for all of the storage pools returned in the storage table hrStorageTable. The new ADLINF parameter supports a value *ASPNBR which will cause the ASP number to be appended to the standard descriptive text.
For example, if the command
CHGSNMPA ADLINF(*ASPNBR) is run, the text returned by a Get request for hrStorageDescr for an independent ASP will be “Independent ASP 33” if 33 is the ASP number for that specific auxiliary storage pool.
The ADLINF parameter supports multiple values, so both of the values of *ASPNBR and *SYSD can be specified at the same time as follows:
CHGSNMPA ADLINF(*SYSD *ASPNBR).
Note: The IBM i SNMP agent must be ended and restarted for changes to the ADLINF parameter to take effect
Larger Storage Pool Block Sizes
The largest possible configurable block size for storage pools supported by the Block size (BLKSIZE) parameter of the CHGSNMPA command was 32768 bytes. However, even larger block sizes are needed to accurately show storage sizes in the hrStorageTable. Now it’s possible to use block sizes up to 1 MB (1048576 bytes). In addition, there are special parameter values, such as 512K and 1M, which can be used to make specifying block sizes easier.
For example, specifying
CHGSNMPA BLKSIZE(512K 4096) sets the storage pool block size to 512K (524288) bytes. The block sizes allowed for disk units have not changed.
The following PTFs provide the new function described by this article:
Clair Wood wrote this week’s article. Clair is an advisory software engineer with IBM in Rochester, Minnesota. His current responsibilities involve development for TCP/IP configuration and applications. He is the product owner of the IBM TCP/IP Connectivity Utilities for i.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.