Ned Harvey wrote:
>Question is: What do you use to version control permission sensitive
>files?
What's the matter with the old tried-and-true RCS? It keeps both
permissions and time stamps just fine.
--
Dave Close, Compata, Irvine CA "Whenever you have a secret,
d...@compata.com, +1 71
ENH> Config management is great, if you're building new systems, and
ENH> especially if you're building and removing a lot of systems from
ENH> production on a regular basis, and you own it all from scratch. Not
ENH> great if you inherited a small number of undocumented customer facing
ENH> servers
Edward Ned Harvey (lopser) wrote:
> I'm really not interested in puppet or chef for this purpose, for about
> a zillion reasons. Here's the simplest most important one:
>
> Config management is great, if you're building new systems, and especially
> if you're building and removing a lot of systems
On Apr 21, 2013, at 8:05 PM, Edward Ned Harvey (lopser)
wrote:
> Yes, of course, the plan is to build a new standard, including all the
> documentation, and replace the existing servers. But if you seriously have
> only 1-3 servers to maintain, it's not worth building another server to be
> t
> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org]
> On Behalf Of Brian Atkisson
>
> Manage the files you care about with puppet, keeping the modules in a git
> repo. If you are concerned about files changing that aren't managed with
> puppet, watch them with aide.
I'm re
Manage the files you care about with puppet, keeping the modules in a git
repo. If you are concerned about files changing that aren't managed with
puppet, watch them with aide.
On Apr 20, 2013, at 12:05 PM, Singer Wang wrote:
Chef
On Apr 20, 2013 12:00 PM, "Yves Dorfsman" wrote:
> On 2013-04-
On 2013-04-21 10:34, Edward Ned Harvey (lopser) wrote:
rdiff-backup is more well suited for the former description you've described,
although it can certainly be used in the latter. Because rdiff-backup
maintains history indefinitely (unless otherwise instructed) you probably don't
want to r
On Apr 21, 2013, at 08:16 AM, "Edward Ned Harvey (lopser)" wrote:> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] > On Behalf Of Yves Dorfsman > > What did this give you that an rdiff-backup wouldn't? I've never used rdiff-backup before. [snip] Thanks for the suggestion.
> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org]
> On Behalf Of Yves Dorfsman
>
> git and friends:
> capture changes when a human thinks changes were made and should be
> recorded.
> Fewer revisions, easy to search, every revision is meaningful.
> You will miss every non-
On 2013-04-21 09:57, Brad Beyenhof wrote:
Although I'm surprised it doesn't have any comment capability.
I'm not sure exactly what you mean by this, but I definitely value the
commit-style nature of git as a version-tracking mechanism, where rdiff-backup
(or duplicity) just copies filesystem
> From: Brad Beyenhof [mailto:bbeyen...@icloud.com]
>
> At $PREVIOUSJOB, I wrote a Perl frontend for rdiff-backup that I kicked off
> nightly via cron to backup shared /home (NFS- and samba-mounted on
> clients) and a few other important data locations. It was a lifesaver when
> clobbered data nee
On Apr 20, 2013, at 6:02 PM, Phil Pennock wrote:
>
> If your package management system insists on owning all files in /etc/
> and complaining if you choose to change the state of some them by
> rolling back a change, then your package management system is broken.
>
> It's acceptable for package
> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org]
> On Behalf Of Yves Dorfsman
>
> What did this give you that an rdiff-backup wouldn't?
I've never used rdiff-backup before.
Now that I'm reading the manual, it's definitely worth investigating. Looks
like it has a lot
On 2013-04-20 22:35, Brian Mathis wrote:
We wound up writing our own tool that creates a copy of every file we want to
watch in a separate location, and keeps that location under revision control.
A script runs every night and emails out the diffs before auto-committing them
to the local repo.
> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org]
> On Behalf Of Brian Mathis
>
> I attempted this myself a few years ago, and also ran into a lot of
> problems. One of the biggest problems is SVN itself -- it dumps .svn
> directories and internal files all over the place
15 matches
Mail list logo
