December might bring holidays, but 3000 newsgroup readers took little time away from posting on the Internet, if the volume of traffic generated could be used as a barometer. More than 1300 messages crossed in the month, covering topics as perennial as TurboIMAGE and as novel as new Internet security needs for 3000s using inbound telnet access.

The group was spared any mass mailing of binary Christmas tree cards, (remember, attachments go to your friends, but only after you’ve asked permission to tie up their mail reader for 20 minutes with that whopping big file). Even without the holiday packages, 3000-L readers enjoyed PC error messages written as haiku poems, a note celebrating the 50th anniversary of the transistor, and a tongue in cheek complaint about New Year’s messages that parodied an earlier complaint about Santa postings. Savvy readers simply warmed up their delete keys instead of complaining.

Emulation across the Internet

It takes a new user to ask an obvious question. Peter Navin announced himself a newcomer from the world of NT and posted a message that asked, “Can remote clients running terminal emulation software (Reflection) log into a HP 3000/MPE server across the Internet and get a command prompt, as apposed to having to dial up directly to the server? In other words, the clients are connected to the Internet via their own ISPs and the HP 3000 server is connected to the Internet via a dedicated DSL or ISDN line, and the clients somehow connect to the server and logon. Windows NT has Point to Point Tunneling Protocol that enables you to create your own LAN over the internet. Does MPE have anything like that?”

Answers indicated the growth of HP 3000 networking capability. Ted Ashton outlined the terminal emulator players by saying, “MPE will support this sort of thing via NS/VT or Telnet. Reflection will talk either of these with a separately-purchasable network option. Alternatively, you could either get MiniSoft’s MS92 which has them both built in (for a significantly cheaper price than Reflection, last I checked) or you can get AICS’ QCTerm which has Telnet built in (for an even cheaper price — it’s free).”

Mel Rees added that “No, MPE does not have VPN, but if you have an NT on your network it can do the VPN stuff and you can still log onto the HP 3000. Although the jury is still out on how ‘safe’ VPN really is, I use it quite regularly.” Joe Geiser of CSI Business Solutions made note that “all terminal emulators will run on a client that has a Dial-Up Adapter with VPN, through an NT Server that has PPTP enabled. I do it all the time while on the road. Ensure that the client has Windows 95 (OEMSR2) or Win98, both of which have VPN support.”

The question spurred another, as they often do on the newsgroup. Is there a known way to have the HP 3000 initiate a connection through a firewall to a known IP address, to allow that IP address to log on to the HP 3000? Jeff Kell, curator of the group, reported that “both telnet and NS/VT must be initiated from the client side to a listening port on the server; if you ‘open’ a connection to a known IP address, the known address must have something listening on the expected port first. The client side of the connection is ‘proactive,’ and I don’t know of a way to make it ‘reactive’ with respect to an open.”

“You may be able to (depending on firewall) map an outside IP address and some special port number with a static translation to the 3000’s address and telnet (or NS/VT) port on the inside. In this manner, you could for example:

telnet outside.hp3000.address 999

and have the firewall associate:

outside.hp3000.address:999=inside.hp3000.address:23

so that the telnet would be ‘mapped’ by the firewall into a telnet request into your 3000. If you want to restrict access to this port to specific outside hosts, the firewall will have to handle those criteria. I don’t know, offhand, of a way for the 3000 to participate in which outside hosts it wants to accept connections from.”

Mike Hornsby illustrated the benefits of proxy servers and firewalls, noting that “many firewall/proxy servers (such as Winproxy) allow for ‘Mapped Links’ that allow it to map a port to other IP addresses and port. So if you map ports 1537 and 1570 to your HP 3000 IP address, you will in effect put your HP 3000 on the Internet for VT access. (The same can be done for telnet on port 23) Note that you can daisy-chain these mapped links to allow a VT or telnet session from behind one firewall to connect to an HP 3000 behind another.”

Internet security holes to plug

While a persistent message to embrace telnet on 3000s floated about the list, other posters warned the new connection deserves some new security measures. Chris Bartram of 3k Associates (and the NewsWire’s Webmaster) noted that “I’d never recommend just “hooking up” a production 3000 (or any system for that matter) to the Internet without taking a serious look at your security capabilities.”

“If you don’t have some additional security or a firewall, don’t do it. Whereas a phone line makes you vulnerable to a (limited area of) phone hackers, few of them will dial long distance to try to break into a system anymore. On the other hand, an Internet connection is the equivalent of a local phone call from every hacker/miscreant on earth; 24 hours a day, 365 days a year.”

“Now that the 3000 supports inbound telnet connections, any ol’ box on the net can get to your colon prompt. Either get a firewall or add some serious security to your box. Not doing so borders on negligence (maybe just OVER the border!). Record IP addresses for all logons. Ask HP to add it to the console messages (also for invalid password attempts!). I put it on the enhancement list long ago. Restrict certain logons (like MANAGER.SYS) to specific network addresses (or hard/ nailed logical device numbers for DTC ports ..You can do that with third-party packages, or via free scripts — ask me for a sample if you need help.)” Contact Bartram at rcb@3kassociates.com.

Users on the list began to specify what extra telnet security they wanted from future MPE/iX versions, although some third parties and HP are in the business of selling it already. Jeff Kell noted that the 3000’s telnet services were engineered with speed in mind: “HP chose to implement telnet as one of those infernal “internal” services to inetd, where you can’t specify the actual socket handler as you can in any Unix inetd. But we trade off performance; by internalizing telnet they apparently took some privileged liberties to optimize the performance and reduce the number of processes required to establish the connection.” As the work load in the HP 3000 division rises to meet IA-64 plans, such requests will be fulfilled far earlier by third-party companies who stand to make a profit off the work.

CIUPDATE: on or allowed?

A programmer asked for help on the difference between TurboIMAGE’s Critical Item Update’s CIUPDATE=ON and CIUPDATE =ALLOWED. Mike Hornsby, who wrote the TurboIMAGE Handbook back in the 1980s, replied that “CIUPDATE=ON means all processes can CIUPDATE, and CIUPDATE=ALLOWED (combined with DBcontrol mode 5) means this process can CIUPDATE. Also, some backward compatibility [issues] arise in the CIUPDATE=ON mode.”

Jim Phillips explained those backward compatibility issues; “It is only significant when you have older programs that rely on IMAGE to not allow critical item updates; that is, it was part of the program design to rely on an IMAGE ‘feature’ instead of doing the checking itself. In this case, enabling global CIUPDATE via the CIUPDATE=ON setting will cause such programs to malfunction by performing a DBUPDATE when they used to fail.”

“If you’re not sure if you have any programs that fall into that category, then you can do what we did and use CIUPDATE=ALLOWED. Then you can code new programs (or update older ones) to use the new CIUPDATE functionality by enabling it via the DBCONTROL intrinsic.”

Get off the 3000, and quick

A reader asked for ways to get more than 1,000 people offline quick on an HP 3000, and in short order, hasty exits were devised. “NSCONTROL STOP, and they are all off your system,” offered one, although Netbase and Shareplex 3000s would have trouble with such a simple plan. Scott McClellan of the CSY lab offered his perspective, saying any brute force solution would be like stampeding exits at a ball game:

“It is much faster to shutdown a very large number of users a few at a time. On old hardware, with not enough memory (us lab guys often have to test on whatever is available), a brute-force =LOGOFF with 1200 users could take (several) hours. An organized shutdown (e.g. abortjob 100 users, wait 2 minutes) would only take like 20-25 minutes. I am sure that the results are different if you are on a current high-end system (which you should be if you have more than 1,000 users) and max memory, but the theory is almost certainly still valid.”