[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [LSB] inetd.conf "drop zone"



   From: "George Kraft/Austin/IBM" <gk4@us.ibm.com>
   Date: Fri, 27 Oct 2000 16:03:26 -0500

   I believe Ted Tso is working on making some updates to System Initilization
   chapter.   Please correspond with him directly, because an informed
   response from me may be delayed.  :-)

I am indeed working on it (and Ray, I hope to write a message to
lsb-spec on the SysV issues we discussed at the Linux Kongres over a
month ago; sorry for the delay in getting to it.  Life has been a little
crazy here).

However, the question here isn't about SysV init scripts, but about the
inetd daemon.  (What's a vowel between friends?  :-)

     Concerning the handling of inetd.conf snippets. I understand that
     LSB defines an interface by which applications can register themselves
     with inetd (or equivalent). I've put together a patch for inetd that
     does this. However, some questions remain:

      -    What will the directory name be? (we use /etc/inet.d for now)
      -    After dropping a file into this directory, a package
	   has to cause inetd to re-read its configuration
	   (probably using a platform-specific script).
	   What will the name of this script be?

As far as I know, there isn't such an interface defined by LSB at the
moment.  There have been random dicussions about how this would be a
Good Thing, but I don't think it's ever been written down anywhere.  As
far as where to put it, my personal preference would be for /etc/inetd.d
myself, but the name isn't that important....

Adding more confusion to this subject is the fact that Red Hat has
recently adopted the use of xinetd, which puts config files in a
completely different place, and which uses a completely different
syntax.  It seems to be a more featureful program, but I find the lack
of backwards compatibility.... dismaying.  Although it does have a
configuration file conversion program, it would have been a lot better
if it could natively parse the old config file as well, since *so* many
people still are more familiar with the old and familiar inetd.conf
format.

We *could* still ignore this from an LSB perspective, since the script
can convert the configuration file and then drop it into /etc/xinetd.d
directory.  (On the other hand, if we get a consensus that xinetd is the
way people want to move, then we can simplify things a little.)

If we ignore xinetd, what I'd propose is:

1)  Use the directory /etc/inetd.d, where inetd fragments should go.

2)  Have a script called "install-inetd-entry" which has two forms:

	install-inetd-entry <file-name-of-inetd-fragment>
	install-inetd-entry --update <file-name-of-inetd-fragment>
	install-inetd-entry --uninstall <file-name-of-inetd-fragment>

The last two will be necessary for those distributions who wish to use
xinetd, since the script will have to find the translated xinetd
fragment, and delete or update it.

						- Ted



Reply to: