Re: [OT] - Best Practices(TM) for Configuration File Changes
Hello, list. Before I pose my question, I am not intending to start a flame-war of any sort -- I'm just searching for different ways of doing things. With so many different version control systems available (aside from the traditional keep current backups solution), I am curious: Q: What is *your* favorite/suggestion solution to keep (working) versions of configuration files, in case something goes awry? i do backups of whole system (not just configs) with rsync+cp -lpR to have multiple generations. this way i don't need ZFS or UFS snapshots to do this. as i have backups i always can get things from it. But Best Practice(TM) is YOUR BEST PRACTICE, most suited to yourself. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
[OT] - Best Practices(TM) for Configuration File Changes
Hello, list. Before I pose my question, I am not intending to start a flame-war of any sort -- I'm just searching for different ways of doing things. With so many different version control systems available (aside from the traditional keep current backups solution), I am curious: Q: What is *your* favorite/suggestion solution to keep (working) versions of configuration files, in case something goes awry? I am specifically targeting configuration files because they are what I change the most, in avoidance of It worked 10 minutes ago... situations. Cheers, -- Glen Barber ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] - Best Practices(TM) for Configuration File Changes
On Sun, 29 Mar 2009 07:37:27 -0400, Glen Barber glen.j.bar...@gmail.com wrote: Hello, list. Before I pose my question, I am not intending to start a flame-war of any sort -- I'm just searching for different ways of doing things. With so many different version control systems available (aside from the traditional keep current backups solution), I am curious: Q: What is *your* favorite/suggestion solution to keep (working) versions of configuration files, in case something goes awry? I am specifically targeting configuration files because they are what I change the most, in avoidance of It worked 10 minutes ago... situations. The base system of FreeBSD includes RCS[1]. I regularly use it to track changes to individual files. The advantage of RCS is that it is easy to use from a system that is barely `up', i.e. a system that has just been brought up to single user mode. No special daemons or other sort of service is required, no ports to be installed, and so on. I can usually just run something like: [1] http://www.gnu.org/software/rcs/ # cd /boot # rlog loader.conf RCS file: RCS/loader.conf,v Working file: loader.conf head: 1.5 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 5; selected revisions: 5 description: revision 1.5 date: 2009/03/27 17:58:59; author: root; state: Exp; lines: +2 -1 Autoload acpi_ibm.ko for the extra Thinkpad X61s tunables. [more output snipped] # Whenever I want to look at a change, I can use `rcsdiff': # cd /boot # rcsdiff -u -r1.4 loader.conf === RCS file: RCS/loader.conf,v retrieving revision 1.4 diff -u -r1.4 -r1.5 --- loader.conf 2009/02/17 20:26:14 1.4 +++ loader.conf 2009/03/27 17:58:59 1.5 @@ -9,6 +9,7 @@ legal.intel_iwn.license_ack=1 # Autoloaded modules. +acpi_ibm_load=YES snd_hda_load=YES #zfs_load=YES if_iwn_load=YES # The co(1) and ci(1) utilities are relatively easy to learn. Whenever a permanent change has to be made, I can use: # cd /path/to/file # rcsdiff -u filename If this shows changes they are probably uncommitted changes I have made without recording when or why. This is usually an indication of some sort of 'temporary hack'. I review the diff, and either commit it or throw it away. Then I check out a clean copy of the file, make the new permanent changes, review the changes one last time with the `rcsdiff' command, and commit them again. # co -l filename # vi filename # rcsdiff -u filename # ci -l filename As an extra bonus, when a system is fully up and running, there is very good integration of RCS with GNU Emacs, so I can edit the files directly from my Emacs session, view diffs with older revisions, roll a bunch of files back or forward through history, and do whatever else is supported by the VC mode[2] of Emacs: [2] http://www.emacswiki.org/cgi-bin/wiki/VersionControl RCS is not really 'modern', i.e. it does not support changesets with multiple files (each file has its own separate, per-file history), and it does not support elaborate file merging techniques (like some of the modern distributed VC systems). But it is always there, it does the Right Thing with file permissions and file ownership, and is well integrated with my favorite editor. That's more than enough for now :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] - Best Practices(TM) for Configuration File Changes
Hi, Roger On Sun, Mar 29, 2009 at 8:20 AM, Roger Olofsson 240olofs...@telia.com wrote: For local configuration files there's a tool called rcs that can be used for tracking changes and rollback. It's a part of the FreeBSD base system. Check the man pages for rcs(1) ci(1) co(1) rcsdiff(1) and rcsintro(1) - rcsintro(1) is probably where you want to start. It's also available on other *nix systems like AIX, Red Hat, Solaris etc. I received a reply (off-list) mentioning the same tool. My response was: I was fairly certain that I would get rcs in a reply. I haven't used it too extensively, but it seems similar to cvs / svn -- which I personally like. I was more curious if people actually do use rcs for this purpose. It appears rcs is the right tool for the job. Thanks for the reply! -- Glen Barber ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] - Best Practices(TM) for Configuration File Changes
On Sun, Mar 29, 2009 at 07:37:27AM -0400, Glen Barber wrote: Hello, list. Before I pose my question, I am not intending to start a flame-war of any sort -- I'm just searching for different ways of doing things. With so many different version control systems available (aside from the traditional keep current backups solution), I am curious: Q: What is *your* favorite/suggestion solution to keep (working) versions of configuration files, in case something goes awry? I am specifically targeting configuration files because they are what I change the most, in avoidance of It worked 10 minutes ago... situations. My configuration files are kept in git managed directories under ~/setup/hostname. Every hostname directory is its own repository. The reason that I'm using git is because it does what I need, is small and fast and doesn't require an external reporitory. For configuration files which are usually plain text all revision control systems would probably work OK. Every directory contains two perl scripts, check.pl and install.pl that respectively check the differences between files in the repository and in the filesystem and install files. Both these programs read a file called 'filelist.username'. This is a text file that has on every line a file in the reposirory, a permission, and its location in the filesystem (e.g. under /etc or /usr/local/etc for user root, or in $HOME for other users) and any post-install commands. Both scripts only process the filelists for the user that is running the script. Excerpt from filelist.root: # List of files that should be installed as root, # with their install locations. # Time-stamp: 2009-03-04 20:52:39 rsmith # setup filepermsystem file commands etc/login.conf 644 /etc/login.conf cap_mkdb /etc/login.conf etc/make.conf 644 /etc/make.conf etc/manpath.config 644 /etc/manpath.config etc/master.passwd 600 /etc/master.passwd pwd_mkdb -p /etc/master.passwd etc/mergemaster.rc 644 /etc/mergemaster.rc etc/named.conf 644 /var/named/etc/namedb/named.conf etc/ntp.conf644 /etc/ntp.conf /etc/rc.d/ntpd restart The file from the first column is installed in the location in the third column with the permissions listed in the second column. The rest of the line (if any) is interpreted as a list of commands and executed by a subshell. This system makes it easy to see if there are any differences between the configuration files in the repository and the real configuration files (e.g. after a mergemaster run). And it can install every file in its correct place. It also makes sure that users can only install their own files, by reading only that user's filelist. 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) pgpFyDwfajseu.pgp Description: PGP signature
Re: [OT] - Best Practices(TM) for Configuration File Changes
Hi, Roland. On Sun, Mar 29, 2009 at 8:45 AM, Roland Smith rsm...@xs4all.nl wrote: My configuration files are kept in git managed directories under ~/setup/hostname. Every hostname directory is its own repository. The reason that I'm using git is because it does what I need, is small and fast and doesn't require an external reporitory. For configuration files which are usually plain text all revision control systems would probably work OK. Every directory contains two perl scripts, check.pl and install.pl that respectively check the differences between files in the repository and in the filesystem and install files. Both these programs read a file called 'filelist.username'. This is a text file that has on every line a file in the reposirory, a permission, and its location in the filesystem (e.g. under /etc or /usr/local/etc for user root, or in $HOME for other users) and any post-install commands. Both scripts only process the filelists for the user that is running the script. [snip] I currently use subversion for my University work (primarily because of how well it handles binary files). SVN seems to be a bit overkill for what I am looking for. The file from the first column is installed in the location in the third column with the permissions listed in the second column. The rest of the line (if any) is interpreted as a list of commands and executed by a subshell. This system makes it easy to see if there are any differences between the configuration files in the repository and the real configuration files (e.g. after a mergemaster run). And it can install every file in its correct place. It also makes sure that users can only install their own files, by reading only that user's filelist. I'll have to play around with this -- interesting. Thanks! -- Glen Barber ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: [OT] - Best Practices(TM) for Configuration File Changes
Glen Barber skrev: Hello, list. Before I pose my question, I am not intending to start a flame-war of any sort -- I'm just searching for different ways of doing things. With so many different version control systems available (aside from the traditional keep current backups solution), I am curious: Q: What is *your* favorite/suggestion solution to keep (working) versions of configuration files, in case something goes awry? I am specifically targeting configuration files because they are what I change the most, in avoidance of It worked 10 minutes ago... situations. Cheers, Hi Glen, For local configuration files there's a tool called rcs that can be used for tracking changes and rollback. It's a part of the FreeBSD base system. Check the man pages for rcs(1) ci(1) co(1) rcsdiff(1) and rcsintro(1) - rcsintro(1) is probably where you want to start. It's also available on other *nix systems like AIX, Red Hat, Solaris etc. /R ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
