[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf PM MIB Issue #9


I think a status object should indicate when a write has taken place.
This could be done on a row-by-row basis if the buttons are row-by-row,
or table by table if the buttons are by table, etc.
If it is likely that a table may get "dirty" so soon, that th euser may
not be able to see the change, then maybe there should be a timestamp
(based on sysUpTime) object to indicate when teh write occurred. The
write button makes the request; the timestamp indictaes when it is
completed; the status button shows whether the row is again dirty.

I think this is a useful thing. A few months ago on this list a security
hole was identified that, it turns out, was caused by the lack of an
immediate write. It is a good thing to know whether a write to stable
storage has been done or not.


Juergen Schoenwaelder wrote:
> >>>>> Wes Hardaker writes:
> Wes> I'm not convinced that forcing this upon the implementer is a
> Wes> "good thing".  It's entirely possible that some implementations
> Wes> will only be able to write immediately, and others will not be
> Wes> able to write until some time X later.
> Which means that management applications can never know whether a
> configuration change has been committed to stable storage. From a
> management application perspective, this is unworkable. (And all the
> CLIs I have seen sofar have a "write config now" button. So why is
> that too hard to put into an SNMP agent?)
> Wes> I fail to see what the problem is with the existing storage type
> Wes> mechanisms.  If one box must write everything nonVolatile at once
> Wes> and another one may not, then it is sort of implementation
> Wes> specific as to what saving methodology is used.
> The problem is that management applications have no clue when a
> configuration change is reflected in stable storage and hence they
> can't seriously make any assumptions that a row which is "nonVolatile"
> is still there after a device reboot/crash. I know one implementation
> which writes to stable storage when the agent exits (which won't work
> if the agent or the system crashes). I know other implementations
> which delay writes to speed up the processing of SNMP set
> operations. Again, there is a time window where changes to
> "nonVolatile" rows might get lost.
> The proposal adds explicit write buttons so when a management
> application touches the button, it will be sure that the configuration
> in stable storage is updated. This does not reduce your freedom to not
> implement such a write button and to continue with the old behaviour
> where things are written to stable storage whenever the implementor
> things it is a good time to do so.
> In fact, the write buttons would be an _additional_ explicit mechanism
> to help management applications that want to know when configuration
> changes are saved in stable storage.
> /js
> --
> Juergen Schoenwaelder      Technical University Braunschweig
> <schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
> Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA