April 22, 2014
Making the best of an attack
The industry-wide provider for hosting TypePad is up, then down, then up again in the battle being waged with hacker Denial of Service attacks. It's the everyday host of the Newswire's blog, so you'll have some trouble getting onto it to read us. It's been five days, and everybody is getting frustrated. This sort of an outage would be getting a 3000 pro's IT recommendations reviewed. Not even deadly storms have knocked out many a 3000 this long.
This is the genesis of good experience, however. It's giving us a good reason to build out an important new branch of the 3000 Newswire's services. Story for Business, which as of this week is a simple Tumblr blog, is giving our readers stories about MPE-related news.
If you go far enough back, you'll recall an era of our history where we hosted our website from an HP 3000 Series 928. We worked with HP's MPE implementation of Apache/iX, until the lags and differences -- imagine an FTP server which didn't include all protocols -- pushed us onto Linux machines. Those machines at 3k Associates continue to perform.
So we're using the formula this week suggested by MPE veteran Vladimir Volokh. Clearly, this is a bad experience that our sponsors and readers are weathering. Vladimir says, "We get asked, 'how do you come up with so much good experience for us?' Because, good experience comes from bad experiences."
Pivital Solutions: Your complete
HP e3000 resource
April 21, 2014
A week-plus of bleeds, but MPE's hearty
There are not many aspects of MPE that seem to best the offerings from open source environments. For anyone who's been tracking the OpenSSL hacker-door Heartbleed, though, the news is good on 3000 vulnerability. It's better than more modern platforms, in part because it's more mature. If you're moving away from mature and into migrating to open source computing, then listen up.
Open source savant Brian Edminster of Applied Technologies told us why MPE is in better shape.
I know that it's been covered other places, but don't know if it's been explicitly stated anywhere in MPE-Land: The Heartbleed issue is due to the 'heartbeat' feature, which was added to OpenSSL after any known builds for MPE/iX.
That's a short way of saying: So far, all the versions of OpenSSL for MPE/iX are too old to be affected by the Heartbleed vulnerability. Seems that sometimes, it can be good to not be on the bleeding edge.
However, the 3000 IT manager -- a person who usually has a couple of decades of computing experience -- may be in charge of the more-vulnerable web servers. Linux is used a lot for this kind of thing. Jeff Kell, whose on-the-Web servers deliver news of 3000s via the 3000-L mailing list, outlined repairs needed and advice from his 30-plus years of networking -- in MPE and all other environments.
April 18, 2014
Denying Interruptions of Service
For the last 18 hours, the 3000 Newswire’s regular blog host TypePad has had its outages. (Now that you're reading this, TypePad is back on its feet.) More than once, the web resource for the Newswire has reported it’s been under a Denial of Service attack. I’ve been weathering the interruption of our business services up there, mostly by posting a story on my sister-site, Story for Business.
We also notified the community via Twitter about the outage and alternative site. It was sort of a DR plan in action. The story reminds me of the interruption saga that an MPE customer faces this year. Especially those using the system for manufacturing.
MANMAN users as well as 3000 owners gathered over the phone on Wednesday for what the CAMUS user group calls a RUG meeting. It's really more of an AUG: Applications User Group. During the call, it was mentioned there’s probably more than 100 different manufacturing packages available for business computers which are like the HP 3000. Few of them, however, have a design as ironclad against interruption as the venerable MANMAN software. Not much service could be denied to MANMAN users because of a Web attack, the kind that’s bumped off our TypePad host over the last day. MANMAN only employs the power of the Web if a developer adds that interface.
This is security through obscurity, a backhanded compliment that a legacy computer gets. Why be so condescending? It might be because MPE is overshadowed by computer systems that are so much newer, more nimble, open to a much larger world.
They have their disadvantages, though. Widely-known designs of Linux, or Windows, attract these attempts to deny their services. Taking something like a website host offline has a cost to its residents, like we reside on TypePad. Our sponsors had their messages denied an audience. In the case of a 3000, when it gets denied it’s much more likely to be a failure of hardware, or a fire or flood. Those crises, they’ve got more rapid repairs. But that’s only true if a 3000 owner plans for the crisis. Disaster Recovery is not a skill to learn in-situ, as it were. But practicing the deployment it’s about as popular as filing taxes. And just as necessary.
April 16, 2014
How to tell which failed drive is which LDEV
I have someone at a remote site that may need a drive replaced. How can I tell which drive is a certain LDEV?
Keven Miller, who at 3kRanger.com describes himself as "a software guy with a screwdriver," answers the question -- for those that don't have the benefit of seeing an amber light on a failed drive.
Well, for me, I run SYSINFO.PRVXL.TELESUP first. Then you have a map of LDEV# to SCSI path. Next, you have to follow your SCSI path via SYSINFO.PRVXL.TELESUP.
From the example above, on my 928, 56/52 is the built-in SCSI path. Each disk has a hardware selection via jumpers to set the address of 0 to 6. (7 is the controller). You would have to inspect each drive, which could be one of the two internal ones, or any external ones.
April 15, 2014
Not too late to register for RUG meet
The CAMUS manufacturing app user group has a meeting tomorrow (April 16), starting at 10:30 Central time. An email to organizer and CAMUS RUG officer Terri Lanza will get you a dial-in number for the event. Birket Foster of MB Foster, one of the community's longest-tenured migration and sustainability vendors, will brief attendees on his perspective of the CHARON HPA, the HP 3000 hardware emulator.
CAMUS also has a Talk Soup as part of its dial-in agenda that runs through noontime. They only host their call twice a year, and it's a worthwhile endeavor to check in with others who are running HP 3000s in production mode.
Contact Lanza for your dial-in at [email protected]
April 14, 2014
HP did keep MPE's CALENDAR up to date
Last week I lumped a error of omission by users into the basket of Hewlett-Packard's 3000 miscalculations. I made my own mistake by doing that. In part of an article about the 3000 user's longer view, I figured the miscue that sparked programming for the Y2K crisis fell into HP's lap. After all, the date handling in MPE was built to break down in 2028. Surely the valiant reworking of two-digit year representation came from a shortcoming out of HP's labs as well, I reckoned.
Vladimir Volokh called me to correct that concept. There was much work to do in our community to salvage good computing in the years leading up to 2000. But that work was the result of developers repairing their own mis-estimations of the durability of 3000 applications. Four-digit representations of years were possible from the very first month the 3000 went into serious duty. (That month happens to be just about 40 years ago, as of this month.) The users of the system, and commercial developers, just didn't see the need for using precious storage to represent four complete digits during 1974.
Four decades have brought the 3000's dating capability within sight of the end-date of accuracy. In the same way as 2000 was a community-wide roadblock, Volokh said that, just like age 70 is the new 60, "2028 has become the new Y2K."
The year 2028 is notable for customers who don't plan to leave the HP 3000. It's the year when timestamps stop being accurate, because the CALENDAR intrinsic in MPE/iX only uses 7 bits to store year information.
For those HP 3000 applications using CALENDAR, HP has advised you use the newer HPCALENDAR in your apps. The newer intrinsic, polished up in 1998 with version 6.0, extends the 3000 application's date accuracy to more than five decades beyond the 3000's inception. 2027 will be the last year to accurately generate timestamps in the 3000's filesystem. HPCALENDAR goes further, for whatever that's worth.
An HP advisory explained the differences, at least in part:
The original MPE timestamp format was that used by the CALENDAR intrinsic, a 16 bit quantity allowing 9 bits for the day of the year and 7 bits for the year, added to 1900. Since the largest number represented by 7 bits is 127, this format is limited to accurately storing years up to 2027.
The newer HPCALENDAR intrinsic uses a 32 bit quantity, allowing 23 bits for the year, since 1900 and the same 9 bits for the day of the year. This format provides a significantly longer period of timestamp accuracy.
April 11, 2014
Again, the 3000's owners own a longer view
Heartbleed needs a repair immediately. Windows XP will need some attention over the next three years, as the client environment most favored by migrating 3000 sites starts to age and get more expensive. XP is already "off support," for whatever that means. But there's a window of perhaps three years where change is not as critical as a repair to Heartbleed's OpenSSL hacker window.
Then there's MPE. The OS already has gone through more than a decade of no new sales. And this environment that's still propping up some business functions has now had more than five years of no meaningful HP lab support. In spite of those conditions, the 3000's OS is still in use, and by one manager's accounting, even picking up a user in his organization.
"Ending?" Tim O'Neill asks with a rhetorical tone. "Well, maybe MPE/iX will not be around 20 years from now, but today one of our people contacted me and said they need to use the application that runs on our HP 3000. Isn't that great? Usage is increasing!"
Pondering if MPE/iX will be around in 20 years, or even 13 when the end of '27 date bug surfaces, just shows the longer view the 3000 owner still owns. Longer than anything the industry's vendors have left for newer, or more promising, products. My favorite avuncular expert Vladimir Volokh called in to leave a message about his long view of how to keep MPE working. Hint: This septuagenarian plans to be part of the solution.
April 10, 2014
Heartbleed reminds us all of MPE/iX's age
The most wide-open hole in website security, Heartbleed, might have bypassed the web security tools of the HP 3000. Hewlett-Packard released WebWise/iX in the early 2000's. The software included SSL security that was up to date, back in that year. But Gavin Scott of the MPE and Linux K-12 app vendor QSS reminds us that the "security through antiquity" protection of MPE/iX is a blessing that's not in a disguise.
WebWise was just too late to the web game already being dominated by Windows at the time -- and even more so, by Linux. However, the software that's in near total obscurity doesn't use the breached OpenSSL 1.0.1 or 1.0.2 beta versions. Nevertheless, older software running a 3000 -- or even an emulated 3000 using CHARON -- presents its own challenges, once you start following the emergency repairs of Heartbleed, Scott says.
It does point out the risks of using a system like MPE/iX, whose software is mostly frozen in time and not receiving security fixes, as a front-line Internet (or even internal) server. Much better to front-end your 3000 information with a more current tier of web servers and the like. And that's actually what most people do anyway, I think.
Indeed, hardly any 3000s are used for external web services. And with the ready availability of low-cost Linux hosts, any intranets at 3000 sites are likely to be handled by that open-sourced OS. The list of compromised Linux distros is long, according to James Byrne of Harte & Lynne, who announced the news of Heartbleed first to the 3000 newsgroup.
April 09, 2014
How SSL's bug is causing security to bleed
Computing's Secure Sockets Layer (SSL) forms part of the bedrock of information security. Companies have built products around SSL, vendors have wired its protocols into operating systems, vendors have applied its encryption to data transport services. Banks, credit card providers, even governments rely on its security. In the oldest days of browser use, SSL displayed that little lock in the bottom corner that assured you a site was secure -- so type away on those passwords, IDs, and sensitive data.
In a matter of days, all of the security legacy from the past two years has virtually evaporated. OpenSSL, the most current generation of SSL, has developed a large wound, big enough to let anyone read secured data who can incorporate a hack of the Heartbeat portion of the standard. A Finnish security firm has dubbed the exposed hack Heartbleed.
OpenSSL has made a slow and as-yet incomplete journey to the HP 3000's MPE/iX. Only an ardent handful of users have made efforts to bring the full package to the 3000's environment. In most cases, when OpenSSL has been needed for a solution involving a 3000, Linux servers supply the required security. Oops. Now Linux implementations of OpenSSL have been exposed. Linux is driving about half of the world's websites, by some tallies, since the Linux version of Apache is often in control.
One of the 3000 community's better-known voices about mixing Linux with MPE posted a note in the 3000 newsgroup over the past 48 hours to alert Linux-using managers. James Byrne of Harte & Lyne Ltd. explained the scope of a security breach that will require a massive tourniquet. To preface his report, the Transport Layer Security (TLS) and SSL in the TCP/IP stack encrypt data of network connections. They have even done this for MPE/iX, but in older, safe versions. Byrne summed up the current threat.
There is an exploit in the wild that permits anyone with TLS network access to any system running the affected version of OpenSSL to systematically read every byte in memory. Among other nastiness, this means that the private keys used for Public Key Infrastructure on those systems are exposed and compromised, as they must be loaded into memory in order to perform their function.
It's something of a groundbreaker, this hack. These exploits are not logged, so there will be no evidence of compromises. It’s possible to trick almost any system running any version of OpenSSL released over the past two years into revealing chunks of data sitting in its system memory.