Re: Regarding sysname, syslocation and syscontact values SET via SNMP manager is resulting error

On 18 April 2012 10:12, Ganesh Reddy K <[email protected]> wrote:
> case 2)  In the snmpd.conf,  i have configured  the
> sysname,syslocation, syscontact  with proper values. Using the GET
> command, the  values are properly shown in the manager.  Now  i am
> trying to set the values using SET operation  for all of the 3
> variables , it is resulting error
>
> as  "SET operation failed: 192.168.1.100  not-writable(17)".

Yes - that is correct.
See the documentation of 'syslocation' and related tokens
in the snmpd.conf(5) man page:

      set the system location, system contact or system name
      (sysLocation.0, sysContact.0 and sysName.0)
      for the agent respectively.  Ordinarily these objects are
      writeable via suitably authorized SNMP SET requests.
      However, specifying one of these directives makes the
      corresponding object read-only, and attempts to SET it
      will result in a notWritable error response.

or the FAQ entry
     Why can't I change sysLocation (or sysContact)?


> Any reason for behaving  this way?

Think what would happen if the agent accepted a SET request
for one of these values, and was then silently restarted.

Initially:    sysLocation.0 = Here     (read from snmpd.conf)
SET:        sysLocation.0 = There
Restart:    sysLocation.0 = Here     (read from snmpd.conf)

So from the view of a management client application, the
location object has suddenly reverted to the old value
without warning.

We discussed how to address this "unexpected" behaviour,
and felt that the best approach would be to prevent the
SET request from taking.


>   Please share any fixes/patch for this.

The cleanest approach is to set the sysLocation/sysContact
object via a SET request.   This value will then be saved
in the persistent config file, and hence carried over when
the agent restarts.

Dave

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users