> 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs