uscheduleconf(1)uscheduleconf(1)NAMEuscheduleconf - configure a scheduling service
SYNOPSISuscheduleconf DIR ACCT LOGACCT [JOBDIR [LOGDIR]]
DESCRIPTIONuscheduleconf creates a svscan service directory DIR, which starts a
service to uschedule for the user ACCT. The jobs will be read from
JOBDIR (or ~ACCT/.uschedule, if JOBDIR is not given or only contains a
minus character).
Logging information will be written to LOGDIR (or ~ACCT/.uschedule/log,
if LOGDIR is not given), using the the account LOGACCT.
Version before 0.7.0 allowed to give "-" for ACCT to use the current
user and "-" for LOGACCT to use ACCT for LOGACCT, but the code turned
out to be buggy. See the NEWS file of the uschedule package for more
information.
OPTIONS-n, --no-user-change
Do not change file ownership and do not switch user ids.
The default is to make ACCT and LOGACCT the owners of JOBDIR,
LOGDIR and the file therein, and to switch to ACCT and LOGACCT
before running uscheduled and the logging program.
With this option the caller will be the owner of all files
created and the programs will run with all the rights they
inherit.
This option was added in version 0.7.0.
ENVIRONMENT
In JOBDIR/env a number of environment variables are set (one file per
variable). HOME, SHELL, USER and LOGNAME are set to values taken from
the system password database.
The PATH variable is set to /command:/usr/local/bin:/usr/bin/:/bin for
any user not having an uid of 0. For users with uid 0
/usr/local/sbin:/usr/sbin:/sbin will be appended.
All these variables may be changed.
SECURITY
Keep the following rules in mind:
*
Do not ever create a service directory DIR in an insecure place.
Nobody but you - the system administrator - must be able to write to
it. Especially do not ever create this directory in the users
$HOME. You would be giving away instant root access!
*
Do not ever create JOBDIR and LOGDIR in an insecure place. These
directories and the content must only be writable by the user for
which the service is run.
*
Be careful about LOGACCT. If you set up a scheduling service for a
user then LOGACCT should be this user. If you are setting up a
scheduling service for a system account then you may want to use a
different user for logging purposes (while this is local policy i
can't think of any reason why the logging should run as root).
*
Resource limits may be configured in DIR/run and DIR/log/run. The
defaults are most possibly not right for every system. Keep in mind
that perl eats lots of resources and that a multilog processor may
use perl ...
EXAMPLES
Setup a scheduler for system services
Create a uschedule service for root, with the service directory
/etc/root-schedule and the logging done to /var/log/root-schedule under
the "misclog" account.
uscheduleconf /etc/root-schedule root misclog \
/etc/root-schedule/jobs /var/log/root-schedule
Setup a scheduler for a user
Create a schedule service for uwe, having the trusted commands in
/etc/uwe-schedule and any parts uwe can change in ~uwe/.uschedule:
uscheduleconf /etc/uwe-schedule uwe uwe \
~uwe/.uschedule ~uwe/.uschedule/logs
AUTHOR
Uwe Ohse, uwe@ohse.de
SEE ALSOuschedule(1), uschedulecmd(1), uschedule_intro(7).
The homepage may be more up-to-date, see
http://www.ohse.de/uwe/uschedule.html.
uschedule 0.7.1 uscheduleconf(1)
