Date: Wed, 19 Dec 2001 07:00:03 -0800 (PST) From: Ruslan Ermilov <ru@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/32953: log-in-vain level should be setable in rc.conf Message-ID: <200112191500.fBJF03o97224@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/32953; it has been noted by GNATS.
From: Ruslan Ermilov <ru@FreeBSD.org>
To: Peter Pentchev <roam@ringlet.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/32953: log-in-vain level should be setable in rc.conf
Date: Wed, 19 Dec 2001 16:56:08 +0200
On Wed, Dec 19, 2001 at 04:30:28PM +0200, Peter Pentchev wrote:
> On Wed, Dec 19, 2001 at 04:22:07PM +0200, Ruslan Ermilov wrote:
> > On Wed, Dec 19, 2001 at 03:46:39PM +0200, Peter Pentchev wrote:
> > > On Tue, Dec 18, 2001 at 05:00:03AM -0800, Ruslan Ermilov wrote:
> > > > On Mon, Dec 17, 2001 at 05:40:02PM -0800, Crist J . Clark wrote:
> > > > > The following reply was made to PR bin/32953; it has been noted by GNATS.
> > > > > On Mon, Dec 17, 2001 at 04:28:07PM -0800, David O'Brien wrote:
> > > > >
> > > > > > >Description:
> > > > > > We allow the turning off and on of log-in-vain in rc.conf as seen in
> > > > > > rc.network:
> > > > > >
> > > > > > network_pass4() {
> > > > > > echo -n 'Additional TCP options:'
> > > > > > case ${log_in_vain} in
> > > > > >
> > > > > > Therefor we should also allow the log-in-vain level to be set in
> > > > > > rc.conf also.
> > > > > [snip]
> > > > >
> > > > > We should. How about this simple change which is back compaitible, but
> > > > > does not add more rc.conf knobs:
> > > > >
> > > > > Index: rc.network
> > > > > ===================================================================
> > > > > RCS file: /export/ncvs/src/etc/rc.network,v
> > > > > retrieving revision 1.119
> > > > > diff -u -r1.119 rc.network
> > > > > --- rc.network 13 Dec 2001 04:21:18 -0000 1.119
> > > > > +++ rc.network 18 Dec 2001 01:26:07 -0000
> > > > > @@ -848,9 +848,12 @@
> > > > > [Nn][Oo] | '')
> > > > > ;;
> > > > > *)
> > > > > - echo -n ' log_in_vain=YES'
> > > > > - sysctl net.inet.tcp.log_in_vain=1 >/dev/null
> > > > > - sysctl net.inet.udp.log_in_vain=1 >/dev/null
> > > > > + if ! expr "${log_in_vain}" : '[0-9]*' >/dev/null 2>&1; then
> > > > > + log_in_vain=1
> > > > > + fi
> > > > > + echo -n " log_in_vain=${log_in_vain}"
> > > > > + sysctl net.inet.tcp.log_in_vain="${log_in_vain}" >/dev/null
> > > > > + sysctl net.inet.udp.log_in_vain="${log_in_vain}" >/dev/null
> > > > > ;;
> > > > > esac
> > > > >
> > > > I think you should add a case for [Yy][Ee][Ss], and treat the fallback
> > > > case as a numeric value, without expr(1)-checking it. There's nothing
> > > > wrong here as the only documented values were YES and NO, and people
> > > > who had it set to the other value (e.g. "YUP") will now have to fix it
> > > > to the right value. :-)
> > >
> > > Why would they have to fix it? This patch treats all non-numeric values
> > > as a default log level of 1; a "YUP" would be treated just the same
> > > as a "YES".
> > >
> > The only documented values are "YES" and "NO" (so far), and treating
> > anything else as "YES" is not good, as one day we may add a new value,
> > "MAYBE", that would mean something different from "YES".
> >
> > > I personally would prefer the expr regexp to be '[0-9]*$', though,
> > > because '[0-9]*' also catches things like '3foo', which is, strictly
> > > speaking, incorrect, although sysctl(8) silently trims at the first
> > > non-numeric character.
> > >
> > Yeah, the regexp may stay (it enables the stricter checking),
> > "YES" block should be added, and fallback block should say
> > "invalid value".
>
> Errr.. Maybe I'm not understanding you here. The whole point of
> this patch is to change the setting so that it is no longer a boolean.
> Are you proposing that it should stay boolean (thus making it impossible
> to address David O'Brien's PR without introducing a new variable),
> or simply that the case statement be separated into 'NO', 'YES', '^[0-9]*$'
> and a default that produces an error message?
>
No, I'm proposing a stricter value checking, i.e.:
1. [Yy][Ee][Ss]
2. [Nn][Oo]
3. [0-9]*$
Everything else should be considered an error in value,
not "YES".
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
ru@sunbay.com Sunbay Software AG,
ru@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112191500.fBJF03o97224>