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: Thu, 18 Oct 2001 13:01:11 +1000 (EST)

On 17 Oct, Kaz Kylheku wrote:
>  In article <address@hidden>,
>  address@hidden wrote:
>  >First off, I should thank everyone who's taken the trouble to discuss
>  >this.  I should also say that the reason I'm still discussing it at
>  >length is not because I'm trying to do something childish like "win an
>  >argument".  I really am simply concerned that maybe there's a major
>  >flaw in my approach, and wanting to find out what it might be.
>  
>  There is a flaw in any approach to using CVS which views the working
>  sandbox as the deliverable object. This is not how CVS is used in 
> ``ordinary''
>  software development, and it's not really the way it can be used for
>  other purposes, like maintaining the software in your /etc directory,
>  managing web pages or whatever.
>  
>  The structure that is versioned in CVS should be seen as a set of inputs
>  which produces the deliverable thing.
>  
>  Not every file in the inputs will necessarily correspond to a unique
>  deliverable object.  For example, a C project may have many .c files,
>  yet the deliverable is one executable.

I basically agree with all those points, but they all generally relevant
for the normal use of CVS, where you have source files that are
compiled.  Most of the text files in /etc are used as-is, which is why
I think it's okay to use CVS in an unusual way in this case.

>  There are reasons not to treat /etc as your working sandbox, in addition
>  to the cited reasons related to avoiding system screwup or security
>  problems:

Thanks for giving these examples below.  But none of them seem like
show-stoppers to me.

>  - There are machine-specific variables in /etc, such as the system's host
>  name. If these are not created by a special step, but rather stored in
>  CVS directly, then you can't reuse the configuration for multiple machines.
>  You may want some centralized way to specify all the variables that
>  make up a machine configuration, and then in the generation step,
>  disperse this information into the right places. You might not care
>  about this today, but you might tomorrow. What if a friend wants to use
>  your funky version-controllable system configuration scheme?

I agree.  In which case my simple scheme is not worth anything.  But
it's designed to be used on a single machine and not transported.  It's
just a lightweight solution for a simple problem.  I'm not trying to
solve the bigger problem.  So this problem vanishes.

Anyone here who already has a configuration system in place like the one
you're describing would be foolish to drop back to my simple system.  I
think my system is worth considering though if you don't use anything
currently to provide management of /etc.

>  - You may want to write scripts which generate some of the /etc content,
>  or use macro preprocessing.  By doing this, there won't be a 1:1
>  correspondence between the repository files and /etc files.

sendmail does this, with m4.  There's still a 1:1 correspondence if
you wish.  There's less harm in checking in the products of the script
than in editing the resultant products directly, for example. 

> It's
>  inappropriate to pollute an actual /etc directory with these
>  extra source files.

Maybe.  sendmail does and no one seems to scream.  At least they're all
together in one place (or close by).  And in my scheme, automatically
under revision control too.

E.g. /etc/mtab changes constantly.  That doesn't mean you have to
commit changes to it.  You could add it to the .cvsignore file if you
wanted.

>  - The files in /etc have important attributes besides their content,
>  like permissions and ownership.  Changes to these can't be tracked in
>  CVS. However, your ``build'' scripts which generate /etc can set up these
>  permissions, and those scripts can be versioned. So you can track this
>  information indirectly.

That's what my script does, too.  Puts everything under CVS control in
situ, records the metadata, and adds that to a cvs repository outside
/etc.  In the event of a catastrophe, you could even use it to
re-create the metadata if you wiped out all of /etc.  Probably easier
to recover it from backups, though.  It's more for comparison purposes.

>  - You may want a different directory layout for your repository
>  versus the running /etc.  There is no reason why the two structures
>  should be identical. For example, if I were doing this, I might
>  make everything flat, just for the sake of convenience. Or organize
>  things into directories according to function.

I wouldn't.  I wouldn't feel sure that there weren't repeated file
names, and it would be hard to find things, and see what files were
logically related.  I can't see a good reason for having a different
directory structure to what's used in /etc.

So, I still really can't see any danger or problem in my el-cheapo
scheme.  At least, no increases in dangers or problems compared to not
having any management at all.

More regards,

luke




reply via email to

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