Recommendations for config file revision control

Murray Taylor MTaylor at bytecraft.com.au
Sat Jun 2 09:46:34 UTC 2007


 

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org 
> [mailto:owner-freebsd-questions at freebsd.org] On Behalf Of 
> Maxim Khitrov
> Sent: Saturday, 2 June 2007 8:37 AM
> To: freebsd-questions at freebsd.org
> Subject: Re: Recommendations for config file revision control
> 
> On 6/1/07, Reid Linnemann <lreid at cs.okstate.edu> wrote:
> > Written by Maxim Khitrov on 06/01/07 14:27>>
> > > Hi everyone,
> > >
> > > I'm currently setting up a new server, and I'd like to 
> keep track of
> > > all changes made to various config files (in /etc, 
> /usr/local/etc, and
> > > a few other places perhaps). My first thought was to setup a
> > > subversion server which would contain the partial 
> directory structure
> > > that matches that of the server's starting at /. It would contain
> > > versioned copies of all the configuration files that I 
> want to keep
> > > track of in their appropriate locations. What I would do 
> then is write
> > > a hook for subversion that will issue an automatic export command
> > > (don't want .svn directories everywhere) every time a 
> commit is made
> > > to the repository. So to edit some configuration file I 
> would first
> > > checkout a working copy of the repository to some other 
> location, make
> > > the change and commit it. The server would be 
> automatically updated
> > > with the new file and I would be able to keep track of 
> every change.
> > >
> > > This seems like a decent strategy to me, but before I go 
> off writing
> > > the scripts and setting up the server I wanted to ask 
> what you guys
> > > might be using to keep track of the server configuration (backups
> > > don't count)? Is there an easier way of doing the same thing, for
> > > example, eliminating the need to do a working copy checkout first?
> > > Perhaps a way to monitor certain files for changes, and 
> automatically
> > > commit them every time a change is saved. I'd be glad to hear any
> > > suggestions you might have in this regard. If possible, 
> I'd like all
> > > the versioned files to contain an id string, so that it's easy to
> > > determine when the file was last changed and by whom, but this is
> > > optional. For the most part I just need a way of going back to
> > > previous versions.
> > >
> > > Thanks,
> > > Maxim Khitrov
> >
> > You might consider avoiding the excess labor of SVN and use 
> RCS, since
> > you're just tracking changes for individual files in place 
> on one host.
> > man rcsintro to see if this is more suitable for you.
> >
> 
> Hm... I think that while SVN would require more work initially, RCS
> would probably be more maintenance. The main problem I see is the
> requirement to execute commands on the server after each modification.
> This may not be always possible. With SVN I have a local copy of all
> the files, so as long as I'm able to commit I don't need to actually
> be logged in to the server.
> 
> See my ideal solution would be to open a file via sftp, for example,
> make the change and upload it. The change is detected, the Id string
> is updated, and the old revision is saved. SVN is one step away from
> that because I need to checkout a working copy first. Also, I couldn't
> do all this directly on the server by just opening vi and editing the
> file. This solution, however, would require some sort of monitoring.
> I'm even considering writing a simple C app that would use gamin to
> track when versioned files have changed, but I don't know how well the
> whole thing will work. With too many files I'm afraid that this
> monitoring would put too much unnecessary load on the server. An
> alternative is to keep the server configuration files just as they
> are, but checkout a working copy of the repository on the server. Then
> a cron script could compare the two directory trees, checking contents
> of the files. If one changes, update the other one. Again... seems
> like too much work for something that should be rather simple in my
> opinion.
> 
> I'll look a bit more into RCS, but it doesn't look like it offers
> anything major over subversion. Any other ideas?


Some people use the   expect  TCL-based system to do 'a sequence of
tasks
as though I was in front of th console' ....

This may help if RCS is a way to go. I believe (but am willing to be
corrected)
the you could launch an expect task, have it do the boring bits that you
did
once to teach it, pause for you to do the interesting bit, then do the 
boring wrapup.....

It may be another way to do your remote management.

mjt 
---------------------------------------------------------------
The information transmitted in this e-mail is for the exclusive
use of the intended addressee and may contain confidential
and/or privileged material. Any review, re-transmission,
dissemination or other use of it, or the taking of any action
in reliance upon this information by persons and/or entities
other than the intended recipient is prohibited. If you
received this in error, please inform the sender and/or
addressee immediately and delete the material. 

E-mails may not be secure, may contain computer viruses and
may be corrupted in transmission. Please carefully check this
e-mail (and any attachment) accordingly. No warranties are
given and no liability is accepted for any loss or damage
caused by such matters.
---------------------------------------------------------------

### This e-mail message has been scanned for Viruses by Bytecraft ###


More information about the freebsd-questions mailing list