Hi again,

So here is a preliminar patch for this proposal; it still lacks documentation
(manpages), but I won't write them until it gets reviewed properly.  As the
changes are non-trivial (in the sense that they change what has been used for
years with something new and different), I guess that this needs approval from
core@, isn't it?

Note that existing /etc/{daily,monthly,weekly}.local scripts will keep
working, to make the transition easier, although they are considered obsolete
in the file lists.

Also, from Hubert's comments, I see that what I've done is quite similar to
what FreeBSD has (though I haven't checked), with the exception that this uses
rcorder to sort the scripts, instead of numbers in names.  (Note that rcorder
is mostly useless now, because none of the scripts provided contain any of the
special keywords recognized, but scripts can be easily ordered if needed; just
as rc.d).

The patch itself is around 35kb, so I didn't attach it.  Please fetch from:

	ftp://ftp.NetBSD.org/pub/NetBSD/misc/jmmv/periodic.diff

Could you comment?

Thanks!

PS: Remember, this will let us close some PRs! ;)  (And maybe bring some
new ones...)



On Sat, 3 Apr 2004 11:17:24 +0200
"Julio M. Merino Vidal" <jmmv@menta.net> wrote:

> 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/
> 


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