Re: Why can't root check in files?

[Jesus Manuel NAVARRO LOPEZ]

Hi, Luke:

address@hidden wrote:
> 
> 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.
> 

The easiest: a non tested checkout goes directly to the production
environment thus potentially giving you an unusable system (specially as
soon as you see it's not good idea posting to the server in-file
passwords; then you substitute by a token like [HERE_PASSWORD]; next you
see is you forgot to manually substitute that token on any given file). 
Another one.  CVS will work as root; as soon as any other process/user
access to that CVS *server* you can expect another hole on your system.

> 
> >  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.
> 

Well, yes you can, by proper config procedures.  You want to use rpm?
well then use it.  But record what's have been installed so you can see
what has been modified, accept/reject changes, then checkin as needed. 
About non scriptable facilities like those you mention, now you see why
they *seem* to be a good thing, not being so in the long run.

> 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!
> 

You should see if their usage proves *real* benefit.

> > > 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.
> 

Yes.  That means you have an extra layer of knowledge of your system and
that you avoid "magics" blindly changing your system's state.

> >  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.
> 

It is not that the build step adds more work, but that you're trying to
save some time avoiding some steps.  You can try, but probably sooner or
later you will see that your shortcut not always pays.  You seem to want
accountability and repeatibility (that's good) but then, you try to
shortcut because it seems too workload.  Then review your objectives. 
It migth prove you don't need such a level of control of your system (it
comes to my mind that if you *really* would need it, tools like
linuxconf or webmin would be immediatly banned, and you wouldn't talk
about other's non-acountable changes to config files as "good changes
that may have requiered lots of work" instead of "dangerous unacountable
changes that must be avoided by any means").  Under this assumption
everything comes clear to me (I don't try to be rude, really).  You want
accountability and repeatibility because you feel it's good and it seems
cool, but you are not really convinced it's the goal to go, so as soon
as that control-layer suppouses more workload you feel it doesn't pay
(and it migth probe so: most home systems, for instance, have great
benefits from using such graphical aid tools with no versionning tools
in use, since the extra work doesn't pay for the avoidance of mistakes
that you can make from time to time and that are neither critical nor
difficult to fix).

> >  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.
> 

*You* are the one with knowledge of the change control system.  I would
thougth that was more than enough.

> 
> 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.
> 

Knowing a bit Woods opinions on this and other fields, I would say
(well, in any case I do say for myself) that loosing unacounted changes
is not a real danger but for the one who made the changes (why he didn't
follow approved procedures?) while "hidden" non-documented non-accounted
changes to a live production server *is* a *real* danger.

> 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 knew once a *good* proffesional on these fields.  He sayed to me:
Sysadmin is not a democracy but a dictatorship: it's the way to go, it's
the way that works, and that's all to be said.  My own experiences from
those old days to-date are that he was real real real right.

> > > 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 ...)
> 

Ahhhh... the monstars of Id, the monstars of Id...

> 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.
> 

Considerable burden to the process of management? Sure?  *If* you want
to have *any* "process of management" then you *must* control the build
process, or you won't have any management at all.  Full stop.

> > > 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.  You forget you *always* have a build stage, be you aware of it or
not. If you use, let's say, webmin, the build step is as simple as
pressing the "commit changes" button, but it's there.  If you vi-edit
/etc/password by hand, there you have your build stage.  Surely you can
use a more complex build process if you need to cope with more variables
(like more machines) or need more control.  As an example, I use more or
less the same approach Woods is talking about.  But in most cases I
manage (only myself) a few so different boxes that it doesn't pay to
have an explicit build process/scripts.  But *there is* a build process;
it's only that it is on my mind and/or layed out on the system's
documentation and it is enforced by means of my only volunt of acomplish
it.

> [...]
> >  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.
> 

Because as you yourself are telling us, your simple solution doesn't
reach the goals you were trying to acomplish from the very beginning
(why would you need/want a source control process if you end admitting
you won't have acountability nor repeatibility).
-- 
SALUD,
Jesús
***
address@hidden
***