[infrastructures] state machines
Daniel Hagerty
Daniel Hagerty <hag@linnaean.org>
Fri, 22 Sep 2006 11:33:24 -0400
> Maybe we should draw an analogy to database technology. An image
> backup (mksysb or some non-AIX equivalent) can be seen as a
> checkpoint in DB terminology. A restore will also include the
> machine state at the time it was run. Isn't it then simply a matter
> of rolling forward the actions between the time the backup was
> taken and Now? Of course, that does require that the change in
> ownership that accompanies the change in the LDAP server is also a
> logged action.
>
> Without the occasional image backup, as far as I can tell, you are
> stuck replaying the whole history since time began. If you simply
> restore a backup, you won't have the latest changes. To get the
> whole thing, you need to do both.
It depends on what you're really doing. The database analogy
holds well if imaging and mutation is what you're doing (it's an apt
description of what one does with isconf), but there are other ways of
breaking the problem up.
Consider /etc/resolv.conf as it appears on a typical system.
You don't have to play back every mutation that's ever been made
to resolv.conf to reproduce a resolv.conf that's functionally
identical to what you had at a given point in time. You can even
arrive at textually identical if you want.
Suppose for example that I use CVS to store a piece of XML like
<dns-information>
<search-path>baz.foobar.com</search-path>
<search-path>foobar.com</search-path>
<server>127.0.0.1</server>
</dns-information>
perhaps with some additional complexity to reflect that one's DNS
system probably isn't global as this implies -- different parts of the
system might use different DNS servers, or what have you, and it might
be better to reflect this in the data, rather than using multiple
files.
Check the XML into CVS, write a program that renders a resolv.conf
from the XML, version the generator program, and then you can check
out the XML+program for the point in time you want to regenerate a
resolv.conf for. You can also integerate the same XML into your
dhcpd.conf generation, and for configuring windows machines. The
concepts of DNS are similar across many contexts, even if its
expression is different.
This kind of approach has been taken before (at larger scales than the
example I cite here), and it has some benefits.