Re: Recommendations for config file revision control
On 2007-06-02 21:45, Maxim Khitrov [EMAIL PROTECTED] wrote: Here's an update on what I ended up going with. I decided to go with my idea of moving all configuration files to a common directory, but with a bit of a change. I created /config and under it base/ and user/. Everything in base/ comes from /etc and /boot, and the rest goes under user/. I didn't want to mix the two. So then I created a new subversion repository, but I set permissions such that only root can read or write to it. Basically I decided to forbid anyone on the outside from getting their hands on the repository contents, since it will be storing things like master.passwd and other sensitive data. Once all this was in place I moved all configuration files to their appropriate locations in /config and created symlinks in their original location. Everything under /config was then imported into the subversion repository using the file:// method. Since I forbid anyone from doing a check-out of the repository to some external location, I don't need to worry about file updates except when they are updated in /config. This simplifies things. What I did to keep the repository up to date was create a simple sh script that is run by cron every 10 minutes. The script simply issues 'svn ci --non-interactive --message Automatic commit' command in the /config directory. So any changes made to the configuration files are automatically recorded every 10 minutes. This works well, but does have a few flaws. First of all, when I edit files from sftp I have no way to add a meaningful message to the commit. Not a big deal, and I can always do a manual commit if I had to. The other thing is that this script will not auto-add files to the repository. Any new configuration file that I'd like to have monitored first gets moved to /config, then has a link created in the original place, then is added to the repository via 'svn add'. A bit more work, but I think it's fine. Technically I can automate the process of adding and removing files from the repository by using svn status output, but at this point the extra work isn't worth it. The bigger problem is the fact that subversion does not store owner and permission settings. That means that if I ever want to delete the /config directory and recreate it, I lose all permissions on things like master.passwd. What I did was add chown and chmod commands to the monitor script for all files that had non-standard permissions. So those get run along with the svn ci command every 10 minutes. The alternative was to use subversion properties, have the script parse those and apply the appropriate settings. However, since the permissions have to be set manually anyway there is no advantage to this over the monitor script, which is also versioned. The permission and ownership problem is also one of the issues which Subversion (or other SCMs) do not solve for base-system binaries too. See for example the thread: Using Subversion for binary distribution? which was recently present in `freebsd-current'. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for config file revision control
On 6/3/07, Giorgos Keramidas [EMAIL PROTECTED] wrote: On 2007-06-02 21:45, Maxim Khitrov [EMAIL PROTECTED] wrote: Here's an update on what I ended up going with. I decided to go with my idea of moving all configuration files to a common directory, but with a bit of a change. I created /config and under it base/ and user/. Everything in base/ comes from /etc and /boot, and the rest goes under user/. I didn't want to mix the two. So then I created a new subversion repository, but I set permissions such that only root can read or write to it. Basically I decided to forbid anyone on the outside from getting their hands on the repository contents, since it will be storing things like master.passwd and other sensitive data. Once all this was in place I moved all configuration files to their appropriate locations in /config and created symlinks in their original location. Everything under /config was then imported into the subversion repository using the file:// method. Since I forbid anyone from doing a check-out of the repository to some external location, I don't need to worry about file updates except when they are updated in /config. This simplifies things. What I did to keep the repository up to date was create a simple sh script that is run by cron every 10 minutes. The script simply issues 'svn ci --non-interactive --message Automatic commit' command in the /config directory. So any changes made to the configuration files are automatically recorded every 10 minutes. This works well, but does have a few flaws. First of all, when I edit files from sftp I have no way to add a meaningful message to the commit. Not a big deal, and I can always do a manual commit if I had to. The other thing is that this script will not auto-add files to the repository. Any new configuration file that I'd like to have monitored first gets moved to /config, then has a link created in the original place, then is added to the repository via 'svn add'. A bit more work, but I think it's fine. Technically I can automate the process of adding and removing files from the repository by using svn status output, but at this point the extra work isn't worth it. The bigger problem is the fact that subversion does not store owner and permission settings. That means that if I ever want to delete the /config directory and recreate it, I lose all permissions on things like master.passwd. What I did was add chown and chmod commands to the monitor script for all files that had non-standard permissions. So those get run along with the svn ci command every 10 minutes. The alternative was to use subversion properties, have the script parse those and apply the appropriate settings. However, since the permissions have to be set manually anyway there is no advantage to this over the monitor script, which is also versioned. The permission and ownership problem is also one of the issues which Subversion (or other SCMs) do not solve for base-system binaries too. See for example the thread: Using Subversion for binary distribution? which was recently present in `freebsd-current'. Hm... I wish I found that thread earlier on, because I actually missed the reference to Mercurial on wikipedia. I've been playing around with it over the past few hours and so far I think it might actually be a better solution than svn. It keeps just one .hg directory in the root of your project, which means that I don't need a separate storage location to isolate the versioned files. In addition to this, I can add an ignore pattern of .* (all files), which means that hg will only worry about the files that have been manually added to the repository. I'm rather intrigued by this system, but I'm going to play around with it a bit more in my test environment. Has anyone ever heard of corruption issues with hg? I guess it still suffers from the same problems with setting file permissions, but the hooks are there, so I'm not worried about that. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Recommendations for config file revision control
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maxim Khitrov Sent: Saturday, 2 June 2007 8:37 AM To: freebsd-questions@freebsd.org Subject: Re: Recommendations for config file revision control On 6/1/07, Reid Linnemann [EMAIL PROTECTED] 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
Re: Recommendations for config file revision control
Do you have an idea of how to manage symlinks with jailed software? Thierry. On Saturday 02 June 2007 01:35, Maxim Khitrov wrote: On 6/1/07, Kevin Downey [EMAIL PROTECTED] wrote: On 6/1/07, Maxim Khitrov [EMAIL PROTECTED] wrote: 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 What is the objection to having the metadata directories (.svn) everywhere? Well to be honest, I just really don't like that design. I think the metadata should be separated out from the data, and placing .svn directories into each directory of the project seems like a bad idea to me. I understand why it was done this way, but I wish that some extra effort was put in to consolidate all that information into perhaps a single .svn directory in the root of the project. That, and since they keep copies of the original files it also creates additional storage requirements, but for storing configuration files I don't really care. I did just think of another thing I could do. What if I create a new directory on the server, and move all configuration files from their original location to this directory. I then make then make it into an svn working directory, and in place of the original files put symlinks that point to the corresponding file in the working directory. This would mean that I no longer have .svn directories all over the file system, there is just one working directory that is separate from everything else. Instead of an export operation I could have the hook script do an update, and this would also give me a rather simple way of editing the files locally on the server (plus it has the advantage of quick access to all important files without having to constantly move from /etc to /usr/local/etc). Does this seem like a decent idea to try and do? Might some software have a problem with its configuration file being a symlink to some other location? devel/bazaar-ng is rather nice, and distributed vcs is very flexible. Will take a look at this as well, thanks. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for config file revision control
On Fri, Jun 01, 2007 at 03:27:57PM -0400, Maxim Khitrov wrote:
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.
Because I didn't want my config file all over the place, I've put them
in a directory tree called ~/setup, with subdirectories for etc, boot,
kernel configuration etc.
This directory tree is managed with git, because you don't have to check
in every single file like with RCS. So e.g. all the changes that I did
for the Xorg upgrade are captured in a single commit. Since git doesn't
support keyword expansion, and I always use emacs for editing, I use
emacs's time-stamp facility to keep the time and date of the last save.
I use an install script to install the config files where they belong,
and take appropriate post-install action.
One could put the directories like /etc under git's direct control as
well. That would save the installation step, and capture any system-made
modifications with git-status. But you'd have to manage the repository
as root.
- install script for /etc config files --
#!/bin/sh
# Shell script to facilitate installing files.
# Time-stamp: 2007-05-20 21:32:43 rsmith
# Installs a normal file.
I () {
install -b -v -p -m 644 $1 $2 |grep install || {
return 1
}
}
# Files that need to be installed as root go here.
do_root() {
I devfs.conf /etc
I devfs.rules /etc
I fbtab /etc
I fstab /etc
I passwd /etc
I group /etc
I hosts /etc
I login.conf /etc cap_mkdb /etc/login.conf
I csh.cshrc /etc
I cshrc.root /root/.cshrc
I login.access /etc
I locate.rc /etc
I manpath.config /etc
I motd /etc
I periodic.conf /etc
I pkgtools.conf /usr/local/etc
I portmaster.rc /etc
I profile /etc
I rc.conf /etc
I pf.conf /etc /etc/rc.d/pf reload
I ntp.conf /etc /etc/rc.d/ntpd restart
I rc.shutdown.local /etc
I resolv.conf /etc
I sysctl.conf /etc
I ttys /etc
I make.conf /etc
I newsyslog.conf /etc
I mtools.conf /usr/local/etc
I smartd.conf /usr/local/etc
I cdrecord /usr/local/etc
I esd.conf /usr/local/etc
# X11 config files
cd X11
I xorg.conf /etc/X11
cd ..
# SANE config files.
cd sane
I dll.conf /usr/local/etc/sane.d
I epson.conf /usr/local/etc/sane.d
cd ..
# Install root's crontab file
if ! crontab -l|diff - crontab.root /dev/null; then
echo Updating crontab.
crontab -u root crontab.root
fi
}
# Main program
if [ `id -u` -eq 0 ]; then
do_root
fi
- install script for /etc config files --
Roland
--
R.F.Smith http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpLsKe5V3XxN.pgp
Description: PGP signature
Re: Recommendations for config file revision control
On 2007-06-02 12:43, Thierry Lacoste [EMAIL PROTECTED] wrote: Do you have an idea of how to manage symlinks with jailed software? Thierry. [snip long posts quoted in their entirety] Hi Thierry. Please don't top-post. Your reply belong to the bottom of the text you are replying, at least in this list. If you feel that by putting your reply near the bottom of the text will `hide it after all this text', then trim the quoted text to the absolutely necessary bits. Please also note that your question is a bit vague. What do you mean by `manage symlinks'? What sort of `jailed software do you have in mind'? Is the question related to the original `config file revision control' topic of this thread? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for config file revision control
I did just think of another thing I could do. What if I create a new directory on the server, and move all configuration files from their original location to this directory. I then make then make it into an svn working directory, and in place of the original files put symlinks that point to the corresponding file in the working directory. This would mean that I no longer have .svn directories all over the file system, there is just one working directory that is separate from everything else. Instead of an export operation I could have the hook script do an update, and this would also give me a rather simple way of editing the files locally on the server (plus it has the advantage of quick access to all important files without having to constantly move from /etc to /usr/local/etc). Does this seem like a decent idea to try and do? Might some software have a problem with its configuration file being a symlink to some other location? Sorry for my previous top-posting. Will a chrooted named work if you make files in /var/named/etc/namedb/ symlinks to the working directory ? Regards, Thierry. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for config file revision control
On 6/2/07, Thierry Lacoste [EMAIL PROTECTED] wrote: I did just think of another thing I could do. What if I create a new directory on the server, and move all configuration files from their original location to this directory. I then make then make it into an svn working directory, and in place of the original files put symlinks that point to the corresponding file in the working directory. This would mean that I no longer have .svn directories all over the file system, there is just one working directory that is separate from everything else. Instead of an export operation I could have the hook script do an update, and this would also give me a rather simple way of editing the files locally on the server (plus it has the advantage of quick access to all important files without having to constantly move from /etc to /usr/local/etc). Does this seem like a decent idea to try and do? Might some software have a problem with its configuration file being a symlink to some other location? Sorry for my previous top-posting. Will a chrooted named work if you make files in /var/named/etc/namedb/ symlinks to the working directory ? Regards, Thierry. I'm not sure I understand your question. A symlink will work if you can get to the target inside the chrooted environment. You can't symlink to a file that's outside of the root. Here's an update on what I ended up going with. I decided to go with my idea of moving all configuration files to a common directory, but with a bit of a change. I created /config and under it base/ and user/. Everything in base/ comes from /etc and /boot, and the rest goes under user/. I didn't want to mix the two. So then I created a new subversion repository, but I set permissions such that only root can read or write to it. Basically I decided to forbid anyone on the outside from getting their hands on the repository contents, since it will be storing things like master.passwd and other sensitive data. Once all this was in place I moved all configuration files to their appropriate locations in /config and created symlinks in their original location. Everything under /config was then imported into the subversion repository using the file:// method. Since I forbid anyone from doing a check-out of the repository to some external location, I don't need to worry about file updates except when they are updated in /config. This simplifies things. What I did to keep the repository up to date was create a simple sh script that is run by cron every 10 minutes. The script simply issues 'svn ci --non-interactive --message Automatic commit' command in the /config directory. So any changes made to the configuration files are automatically recorded every 10 minutes. This works well, but does have a few flaws. First of all, when I edit files from sftp I have no way to add a meaningful message to the commit. Not a big deal, and I can always do a manual commit if I had to. The other thing is that this script will not auto-add files to the repository. Any new configuration file that I'd like to have monitored first gets moved to /config, then has a link created in the original place, then is added to the repository via 'svn add'. A bit more work, but I think it's fine. Technically I can automate the process of adding and removing files from the repository by using svn status output, but at this point the extra work isn't worth it. The bigger problem is the fact that subversion does not store owner and permission settings. That means that if I ever want to delete the /config directory and recreate it, I lose all permissions on things like master.passwd. What I did was add chown and chmod commands to the monitor script for all files that had non-standard permissions. So those get run along with the svn ci command every 10 minutes. The alternative was to use subversion properties, have the script parse those and apply the appropriate settings. However, since the permissions have to be set manually anyway there is no advantage to this over the monitor script, which is also versioned. So that's my solution to this problem, for anyone else who is interested. I took a look at all the recommended version control systems, including the list on wikipedia. A few looked interesting, but I decided against them for one reason or another. I think this subversion solution is a good compromise, but I'm always open to better ideas if you have any. - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Recommendations for config file revision control
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for config file revision control
I keep track of my servers config files with CVS. Let's say I want to track a machine named 'box'. On this machine I have a working copy of the cvs module box in /root/box. I have a couple of scripts cvs-add and cvs-ci. 'cvs-add /etc/rc.conf' copies /etc/rc.conf to /root/box/etc/rc.conf and then adds it to the cvs repository. 'cvs-ci -m message /etc/rc.conf' verifies that /root/box/etc/rc.conf exists and that the two files are indeed different then makes the copy and checks it in the repository. Finally I install a cronjob which checks if the files in the working copy are indeed identical to the 'real' files they mirror. It's very simple but very handy. However I'd like to hear about alternative solutions. Regards, Thierry. On Friday 01 June 2007 21:27, Maxim Khitrov wrote: 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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for config file revision control
On 6/1/07, Reid Linnemann [EMAIL PROTECTED] 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? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for config file revision control
On 6/1/07, Maxim Khitrov [EMAIL PROTECTED] wrote: 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 What is the objection to having the metadata directories (.svn) everywhere? devel/bazaar-ng is rather nice, and distributed vcs is very flexible. -- The biggest problem with communication is the illusion that it has occurred. G. B. Shaw www.thelastcitadel.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for config file revision control
On 6/1/07, Kevin Downey [EMAIL PROTECTED] wrote: On 6/1/07, Maxim Khitrov [EMAIL PROTECTED] wrote: 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 What is the objection to having the metadata directories (.svn) everywhere? Well to be honest, I just really don't like that design. I think the metadata should be separated out from the data, and placing .svn directories into each directory of the project seems like a bad idea to me. I understand why it was done this way, but I wish that some extra effort was put in to consolidate all that information into perhaps a single .svn directory in the root of the project. That, and since they keep copies of the original files it also creates additional storage requirements, but for storing configuration files I don't really care. I did just think of another thing I could do. What if I create a new directory on the server, and move all configuration files from their original location to this directory. I then make then make it into an svn working directory, and in place of the original files put symlinks that point to the corresponding file in the working directory. This would mean that I no longer have .svn directories all over the file system, there is just one working directory that is separate from everything else. Instead of an export operation I could have the hook script do an update, and this would also give me a rather simple way of editing the files locally on the server (plus it has the advantage of quick access to all important files without having to constantly move from /etc to /usr/local/etc). Does this seem like a decent idea to try and do? Might some software have a problem with its configuration file being a symlink to some other location? devel/bazaar-ng is rather nice, and distributed vcs is very flexible. Will take a look at this as well, thanks. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
