Hi all,

Looking at misc/14825, found a minor discussion about creating /etc/periodic.d,
which is very interesting.  Some of the people who replied to it said that they
were working on implementing this, but the last message in the PR is dated as
2002, so it seems nobody finished it, right? ;)

The main idea is to create an /etc/periodic.d directory where several scripts
reside (as /etc/rc.d), each one doing a single task.  Then, have the daily (and
other scripts) parse daily.conf and such files to get several yes/no values,
use rcorder to sort the periodic.d files accordingly and run the ones which
had their setting set to yes.

So I started to work on it, and already got a preliminar working version.  Even
though, there are several "design" questions that I would like to expose to get
some discussion about them...

1) periodic.subr

   As they are now, the scripts use rc.subr to get basic functions like
   checkyesno.  The new scripts should be similar to what we have in rc.d, so
   I tried to use other rc.subr functions to handle them.  Although they work,
   they are not intuitive, and provide lots of functionality that won't be
   used.  For example, a periodic.d script should not get any 'start|stop'
   arguments, as they will only confuse people.

   So I added a periodic.subr file, which contains some simple functions (but
   very similar to the ones in rc.subr, like load_periodic_config,
   run_periodic_command, etc) to get them working.  I hope there will be no
   "problem" with this.

2) Configuration files

   We now have three configuration files to tune what happens in the scripts.
   These files set several variables to yes/no to determine what needs to be
   executed.  The "problem" here is that, with the new framework, if somebody
   wants to add a new script in periodic.d, has to modify three files to
   reflect this change (set it to 'yes' in one, and 'no' in the others).  If
   he doesn't do it, then he'll get warnings at runtime about an undefined
   variable.

   The other approach I see is to have a single periodic.conf file where each
   variable can take any of the following values: never, daily, weekly or
   monthly.  This way, only one file needs to be modified, and a job will be
   always executed from a single script.

   I prefer the later option, as it's clearer and more centralized, but breaks
   "tradition".

3) The scripts themselves

   After the changes, /etc/daily and others become a 5 line script, which aside
   of setting some variables, call a start_periodic function with an argument
   that specifies the frequency, i.e., 'daily'.

   I think they could be merged into a single script, say /etc/periodic, that
   directly takes the argument from the command line.  So one could run
   '/etc/periodic daily' and get what's expected.  Doing this will mean a
   minor change in root's crontab to call the new script.

   I also prefer the later, but breaks even more with "tradition"...

4) security

   The security script is conceptually different than daily, weekly and monthly,
   but as it's directly handled by them, it could be treated the same.  That is,
   if we go with a single configuration file for all the scripts, add a fifth
   value, 'security'.

Is it a good idea to implement this?  Comments on the specific details?

Thanks!

-- 
Julio M. Merino Vidal <jmmv@menta.net>
The NetBSD Project - http://www.NetBSD.org/