Bug 46449 - inetdconvert script does not convert entries with "no parameters" properly
inetdconvert script does not convert entries with "no parameters" properly
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Ben Levenson
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2001-07-03 11:18:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 :
(...beginning...of...inetd.conf...)
     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
           protocol
           wait/nowait[.max]
           user[.group]
           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. 
(...end...of...inetd.conf...)

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
server_args.                                                           
(...)

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.