Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Mar 2002 10:50:01 -0800 (PST)
From:      swear@blarg.net (Gary W. Swearingen)
To:        freebsd-doc@freebsd.org
Subject:   Re: docs/35943: at(1) config files are misplaced in /var/at/
Message-ID:  <200203181850.g2IIo1V96298@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/35943; it has been noted by GNATS.

From: swear@blarg.net (Gary W. Swearingen)
To: Giorgos Keramidas <keramida@ceid.upatras.gr>
Cc: bug-followup@freebsd.org
Subject: Re: docs/35943: at(1) config files are misplaced in /var/at/
Date: 18 Mar 2002 10:44:26 -0800

 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.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203181850.g2IIo1V96298>