[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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)!


Reply to: