On Tue, Apr 06, 1999 at 02:46:12PM -0700, Jonathan Stone wrote:
> user crontabs are information created by users, maintaned by users,
> and edited, pretty arbitrarily, by users.  In that sense they are
> owned by users.

This description fits .profile and gang pretty well.

As for 'pretty arbitrarily', I'd argue that perhaps it shouldn't
be as arbitrary as it is. Someone else already suggested a file 
size limit, which seems quite reasonable. If you need more than
a couple screenfuls of crontab, you're probably doing something
wrong. Cron doesn't scale well, especially if you start a lot
of jobs at once.

Either 
	a) put the crontab in the users dir, and have the cron program
'register' the file. That should deal with performance concerns, 
but it doesn't deal with NFS mounted home-dir issues. (although I
might argue that if cron tries to run a job for a user, and their
home-dir isn't available at the time, odd are the cron job may be
missing things it needs anyway.
or
	b) treat the crontabs like the passwd file. There's an
interface program (cron/passwd) which a user uses to make changes,
to a file they can't normally edit. Enforce size limitations,
default fairly small, and make it system definable.

> In 4.[23]BSD when cron only supported a crontab for root, then keeping
> root's crontab in /etc matched our hier(7), since that was `system'
> config info (stuff done by the superuser) rather than `personal' cron
> info. (think about it: {daily, monthly, weekly} scripts, usw).

Cool, didn't know the background. I had no use for cron on the
early unixes I used, and by the time I did/on the systems I did
it wasn't root only.

> User information like indivdual users' crontabs doesn't belong in
> /etc, anymore than individual users maildrops or their personal
> .profile/.login/.cshrc belong in /etc.

So aside from the find /home argument, if it was a database type
'registered' service, could they live in ~ then?

> Okay, so maybe in some setups, they don't work well in /var.  But that
> doesn't mean they belong in /etc. That just changes one set of problems
> for one group of users, for another set of problems in a different group.
> *That* isnt likely to happen. 

I never said I was for the /etc move ;-) I just want to see the
justification for any side of the argument before I make up my mind.

> If *you* don't like /var/cron, you can apply the symlink kludge which
> someone suggested earlier as a palliative for those who object to the
> change. If symlinking isn't good enough for you, who are you to say
> it's good enough for someone else?

I don't like var cron because it's config data. I'd like to figure
out where it belongs so it's clear for any sysadm. Tell me why /var
makes more sense than anywhere else.

Michael Graff adds:
> However, unlike the password file, the crontabs can be made very
> large.

That's a bug that got a lot of press last year, people stuffing
.tgz into their crontabs to avoid quota. Cron should restrict
the file to a reasonable size.

-- 
David Maxwell, david@vex.net|david@maxwell.net --> Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville