Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Periodic execution of a program
Message-ID: <5546@auspex.auspex.com>
Date: 27 Jan 91 02:13:38 GMT
References: <5829@rex.cs.tulane.edu> <393@bria>
Organization: Auspex Systems, Santa Clara
Lines: 24

>Well, then tell your admin to get off his butt and either put you in
>/usr/lib/cron.allow, or touch /usr/lib/cron.deny.  This will convince cron
>that you are allowed to have cron jobs executed on your behalf (personally,
>I find it a tad apalling that you don't have the permission to create a
>crontab).

I agree, but that's a deficiency of the traditional UNIX "cron"
mechanism, which was fixed by, among others, the S5R2 "cron" - the old
system had only *one* "crontab" file, in "/usr/lib/crontab", and all
jobs from that were run as "root" (you had to do an "su" to run them as
somebody else) so it wasn't generally available.

Since the guy was using a Pyramid, it could have either - or perhaps
both! - the BSD "cron" and the S5R2-or-later-S5 "cron"; when he said he
"[didn't] have access to crontab", I'm not sure whether he meant he
didn't have access to the "crontab" *file* (i.e., the BSD "cron"), or
didn't have access to the "crontab" *command* (i.e., the S5 "cron").

If the former, he'd have to ask the administrator to turn on the S5
"cron", and if he runs in the BSD universe, do "att crontab" and
remember that his "cron" job will run in the AT&T universe.

If the latter, he should complain to his system administrator and ask
that they set up the files you mention to let them use "crontab".