Date: Fri, 16 Oct 1998 13:27:48 -0400 (EDT) From: Clark Gaylord <gaylord@gaylord.async.vt.edu> To: randy@psg.com (Randy Bush) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: syslogd and syslog.conf Message-ID: <199810161727.NAA25636@gaylord.async.vt.edu> In-Reply-To: <m0zUBki-0008G5C@rip.psg.com> from Randy Bush at "Oct 16, 98 08:25:16 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > there are potentially non-system routines that will break with this "fix". > > this is the point that worries me. a change is being proposed in a data > file, and it is being assumed that syslogd(8) is the only program which > reads that file. as syslog.conf(5) has been documented publicly, i would be > more cautious about changing the definition, for mere cosmetic not emergency > reasons, without widely published warning well in advance. Yes, this is really my point. I intentionally overstated the issue for dramatic purposes, but this is exactly the issue. If there were significant benefit, there would not be any debate, which makes this somewhat ironic -- it is a minor cosmetic proposal, yet it has generated a lot of heat. But this heat is caused for exactly the right reason, viz, extreme religious caution bordering on paranoia when changing *any* core system file. Now, having said that, let me say that this proposal is potentially justifiable, and, moreover, even justifiable within stable (and hence we can justify even discussing it here ;-), if it can be argued that it *cannot* break anything. We are not proposing a change to syslog.conf; we are talking about a looser definition of syslog.conf that would permit syslogd to read space delimited files. This could encourage a particular user to use spaces and hence break something else that they have independently done, but that is clearly outside the scope of our concern. The only system use of syslog.conf is (can we rigorously confirm this?) syslogd. The criterion then is: is it possible to construct a syslog.conf that works with the existing syslogd, yet would break with the proposed change? The usual case to consider is if there are spaces in the filenames. If this won't break, there may be no debate. Given that this may break, do we consider it a relevant case, or do we tell people "if you are stupid enough to put spaces in your file names, you deserve what you get"? I can think of no other way that this change could break existing systems; if so, we are down to debating this point. Clark -- Clark K. Gaylord Blacksburg, Virginia USA cgaylord@vt.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810161727.NAA25636>