On Mon, Jan 08, 2001 at 07:55:57AM -0800, Bruce Lane wrote:
> 	My thanks to all three of you. I had also asked a friend/coworker about
> this (he's been a Unix admin for about 15 years, and has long since reached
> 'guru' status), and, when I described my system setup, he thought that
> inetd and tcpserver might be fighting with each other because both may have
> been responding to portmap's signal that SMTP or POP wanted service.

That's not possible. portmap (rpcbind in 1.5) is only for RPC based services,
which neither SMTP, nor POP are. SMTP and POP both bind to 'well-known' ports.
Also, only one process can bind to a given IP/port combination to listen on it,
so whoever gets there first wins, and whoever gets there second gets
bind: Address Already in Use

> 	To check this theory, I reconfigured the mail server to use tcpserver
> (part of the ucspi package from Dave Bernstein) for all its TCP services,
> then shut down inetd altogether.
> 
> 	It seems to have made an immediate difference. Response is now

If it did, it's a side-effect of tcpserver doing something differently
(DNS is still my guess). I don't use tcpserver, so I can't give an educated
guess.

> lightning-swift in most cases, with only occasional minor delays on the POP
> side (no more than 20 seconds or so). I don't know if it's trying to do

Those delays are probably POP copying large mailboxes before starting
transfers. You can manually telnet to the POP port and login by hand to see
how quick the response is.

> 	For the record, I have also checked to see that the machine looks first to
> /etc/hosts before hitting DNS. However, I have not added my primary
> workstation (the one I usually get mail at) to /etc/hosts because it has a
> dynamic IP.

Did you add the client machines to /etc/hosts? That's what the lookup is
failing for (if it's DNS).

> 	What I've done so far is, I grant you, a short-term solution. I've been
> looking at xinetd as a replacement for the usual inetd, and I think I'm
> going to go with it. It seems to be able to do everything that tcpserver
> can, and more. Anyone else on the group used it?

I've never used it, but I generally avoid replacing the default system
tools without a really good reason since it's a maintainence headache later.

The only features in xinetd that NetBSD's inetd doesn't have - from
http://www.synack.net/xinetd/faq.html would seem to be:

 1) It can do access control on all services based on:
  b. time of access
(You could cron it if you wanted to, but this is probably nicer)

 3) It provides hard reconfiguration:
  a. kills servers for services that are no longer in the configuration file
  b. kills servers that no longer meet the access control criteria
(I don't change my service sets often enough to find doing this manually a
burden.)

 4) It can prevent denial-of-access attacks by
  a. placing limits on the number of servers for each service (avoids process
	table overflows)
  b. placing an upper bound on the number of processes it will fork
  c. placing limits on the size of log files it creates
  d. placing limits on the number of connection a single host can initiate
  f. discontinue services if the load exceeds specified limit
(a,b are nice, c doesn't solve the host-wide issue, d is really nice, f
is misguided IMO)

None of those are enough for me, I'd probably prefer to work on adding
4abd to NetBSD's inetd.

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
(About an Amiga rendering landscapes) It's not thinking, it's being artistic!
					      - Jamie Woods