Re: And now for something completely different... etch!
Manoj Srivastava <srivasta@debian.org (va, manoj)> writes:
> On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein <fredderic@excite.com> said:
>
>>> > - inetd begone! -> xinetd (better mechanism to control DoS,
>>> > separation, etc.)
>
>>> xinetd begone. There is no justification for using anything
>>> resembling inetd on a modern system.
>
>> What planet do you live on? I want MORE use of inetd, not less. I
>> want to be able to select a service, and tell the system whether I
>> want it running all the time, or only when needed.
>
> Why? What you offer here are preferences and opinions, with
> nothing to back them up. Previous posters in the discussion have
> offered reasons not to use inet daemons -- off the top of my head, it
> was a) in the current day and age, an idling daemon does not consume
> a significant amount of resources, b) a inted daemon adds complexity
> to the mix, and another point of failure/attack c) It adds latency to
> response for the daemon (I may have missed other points).
>
> What do you have to counter these points? I can speculate that
> you may disagree with point a above, but if so, I think in my
> experience point a has been justified.
>
> manoj
What amounts to significant is higly usage dependent. In embeded use,
e.g. all those wireless routers with linux out there, wasting an extra
MB ram might be critical. On the other hand the ram has to be
available in case the service does get used anyway. But there might be
cases where only one of several alternative services is in use at any
given time (e.g. either telnet or http configuration frontend). Having
both always loaded needs more resources.
Using inetd means services don't have to be manualy restarted when the
config file is changed (as that is parsed on each connect).
Inetd gives a single point to control access. A single point to filter
out unwanted or unalowed access. Easier than to implement the same
access restrictions in every daemon.
MfG
Goswin
Reply to: