Bug 35943

On 2002-03-15 18:15, Gary W. Swearingen wrote:
>
> The configuration files for at(1), at.allow and at.deny, are currently
> looked for in /var/at/ instead of in /etc/ like almost all other system
> configuration files.

There are other programs that use /var too.  Cron(8) for instance, saves
the crontabs in /var/cron/tabs.  Why is it so bad that at(1) saves files in
/var too?

Giorgos Keramidas                       FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr}  http://www.FreeBSD.org/docproj/

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> There are other programs that use /var too.  Cron(8) for instance, saves
> the crontabs in /var/cron/tabs.  Why is it so bad that at(1) saves files in
> /var too?

It's NOT bad that programs SAVE files in /var/; that's what it's there
for.  And /etc/ is there for read-only config files.  But the cron(8)
and at(8) programs are the only ones I know of that read from read-only
configuration files in /var/.  (I was saving cron(8) until I saw how
at(1) went, but only for cron's "allow" and "deny", not its databases.)

Of course, it is debatable whether it is better to keep a program's
files together or scatter them about, or whether it's useful to
distinguish between config files and database files the crontabs, but I
think that in one of these rare cases where there is a clear rule or
convention, it should be adhered to by all system programs when it's
practical; in this case it's easy.

On 2002-03-17 11:34, Gary W. Swearingen wrote:
> Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
> Of course, it is debatable whether it is better to keep a program's
> files together or scatter them about, or whether it's useful to
> distinguish between config files and database files the crontabs, but I
> think that in one of these rare cases where there is a clear rule or
> convention, it should be adhered to by all system programs when it's
> practical; in this case it's easy.

Sure.  As an idea it's nice.  Any chance you can come up with a "proof of
concept" patch?  That will make things easier to test, since this is not a
very bad idea.

Giorgos Keramidas                       FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr}  http://www.FreeBSD.org/docproj/

Giorgos Keramidas <keramida@freebsdd.org> writes:

> Any chance you can come up with a "proof of
> concept" patch?

Please assume that I will not develop any patches for any PR for the
indefinite future.  It's not because of any mistreatment of my patches
or anything like that; I've just found patch development to be REAL
WORK, and few, if any, of my PRs will have higher priority than other
real work that I should be doing (some of which should eventually
benefit FreeBSD too).

This patch would be a one-liner (in Makefile.inc) to just change the
location, but I assume that the change needs to be backward compatible.

P.S. Looks like you've got a typo ("dd") in your return address.

On 2002-03-17 18:33, Gary W. Swearingen wrote:
> Giorgos Keramidas <keramida@freebsdd.org> writes:
>
> This patch would be a one-liner (in Makefile.inc) to just change the
> location, but I assume that the change needs to be backward compatible.

If the change is indeed deemed appropriate, changes to mtree/BSD.root.dist
probably need to be made too, to make sure that /etc/at is created by
mergemaster, with the proper files in it.  Perhaps a couple of sample
at.allow and at.deny files, should be put there too?  Some way of
notifying administrators that their old /vat/at/at.* files are no longer
used, and they should copy them to /etc/at?

I don't know, I'm just looking for a more complete "drop this in your
source tree and rebuild, to see everything working" thing.  Ideas, are nice
too.  It doesn't always have to be "diff -u" output (although that helps a
lot most of the time).

> P.S. Looks like you've got a typo ("dd") in your return address.

Yep, thanks.
I typoed, and found out only after the followup reached my INBOX.

Giorgos Keramidas                       FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr}  http://www.FreeBSD.org/docproj/

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> If the change is indeed deemed appropriate, changes to mtree/BSD.root.dist
> probably need to be made too, to make sure that /etc/at is created by
> mergemaster, with the proper files in it.  Perhaps a couple of sample
> at.allow and at.deny files, should be put there too?  Some way of
> notifying administrators that their old /vat/at/at.* files are no longer
> used, and they should copy them to /etc/at?

I wouldn't bother with /etc/at/ as few will have both "allow" and "deny"
files because "at" will only read one.  /etc/at.allow and /etc/at.allow
And remember that neither file should exist on a pristine system.

The sample files idea is a good one, but because of the file-reading
algorithm in which mere file existence affects the results, the samples
should have ".example" tagged on the end or something.  But the files
are simple enough that I think they'd be more a nuisance for developers
and users than they'd be worth.

As for notifying SAs, etc, "they" should develop a standard scheme for
having mergemaster output a list of things that should be done or
checked.  Until then, isn't /usr/src/UPDATING the place for such
notification?  There's always the problem of people having scripts or
programs which they've forgotten about that would need to be changed,
etc.  I don't have a first-hand feel for how such changes are considered
on FreeBSD, but I suspect that conservatism and backward-compatibility
are well-respected and expected features of FreeBSD, for good and ill.

Comment 7 Tom Rhodes 2006-06-07 06:23:34 UTC

Hi,

Gary states: at(1) should look in /etc for the files.
Giorgos states: Not a bad idea, but it should be backwords compat.

I say:

If we are going to do something like this, I'd like to see the
following requirements met:

1: We do add support for at least both file locations and
   wrap the old one in BURN_BRIDGES.

2: Follow the POSIX example and drop the files in /usr/lib/cron
   instead of /etc.  Linux drops them in /etc.  Solaris and
   POSIX looks for them in /usr/lib/cron.  I'd prefer to follow
   POSIX and Solaris here.

Now we should either create a patch and toss it across -arch
and -standards, or not bother and close this PR.  There will be
a lot of complaints about this being a bikeshed, useless change,
taking us out of sync with other BSDs, etc.  But let's either
make an effort to do something or drop it totally.  What's it
going to be?  :)

Thanks,

Note, if I don't get feedback on this, I'll close the PR.

-- 
Tom Rhodes

Comment 8 Giorgos Keramidas 2006-06-07 12:46:58 UTC

On 2006-06-07 01:23, Tom Rhodes <trhodes@FreeBSD.org> wrote:
> Hi,
>
> Gary states: at(1) should look in /etc for the files.
> Giorgos states: Not a bad idea, but it should be backwords compat.

I don't know how many people use at(1), but I do all the time.

If we change the place where its files are kept, then it should be done
with a big fat warning in src/UPDATING; that's all.

> I say:
>
> If we are going to do something like this, I'd like to see the
> following requirements met:
>
> 1: We do add support for at least both file locations and
>    wrap the old one in BURN_BRIDGES.
>
> 2: Follow the POSIX example and drop the files in /usr/lib/cron
>    instead of /etc.  Linux drops them in /etc.  Solaris and
>    POSIX looks for them in /usr/lib/cron.  I'd prefer to follow
>    POSIX and Solaris here.

POSIX is fine and a good goal, but I think the BSDs tend to pick the
``BSD way'' when there is an important conflict.  I don't remember the
exact email message where I read this, but people more experienced with
the topic -- whose opinion I trust better than mine a lot of the time --
like Bruce Evans, are in a better position to make the choise :)

- Giorgos

Comment 9 Tom Rhodes 2006-10-14 01:12:15 UTC

State Changed
From-To: open->closed

A discussion of where the cron(8) configuration files should 
happen on -arch or -hackers or -current or all three; not in 
a PR.  Note that an email to any of those lists should have 
a patch made available for review.  Thanks! 

Comment 10 Tom Rhodes 2006-10-14 01:12:15 UTC

Responsible Changed
From-To: freebsd-doc->trhodes

Over to me.