Re: cvs commit as root

[Ralph Mack]

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

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 and run-time efficiency (since it inherently
checks file dates before doing anything).

Ralph