[kwlug-disc] etckeeper, and not - prepping for the day I inevitably shoot myself in the foot?

B.S. bs27975.2 at gmail.com
Mon Apr 10 16:57:17 EDT 2017


I think perhaps questions / issues have been mixed.

(1) It seems reasonable in some cases to have a version history of files 
in a directory. A reasonable way to do so seems to be some fashion of 
'git init ; cd favdir ; while true ; git -am add ; git commit; sleep 
24hours ; done;'

[etckeeper does this for /etc (and thus has some understanding and 
accommodation of the complexities / unique aspects of those files). And 
may serve as a template from which to start the above. e.g. cron entries 
to commit files daily.]

Is that (git init ; etc) unreasonable / are there other ways already out 
there? [git being 'mainstream' / familiarity less likely to be in cold 
storage. But I'm not hung up on git. Merely that one can only retain the 
vagaries of so many disparate functionalities.]

(2) File browsers that understand git in a directory could be useful for 
just that reason of forgetting command line syntax. Do they exist?

 > What is wrong with one of the graphical git browsers? qgit is okay for
visualization.

Thanks for that. Didn't say there was anything wrong with them. Did note 
that such could be used / useful even on non-graphical systems, via sshfs.

 > One issue with these tools is that although they might show you
history, you generally do not want to run GUI tools as root. Thus you
would not want to use these tools to revert changes.

Fair enough. Step one is to even determine whether one wants to. i.e. 
Detect botch, browse to determine prior version restoration is even 
possible. Can worry about restoration once so determined.

 > The /etc directory does not exist in a vacuum. It is often linked to
software packages that are in other parts of the file system (/var, 
/usr, /opt, ...etc.)

Agreed, and etckeeper has some smarts surrounding that. e.g. Permissions 
maintenance on /etc/shadow, hooks into apt at package removal/install, 
and more.

 > Also, there are all those dot files and directories in your home 
directory that configure various things you use (your browser, office 
suite, editor, file manager, desktop, widgets, ...etc.)

Yep. I didn't pose the question on a ~ use case, but I take your point. 
(There are many links talking about using git on ~. e.g. .gitignore 
everything vs nothing. And the need to be judicious.) What drove my 
question was more .conf files in /var/ossec/etc. [And once one thinks to 
pose that question, the concept easily expands to the more general case 
of any directory.]

 > So, backing up just /etc has its uses, but it would not cover everything.

Absolutely. It would not replace backups, snapshots, and so on. But 
should be able to, with minimal resources, help you dig out a single 
file or a single line in a file. (vs taking an entire system back in 
time) And, presumably, do so in a reasonably quick time frame (vs 
restoring a backup), while not being too resource exhaustive.

The question(s) were posed from the viewpoint of a few text files, or 
even lines within them.

Particularly where, say, nightly rsync's aren't happening. Else one 
could just look in the yesterday's sync of the file.


So, 'git init' in any directory reasonable. Favourite git gui browsers?
(Did find tig for ncurses. Interesting, but my git knowledge is in cold 
storage at the moment.)



On 04/10/2017 12:13 PM, Khalid Baheyeldin wrote:
> I think this is helpful in some cases, but it may cause trouble in other
> cases.
>
> The /etc directory does not exist in a vacuum. It is often linked to
> software packages that are in other parts of the file system (/var, /usr,
> /opt, ...etc.)
>
> Also, there are all those dot files and directories in your home directory
> that configure various things you use (your browser, office suite, editor,
> file manager, desktop, widgets, ...etc.)
>
> So, backing up just /etc has its uses, but it would not cover everything.
>
> The ideal solution is a snapshot of 'the system' as it exists, with all the
> various parts in their state at the time of the snapshot. A full system
> backup is supposed to do that. As others said, ZFS does that too. LVM also
> has some features related to snapshots (from what I understand), but they
> are whole snapshots, not deltas like ZFS.
>
> If you have a disaster, the fallback is to restore a full backup, going to
> a known state, despite losing stuff from the time of the backup until the
> time of the disaster. But consistency and integrity is preserved.
>
> That is not to say that you can do partial restores (specific files, e.g.
> that spread sheet from two weeks ago).
>
> On Sun, Apr 9, 2017 at 11:09 AM, B.S. <bs27975.2 at gmail.com> wrote:
>
>> So, I can see value in keeping everything in a directory in git, for the
>> day I change some config file when trying something, decide that was the
>> wrong thing to try, and want to revert but forget what I did. (e.g. Some
>> obscure option setting I can't recall the specific syntax for.)
>>
>> To that end, I've installed etckeeper, and will just let that run.
>>
>> Outside of /etc, I can 'git init' any given directory, and duplicate
>> etckeeper's daily cron git commits in some fashion. (cd favdir ; while true
>> ; git -am add ; git commit; sleep 24hours ; done; )
>>
>> I don't use git enough to ever be able to remember command lines, so could
>> appreciate the idea of a git aware file browser gui that understands
>> working backwards / forwards in file versions. I see, for example, git-gui,
>> which will spawn gitk as desired, and google quickly reveals many other gui
>> candidates. Also cool is sshfs'ing and running such gui on local system
>> against remote non-gui server. (Not looking to replicate such git's / there
>> is no git server there.)
>>
>> What am I?
>>
>> i.e. What facilities / search terms am I blindly groping in the dark
>> towards?
>>
>> I am going to shoot myself in the foot eventually, and will want to revert
>> to a prior file version. Assume no backups. (i.e. I could daily rsync /
>> snapshot to dated file/directory versions, but that's just another form of
>> what I'm already asking about.) K.I.S.S. / easy viewing of prior file
>> versions, applies.
>>
>> Suggestions? / thoughts? / links? / thanks.
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>
>
>
>
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>




More information about the kwlug-disc mailing list