Re: [webmin-devel] Webmin feature enhancement idea to recover from mistakes

[Jamie C. <jca...@we...>]

This sounds quite similar to another feature that people have 
suggested - the ability to 'undo' changes made using webmin. However, 
that one is currently way down my TODO list, due to the complexity of 
tracking changes made to each config file so that they can be reversed 
properly. And in some cases (like deleting a user's home directory), 
undoing such a change would be impossible.

So unfortunately, a confirmation or undo feature like this is probably 
not going to appear for a while..

  - Jamie

Andrew Kornak wrote:
> I had a chance to think about this. It might be too difficult to add a
> network
> test specifically for this. I'm thinking something more general and I
> believe
> more simple which could be used in any module. For instance, If I make a
> change and activate it, a variable such as restore=1 is set. After a
> designated
> period a confirmation message would appear during a webmin session.
> This might simply be a button to press to confirm the changes and thus
> changing the variable restore=0. This would prevent the restoration of
> previous values. A simple manual click by a user would confirm the changes
> that were made. If, say a user does not confirm, values would revert back.
> I can see this as being a useful feature for any module. I think this would
> be a simpler way of confirming changes. Any module could have a cache
> or backup directory that would be used to backtrack changes. The changes
> would simply be keystrokes/web-clicks or field values that are affected
> during
> a change, like netmask=255.255.255.0. Then, the module could process the
> field values using the same script (hopefully) with the text file that holds
> the values
> instead of the webmin form. What do you think?
> 
> -Andrew
> ----- Original Message ----- 
> From: "Jamie Cameron" <jca...@we...>
> To: <web...@li...>
> Sent: Friday, October 24, 2003 8:58 PM
> Subject: Re: [webmin-devel] Webmin feature enhancement idea to recover from
> mistakes
> 
> 
> 
>>Andrew Kornak wrote:
>>
>>>I recently had the misfortune of making a mistake in my network settings
>>>which in turn had the effect of disconnecting me from my server which is
>>>at a remote location. Eventually someone was able to manually come in
>>>and correct my mistake, but, it occurred to me that a possible soution
>>
> to
> 
>>>this kind of problem would be to have a mechanism by which changes
>>>are not permanent unless they are confirmed through a transparent
>>>webmin confirmation process. By this I mean, when a change is made
>>>it would revert to a previous setting unless one where to confirm by
>>>logging in again or by clicking a confirm setting when you login again.
>>>So, say I make a drastic mistake in my network configuration. The
>>
> setting
> 
>>>is made, the network restarts, I lose the connection! Ofcourse, if I
>>
> have
> 
>>>no connection, I cannot confirm, thus my ass is saved!! Hurray!! The
>>>confirmation might be an interval set by the user. It could be a 10
>>
> minute
> 
>>>default
>>>or something. I know that webmin has a caching mechanism built in,
>>>perhaps this would be something like that where it would be used to
>>>recover from a mistake? Perhaps this would be useful in other modules
>>>as well. Perhaps you might lose you web server or database or something.
>>>I don't know, would this be feasible? I can't be the only one that makes
>>>this
>>>kind of mistake. Since this interface is so dependent on a functioning
>>>network, perhaps it would be useful? It could also be an optional
>>
> feature
> 
>>>only. A feature that might save someone from losing their job! Just a
>>>thought.
>>
>>Perhaps what is needed is a feature in the Network Configuration
>>module for testing connectivity after changes are applied, and rolling
>>  the changes back if the network appears to be down. The test could
>>be performed by pinging some external host, defined in the module's
>>configuration .. and the rollback done by saving the state of all
>>interfaces and routes before applying changes, and restoring them if
>>something went wrong.
>>
>>Implementing it could be a little tricky, but it is worth doing (since
>>I've had the same problems myself!), so I will see about adding it to
>>a future release.
>>
>>  - Jamie