Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   FSVS and versioning /etc (http://www.linux-archive.org/debian-development/55027-fsvs-versioning-etc.html)

Philipp Marek 02-13-2008 10:15 PM

FSVS and versioning /etc
 
Hello everybody!

Now that FSVS has made it into debian (http://packages.debian.org/fsvs) I'd
like to make it easier for users to keep track of their systems'
configuration.

I asked Sheldon to build a package fsvs-system-versioning; that will depend on
fsvs, and provide some default configuration to keep /etc versioned.


Some facts:
* A lot of filename patterns are just ignored, like *.dpkg-old.
* Some files have a commit-pipe defined, so that eg. the passwords get
stripped out of the shadow files.
In case of a restore all passwords have to be set afresh.
* For a few files that include passwords (like ddclient) there are
already filters.
* Currently I use the apt option Dpkg::Post-Invoke to commit, although
some anacron-job once a day or week might be good.
Another idea might be to commit a new version only once per apt-get run.
* This is thought to help *configuring* the system; that means that both
system updates (and installations) and user changes should be versioned.
* Needed space for the repository is on my system (with 1853 installed
packages) about 12MB for the initial import; the few changes up to now
take no space (10 to 30kB).


Now there are some open questions.

1) Does apt export some state about the current installation
(eg. via the environment)?
2) Should we call fsvs after each *single* package? Together with 1 that
would allow to see exactly which installation caused some change.
3) Apart from the few files I saw that should be kept secret
(and so either have to be modified for commit, or ignored fully),
there'll be some more.
Should all be kept in fsvs-system-versioning, or should each package
(later, when they're converted) have some header in its control part?
Another way would be to provide some functions in
/etc/system-versioning.sh, like "commit", "ignore", and
so on ... but eg. the commit-pipe is more or less fsvs-specific, and
we'd have to ship some empty functions per default (in case fsvs is
not installed).
Another idea would be some /etc/fsvs-versioning/ignore.d/ directory,
where packages could drop their lists of files to be ignored, and some
update-fsvs-versioning.
4) fsvs can do empty commits, to record the fact that nothing changed.
Should we avoid that? Currently the "Urls" file gets committed, because
the local revision is changed after every commit. Should that file
be ignored, to avoid needless use of disk-space?


Currently the ignore patterns are relative to the working copy root; this is
no problem for /etc itself, but if someone wants to use the same mechanism to
keep / versioned all the ignore patterns have to be re-done, to include
the /etc part. But that's something that I'll change in fsvs - some way to
define absolute ignore patterns.


Thank you for your comments!
Please keep us CC'ed. Thank you.


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Joey Hess 02-13-2008 11:35 PM

FSVS and versioning /etc
 
Philipp Marek wrote:
> * Some files have a commit-pipe defined, so that eg. the passwords get
> stripped out of the shadow files.
> In case of a restore all passwords have to be set afresh.
> * For a few files that include passwords (like ddclient) there are
> already filters.

Is there some insecurity in how the data is stored that makes stripping
passwords on an ad-hoc basis like thia a good idea?

> * Currently I use the apt option Dpkg::Post-Invoke to commit, although
> some anacron-job once a day or week might be good.

If it has to manually commit, I don't see the point -- already wrote
etckeeper. :-) I'd think that the benefit of a versioned filesystem
would be that you don't have to manually commit changes.

> Another idea might be to commit a new version only once per apt-get run.

That's what etckeeper does.

> * Needed space for the repository is on my system (with 1853 installed
> packages) about 12MB for the initial import; the few changes up to now
> take no space (10 to 30kB).

git takes about 2.5 mb to version my 16 mb /etc (161 revisions so far).

--
see shy jo

Philipp Marek 02-14-2008 04:26 PM

FSVS and versioning /etc
 
Joey Hess wrote:
> Philipp Marek wrote:
> > * Some files have a commit-pipe defined, so that eg. the passwords get
> > stripped out of the shadow files.
> > In case of a restore all passwords have to be set afresh.
> > * For a few files that include passwords (like ddclient) there are
> > already filters.
>
> Is there some insecurity in how the data is stored that makes stripping
> passwords on an ad-hoc basis like thia a good idea?
Sorry, I don't understand you here.
Having the passwords in the repository might make them vulnerable, especially
if it's an off-site backup.

So per default they get stripped out.

In what way could that be *more* unsecure? I don't make the password fields
in /etc/g?shadow empty, if it's that what you mean.

> > * Currently I use the apt option Dpkg::Post-Invoke to commit, although
> > some anacron-job once a day or week might be good.
>
> If it has to manually commit, I don't see the point -- already wrote
> etckeeper. :-) I'd think that the benefit of a versioned filesystem
> would be that you don't have to manually commit changes.
Not manually - just at user-defined points in time (eg. "added a new user"),
or when doing updates.

> > Another idea might be to commit a new version only once per apt-get
> > run.
>
> That's what etckeeper does.
I know, I looked at that ;-)

I'd like to try doing a commit for each package - but I don't find the link
anymore where I saw how that could be done. Something about low-memory
systems, IIRC.

I'd like to do a non-empty commit after each package, and a final (possibly
empty) commit after the apt-get run.


> > * Needed space for the repository is on my system (with 1853 installed
> > packages) about 12MB for the initial import; the few changes up to now
> > take no space (10 to 30kB).
>
> git takes about 2.5 mb to version my 16 mb /etc (161 revisions so far).
I know that git stores the data compressed, which gives it an advantage.

At the time I wrote FSVS there've been several ways to store complete binary
trees in some versioning system; but they either couldn't do meta-data, or
had to jump through some loops to dump the meta-data into a file, which could
then be stored normally -- like etckeeper.
Doing that for several hundred thousand inodes is not fast - that's why I put
meta-data versioning in FSVS directly.


Well, it's just one more way to do things :-)


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


All times are GMT. The time now is 06:00 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.