[ On Tuesday, June 6, 2000 at 14:30:16 (-0400), Andrew Gillham wrote: ]
> Subject: Re: inetd.conf [sommerfeld@netbsd.org: CVS commit: basesrc]
>
> Mike Pelley writes:
> > > Indeed.  I'd rather see inetd running idle and listening on no sockets.
> > > Then users need only follow the tried and true recipe of editing
> > > /etc/inetd.conf and then kicking the already running inetd to get things
> > > going.
> > 
> > I agree - I think many less experienced users may not be aware of the inetd
> > switch in rc.conf, and yet know that to enable a service they have to edit
> > inetd.conf and hup inetd.  I imagine there will be a few users banging their
> > head on the console trying to get their smtp/ftp/etc. server running if we
> > disable inetd in rc.conf.
> 
> The same could be argued for any other service that sits and waits for
> incoming connections.  E.g. are we going to ship with sendmail=YES and
> a sendmail.cf that only listens on local sockets?  Then the user just
> needs to edit sendmail.cf and hup sendmail.

I don't think it's quite that generic.  Inetd is a special case of
something that's specifically designed to sit and listen for connections
on many different kinds of services.  Very few network server daemons do
anything similar, except maybe in part portmapper/rpcbind (and of course
"listen" on SysVr4).

> Yes, my examples may be a bit on the extreme and/or silly side, but if the
> service is not (or can't be) used, why run it?

Ah, that helps with the terminology:  inetd isn't a service per se, but
rather a service broker.

> My personal opinion is that there is no point in running inetd if it has
> nothing to do.

I agree, but....

>  Why have a process sitting there taking up valuable resources
> to do absolutely nothing, just because it will be "a little easier" for a
> person that is already confused about not being able to telnet to their
> fancy new BSD box.

"valuable resources"?  Not really...

"a little easier"?  It's not necessarily a matter of "easy", but rather
I think more a matter of meeting the expectations of the vast majority
of existing BSD administrators.  I've never of any kind of system using
BSD networking that didn't always start inetd automatically fairly early
during boot-up.

Though certainly it's hard enough already to explain to someone why they
have to edit /etc/inetd.conf to enable "talk", for example, let alone
try to tell them that they have to edit /etc/rc.conf and also start this
"inetd" thing by hand for the first time....

> Ok, stupid humor aside, when the base system becomes PKGized, there
> will need to be a way to enable things in inetd.conf and rc.conf, so
> I suppose 'pkg_installSHIELD' will need to be able to add/edit both.
> 
> Unless the user should be expected to "pkg_install ftpd" and then have
> to enable it in inetd.conf/rc.conf?

I don't see a problem with the latter for the time being (though I am
leaning towards wanting to see the rc.d system fixed so that rc.conf (or
whatever) only contains options, not on/off settings -- the existance of
a file in a directory should be sufficient to turn something on or off,
and those who want to version-control such things can write scripts that
rebuild /etc/rc.d from scratch and they can version-control their scripts).

> Or is NetBSD going to ship with ssh installed and enabled by default?

or at least SRP-enable everything with encryption left as an option for
those with the crypto stuff...

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>