inetd

[Cef]

On Mon, 6 Sep 2004 19:16, John wrote:
> Cef wrote:
> >In the end (after warty), update-inetd really belongs in netkit-inetd, and
> >anything at all that calls update-inetd needs to either handle not finding
> > at install. If it really needs inetd (ie: doesn't have it's own
> > stand-alone daemon mode),  it should depend upon netkit-inetd. I still
> > think inetd shouldn't run on boot either unless asked, as IMHO this
> > should be a conscious decision to enable it on the part of the machines
> > owner.
>
> I personally prefer xinetd over inetd.

This is a flamewar waiting to happen.

> Has the group considered xinetd?

Doubtful at the moment. It's a 'somewhat' big change, that isn't warranted for 
a desktop setup.

> Does what you propose break xinetd?

In it's current form, not really. The whole inetd/xinetd/etc issue is pretty 
much broken as it stands, so it can't get much worse. update-inetd was 
written specifically for inetd only, so such a change doesn't stop xinetd 
from working.

However, almost none of the available packages really support xinetd (ie: it's 
up to the admin to configure xinetd to run, and configuring it to call 
programs), so it's a problem that needs to be sorted out at some stage in the 
future. Since the only way you'll find out what options the program expects 
to be called with by default are those that get inserted into inetd.conf, and 
since the config file won't be written to if it doesn't exist, you're going 
to have issues.

Changing every program to support xinetd as well as inetd (or any other *netd 
like program) is a lot of effort, and if another derivative appears, you'll 
have another program to support. By supporting one set format and having 
utilities that convert the format as needed (eg: scripts), you only have to 
write one new script to support a new program, not patch every program.

> Note that if xinetd were the standard super daemon, packages would
> a) depend on it

They do already, as xinetd provides .

> b) Plonk their config file into /etc/xinetd.d

Could be handled through a script that works with inetd/etc as well, so one 
script is used to drive all *netd implementations.

> c) Not need scripts to run update-inetd or equivalent.

But then you're tied to one program, which is really what the problem with 
*netd is currently.

> Seems to me a much nicer way to go for packagers, maintainers, sysadmins
> and those who want to hack on the superserver's  configuration.

Actually, tying someone down to the ONE program isn't really that nice at all. 
It's called lock-in. It's like telling every vi user that they must only use 
emacs from now on.

-- 
 Stuart Young - aka Cefiar - cef at optus.net