net.digest December 2000

Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup and mailing list. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your HP 3000s.

Edited by John Burke

Do we have a President-Elect yet? As I write this, in late November, we do not. Much of the off-topic conversations on 3000-L in November were obviously about the election and, particularly, how to count votes accurately. I think I know more about voting machines now than I care to. But there was still time to question the tone of an HP e3000 brochure based upon keynote speeches at HP World, to comment on the lack of service provided by the airlines, to trash SAP and management-by-magazine, to suggest an interesting approach to marketing Transact in particular and the HP e3000 in general, and to give an update on Team 3000-L’s standing in the seti@home project (68th among all clubs).

Amazingly, there was still enough energy around to generate a lot of good technical tips and tricks, some of which follow.

As always, I would like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse’s behind, let me know. You can reach me at john.burke@paccoast.com.

Help, my Telnet users cannot connect

This has been the subject of multiple threads over the last year or at least since significant numbers of sites have started using host-based Telnet on the HP e3000. It basically boils down to jinetd (Telnet runs under jinetd) being starved for resources on heavily loaded systems and refusing to make Telnet connections. Here’s an example:

“We have a problem connecting via Telnet when our system is very busy (MEM 99% and CPU 99% as reported by GLANCE). The Telnet connection is not made and the console displays the following message:

/#J1/77/ Could not initialize data in path with TCP.

“Connections from terminals and PCs using VT are not effected. Is there anything we can do?”

One of the more popular workarounds is to assign the jinetd job a priority of BS with the ALTPROC command. While this does not appear to have caused any problems, nevertheless, HP does not (officially) support it.

However, it appears the word had not gotten out to everyone at the HP RC, because one poster to 3000-L reported:

“I got a verbal OK from HP RC on a similar problem to make the JINETD.NET job different, thus:

!job jinetd, manager.sys;HIPRI;PRI=CS !run inetd.net.sys;PRI=152 !eoj

“It puts your listener in the linear sub-queue (BS), not at the 100 default, but rather at the top of the CS queue.”

Fortunately, James Hofmeister, of the HP Worldwide Technology Network Expert Center, stepped up to explain the problem and give a status report (actually several postings I merged and edited into one):

Note: The error “Could not initialize data in path with TCP” is seen with this problem.

Sorry you got this bad advice... “;PRI=152” is not supported by the HP CSY Labs. We do on occasion recommend as a “diagnostic test” for HP RCE’s to try “;PRI=152” and then attempt to duplicate a problem, but this configuration is not to be left on a customer’s production system.

For details on this problem go to the HP-ITRC and find SR 8606156115.

The current status of this problem is that a solution has been coded which will perform a GETPRIORITY of INETD at PRI=152, but will still create the servers at PRI=CS.

The problem with specifying “;PRI=152” is the servers are also created at “;PRI=152”. If you experience a system hang or network hang or system abort out of the network code with the “;PRI=152” specified, you will be notified you are operating with a unsupported configuration.

P.S. I will send a message out to the HP RCE’s making them aware that “;PRI=152” is not a CSY Labs supported solution.

The solution/patches are now available as Beta releases: INTFDX2 for MPE/iX 6.0 and INTFDX3 for MPE/iX 6.5.

When requesting this Beta Test patch from the HP-RC, please request the patch by referencing SR 8606156115.

While we are on networking issues, what’s the story with tracert?

Seemingly a long, long time ago in a galaxy far, far away, there was an announcement about tracert being made available for MPE/iX. tracert is particularly useful in diagnosing network routing problems and would be a welcome addition to the system administrator’s toolkit. It got as far as a beta patch to 5.5, and them seemed to drop off the radar screen. It turns out that not only can MPE/iX not initiate a tracert, but also it can not respond to another system’s tracert. Here’s the story, again from James Hofmeister:

Yes, sorry, the tracert inbound to the 3000 requires ICMP code that will perform the ICMP reply “Time Exceeded for a Datagram” and this code currently does not work.

We initially attempted to implement tracert on MPE/iX 5.5. The Alpha and Beta tests of this functionality went fine but when we General Released it, we found two or three different corner cases where it was aborting machines. It since has been pulled from all future patches and all patches that contained this functionality were marked bad.

The tracert functionality on the 3000 requires code in three areas:

• The tracert program which is an unsupported freeware program in which minimal changes were made to port it to the 3000;

• The NS-Transport ICMP code needs to be enhanced to support the ICMP reply “Time Exceeded for a Datagram”; and

• The NS-Transport IP code needs to be enhanced to support socket layer modification of the IP Time To Live field.

I know many folks are interested in this functionality and I hoped we could have delivered it a long time ago. I do not have an ETA as our resources are currently focused on addressing any difficulties customers/systems experience updating from 5.5 to 6.x.

Hey, we’re on a roll here. What’s the story
with ping and nettool user capabilities?

A user innocently asked what capabilities are needed to run PING.NET.SYS on their e3000. They were trying to run it from a user with AM,AL,GL,OP,ND,SF,BA,IA,PM,MR,DS,PH, and reported that nothing happens.”

It turns out the necessary and sufficient capabilities to run PING.NET.SYS from a session are IA, NA and NM. Which is silly, of course, since any fool with a PC can run ping from a command prompt window. Plus, giving out NA and NM is VERY dangerous. It is far too easy for someone to inadvertently trash your network.

Interestingly, nslookup (/BIND/PUB/bin/nslookup), which came to us thanks to Mark Bixby’s port of BIND and which is on 6.0 and above systems by default, has a necessary-and-sufficient capabilities list of just IA and PH. This makes much more sense.

Why does anyone care? Putting on my SIGSYSMAN Executive Committee hat for a moment, note that step one in any network troubleshooting checklist invariably involves issuing one or more pings. This is something you would like an operator, or Help Desk consultant, to be able to do.

For example, we have over 100 network printers on our production system — and when someone calls in with a printer problem, the Help Desk consultant taking the call is instructed to first check connectivity by pinging the printer. Ideally, they should be issuing the ping from the HP e3000, not their desktop, to fully check connectivity. But this means giving them NA and NM capability, or writing some kind of wrapper program that temporarily gives them NA and NM capability. This should not be necessary.

Combining nslookup with PING.NET.SYS in a relatively simple command file gives you a ping utility that is every bit as fast and versatile as the ping that comes with WinNT. [The ping module of NETTOOL.NET.SYS does name resolution, but its name resolution is excruciatingly slow. In contrast, nslookup is very fast and efficient. Note that NETTOOL also requires NM capability.]

Combine this with Donna Garverick’s tip to put all network printers in DNS by classname, and you have a potentially powerful first step diagnostic tool.

I’ve got Apache/iX running, but how do I display
something other than the default documentation?

Another user was trying to reference a regular MPE file from Apache, and they were getting an error telling them that the URL was not found. The Web page was at /APACHE/PUB/htdocs on the system, and they were trying to display a file with the usual a HREF=“/ACCT/GRP/FILE” and /a around the title

It seemed like this path should be correct, because “from the shell I can do ‘more /ACCT/GRP/FILE’ and see the file.”

[Before dealing with this question and the various responses, let me put in a pitch for Samba/iX (originally ported by Lars Appel) and Apache/iX (originally ported by Mark Bixby). If you do not have both running on a system in your shop, put this magazine down right now and go install them (Samba first). No excuses. I don’t care if you only have one HP e3000. Samba and Apache are safe and take up very little in the way of system resources, but open up a whole new world of possibilities for your organization. Within days, if not hours, you will be able to amaze and influence both your colleagues and bosses with what the HP e3000 can do. Just do it.]

With Apache running, how do you display something interesting?

Now, in answer to the original question, Peter Osborne proposed:

The document you href to must either be a fully qualified path to a url (like http://www.mysite.com/myfile.html) or must be relative to your document root (like /index.html which would be /APACHE/PUB/htdocs/index.html). If you need to display files from other accounts, you can set up an Alias in your httpd.conf file to the /ACCT/GROUP where the file resides.

Mark Bixby, who ported Apache to the 3000, chimed in with an exhaustive list of possible solutions:

When a browser tries to retrieve /ACCT/GRP/FILE, Apache is going to look for /APACHE/PUB/htdocs/ACCT/GRP/FILE. If you look in /APACHE/PUB/logs/error_log, you will probably see an error message showing the long name that wasn’t found.

By default, Apache will always look for documents starting at the directory specified in the DocumentRoot directive in httpd.conf. You have a few choices for allowing the Web server to access files outside of the Apache account:

• Set DocumentRoot to /. BUT DON’T TRY THIS AT HOME! It will allow a browser to read any file on your e3000, probably causing grave security problems.

• Specify Options +FollowSymLinks and create a symlink /APACHE/PUB/htdocs/ACCT which points to /ACCT. This will allow a browser to read all files below /ACCT.

• Specify Options +FollowSymLinks and create a symlink /APACHE/PUB/htdocs/thefile which points to /ACCT/GRP/FILE. Modify your HTML to say HREF=”/thefile”, and then a browser click on it. The Web server will read /ACCT/GRP/FILE.

• Utilize the UserDir feature so that when a browser requests a URL of http://yourhost/~USER.ACCOUNT/thefile, the Web server will read /ACCOUNT/USERHOMEGRP/public_html/thefile.

• The Alias directive is probably more secure than the symlink method, and “Alias /foo /ACCT” tells Apache that browser requests for http://yourhost/foo/bar need to come from the file /ACCT/bar.

Doug Werth noted a further use for the FollowSymLinks option:

The FollowSymLinks option is also useful for creating CGI programs that require special capabilities such as PH. A program requiring more capabilities than IA,BA must reside in an MPE GROUP and not in an HFS directory. You can create a symbolic link in the cgi-bin directory to run such a program if you enable FollowSymLinks.

<Directory /APACHE/PUB/cgi-bin> AllowOverride None Options FollowSymLinks (edit this line) </Directory>

John Burke is the editor of the NewsWire’s HiddenValue and net.digest columns and has more than 20 years’ experience managing HP 3000s.