[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: convergence and undoing changes
From: |
Alva Couch |
Subject: |
Re: convergence and undoing changes |
Date: |
Fri, 18 Nov 2005 20:42:46 -0500 |
User-agent: |
Mozilla Thunderbird 0.6 (Windows/20040502) |
Mark Burgess wrote:
> You are correct however in pointing out that users CAN screw this up
> by trying to be too clever, by not thinking convergently.
This is what I am getting at.
> But that is not the normal state of affairs.
My experience is that users are all too cavalier about the way they
modify cfagent.conf. I think a specific discipline -- unknown to many
users -- is the key. We can either document that discipline or
encapsulate it in some kind of transaction engine. I propose to do both.
My examples using editfiles are a matter of public record. But the
problem can even happen when one utilizes purely convergent actions.
Here's a "typical" example of user thinking.
- user asserts contents of a file F. Say it is a service startup
in /etc/xinetd.d and the intent is to customize some service.
- then, some time after F is stable, the user changes the assertion
to revert F to its original state.
- unbeknownst to the user, some different set of stations are down
while F is reverting to the original state.
- then, satisfied that the file is reverted, the user takes the
reversion assertion out of the script, considering work to be done.
- time passes and the unreverted machines come back up. There is
no reversion to affect them. So they stay with the new version.
- At this point, there are two classes of machines: those with
the original version of F and those with the new version. If the
new version has a security hole, congratulations, you didn't manage
to plug it.
The key here is that for reversions to be effective, they must stay
in the configuration until it is absolutely sure that all stations
have applied them. In a very large network, one is likely never
sure, so one can *never* remove the reversions from the config file.
This is the principle of observability:
Once one manages a thing, one must continue to manage that
thing in perpetuity.
In my experience this kind of "reversion botch" is very common.
--
Dr. Alva L. Couch
Associate Professor of Computer Science
Associate Professor of Electrical and Computer Engineering
Tufts University, 161 College Avenue, Medford, MA 02155
Phone: +1 (617) 627-3674
Web: http://www.cs.tufts.edu/~couch
- convergence and undoing changes, Viraj Alankar, 2005/11/12
- Re: convergence and undoing changes, christian pearce, 2005/11/18
- Re: convergence and undoing changes, Mark Burgess, 2005/11/18
- Re: convergence and undoing changes, christian pearce, 2005/11/18
- Re: convergence and undoing changes, Mark Burgess, 2005/11/18
- Message not available
- Re: convergence and undoing changes, Mark Burgess, 2005/11/19
- Re: convergence and undoing changes, Marco van Beek, 2005/11/19
- Re: convergence and undoing changes, Mark Burgess, 2005/11/19
Re: convergence and undoing changes, Ed Brown, 2005/11/18
- Re: convergence and undoing changes,
Alva Couch <=
RE: convergence and undoing changes, Zeev Fisher, 2005/11/19
RE: convergence and undoing changes, Moore, Joe, 2005/11/21