For many mainframe systems programmers, trying to figure out how to install Linux, whether on the mainframe or midrange hardware, can be an extremely frustrating experience. It’s unlike anything you’ve ever done before. This article offers insight on Linux installation considerations and provides the general information you’ll need for a successful installation as well as what groups you’ll need to get involved. You won’t receive any “answers” from this article because each shop is too different for anything generic to fit well with your environment.
This article will provide you with enough insight to ask the answers, the job of installing Linux should be fairly straightforward. This article assumes you’ve already selected a Linux distribution. If that’s not the case, you should also read “Selecting a Linux or Linux/390 Distribution” in the August/September 2006 issue of z/Journal. Since this is z/Journal, our focus is on mainframe Linux, but we’ll also touch on other architectures where it makes sense.
First Things First
The temptation to get Linux up and running as a personal or “skunkworks” project is strong, but that’s the wrong thing to do. It’s likely that, when the other groups you should have involved find out, they’ll torpedo your project without blinking. Linux is, by definition, a “network operating system.” That means it will need to be on the network and it will be providing network services. Linux also is a strong platform from which intruders can launch further attacks. You absolutely don’t want to be seen as a loose cannon introducing all sorts of risks to your company.
So, get the right people involved upfront. This would include people responsible for:
- Network hardware
- Internet Protocol (IP) architecture
- Network administrators
- Storage administrators
- Security, including network security
- Mainframe hardware, including whomever is responsible for IOCP generations
- Midrange systems administration.
Sit down with your network and storage administrators and draw pictures, particularly in the case of mainframe Linux. Most network and storage administrators aren’t used to the idea of a mainframe needing more than one IP address per LPAR. If you’re going to be running Linux on z/VM (strongly recommended in most cases), that number could increase to hundreds.
Installing Linux is completely different from installing z/OS or z/VM. It’s possible to install z/VM from DVD, similar to midrange OS installs, but for mainframe Linux, you’ll absolutely need an “installation server,” with a usable TCP/IP connection to the system you’re going to be installing. This system will make the installation files available to your target system. It’s best if this is a Linux or Unix system. (You should expect untold hours of frustrating and ultimately fruitless effort unless you use a Linux or Unix server.) It’s possible to use the built-in File Transfer Protocol (FTP) server in your Hardware Management Console (HMC) to serve up the installation files, but remember, you must be able to reach that server from the system to be installed. Your network security team may have that route blocked, if for no other reason than they didn’t think anyone would ever need to access the HMC via FTP.
There will be several people who want to get started with Linux, but who may find they’re not getting any cooperation from the groups listed. If that happens, and you decide to proceed anyway, keep them informed of what you’re doing. It will keep things aboveboard, and as you make progress, they might decide they need to get involved simply to protect themselves from what they perceive as mistakes on your part.
Pick the Right Architecture
Where are you going to be running Linux? On Intel or other midrange hardware? In an LPAR? On z/VM? All three? What architecture is appropriate depends largely on the workload you think you’ll be running. Mainframes aren’t good candidates for CPU-intensive workloads. Just about any other architecture is faster for straight computational tasks. This is less true for the System z, but you’re still looking at pretty expensive CPU cycles compared to the alternatives. CPUintensive work should occur on Intel/ AMD or RISC hardware. This includes heavy program compilation, since compilers are CPU-intensive.