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

Re: snmpconf PM MIB Issue #9



Agreed.  Regardless of the semantics of the write button, it seems that 
dirty bit is required.


-Matt

--On Wednesday, June 20, 2001 9:02 AM -0400 David Harrington 
<dbh@enterasys.com> wrote:

> Hi,
>
> 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.
>
> dbh
>
>
> 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