Subject: Re: inetd.conf [firstname.lastname@example.org: CVS commit: basesrc]
To: NetBSD Networking Technical Discussion List <email@example.com>
From: Andrew Gillham <firstname.lastname@example.org>
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
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 Gillham | NetBSD ist Affengeil.
email@example.com | Nachts ist es kaelter
I speak for myself, not for my employer. | als draussen.