On 15 Oct, Greg A. Woods responded to: > [ On Monday, October 15, 2001 at 09:50:29 (+1000), [EMAIL PROTECTED] >wrote: ] > > Subject: Re: Why can't root check in files? > > > > My system is now under cvs control via having /etc as a cvs working > > directory, and so far at least it has caused me no problems, and worked > > just as I expected. > > > > I have no idea why you claim it is dangerous. > > Trust me -- I have a _LOT_ of experience in this very matter.
Some examples would help. I'm still drawing a blank on imagining dangers. > > Yes, the su logs will probably be enough to provide proper > > accountability in this case. > > Maybe. > > However there are many variables here. For the _general_ case it is > insufficient to make such an assumption. For the _general_ case commits > to CVS must always be done as a unique individual identifiable (i.e. > authenticated) and authorised user. Sorry, I meant that the su logs will probably provide enough extra information beyond what cvs records to provide accountability. Re: recording metadata: > It's trivial -- you record them by checking in the scripts and/or > control files that make up your "build" system. (eg. your makefile) > > This is yet another reason why you _need_ an intermediate "build" step > to install the source files into their target locations. It is this > very process which records your metadata. But this seems to me like an onerous requirement, and an intrusive policy. It means that you can't just use rpm to install packages, or webmin or linuxconf or control-panel etc. etc. to help configure your system. You can't use any of those things without manually comparing those changes back to what your "build" step does, and retro-fitting the changes that you approve of back into your build system. In other words, you lose most of the benefits of using the helper tool in the first place! > > Also, your method would also require a diff of each file to be > > installed, against the corresponding live file - since other people in > > the wheel group could make changes directly; possibly via webmin or > > linuxconf or any of the other sysadmin tools floating around, or by > > installing new packages. Otherwise you risk wiping out changes > > (possibly good changes that may have required lots of work). > > Oh, no! Absolutely NOT! My method mandates that _all_ changes be made > through the CVS source files, and _only_ through the CVS source files. If you insist. It still means you have to do a diff of each file, and a comparison of each file's metadata, to what is embodied in your build system. Which sounds to me to be harder than what I assumed you were doing. > This is yet another reason why you _need_ an intermediate "build" step. It sounds to me like an extra reason why an intermediate "build" step introduces more work! I'm not saying that it doesn't also give you benefits - I';m just saying that it's more work. Like using cfengine would give you more benefits, but is also more work. > You _want_ all changes to be forced through the change control system! To me the difficulty in the scheme you describe is the complexity introduced by this extra level of indirection. And not all the changes can easily be forced through the change control system, since they're designed to just work with /etc, and have no knowledge of the change control system. The one thing that everyone agrees on - the one well-defined set of data which everything can refer to and work in relation to - is the live system in /etc > While "loss" of unauthorised changes is a risk with my system (though it > can be mitigated in various ways by adding more checks), it's also a > very successful (and proven so) way to enforce discipline on one's > fellow administrators! :-) Okay, so we're agreed that the scheme you describe risks the loss of changes. Maybe I've also explained that it also means that lots of neat system config tools (webmin etc.) become Forbidden in your scheme, or at least force lots of manual work: retrofitting their changes back into your build system. But also mandating this mechanism as the way to enforce discipline seems a bit draconian. There are other ways - requiring a process of peer review of changes by another administrator would be one; logging each change would be another; using my scheme is another. > > I don't see any benefit from having a cvs checkout of the etc files > > somewhere else - the system isn't going to look at any of them if > > they're not in /etc, so I can't see much value in it. > > It's not exactly a checkout of those files -- it's a checkout of the > _sources_ for those files. There's an almost inifite conceptual > difference that's critical to understand here! Well, a *large* conceptual difference, sure. :-) (Your comment reminds me of that line in Forbidden Planet, where the scientist says that the large number of dials are logarithmic, and reach as high as "10 raised almost literally to the power of infinity". :-) Anyway ...) I believe I appreciate the difference. But that level of indirection, that separation of the sources from the live files, seems clearly to me to add a considerable burden to the process of management, for the reasons that I've tried to explain above. > > Maybe the clue is in your mention of "target system(s)". Perhaps you > > were pushing out the changes to multiple machines. My scheme is > > designed to work locally, just on the local machine. Okay, good, then I have understood. You were trying to manage something more complex than I am - not just the config of the local machine, but of others too. (I imagine that differences between each machine would raise interesting problems, and I imagine push you towards something larger and more powerful like cfengine to solve that bigger problem.) > This is yet another reason why you _want_ an intermediate "build" step! Yes, it's a reason why you need a build step - *if* you're managing more than just the local machine. [...] > No, I solved the exact same problem you're attempting to sove, just in a No, you weren't solving the exact same problem. You've just explained how you were solving a superset of my problem. Since I'm trying to solve a simpler problem, I don't see why the solution can't be simpler. To be honest, I'm not sure where our discussion is heading any more. I'm happy to have learned that I can do what I want with cvs, as it is. I also see lots of areas where I'm in agreement with you. The main points of difference seem to be: 1) You say that doing what I'm doing to manage the config of a single local machine is dangerous. (This worries me. I'd love it if you could give me some examples.) 2) I say that the scheme you described, dramatically reduces the usefulness of tools like linuxconf. Regards, luke . _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
