[Top][All Lists]

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

Re: cvs commit as root

From: Ralph A. Mack
Subject: Re: cvs commit as root
Date: Sun, 09 Dec 2001 23:38:40 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2

> Let me clear something up here.  First off, I'm not debating the value
> of your technique.  Like I said, it is well beyond my level of
> operation.
> Only descibed my home grown technique as strictly amatuer hour.  Just
> filled in a little to show how it actualy works.
> > For example how would you manage per-user crontab files?  I did it
> > quite simply in my makefile with this kind of rule:
> In my setup, its not the kind of thing I would be concerned with.
> I don't expect to cause mass harm with crontab settings. Although
> possible I'm sure.  My crontab usage is rather low level.
> I'm more concerned with keeping tabs on things that effect the system
> in a basic way.  Things like /etc/fstab /etc/profile /etc/syslog. Or
> on freeBSD things like /etc/rc.conf  The heart of the config setup.
> rc.firewall and others of similar importance.

One of the implications of CVS managing your files as source files
rather than as deployed files is that CVS assumes a certain latitude in
how it uses file system "attribute" information like permissions and
ownership and such. CVS tends to do this sort of thing a directory at a
time, which is a very broad brush, particularly when you are talking
about something like the /etc directory. CVS updates also, I believe,
recreate files in working directories without respect to their prior

Keeping a layer of makefile/script between your source control system
and your deployment areas gives you a greater control of file system
attributes of deployed files. If you are concerned about security you
may want this layer in place, as there are some files (e.g.
/etc/profile) that, in order to be used on a day-to-day basis, need
different permissions than you would willingly place on other files
like, say, /etc/shadow.

There is always a continuum between convenience and security that any
system admin needs to weigh. I won't intrude on your prerogative with
arguments or suggestions in this regard beyond thinking about the
hassles involved if a third party used your system as a staging platform
for an attack on somebody with something valuable to lose and the
habit of pushing their weight around.

On one front I agree with you: most shell script looks a bit like line
noise. :-) However, it can be learned with surprisingly little effort.
The base rules are very simple and shell script is very idiomatic. Some
combinations of syntax and commands are so useful that they tend to get
used quite a lot. Once you've learned a few of the common idioms, it
becomes very easy to read scripts like /etc/rc.local or /etc/profile
and nothing that you are likely to use for this purpose will be more
complicated than those. Besides you will need a good command of shell
script in order to manage a Unix-influenced operating system effectively
anyway. Without it you are severely hampered.

If makefiles make you uncomfortable, start out with a few simple shell
scripts and learn make later. All make really gives you over a
well-written shell script is convenience (all activity is rule-based)
and run-time efficiency (since it inherently checks file dates before
doing anything).


reply via email to

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