On Tue, 22 Jun 1999 18:18:34 -0400, John Baldwin wrote:
> But if I want to log *all* connections to service foo, but not bar, I
> could not use tcpd for foo and and bar by itself and achieve that, so
> you are removing some configurability. If very few people use this
> extra configurability and if it is a pain to add it in, then I guess
> it's no real big deal.
I used to pride myself in my communication skills, but I'm starting to
doubt myself. :-)
My concern is that what you want introduces duplicate functionality. I'm
not denying that you can't do exactly the same things with inetd that
you could with tcpd, but that's to be expected.
So far, the mail that I've received which has requested per-case
exclusion options has been motivated by two concerns:
1) Performance.
I think we're all clear now that exclusion options will not
introduce a significant performance gain. We've already
scored our performance gain by obviating an exec on tcpd.
2) Logging.
I understand that folks want to be able to have their logs
look the same as they did when tcpd was in use. That's
already not possible, since the wrapping-related messages you
see come from inetd[pid] and not tcpd[pid].
I believe that you can have all the messages you used to get
going to all the places it used to go, but now using
different configuration. Now you should use the
hosts_options(5) "severity" option to assign a syslog
selector to the messages generated for a service and tune
syslog.conf to get messages to the right log destinations.
It's critical that folks understand that built-in wrapping in inetd is
not the same as inetd passing the job of wrapping to a program called
tcpd. Something different is happening in each case. It just so happens
that the two cases share a common goal.
When you say you want "functionality that exists with TCP wrappers", I
think you mean "identical semantics to those used with tcpd". You can't
have it, it's that simple.
What you should be able to have is the same functionality as was
available when using tcpd. I don't think the fact that you may need to
set things up differently to achieve the same results as you had before
isn't a serious problem, because you're doing a different thing now.
Hopefully this clarifies what's going on in my head. :-)
Later,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
