info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why can't root check in files?


From: luke
Subject: Re: Why can't root check in files?
Date: Tue, 16 Oct 2001 13:14:25 +1000 (EST)

On 15 Oct, Greg A. Woods responded to:
>  [ On Monday, October 15, 2001 at 09:50:29 (+1000), address@hidden 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
.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]