Jack,

I'm taking an interest in this post because I'm a VIPA advocate and
configuring the two flavours of TELNET deamon in a user-friendly way is
something VIPA, together with the PORT BIND parameter, do rather well. It
looks as if you are also trying to tackle the issue of configuring the two
flavours of TELNET here - so I read on.

I know about INETD only from long ago with the RS/6000 UNIX, AIX and I'm
looking at the MVS UNIX INETD only from the manuals.

Because of the research I have just done for this post, I see that section
2.18.5, "Configuring TSO and z/OS UNIX Remote Execution servers to use the
same port" in the CS IP Configuration Guide extends the VIPA/BIND trick to
REXECD and RSHD.

First a trivial point, it's etc/inetd.conf, not etc/inetd.config - as I see
Art also mentioned.

I found the following in section 1.4.5.1.2, "Trusted multilevel secure
server applications" in the CS IP Configuration Guide:

<quote>

The following z/OS CS servers are designed to be forked by inetd. They each
perform additional user authentication.

z/OS UNIX REXEC server
z/OS UNIX RSH server
z/OS UNIX Telnet server

</quote>

>From UNIX System Services Command Reference one can see that two other
daemons are supported by INETD, namely, RLOGIND and UUCPD.

The following statement in section 2.26, "Chapter 31. TIMED daemon" tends to
confirm that a daemon must be written to be started by INTETD and cannot
just be any old daemon:

<quote>

Guideline: TIMED is different from the TIME daemon available as an internal
daemon of INETD. INETD cannot be used to start and perform as a listener for
TIMED.

</quote>

This is supported even more by section APPENDIX1.1 Appendix A. "Setting up
the inetd configuration file" in the CS IP Configuration Guide which states
the following:

<quote>

inetd is a generic listener program used by such servers as z/OS UNIX telnet
server and z/OS UNIX rexec server.

Other servers such as z/OS UNIX ftp server have their own listener program
and do not use inetd.

</quote>

Art is onto an important point in drawing attention to the "/etc/services",
ETC.SERVICES, file. INETD logic appears to rely on this file in order to
specify the ports for which it will be the "listener". Thus the inetd.conf
file specifications need to be complemented by the "/etc/services",
ETC.SERVICES, file.

>From all of this it seems

1. You need to configure INETD - and ETC.SERVICES - to support OTELNETD
2. You cannot use INETD to support TN3270 - which I guess is what you mean
by "tso telnet" - the TELNET where, if suitably configured, the first
message you see is an Unformatted System Services (the other meaning of
"USS") message 10, USS being a facility created for VTAM but has been
adopted additionally by CS IP.

> I was trying to get inetd to take control for telnet sessions (otelnetd
and/or tso telnet) but so far I can only get vtam (msg10) to get control.
Netstat show mvs tcpip task listening on port 23 (from tcp profile). inetd
is listing on port 513 and 540 (from /etc/services).

Note that the ports which INETD is "listening" on are as follows (according
to my Windows NT "Services" file):

513 - the "who" service - daemon "whod"
540 - the "uucp" service - daemon "uucpd"

> I've removed the intclien from port 23 tcp profile as well as the port 23
from the telnetparms, I've added port 4023 as inetd in the mvs tcp profile,
I've added port 4023 as tcp in /etc/services but still no luck.lots of
different errors, the current set from the attached configuration is:

It would appear you are trying to set up otelnetd on port 23. You should
scrap all these changes and use the VIPA/BIND trick as it is described in
section 2.18.5, "Configuring TSO and z/OS UNIX Remote Execution servers to
use the same port" in the CS IP Configuration Guide for REXECD and RSHD.

Let us assume you assign one VIPA to the CS IP TN3270 server and another to
OTELNETD, the definitions might be as follows:

In the PROFILE file:

DEVICE VIPAD1 VIRTUAL 0
LINK   VIPA1  VIRTUAL 0 VIPAD1
DEVICE VIPAD2 VIRTUAL 0
LINK   VIPA2  VIRTUAL 0 VIPAD2

HOME
10.1.1.1       VIPA1
10.1.1.2       VIPA2

PORT

 23 TCP OMVS BIND 10.1.1.1 ; z/OS Unix TELNET
 23 TCP INTCLIEN BIND 10.1.1.2 ; CS IP TN3270

In /etc/services:

otelnet          23/tcp

Your inetd.conf looks fine.

If using VIPAs is too rich for you, you could set your TELNET services up
the following way:

In the PROFILE file:

PORT

 23 TCP INTCLIEN ; CS IP TN3270

4023 TCP OMVS ; z/OS Unix TELNET

In /etc/services:

otelnet          4023/tcp

Of course, I am using your "special port" 4023 for the z/OS Unix TELNET
service.

>>> inetd.16777834.: FOMN0080 *:otelnet/tcp: getaddrinfo: EDC9508I The
service passed was not recognized for the specified socket type.

This error message appears because you do not have the service otelnet
specified in etc.services - with protocol "tcp". This error message rather
nicely shows the need for etc/services to be lined up with the services
specified in inetd.conf.

There are some questions about what exactly is "working" for John McKown.
I'm not convinced he is talking about what you want - but maybe I should be.
Please see my response to his post.

Everything I have specified is how I think it's done from what I have found
in the manuals. The only part of the configuration that doesn't tie up in
the same way you normally see it is in the association of the z/OS UNIX
TELNET service, otelnet, port with an INETD process. However, from section
2.18.5, "Configuring TSO and z/OS UNIX Remote Execution servers to use the
same port" in the CS IP Configuration Guide, you can see that, rather than
having the name of a procedure, the "jobname", there is the special name
OMVS. This is because the INETD process runs under OMVS (z/OS UNIX System
Services). The sample NETSTAT implies that the ports associated with OMVS
under the PORT statement have an apparent INETD "listener", INETDCS1. You
should see something equivalent to the NETSTAT output when you get OTELNETD
working with INETD.

I realise I've suggested using VIPAs without really explaining how.

If you have only a single IP interface to your CS IP instance and possibly
you use static routing, you may not be familiar with VIPAs. If you set your
application destination addresses up as I have shown, you can instruct your
client end-users to use port 23 whichever TELNET service they want and, with
suitable name server entries, they can access applications as follows:

unix.mycorp.com (which the name server converts to 10.1.1.1)
tso.mycorp.com (which the name server converts to 10.1.1.2)

Alternatively, if you want to be able to select, say, TSO or CICS, when the
USS message 10 is presented, you might provide the following:

vtam.mycorp.com (which the name server converts to 10.1.1.2)

I guess if your TELNET clients have some sort of "profile" support, your
end-user could simply select "unix on the mainframe" or "vtam on the
mainframe" and it would not matter what the underlying details were:
different names (or addresses) with the same port, same names (or addresses)
with different ports. However there may be a maintenance benefit with the
VIPA technique especially if you move to having redundant interfaces -
assuming you don't have them now.

John McKown's post raised the issue of using the internal TN3270 server or a
separate address space for the TN3270 server and he highlighted the "special
jobname" INTCLIEN.

The name INTCLIEN seems ridiculous when talking about a server and, indeed,
it is. What is necessary is to revise one's perspective over what is a
"client" and what is a "server". The IP component of CS has a main address
space and a number of supported address spaces - equivalent in the days when
the product was TCP/IP for MVS - just created from TCP/IP for VM - to VM
"machines". The main address space may be described as a "server" and all
the dependent address spaces as "clients" even if they are "servers" in the
usual sense of the term, for example, the FTP server. Taking this
perspective, the TELNET server - now to renamed by CS IP as TN3270 even if
it can still support emulated 3767 access - is a "client" and, if it runs
internally, it may have the special name INTCLIEN.

Chris Mason

----- Original Message ----- 
From: "Jack Kelly" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@BAMA.UA.EDU>
Sent: Thursday, 02 March, 2006 4:55 PM
Subject: inetd to take telnet request


I was trying to get inetd to take control for telnet sessions (otelnetd
and/or tso telnet) but so far I can only get vtam (msg10) to get control.
Netstat show mvs tcpip task listening on port 23 (from tcp profile). inetd
is listing on port 513 and 540 (from /etc/services).

I?ve removed the intclien from port 23 tcp profile as well as the port 23
from the telnetparms, I?ve added port 4023 as inetd in the mvs tcp
profile, I?ve added port 4023 as tcp in /etc/services but still no
luck.lots of different errors, the current set from the attached
configuration is:

inetd.16777834.: FOMN0080 *:otelnet/tcp: getaddrinfo: EDC9508I The service
passed was not recognized for the specified socket type.

telnetd.83886697.: EZYTU34I id 50008 pri 3 call getpeername
(0,8C69718,8C69710->128) code 451 reason 110D0223 h_errno N/A

r/c451 is
ENOTSOCK
 Socket operation on a non-socket.

/etc/inetd.config is

#======================================================================
# service | socket | protocol | wait/ | user | server  | server program
# name    | type   |          | nowait|      | program |   arguments
#======================================================================
#
otelnet   stream tcp nowait OMVSKERN /usr/sbin/otelnetd otelnetd -l
#shell    stream tcp nowait OMVSKERN /usr/sbin/orshd    orshd    -LV
login     stream tcp nowait OMVSKERN /usr/sbin/rlogind  rlogind  -m
#exec     stream tcp nowait OMVSKERN /usr/sbin/orexecd  orexecd  -LV
#
uucpd     stream tcp nowait UUCPD    /usr/sbin/uucpd    uucpd    -10

snips from /etc/services are

ftp             21/tcp
#telnet          23/tcp
telnet          4023/tcp
smtp            25/tcp

login           513/tcp
who             513/udp

uucp            540/tcp

the mvs tcp profile snips are

TELNETPARMS
    PORT 23

PORT
      7 UDP MISCSERV            ; Miscellaneous Server
      7 TCP MISCSERV
      9 UDP MISCSERV
      9 TCP MISCSERV
     19 UDP MISCSERV
     19 TCP MISCSERV
     20 TCP OMVS      NOAUTOLOG ; FTP Server
     21 TCP FTPD1               ; FTP Server
     22 TCP SSHD1               ; FTPS-UNIX
     23 TCP INTCLIEN            ; TELNET SERVER-MVS
 ;   23 TCP INETD4 BIND 156.132.10.15
 ;   23 TCP INETD               ; TELNET SERVER-UNIX
 ;   23 TCP OMVS                ; TELNET SERVER-UNIX
     25 TCP SMTPD               ; SMTP Server

Jack Kelly
LA Systems @ US Courts
x 202-502-2390

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to