Skip site navigation (1)Skip section navigation (2)
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>