HP has made a lot of enhancements in order to enable the MPE/iX Internet features available in release 5.5. But learning how to deploy them means a system manager has to read a lot of different manuals (like “Configuring and Managing MPE/iX Internet Services”), HP Communicators (especially the C.55.00 Communicator), and different Web pages (browsing to www.docs.hp.com/mpeix/ or the HP Electronic Support Center site).

I have never seen a short summary of all the needed steps. Here are my notes on how to set them up, as concise and complete as I can make them.

The main difference between the 5.0 release and 5.5 is that MPE/iX 5.5 looks more like Unix. Well-known Unix services and configuration methods have been ported to MPE/iX. Additionally, some freeware services can be configured the same way.

The problem with those services: It’s very hard to see whether or not they are started and running. A clever SHOWPROC 1;TREE;SYSTEM for the ports being configured may be useful, but the monitoring of background jobs may be more convenient. Whatever method you choose, the new services make MPE/iX behave more like Unix, a so-called non-legacy platform. So we probably should be proud that our so-called legacy platform can run widely accepted non-legacy services.

But back to the task! Basically, three steps are needed: (1) Create and edit the needed configuration files, (2) link the configuration files into Posix standard locations, and (3) start the needed background job.

Create and edit needed configuration files

On most systems, a SERVICES.NET.SYS file will exist. So I recommend you compare the content of your existing

SERVICES.NET.SYS file with SERVSAMP.NET.SYS. This file contains the information about the services provided. SERVSAMP.NET.SYS looks like:

# The form for each entry is:
# <official service name> <port number/protocol name> <aliases>
#
echo 7/tcp # Echo
echo 7/udp #
discard 9/tcp sink null # Discard
discard 9/udp sink null #
daytime 13/tcp # Daytime
daytime 13/udp #
chargen 19/tcp ttytst source # Character Generator
chargen 19/udp ttytst source #
ftp 21/tcp
telnet 23/tcp
time 37/tcp timeserver # Time
time 37/udp timeserver #
domain 53/tcp nameserver # Domain Name Service
domain 53/udp nameserver #
bootps 67/udp # Bootstrap Protocol Server
bootpc 68/udp # Bootstrap Protocol Client
tftp 69/udp # Trivial File Transfer Protocol
DAServer 987/tcp # SQL distributed access


Copy SERVSAMP.NET.SYS to SERVICES.NET.SYS, or edit the existing file to match. You’ll be doing this kind of process for all other files discussed below.

The second file is PROTOCOL.NET.SYS. The sample file distributed with 5.5 is PROTSAMP.NET.SYS, and it looks like:

# This file associates protocol numbers with official protocol names and
# aliases. This allows the user to refer to a protocol by a symbolic
# name instead of a number. For each protocol a single line should be
# present with the following information:
# <official protocol name> <protocol number> <aliases>
#
# Note: The entries cannot be preceded by a blank space.
#
tcp 6 TCP # transmission control protocol
udp 17 UDP # user datagram protocol


Having copied this, the 3000’s services now know what TCP and UDP means.

A very essential file is INETDCNF.NET.SYS. Here the Internet Daemon Configuration is declared. The sample file is INCNFSMP.NET.SYS and looks like:

#
# Internet server configuration database
#
echo stream tcp nowait MANAGER.SYS internal
echo dgram udp nowait MANAGER.SYS internal
daytime stream tcp nowait MANAGER.SYS internal
daytime dgram udp nowait MANAGER.SYS internal
time stream tcp nowait MANAGER.SYS internal
time dgram udp nowait MANAGER.SYS internal
discard stream tcp nowait MANAGER.SYS internal
discard dgram udp nowait MANAGER.SYS internal
chargen stream tcp nowait MANAGER.SYS internal
chargen dgram udp nowait MANAGER.SYS internal
#telnet stream tcp nowait MANAGER.SYS internal
#bootps dgram udp wait MANAGER.SYS /SYS/NET/BOOTPD bootpd
#tftp dgram udp wait USER.TFTP /SYS/NET/TFTPD tftpd


If you want to use telnet, you must edit this file and remove the #, the Unix sign for a comment line, in front of the telnet service definition. Whenever a service can run as an Internet service (e.g. Samba/iX) it can be configured to start automatically in this file:

nmbp dgram udp wait MGR.SAMBA /SYS/SAMBA/NMBD nmbd
smbp stream tcp nowait MGR.SAMBA /SYS/SAMBA/SMBD smbd

This permits it to be started whenever the Internet daemon runs. The second entry is needed in SERVICES.NET.SYS, of course; e.g.:

nmbp 137/udp # Samba/iX
smbp 139/tcp # Samba/iX

The following will happen: Internet Daemon will start Samba/iX immediately, not waiting for a port request. Samba/iX is a TCP-based service smbp with the program /SYS/SAMBA/SMBD. This service is defined in /etc/services for port 139 using TCP protocol. This is enough to start Samba/iX — no additional background jobs are needed!

A fourth file may be installed the same way to configure the Bootstrap Protocol Daemon: BOOTPTAB.NET.SYS via BPTABSMP.NET.SYS. This file may be of special interest if you want to boot or start printers as well. For more details please refer to the sample file itself — here I’m not an expert.

The files HOSTS.NET.SYS and RESLVCNF.NET.SYS should already exist. Samples are named HOSTSAMP.NET.SYS and RSLVSAMP.NET.SYS.

Optional files are the INETDSEC.NET.SYS and SNMPCONF.NET.SYS. The samples are INSECSMP.NET.SYS and SNMPSAMP.NET.SYS. Additional Internet security can be added using the first file, and SNMP can be used for all kind of SNMP services. Both are not needed!

Link the configuration files into POSIX standard locations

Because of the origin of those services, they expect the configuration information in the same place as a Unix system. To ensure this, the NEWLINK command must be used in this way:

NEWLINK /etc/hosts,HOSTS.NET.SYS
NEWLINK /etc/resolv.conf,RESLVCNF.NET.SYS
NEWLINK /etc/services,SERVICES.NET.SYS
NEWLINK /etc/protocols,PROTOCOL.NET.SYS (sic! not a typo!)
NEWLINK /etc/inetd.conf,INETDCNF.NET.SYS
NEWLINK /etc/inetd.sec,INETDSEC.NET.SYS
NEWLINK /etc/bootptab,BOOTPTAB.NET.SYS


Start the needed background job

Now you stream the Internet Daemon background job JINETD.NET.SYS. That’s it! Now you can try to reach your HP 3000 with a normal telnet session out of your favorite terminal emulator or any Unix host! Incoming telnet is now available as easily as outgoing telnet.

A simple command file could look this way:

                                        SETVAR CIERROR=0
                                        CONTINUE
                                        PRINT SERVICES.NET.SYS
                                        IF CIERROR = 0 THEN
                                           ECHO SERVICES.NET.SYS exists.
                                           INPUT YES;PROMPT=”Do you
want to override it ?”
                                           IF ups(“!YES”) =
“Y” THEN
                                              COPY
SERVSAMP.NET.SYS,SERVICES.NET.SYS
                                           ENDIF
                                           ELSE
                                              COPY
SERVSAMP.NET.SYS,SERVICES.NET.SYS
                                        ENDIF
                                        

... and so on for the rest of the configuration files ...

NEWLINK /etc/hosts,HOSTS.NET.SYS

... and so on ... see above!

What you get for this effort

All configuration changes in services and protocols are easy to perform without stopping any Internet service. You only need to edit the configuration files and type the command INETD.NET.SYS -c or /SYS/NET/INETD -c or RUN INETD.NET.SYS;INFO=“-c”, assuming that the Internet Daemon is already running.

For example, if you want to enable the REMSH remote shell service, just do the following:

• Check the file SERVICES.NET.SYS for this entry:

shell 514/tcp cmd # remote command, no password used

If this line is not present, edit the file appropriately.

• Submit the command INETD.NET.SYS -c

• Make sure that on the remote (Unix) system the file .rhosts exists to allow your MPE logon. This file must contain the CPU name and the MPE user who is allowed to execute commands on the remote system, e.g.

zeus MANAGER.SYS
zeus OPERATOR.SYS
or s.th. like this.

Please take into consideration that REMSH will not work between MPE systems, or from Unix to MPE (see Communicator 5.5, Express 3, p.2.4 for an explanation of why).

Other advantages are:

• One background job for different Internet Services.

• Logging is included. Change the JINETD.NET.SYS to RUN INETD.NET.SYS;INFO=“-l” in the second line.

• One command to stop all services: INETD.NET.SYS -k (for kill).

• Most of the newer services can be installed using this method without a need to establish a new background listener job, e.g.: Sendmail/iX.

• No knowledge about Posix and HFS filesystems is needed. (Nevertheless, it’s obvious that MPE has become more developed in this aspect. To know more about Posix and HFS is certainly not a bad thing!)

• The same setup is needed to establish Network Printing (NPCONFIG.PUB.SYS). But I won’t get into that here.

Disadvantages I found

• The performance impact of telnet is unclear yet. I enabled this feature on my test box a while ago and saw some peaks, but it’s a small box (Series 960). Only a few sessions are currently directly connected via telnet, and I assume that the overhead is negligible. But I’d like to hear from you about that.

• If you want to stop only one service, it will become a little bit more complicated if no kill command is implemented in the service itself. And you cannot kill in a secure way the processes on a single port. Nevertheless, you may change the SERVICES.NET.SYS file, kill INETD using INETD.NET.SYS -k, and start again without the disabled service. To restart, change SERVICES.NET.SYS again and reconfigure INETD using INETD.NET.SYS -c.

• Monitoring is not so easy as with single jobs.

I hope this article will help you to make the best use of the new services for our beloved HP 3000. You may give me feedback and report any errors in this article directly to me at aschmid4@csc.com.