view.pty manual page
Table of Contents

NAME

view.pty - MIB view access configuration for SNMPv2 entities

SYNOPSIS

viewIndex viewSubtree viewType viewStorageType viewMask |

DESCRIPTION

The configuration file view.pty is one of several configuration files required by the SNMPv2 entities. The default location of view.pty is /etc/opt/snm/agent for Solaris 2.x and /etc/snm/agent for Solaris 1.x, or /etc/opt/snm/manager (Solaris 2.x) and /etc/snm/manager (Solaris 1.x) but can be specified by the environment variable SR_MGR_CONF_DIR or SR_AGT_CONF_DIR.

The view.pty file contains the configuration information for the view table which defines the MIB view information for the SNMPv2 parties in the party table.

Each entry in the file consists of 2 lines:

viewIndex viewSubtree viewType viewStorageType viewMask |
where

viewIndex
is the contextViewIndex 0 or more contexts whose MIB view is being defined.
This value is an integer.

viewSubtree
in combination with viewMask, defines a family of MIB view subtrees. This family is included in or excluded from the MIB view for the context. This value is an OID.
Note: If an OID is duplicated, the one which occurs first will be the one used and all subsequent OIDs will be discarded.
For a more detailed description, please see the Party MIB (RFC1447) and context.pty(5).

viewType
indicates the status for this view entry. It can have a value of either
included, which means this MIB view is included in the context's MIB view,
or

excluded, which means that this MIB view is not included in the context's MIB view.

viewStorageType
indicates the storage type for this row in the view table. Possible values are:
other
volatile
nonVolatile
permanent
According to RFC1447,

· volatile is lost upon reboot, e. g., in RAM,

· nonVolatile is backed up by stable storage, e. g.,
in NVRAM,

· permanent cannot be changed or deleted, e. g., in
ROM,

and "other" is provided in the unlikely event that someone will find a need for a storage type not covered by the other three.
This field is a case-sensitive string corresponding to one of the above values.

viewMask
allows restriction of the view at a finer level than the viewSubtree and viewType pair. For instance, a view can be restricted to one row of a table. See the example below.
The value " - " causes the corresponding viewMask to be a null string, which in turn allows all entries "below" the viewSubtree entry to be visible, unless canceled by another view.pty entry.
The viewMask string can have a length from zero to sixteen bytes (so from " - " to 16 hexadecimal digits.) Note: All positions of the numbers must be represented; i. e., 01 for 1.
For more information, it is strongly suggested that you read the security documents, RFC1446, and RFC1447.

EXAMPLES

Simple Subtree Inclusion
An entry that would include a subtree for viewing might look like

1 system included nonVolatile

This indicates that the SNMPv2 parties that have a SNMPv2 context with contextViewIndex of 1, have the viewSubtree of system included in their MIB view, and this view entry should be stored in non-volatile storage such as NVRAM. In other words, any parties with this contextViewIndex can "see" the system group unless limited by another entry.

Note: If an OID is duplicated, the one which occurs first will be the one used and all subsequent OIDs will be discarded.

Simple Subtree Exclusion
An entry that would exclude a subtree for viewing might look like

2 interfaces excluded nonVolatile

This indicates that the SNMPv2 parties that have a SNMPv2 context with contextViewIndex of 2, have the viewSubtree of interfaces excluded in their MIB view, and this view entry should be stored in non-volatile storage such as NVRAM. In other words, any parties that have a SNMPv2 context with this contextViewIndex cannot "see" the interfaces group unless allowed by another entry.

Note: If an OID is duplicated, the one which occurs first will be the one used and all subsequent OIDs will be discarded.

Using the viewMask to Limit the View
The viewMask string is convoluted. Prepare for serious obfuscation:

The viewMask is built from octets that correspond to the OID being restricted. Say you want to restrict a contextViewIn_dex entry's view of the ifTable to the second row, all columns. The first three fields of the view entry would be:

3 ifEntry.0.2 included

A null entry for viewMask will not work because nothing will ever exactly match the viewSubtree OID, ifEntry.0.2. Specifying the ".0.2" on the ifEntry OID created two place holders that will be exploited by the viewMask.

The OID for ifEntry.0.2 would be:

1.3.6.1.2.1.2.2.1.0.2

The viewMask is a series of ones and zeros used for masking out parts of the tree. A zero indicates a "wildcard" (i. e., matches anything), a one indicates an exact match must be made. So

OID:
1.3.6.1.2.1.2.2.1.0.2 viewMask: 1 1 1 1 1 1 1 1 1 0 1

would require an exact match on all fields except the table column (i. e., the 0 in ifEntry.0.2).

Now for the obfuscation. The octets within the viewMask are rotated within bytes. Using the above example, you would first group the bits of the viewMask into bytes, padding the right end with ones if necessary, then rewrite each byte from right to left, but leaving the bytes "in order:"

byte 1
byte 2 1 1 1 1 1 1 1 1 1 0 1 original mask 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 padded with 1's 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 rotated mask
ff
fd hex value

Notice that bit 1 of each original byte was "rotated" to the 8th position, bit 2 to the 7th, bit 3 to the 6th, etc.

So the viewMask entry would be:

ff fd

With this entry in view.pty, and all appropriate entries in the other configuration files, a getmany(l) on the ifTable will return something like:

ifIndex.2 = 2
ifDescr.2 = lo0
ifType.2 = softwareLoopback(24)
ifMtu.2 = 1536
ifSpeed.2 = 0
ifPhysAddress.2 =
ifAdminStatus.2 = up(1)
ifOperStatus.2 = up(1)
ifLastChange.2 = 0
ifInUcastPkts.2 = 182945
ifInErrors.2 = 0
ifOutUcastPkts.2 = 182949
ifOutErrors.2 = 0
ifOutQLen.2 = 0
ifSpecific.2 = ccitt.0

Of course, the second row would have to exist before you could retrieve it.

Note: If an OID is duplicated, the one which occurs first will be the one used and all subsequent OIDs will be discarded.

A Sample view.pty File
The following is the default view.pty file shipped in August of 1993. It allows all parties using contextViewIndex of 1 to see the system, snmpStats, snmpParties, snmpTrap, and snmpTraps groups. All parties using contextViewIndex of 2 are allowed to see everything under the internet group, and all parties using contextViewIndex of 3 are allowed to see the partyAuthClock only.

This last entry is the contextViewIndex used by the "clock synch" routines.

1 system included nonVolatile
1
snmpStats included nonVolatile
1
snmpParties included nonVolatile
1
snmpTrap included nonVolatile
1
snmpTraps included nonVolatile
2
internet included nonVolatile
3
partyAuthClock included nonVolatile

FILES

Additional SNMPv2 Configuration Files
When the agent is compiled with either SNMPv2 or both SNMPv1 and SNMPv2 defined, the configuration files acl.pty, agt.pty, context.pty, mgr.cnf, and mgr.pty are required.

acl.pty
Access control privileges for the SNMPv2 parties.

agt.pty
Initial party table information for the agent.

context.pty
Context information for the SNMPv2 parties.

mgr.cnf
Configuration information for the managers.

mgr.pty
Initial party table information for the managers.

snmpv2d.conf
Configuration information for the SNMPv1 entities.

snmpinfo.dat
OID translations used by the entities.

view.pty
MIB view information for the SNMPv2 parties.

For Solaris 2.x, the files are located under:

/etc/opt/snm/{agent,manager}/acl.pty
/etc/opt/snm/agent/agent.pty
/etc/opt/snm/{agent,manager}/context.pty
/etc/opt/snm/manager/manager.cnf
/etc/opt/snm/manager/manager.pty
/etc/opt/snm/manager/snmpinfo.dat
/etc/opt/snm/agent/snmpv2d.conf
/etc/opt/snm/{agent,manager}/view.pty

For Solaris 1.x, the files are located under:

/etc/snm/{agent,manager}/acl.pty
/etc/snm/agent/agent.pty
/etc/snm/{agent,manager}/context.pty
/etc/snm/manager/manager.cnf
/etc/snm/manager/manager.pty
/etc/snm/manager/snmpinfo.dat
/etc/snm/agent/snmpv2d.conf
/etc/snm/{agent,manager}/view.pty

SEE ALSO

v2install(1), acl.pty(5), agt.pty(5), context.pty(5), mgr.cnf(5), mgr.pty(5), snmpv2d.conf(5), SNMP RFCs (RFC1155 RFC1157 RFC1212 RFC1213 RFC1215, RFCs 1441-1452)


Table of Contents