Date: Fri, 25 Jun 1999 11:02:04 -0700 From: Aaron Smith <aaron-fbsd@mutex.org> To: Sheldon Hearn <sheldonh@uunet.co.za> Cc: Keith Stevenson <k.stevenson@louisville.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: Inetd and wrapping. Message-ID: <199906251802.LAA31221@sigma.veritas.com> In-Reply-To: Your message of "Fri, 25 Jun 1999 16:05:05 %2B0200." <14531.930319505@axl.noc.iafrica.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Jun 1999 16:05:05 +0200, Sheldon Hearn writes: >We'll also end up with an inetd that _can_ wrap if it's told to (-w >and -ww). So we end up offering a better super-server than we had >before, with no backward compatibility problems, and no additional >incompatibilities with other systems (I can't find an inetd that uses >the -w flag for anything). hi sheldon, i have no problem with -w options, but i am still surprised that you want to go ahead with the conf format change. i'm going to present my rebuttal here, but the only argument i could dig up was "there is missing functionality". (john baldwin? not sure) raised the issue that before, he could control which services were wrapped. now, all services are wrapped. why is this bad? what has been lost? can the user no longer get the old behavior? no, he can. undefining LIBWRAP at compile time (or a runtime flag) plus tcpd gets him exactly where he was before. this will be even less of an issue with -w flags or an inverted default. performance incurred by reading "default allow" rules on invocations? no, for several reasons. the hosts.allow file is going to be in the cache. the design is first matched, so one can also place the service one is concerned about at the beginning of the lists. but third and most importantly: if startup performance is an issue to the extent that the small overhead of this call is important, you should not be using inetd. you should have a standalone daemon. (which you can decide to wrap or not wrap). the overhead here is going to in reality be small. logging configurability? i seem to remember something about this, and while i am trying to come up with a difference, i can't see one. hosts.allow is very configurable logging wise. the messages come from inetd, yes...but they can be separated out by severity/facility. i can't imagine logging differences is a good reason. so to this one too i have to say "no". we already have a service-by-service control file "hosts.allow" that provides the ability to in EFFECT control what gets wrapped. please do not duplicate that functionality again -- we can do without it. it's an additional complexity that buys us *nothing*. >The additional option in inetd.conf is not something I want. However, >it's something someone has made a legitimate public argument for, to >which I can't come up with a decent rebuttal. i hope i've made a persuasive case that a *conf file format change* isn't justified here. it doesn't make sense, especially if you are, as you have mentioned, going to switch unwrapped to default and require -w for wrapping. thanks, aaron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906251802.LAA31221>