Slashdot Mirror
Version Control for Important System Files?
TokyoCrusaders92 asks: "Like a lot of other organizations (800 staff, 5000 students) we have a mix of Windows, Novell & Linux (primarily Linux) for our IT infrastructure. We now have a multitude of config files, firewall rule bases, shell scripts, and so forth which are managed by multiple people and groups. Recently, we started using RCS for version control of the firewall rule-base, but this doesn't seem like it would scale up to larger groups of users. While thinking about this, it would seem that the critical features would include: version control; logging; multiple users; secure authentication; and integrity checking. What are other people using to manage their config files?"
What more could you possibly need?
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
I keep my config files in a directory structure in my home directory on my laptop which mirrors the structure of the systems I maintain. I use the mercurial DSCM for version control and push revisions to a user account on each server. From there I run a script as root which recursively copies the files into the target directory tree.
http://michaelsmith.id.au
How similar are your systems? I help manage several thousand distributed boxes that are reasonably identical, and we keep everything in a central CVS server: management scripts, config files, crontabs, what have you. There's no reason it couldn't be used for more heterogeneous systems, other than having to be more careful with file naming conventions.
hang brain.
Next question?
Dewey, what part of this looks like authorities should be involved?
Using something like subversion or any other version control system for such a task just leads to Yet Another Homebrew Administration System, that will probably lead your successors to tears and insanity. Use tools already there, and that are pertinent to the job.
version control; logging; multiple users; secure authentication; and integrity checking. All those features you need are mostly already there in puppet: http://puppet.reductivelabs.com/ (and maybe also in cfengine, but that's a nightmare). And the development on puppet is really picking up steam at the moment.Problem for your situation is that it has no Windows or Novell support as of yet, but recently work on Windows at least seems to have started. And if your first priority is mainly config file management: that part should be fairly trivial.
xchg
jmp emailMe
We have a login script that calls another script that is the one that gets modified. To use different script you just change the name of the called script to the one you want. If the script gets changed then the person who changed it changes the name and we can tell how old it is by the date stamp on the file. So far we have these (oldest to newest):
sublogin.bat
sublogn2.bat
sblg2fix.bat
latestlg.bat
newlatst.bat
finalfix.bat
reverted.bat
fixwrked.bat
NtOnMyPC.bat
WksOnMyn.bat
NTONMYPC.bat
TryThis1.bat
Seriously though, subversion is good because it lets you do atomic checkins.
Australian running a company that does C# / C++ / Java / SQL / Python / Mathematica
See Files-11 for a flashback.
!ERR: Signature not found.
NtOnMyPC.bat
WksOnMyn.bat
NTONMYPC.bat
Do not M$FT file systems tend to be case insensitive?
Get an "Industry Standard OpenVMS" (that the name HP gives to that beast) and use it as your main file server and config info repository. All the features you desire are there by default.
While this response was accurate from the technical point of view, it was meant to be a joke
*** Suerte a todos y Feliz dia!
I use rsnapshot to do version control of my entire system. From the description:
rsnapshot is a filesystem snapshot utility for making backups of local and remote systems.
Using rsync and hard links, it is possible to keep multiple, full backups instantly available. The disk space required is just a little more than the space of one full backup, plus incrementals.
Personally, I configure rsnapshot to generate snapshots every 4 hours, and then daily, weekly, and monthly.
In your case, since you only want versioning for your configuration files, you can point rsnapshot at just the configuration directories (probably just /etc).
Gan Family Homepage
For Windows, the default answer for deploying configuration is Group Policy. With the Group Policy Management Console you can back up your GPOs and store them in your version control system. Alternatively, you can use a specialized Group Policy version control and troubleshooting product like Group Policy Manager from Quest which allows offline editing and testing before deployment to your production environment.
You can actually extend Group Policy to your *nix and Novell machines as well using Vintela Group Policy (a part of Vintela Authentication Services), which also has features to allow your *nix machines to use your Active Directory accounts. If you use it in combination with Group Policy Manager, you can back up the *nix specific settings alongside the rest of your GPO. Also, the integration allows you to diff different versions of your *nix settings alongside the rest of your GPO.
[Disclaimer: I am a developer on the Group Policy Manager team at Quest. While I'm proud of my product, I'm not any kind of official spokesperson for my employer.]
BRENT ROCKWOOD, EST'd 1975
On systems where it matters, I keep config files etc in RCS.
In each directory where config files live that I want to keep, I create an RCS directory and rcs -i the file(s).
Nightly, I job runs that finds all files for which an RCS entry exists and that are newer than that entry, and a copy is checked in.
No need to think about checking in/out all the time, no problem that the RCS seems to believe that you don't want to keep the actual file around.
It does not save every edit but at least I have a copy of each day's state of the file.
will be a big help
Try darcs (http://www.abridgegame.org/darcs/). Should do everything you need and has the advantage that you can create multiple repos for different purposes which all base on a single base repository. So i have a repository with all my config files and several others for different users which can pull their changes on top of the standard stuff. The syntax is quite easy to learn too.
Only drawback is that it is quite slow with really big repositories (e.g. linux kernel).
For a new installation, Subversion is probably a better choice than CVS, mainly because changesets are committed atomically, directories are versioned, and it has better security when dealing with remote access.
http://outcampaign.org/
- create the dir in the repository but leave it empty
- checkout that url on the existing dir, since url is empty nothing is overwritten
- now do an svn add then commit to get everything into the repository
This leaves you with a versioned dir without need for renaming or deletionPATH train schedule online
this one is mine.
I use vice versa pro
http://www.tgrmn.com/ disclaimer, I'm just a customer
It lets me sync files across different directories.. and if it finds changes, it has an option to archive a copy of what was there before in a third directory, with a date/time stamp.
you can set it to retain X# of copies, or for x# of days.. I have it set to automatically run on any change in the
mydocs folder on my pc at work, or my pc at home.. if I open a file at home and modify it, I can rest easy knowing the chages will be there on my work pc the next day, and if I screw up, I can go to the archives...
I can set the bandwidth limit so as to not drown out my point to point connection (the work connection is commercial account cable modem, and also supplies my workplace website)
every day http://en.wikipedia.org/wiki/Special:Random
Config files are trivial to manage in CVS, it doesn't really need anything more sophisticated. You could probably get away with RCS but it'd be more hassle.
Deleted
As a lot of people suggested - SVN, one repository per type of server (so you can merge changesets even internally, although using diffs is also easy), the only problem we've got is that everyone uses root@ on that machine, and the repository is checked out by servername@svn-server, so everyone has to write his name when commiting changes. If it was possible to auth users based on ssh keys on the svn server, it would be perfect.
don't waste your money on "Enterprise CVS solutions" that suck donkeys balls (the more expensive, the crappier it is, pretty much all of them).
They will gladly charge an arm and a leg for something as good (or worse) as CVS
Yes, I think you're thinking what I'm thinking and it is beyond me why people pay so much money for that crap. Probably because in their minds expensive == good
how long until
Yup, definitely ClearCase. With UCM. It will make you forget about all of your current problems.
After you sign the huge check$ and the army of IBM consultants have left you will spend so much time dealing with cryptic errors, frantic users, and merge problems that you will have totally forgotten any problems you now have.
One word: cfengine
http://www.cfengine.org/
I've been thinking about doing a project like this. I would probably use rdist+ssh/nfs/samba to copy the files to a central host, and run a cron job that calls a Perl script to check in changes regularly, only if something has changed; perhaps along with selections from the logfiles of the machine where the change happened. I would probably use SVN as the version-control system. However, those are the just the tools that I'm most familiar with; I'm sure many other tools could be used to accomplish this task.
Our staff student ratio is 400/6000. Perhaps you could fire the 200 or so IT dudes it takes to babysit all those linux boxes and deploy Windows.
The functionality seems good, but that's the most ugly and inconsistent UI I've seen in a long time! Check out the screenshots page for at least 3 or 4 different styles of buttons and colour schemes. If they could polish the UI to make everything consistent, and perhaps use a manifest to use the XP theme, it could be very nice indeed. As it stands it looks like something my boss would knock up in VB as a prototype. *shudders*
Simply write a script that runs MD5sum on every file in the filesystem once per minute and then copies any that have changed over the network to a central VMS server (which will take care of the versioning for you).
That's what you get for not listing cost effectiveness or efficiency amongst your requirements. Be more careful in future.
First, some points about what would motivate a decision for Subversion:
- Revision control (Which includes all the things you do in software engineering: tagging, branching, merging, diffing, patching.)
- Excellent cross-platform support
- Several choices for client connectivity. HTTP(S)/mod_dav and SSH are the most popular.
That said, Subversion is NOT just for managing traditional software projects. There are many other types of controlled resources that require the features above. In our case (a large University), we use Subversion to manage our builds of the applications that _run_ our software. Our builds of Tomcat and JBoss are tightly controlled, and we use revision control techniques to manage them. Diffing files from a new release against our trunk, merging vendor changes, and branching configurations for different environments are common practice.
Subversion is an excellent tool for software configuration management.
M
About 2 years ago, we've introduced SVN to check in and keep control over our config files in /etc on our rootserver.
It allows us to see when, what and - given the administrator provided this information when the file was committed - WHY changes have been applied. That's pretty important in an environment, where up to 9 administrator have access to the files.
Saves you from losing precious configurations and allows for easy rollback if a certain configuration change doesn't work. You can even use your config on more than one server. Use branches and switching files for configs that are host-dependant.
On the downside, this system only works if all administrators commit their files immediately after the change and document the reason for changing.
bye,
Settel