FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-13-2008, 10:15 PM
Philipp Marek
 
Default 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
 
Old 02-13-2008, 11:35 PM
Joey Hess
 
Default 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
 
Old 02-14-2008, 04:26 PM
Philipp Marek
 
Default 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
 

Thread Tools




All times are GMT. The time now is 09:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org