Subject: Re: inetd.conf [sommerfeld@netbsd.org: CVS commit: basesrc]
To: NetBSD Networking Technical Discussion List <tech-net@netbsd.org>
From: Andrew Gillham <gillhaa@ghost.whirlpool.com>
List: tech-net
Date: 06/06/2000 18:45:31
Greg A. Woods writes:
> 
> Ah, that helps with the terminology:  inetd isn't a service per se, but
> rather a service broker.

But again if there are no services offered, why run a service broker?  Once
the first service is enabled, the service broker should be started.

> "valuable resources"?  Not really...

264 root       2    0   104K  572K sleep   0:30  0.00%  0.00% inetd

Well, while not as valuable on my 128MB box, why run this on a 4-8MB
machine?  Especially an old slow one. :-)

> "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.

Well editing one file with a "foreign editor" (aka "six" err I mean "VI")
is only "a little easier" than editing two for someone of limited experience
or technical ability.

While I'm not saying to completely "dumb down" the process, I just think that
there should be an "easier" way to re-enable things. 

> 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....

# svc_enable talkd
# svc_start talkd
[to invent ficticious commands]

I am all for more security, but as someone else mentioned it needs to be
clearly documented (and IMHO easy) how someone should go about enabling
certain things.
As an example, the whole ELF "-rpath" mess is going to (IMHO) bite
NetBSD/i386 on the backside with 1.5.  That is just an example of the
"right way(*)" being a PITA when it isn't fully documented or executed.

(*) And if executables (such as from pkgsrc) should have the -rpath so
that ld.elf_so knows where to find the libraries, why then isn't the
base system built with -rpath?  Because there is a default specified
in rtld.h for /usr/lib.  Why not just put /usr/pkg/lib and /usr/X11R6/lib
as well? (otherwise should the default of /usr/lib be removed?)

-Andrew
-- 
-----------------------------------------------------------------
Andrew Gillham                            | NetBSD ist Affengeil.
gillham@whirlpool.com                     | Nachts ist es kaelter
I speak for myself, not for my employer.  | als draussen.