[Nix-dev] Disaster recovery / re-deployment

[Bryce L Nordgren]

On Thu, Jan 5, 2012 at 5:32 AM, Rickard Nilsson
<rickard.nilsson at telia.com>wrote:

>  Hi,
>
>  On Tue, 03 Jan 2012 15:47:23 +0100, Florian Friesdorf
>  <flo at chaoflow.net> wrote:
> > Hi Rickard,
> >
> > On Tue, 04 Oct 2011 11:45:14 +0200, "Rickard Nilsson"
> > <rickard.nilsson at telia.com> wrote:
> >> > However in your case
> >> > http://mawercer.de/~marc/minimal-install-archive.patch should be
> >> enough
> >> > if you're lucky.
> >>
> >> Thanks! I will start out from that and see where I end up.
> >
> > did you made progress with that? For a full backup there might be
> > more
> > files needed, e.g.:
> > /etc/wpa_supplicant.conf
> > /etc/passwd
> > /etc/shadow
> > /etc/group
> > /var/lib/wicd/*
>

Longer term, it may be  worth considering a generic approach to
statefulness within nix's stateless framework. Many of the applications one
would wish to deploy exist primarily to maintain stateful information. A
database is a simple example. The information on disk is organized and
maintained by a specific version of the database software, and hence
depends on that version. There are specific procedures for upgrading the
stateful information such that it can be managed by the next version of the
database software. There are generally no procedures for downgrading such
that the information can be managed by a previous version.

The same thing applies to system configuration. Configuration file formats
and contents may depend on the version of the software/service/daemon they
belong to (although they're usually pretty good about being backward
compatible). Desktop apps will have "user preferences" stored somewhere.
Every time I upgrade Eclipse, I have a period of instability as plugins
which were referenced in the workspace are replaced and individually
reconfigured--and its hard to keep my "software development" version of
eclipse truly separate from my Topcased (modeling) instance.   In reality,
very few applications are truly stateless.

Web applications are even more challenging because they usually save state
both in a database and on the filesystem. There is also an additional layer
of "deployment information" which also needs to be saved. Deployment
information should be reusable from system to system, perhaps parameterized
by the base url you would like to deploy to. For Java webapps, it may
include information about how to proxy the app with apache, so you don't
have to suffix your hostname with :8080.

The interesting question is: How would you bring the advantages of
Nix+NixOS (atomic upgrades, rollbacks, etc) into the realm of applications
which maintain stateful information? Could modules be used? Does some new
mechanism need to be invented?

Bryce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120105/f3964304/attachment.html