Bug 46449 - inetdconvert script does not convert entries with "no parameters" properly
inetdconvert script does not convert entries with "no parameters" properly
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2001-06-28 15:05 EDT by Need Real Name
Modified: 2007-04-18 12:34 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-03 11:18:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-06-28 15:05:06 EDT
Description of Problem:
The inetdconvert script does not respect that, and will create faulty 
"additional" parameters equal to the server name.

How Reproducible:
Every time

Steps to Reproduce:
1. Add this line to the file /etc/inetd.conf
2. Make sure that xinetd does not know about telnetd (temporarily remove 
the file from /etc/xinetd.d)
3. Try to convert /etc/inetd.conf file with :
inetdconvert --convertremaining
4. Restart xinetd
5. Try to telnet to the machine.
6. Get an error message like this :
Usage: telnetd [-debug] [-D (options|report|exercise|netdata|ptydata)]
         [-h] [-L login_program] [-n] [port]                           
Because in.telnetd appears into the telnetd server parameters.
Comment 1 Trond Eivind Glomsrxd 2001-06-29 15:37:29 EDT
You didn't enter the line you mentioned...
Comment 2 Need Real Name 2001-06-29 16:34:04 EDT
Oops, sorry about that. I had to switch between the Javascript/Non-Javascript
version of bug submission (StarOffice has some more homework to do...)
Here is the kind of faulty line that will trigger the error :
telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd  in.telnetd 
Notice that the argv[0] parameters in.telnetd is going to be included into the
xinetd args parameters, causing the problem.
Comment 3 Trond Eivind Glomsrxd 2001-06-29 17:20:58 EDT
But doesn't that line say just the same? Run /usr/sbin/in.telnetd 
with argument "in.telnetd" - this looks like a bad modification of the standard
"/usr/sbin/tcpd in.telnetd"?
Comment 4 Need Real Name 2001-07-03 11:18:19 EDT
Sorry again, I was in a hurry and a lot has been lost into the migration from
the Javascript to the non-Javascript version of the submission form.

The line I submitted is the official-ad-requested-by-the-inetd-man-page way to
set up a server _without_ using the tcpwrapper. This is the pathological case
that triggers this problem : when you have some servers that should be launched
by inetd _whithout_parameters_, then you have to provide argv[0] nonetheless.
This is peculiar, but this is it !!!

I have to went through an exegesis of the inetd.conf/xinetd.conf man pages to
understand. Here are the exerpt that showed me the light :
From inetd.conf man page :
     Upon execution, inetd reads its configuration information from a configu-
     ration file which, by default, is /etc/inetd.conf. There must be an entry
     for each field of the configuration file, with entries for each field
     separated by a tab or a space.  Comments are denoted by a ``#'' at the
     beginning of a line.  There must be an entry for each field.  The fields
     of the configuration file are as follows:
           service name
           socket type
           server program
           server program arguments 
     The server program arguments should be just as arguments normally are,
     starting with argv[0], which is the name of the program.  If the service
     is provided internally, the word ``internal'' should take the place of
     this entry. 

Note how they _insist_ on the fact that there must be an entry for _each_
fields, including the server program arguments.
Now, if we look at the xinetd.conf man page :
       server_args      determines the arguments passed to the server. In
contrast to inetd, the server name
                        should not be included in

So, as you can see, the designers of xinetd really looked at that problem
before. The problem is that the inetd -> xinetd configuration utility _does_ not
make that distinction.

It's no bgi deal to correct, the only problem is that I do not know python
enough to send a patch.
Comment 5 Trond Eivind Glomsrxd 2001-07-23 18:54:18 EDT
Fixed in xinetd-2.3.0-3

Note You need to log in before you can comment on or make changes to this bug.