Re: cvs commit as root

[Greg A. Woods]

[ On Saturday, December 8, 2001 at 07:19:10 (-0800), Harry Putnam wrote: ]
> Subject: Re: cvs commit as root
>
> Well, its not really true that it `isn't much different'.  The copying
> step is really a major pain in the butt.  And represents aboutt 50% of
> the work needed to keep something in cvs.  Removing that step cuts the
> work roughly in half and probably considerably more.  Considering it
> creates extra steps for many other proecess as well.

If you think those things then you're doing something very wrong.

The copying step should be no more than typing one short command, such
as 'make'.  Yes there's the overhead of maintaining the process, but
it's nowhere near 50% of the total work in using CVS -- maybe 10% at the
very most.  (but then you're maintaining your hairy little nest of
symlinks now anyway)

> For example: Diffing the file curently in use against the latest cvs
> controlled version requires a more complex command line.

Or a simple canned process that works for all the files.

When using CVS, especially for system configuration files, but even for
anything else (documents, web pages, etc.) you really _MUST_ treat the
files in a CVS working directory as "source" files.  You are in some
effect doing that now, but you've tied your live files to the source
files in one particular special working directory with string that could
cause you any number of different kinds of problems on a regular basis.
You need to cut those strings (i.e. don't use symlinks) and instead
write a very simple little script that can update your live files from
any given working directory, doing whatever validation you feel
necessary before affecting the live files, and doing any other tasks
necessary to make the updates actually take effect.

For example how would you manage per-user crontab files?  I did it quite
simply in my makefile with this kind of rule:

/var/spool/cron/crontabs/news: crontab.news
        @if [ -f $@ ] ; then \
                if cmp $? $@ > /dev/null ; then \
                        :; \
                else \
                        diff -c $@ $? || true ; \
                        echo "su news -c crontab < $?"; \
                        su news -c crontab < $? ; \
                fi; \
        else \
                echo "WARNING: $@ was missing!"; \
                echo "su news -c crontab < $?"; \
                su news -c crontab < $? ; \
        fi

Here's a sample rule for a file that needs another special action done
to make it really active:

/etc/syslog.conf: etc/syslog.conf
        @if [ -f $@ ] ; then \
                if cmp $? $@ > /dev/null ; then \
                        :; \
                else \
                        diff -c $@ $? || true ; \
                        echo "install -o root -g staff -m 444 $? $@"; \
                        install -o root -g staff -m 444 $? $@; \
                        if [ -s /etc/syslog.pid ] ; then \
                                echo "kicking syslogd"; \
                                kill -1 `cat /etc/syslog.pid`; \
                        fi; \
                fi; \
        else \
                echo "WARNING: $@ was missing!"; \
                echo "install -o root -g staff -m 444 $? $@"; \
                install -o root -g staff -m 444 $? $@; \
                echo "NOTICE: start syslogd"; \
        fi

Note that the above rules are really very primitive examples of
procedures that grew over time and which used only a very minimal set of
'make' features.  Modern versions of make would allow much more
sophisticated rules to be written in a very compact and simple-to-use
way.

If I were to do it all over again though I'd use something very much
like 'cfengine' (though I don't know for sure if I'd use 'cfengine', or
maybe re-design and implement something similar).

> Most config files do not lend themselves to this kind of thing so most
> of the files I keep there are scripts that work in common on all OS
> involved. (FreeBSD solaris linux)

thus the reason for cfengine....

This isn't a new problem, and your approach to it isn't new either.
It's not my own experience alone that says it's not the best approach
either (eg. I didn't write cfengine!  ;-).

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>