[ On Friday, October 12, 2001 at 10:51:23 (+1000), [EMAIL PROTECTED] wrote: ] > Subject: Re: Why can't root check in files? > > I've looked at it. It is solving a somewhat different problem. It is > not only far heavier tool than what I need, it's also more active (li > kely to reset permissions to what you had laboriously constructed), and > has a much larger learning curve. > > Hands up how many people are using cfengine on their home system?
That's not quite a fair question. The issue isn't which tool you use to drive the configuration of your system using the source files that you will manage with CVS, but rather that you start out with the premise that you do indeed need such a tool in the first place. The choice of which tool you end up using will be guided by requirements entirely unrelated to which change tracking tool you use with the input source files. > Greg A. Woods replied to: > > > > You need to use some intermediate build process, which when necessary > > must be run as the superuser, to install your config files into their > > final resting place. > > That's not actually true. I *have* a script that runs over a set of > /etc-like directories and adds all the plain text files into a CVS > archive, and populates the live area with CVS directories and > .cvsignore files without altering any of the existing files. Yes, it is true. Your script is part of that tool, though it's incomplete and apparently headed in the wrong direction. You most definitely do not ever want to make /etc a CVS working directory! That's not only dangerous, but is why you're ecountering this problem in the first place. You now need a corresponding program to install the resulting source files into their proper locations in the production system. > > However the maintenance of the source files and commits of their changes > > to CVS must be done by a real user-id, i.e. some user-id that represents > > exactly one real-world person. > > You can't guarantee this, ever. Excuse me? Accountability is a fundamental cornerstone of all computer systems security. You have no real security without it. Everything you said after that sentence is further down the road of your confusion and isn't worth arguing point by point. The process I've used successfully in the past was to build a mechanism much like cfengine (but more primitive), and to create a CVS module writable only by the "wheel" group. This module was populated with configuration files for the target system(s). Users then checked out this module, as themselves into a private and protected working directly, and from there they could commit changes to the files in it. To install the resulting files into production they would 'su' and then run "make install" in their working directories. One of the first commands run by the makefile was a "cvs -nq update" check to ensure that the files they were installing were all committed (and up-to-date). Other simple consistency checks were also done on some of the files, such as ensuring the old copy was still identical to the revision noted in its RCS $Id line (i.e. to ensure no uncommitted changes would be clobbered). Accountability here is maintained in several ways, including through the CVS repository and through the 'su' logs. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs