On 06/22/05 12:02:53PM -0500, Manoj Srivastava wrote: > On Wed, 22 Jun 2005 07:22:33 -0400 (EDT), Freddie Unpenstein <[EMAIL > PROTECTED]> 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.
>From the security aspect using xinetd automatically gets you things like connection rate limiting, tcp wrappers support, source address restrcitions, available time restrictions, connection logging, interface binding, etc. Sure some daemons already sport those options, but not all do and if a standard is to be chosen it should be safer one. If you know the service well enough to configure it you probably also know how to disable the xinetd instance and enable the init script. > > manoj Jim. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
