dacssched

DACSSCHED(1)                 DACS Commands Manual                 DACSSCHED(1)



NAME
       dacssched - rule-based command scheduling

SYNOPSIS
       dacssched [-h | -help] [-ll log_level] [-q] [{-r | -rules} rules_uri]
                 [{-s | -sched} sched_uri] [-v]

DESCRIPTION
       This program is part of the DACS suite. It is a stand-alone program
       that neither accepts the usual DACS command line options (dacsoptions)
       nor accesses any DACS configuration files.

       The dacssched command runs other programs when specified conditions
       have been met. It does this by periodically examining a schedule,
       which, for each scheduled event, identifies the necessary conditions
       and the command line to be executed should the conditions be satisfied.
       Rules are stored separately from the schedule, although in a future
       version it might be possible to contain them with their schedule.

       Although dacssched is conceptually similar to cron(8)[1], atrun(8)[2],
       and other programs used to schedule a command to be executed or a
       reminder to be sent at certain times or dates, there are some important
       differences. First, because the DACS rule evaluation engine is used,
       conditions much more broad and complex than simply the time or date can
       be used to schedule a command - DACSexpressions[3] are available. For
       instance, a rule to manage automated file backup could be written to
       take into account context other than simply the day of the week and the
       time of day, if necessary even running external programs to assist in
       making the determination. Second, both a schedule and the rules
       referenced by a schedule are accessed through the DACS virtual
       filestore, which means they can be stored in file or database,
       retrieved by HTTP, and so on.

           Note
           Although this program may be useful, it is currently merely a
           prototype intended for demonstration and experimentation purposes.
           Some configuration capabilities, features, and security steps
           required by a production version have not been implemented. The
           prototype must be invoked periodically; a production version would
           run in the background and automatically rescan the schedule at a
           given frequency. Note that because of its flexibility, the schedule
           must be polled at a suitable frequency - in general, the program
           cannot compute when the next scheduled event will occur. Also
           because events need not be triggered by a time or date, some events
           may need to "self-disabling" so that they are not repeatedly
           executed unintentionally.

   Operation
       The program loads a schedule, which either comes from a default file or
       a location specified on the command line. A schedule is an ordinary
       text file, each line of which is either blank, a comment, or a
       scheduled event. The file is processed in the order in which the events
       appear from the top. Initial whitespace on any line is ignored. A
       comment line begins with a "#" character. A scheduled event consists of
       a name, followed by whitespace, followed by a command. If name
       evaluates to True (i.e., it grants access), the command is executed
       through system(3)[4]. If rule evaluation fails because of an error, the
       event is not executed. Events are not removed from the schedule after
       their command has been executed.

       A name, which must begin with a slash, has no significance to
       dacssched; it is simply a label that is used to identify the rule to
       apply and is matched against a rule's service element.

       Here is a simple schedule containing one event:

           # A simple schedule
           /setdate   /usr/local/sbin/rdate -a

       If the condition labelled /setdate is True the specified command will
       be executed.

       A simple rule such as the following might be associated with the event:

           <acl_rule status="enabled">
               <services>
                 <service url_pattern="/setdate"/>
               </services>

              <rule order="allow,deny">
                <allow>
                  time(hour) eq 2 and time(min) eq 0
                </allow>
              </rule>
           </acl_rule>

       This rule enables the event /setdate at 2:00am every day. We will
       assume that the schedule is processed exactly once per minute.

       Internally, dacssched converts the scheduled event above into the
       expression:

           rule("/setdate", rule_uri)

       (where rule_uri specifies the ruleset to use) and then evaluates the
       expression. Please refer to the rule predicate[5] for additional
       information.

   OPTIONS
       The arguments are processed as they are examined (left-to-right) and
       their ordering can be significant.

       By default, the program will look for a schedule in the file
       ${Conf::DACS_HOME}/dacssched/sched. (default:
       /usr/local/dacs/dacssched/sched) The default location for the rules is
       ${Conf::DACS_HOME}/dacssched/acls. (default:
       /usr/local/dacs/dacssched/acls)

       The following command line flags are recognized:

       -h
           Prints the usage blurb.

       -ll log_level
           Set the debugging output level to log_level (see dacs(1)[6]). The
           default level is warn, and the -v flag bumps the level to debug or
           trace.

       -q
           Be quiet, except for error messages. The -v and -ll flags are
           independent of this.

       -r rule_uri
       -rules rule_uri
           This flag specifies the ruleset to be used. It can be an absolute
           pathname or a URI in the syntax of the VFS[7] configuration
           directive. Examples:

               -r "[acls1]dacs-fs:/local/acls"
               -rules /usr/local/myrules


       -s sched_uri
       -sched sched_uri
           This flag specifies the schedule. It can be an absolute pathname or
           a URI in the syntax of the VFS[7] configuration directive.

       -v
           Increase the level of debugging output. The flag may be repeated.

DIAGNOSTICS
       The program exits 0 if everything was fine, 1 if an error occurred.

SEE ALSO
       dacs.exprs(5)[3], dacs.acls(5)[8]

AUTHOR
       Distributed Systems Software (www.dss.ca[9])

COPYING
       Copyright2003-2013 Distributed Systems Software. See the LICENSE[10]
       file that accompanies the distribution for licensing information.

NOTES
        1. cron(8)
           http://www.freebsd.org/cgi/man.cgi?query=cron&apropos=0&sektion=8&manpath=FreeBSD+9.1-RELEASE&format=html

        2. atrun(8)
           http://www.freebsd.org/cgi/man.cgi?query=atrun&apropos=0&sektion=8&manpath=FreeBSD+9.1-RELEASE&format=html

        3. expressions
           http://dacs.dss.ca/man/dacs.exprs.5.html

        4. system(3)
           http://www.freebsd.org/cgi/man.cgi?query=system&apropos=0&sektion=3&manpath=FreeBSD+9.1-RELEASE&format=html

        5. rule predicate
           http://dacs.dss.ca/man/dacs.exprs.5.html#rule

        6. dacs(1)
           http://dacs.dss.ca/man/dacs.1.html

        7. VFS
           http://dacs.dss.ca/man/dacs.conf.5.html#VFS

        8. dacs.acls(5)
           http://dacs.dss.ca/man/dacs.acls.5.html

        9. www.dss.ca
           http://www.dss.ca

       10. LICENSE
           http://dacs.dss.ca/man/../misc/LICENSE



DACS 1.4.28b                      02/04/2014                      DACSSCHED(1)