Implications of Submitting Core Unix Configuration Files to RCS

[Ralph Grothe]

I wanted to post this as a SW call to the HP support people using my system handle, but the webserver taking the queries seemed overloaded and always timed me out. :-(

Since I'm sick of piling up backup copies of frequently changing configuration files (e.g. crontabs, passwd, hosts DNS zones etc.) as to keep track of revision history, and to bail out from misconfigurations, I would rather like to put those candidates under revision control of e.g. RCS.
Would this have any impact on standard HP-UX tools/procedures, such as SAM, patches, upgrades, system scripts, and the like?
Of course, I would make sure to always keep a working file around through e.g. "ci -u ".

Regards
Ralph

[Paula J Frazer-Campbell]

Hi
Just a suggestion.
I have a dir off my main database into which gets copied every evening all config files -via a small script.
This is then backed up with the company data and so I can then recover a config file as and when I require it.
If you have more that one person making changes to config files use a script for them to edit the files ie "vihosts" which first of all makes a copy of the hosts file and the invokes vi hosts.

[Ralph Grothe]

Hi Paula,

I also thought about a croned/scripted regular backup solution, but what appeals to me with an RCS like solution is its compact form of only saving the deltas of changed files.
Of course with a sort of database in the background one could think up something similar, but why reinvent the wheel while those tools are already lurking under the hood?
Apart from that we have a nightly ADSM backup job running from whose backups I could retrieve former versions of files.
But this seems too fussy to me (is this an indicator that we are running the wrong backup strategy here? ;-)
Whereas your suggestion of writing a kind of wrapper script to hide the nitty-gritty from the maintainer seems well worth a thought.
I know there's a visudo command for the sudo config. file, and haven't we a vipw command which takes care for filelocks behind the scenes?
As it doesn't directly answer my question, but put me on another trail, I hope you can live with merely 4 pts.

[Andreas Voss]

Hi,

the only problem i see are the uid/gid and permissions of the workfile created by co -u ...
Extract from: man rcs
Do not add optional ACL entries to an RCS file, because they are deleted when the file is updated. The resulting access modes for the new file might not be as desired.

Regards

[Ralph Grothe]

Hi Andreas,

it feels kind of daft not to reply to you in German, but I don't want to exclude other forum participants from the thread.

Actually, I also came across your manpage quote regarding ACLs.
This isn't a topic (so far) as I'm not using ACLs.
I had a few files and executables that needed a more fine grained permission context. But for those I'm using the GPL tool sudo which also allows some logging.

The configuration files that undergo more frequent changes are to be tampered with only by us sysadmins (varying levels of experience from experts to newbies like me). So when these files need to be changed they will be changed under root's effuid.
Comparing permission bits between the workfile copies and the relating *,v files I can see no difference.
So is there anything else I would have to take into account.

(n.b. be clement with my reserved assignment of points for your hint, but your scores already outnumber most mere mortals' in this forum ;-)