net.digest - December 2000

 

Do we have a President-Elect yet? As I write this, in late November, we do not. Much of the off-topic conversations on HP3000-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 HPWorld, 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 HP3000-L's standing in the seti@home project (68th among 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. If something from these columns helped you, let me know. If you’ve got an idea for something you think I missed, let me know. If you spot something on HP3000-L and would like someone to elaborate on what was discussed, let me know. Are you seeing a pattern here? 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 HP3000-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 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 as per 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 2-3 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 3 areas:

The tracert program which is a 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? I'm trying to run it from a user with AM,AL,GL,OP,ND,SF,BA,IA,PM,MR,DS,PH and nothing happens?"

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. nslookup is very fast and efficient. Note that NETTOOL also requires NM capability.]

Combine this with Donna Garvarick'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?

Here's the question that prompted this thread:

"I'm trying to reference a 'regular' MPE file from Apache, and I'm getting an error telling me that the URL is not found. The web page is at /APACHE/PUB/htdocs on my system, and I'm trying to display a file with:

<a HREF="/ACCT/GRP/FILE">title</a>

"Any suggestions? It seems like this path should be correct. 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.

OK, now that you have Apache running, how do you display something interesting? There are several possibilities to consider.

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 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:

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>