Date: Wed, 20 Sep 2000 23:40:02 -0700 From: "Crist J . Clark" <cjclark@reflexnet.net> To: "Chad R. Larson" <chad@DCFinc.com> Cc: jmutter <jmutter@ds.net>, freebsd-stable@FreeBSD.ORG Subject: New periodic.conf (was Re: SysV Style Init?) Message-ID: <20000920234002.X367@149.211.6.64.reflexcom.com> In-Reply-To: <200009210327.UAA03936@freeway.dcfinc.com>; from chad@DCFinc.com on Wed, Sep 20, 2000 at 08:27:23PM -0700 References: <Pine.GSO.4.10.10009201823350.25845-100000@s1.ds.net> <200009210327.UAA03936@freeway.dcfinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 20, 2000 at 08:27:23PM -0700, Chad R. Larson wrote: > As I recall, jmutter wrote: > > Before I go and do this on my own, has anyone bothered to convert the > > rc.* scripts to System V style S/K scripts? I'm trying to introduce > > FreeBSD into a large .com, the SysV style init scripts would be > > helpful so that I can avoid retraining the production staff. > > One of the few things about SysV that I think is an improvement over > BSD is the concept of "run states". Fairly easy to implement, I > believe (small changes in "init" and some shuffling of scripts), but > probably a political uphill fight against traditionalists... I am still trying to figure out what the hell happened to the periodic scripts when I was not looking. There used to be a /etc/daily, /etc/weekly, and /etc/monthly. One script was run when appropriate. Then there was the conversion to the 'periodic' format, which I felt was pretty kewl. The daily, weekly, and monthly actions were broken up into tiny files that each did one action. You could drop more in, take others out, and if you ever wanted to, say, change how the disk status was done, you go hack on /etc/periodic/daily/400.status-disks and you're done. /Now/ we have a set up where we have all of these individual files, but one central file that sets all kinds of defaults for _all_ of the files (or potentially all of them). So, we went from centralized single scripts, to a pack of small distributed scripts, and now we have a whole bunch of small scripts configured from a central file. If you want to change how disks are done, you need to examine /etc/periodic/daily/400.status-disks and /etc/defaults/periodic.conf simultaneously and hope that your changes just require mods to the values that they let you customize. Then you drop the changes in /etc/periodic.conf. Otherwise, you need to hack the file and this new setup just makes life a hassle. I think I can guess the reasoning. Someone wanted to have a defaults/periodic.conf and periodic.conf so that minor changes to values in the small scripts won't be clobbered if one flies mergemaster on autopilot instead of merging by hand. I think the distributed script files with a centralized configuration file is kind of an awkward construction. That said, I was thinking of breaking /etc/security into an assortment of scripts. I would think it is frequently hacked by users. I have a Tripwire check for example. It be great if I did not have to manually merge that whole thing each time /etc/security changes. There is no reason it should not be done the same way the other periodic scripts are. But with this new /etc/periodic.conf has kind of quenched my enthusiasm. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000920234002.X367>