Networking and Interoperability

The days of IT operations running just UNIX or another single platform are long gone. UNIX is still very much in use but Linux has become a major player, and both Windows and Linux are the dominant forces in the data center, with many IT operations optimized for Windows and Linux interoperability. The big challenge lies in actually getting these different operating systems and perhaps others to co-exist successfully.

At Transformix, dealing with systems that interoperate is now a routine. The most common situations involve network printing or shared database servers. However, more and more we are seeing the use of shared directories, and remote program execution. The most common broad categories of work we do involve these key areas:

  • UNIX to Windows integration
  • Linux to Windows integration
  • HP 3000 MPE to UNIX integration
  • HP 3000 MPE to Windows integration
  • Web integration

Not surprisingly, certain standard products are typically used regardless of platform. These include OpenSSH and CIFS (Samba) among others. What follows is an example of one such solution we have implemented recently.

N between HP-UX and Windows Example

Introduction

The Customer’s direct marketing organization uses Escalate Retail software (also known as Ecometry) for most of its Mail Order and Catalog System related business functions. This Ecometry software is packaged vendor supplied software. At this customer it is supplemented by in-house written Surround Code that consists of a combination of COBOL code, JCL and Suprtool scripts.

The central repository for data in the Ecometry application is an Oracle database consisting primarily of Escalate Retail provided schemas supplemented by customer provided schema. The primary interface between Ecometry application programs and Surround Code is mostly done through the Ecometry provided Oracle database tables. In addition to the data stored in Oracle, some flat files are used by the application. These flat files are exchanged between Ecometry and Surround Code.

The Ecometry packaged application is self contained and, as expected, comes with programs and scripts that provide the core functionality used by The customer. The Surround Code also consists of mostly jobs that run independent of Ecometry programs. However, some jobs and/or scripts invoke a mixture of Ecometry programs and Surround Code programs.

The situation described above presents two requirements for interoperability between Ecometry standard processing and Surround Code; they are:

  1. The exchange of flat files.
  2. Use of Ecometry programs in Surround Code and scripts.

On the customer HP 3000 a single computer was used for all processing. This simplifies interoperability between Ecometry standard code and Surround Code. However, in the migrated environment, multiple application servers and a separate database server are used. The new deployment architecture presents additional challenges to interoperability. Moreover, in order to overcome some technical challenges in the migration of the customer Surround Code, a solution described in this document allows the Code, migrated by Transformix, to interoperate with the Ecometry application migrated by Escalate Professional Services.

This solution provides an interim way to seamlessly use an HP-UX computer for running Surround Code that works in conjunction with a Windows based Ecometry application. Both computers are on the same network, they share a common set of files and the same Oracle database. The solution provides for remote execution of Ecometry standard programs running on Windows to be invoked from HP-UX with standard out results made available immediately to other programs that run on the HP-UX computer.

The Solution

Overview

On the same network there are three categories of servers; Ecometry Database Server, Ecometry Application Server and Surround Code Server.

Shared Directory

The shared directory is accomplished by sharing the D:\ECOMETRY\ECOMLIVE\PUB folder on the Ecometry Application Server. The Surround Code Server mounts the shared folder and then all files written on the Ecometry Application Server are available to the Surround Code Server and all files written on the Surround Code Server are available to the Ecometry Application Server.

Remote Program Execution

As was mentioned previously, the Surround Code Server will sometimes need to run programs that execute on the Ecometry Application Server with standard out coming back to the Surround Code Server. This is accomplished using the following steps:

  1. Microsoft Services for Unix Applications (SUA) is installed on the Application Server.
  2. OPENSSH is installed in the SUA environment.
  3. OPENSSH is started on the Application Server.
  4. A public key is created on the Surround Code Server.
  5. The Surround Code Server public key is copied to the Application Server and it is placed in the authorized-keys file of the appropriate user on the Application Server. This makes it possible to login to the Application Server from the Surround Code Server with no password.
  6. A command can now be executed on the Application Server from the Surround Code server with a command like “ssh user@appserver ls” with the stdout output coming back to the Surround code server.

Technology used to implement the Proposed Solution

Microsoft SMB, CIFS and SAMBA

The Server Message Block (SMB) Protocol is a network file sharing protocol, and as implemented in Microsoft Windows is known as Microsoft SMB Protocol. The set of message packets that defines a particular version of the protocol is called a dialect. The Common Internet File System (CIFS) Protocol is a dialect of SMB. Both SMB and CIFS are also available on VMS, several versions of Unix, and other operating systems.

CIFS or SMB is the primary file sharing technology used between Microsoft Windows computers. HP-UX provides a CIFS implementation compatible with Windows 2003 R2.

Remote Execution

Subsystem for UNIX-based Applications (SUA)

Subsystem for UNIX-based Applications (SUA) is the next-generation of Microsoft’s POSIX subsystem, similar to the Interix subsystem that formerly shipped with Windows Services for UNIX 3.5 or previous POSIX subsystems that shipped with Windows 2000 and NT 4.0. Subsystem for UNIX-based Applications and its accompanying utilities provide you with an environment that resembles any other UNIX system. It also includes case-sensitive file names, job control, compilation tools, and the use of over 300 UNIX commands and utilities and shell scripts. Because the Subsystem for UNIX-based Applications is layered on top of the Windows kernel, it offers true UNIX functionality without any emulation.

OPENSSH

Transport uses the SUA Community version of OpenSSH to support its administrative functions. Microsoft® does not provide SSH support with SUA, and the remote shell (rsh) service included with SUA has limitations that make it unsuitable for GPFS. Interop Systems Inc. hosts the SUA Community Web site (http://www.interopsystems.com/community/), which includes a forum and other helpful resources related to SUA and Windows/UNIX interoperability.

Passwordless Login with Public Key Exchange

Logging into another machine without a password is extremely convenient. This is in part what made the Berkeley R commands so popular and useful. But no password is also very dangerous because someone could then easily pretend to be another user. If that other user is a system administrator and the person using that account is a bad guy, then the situation can be quite dire. Lost or changed data, company secrets exposed to competitors or your machine being used to attack other machines or even host unwanted material that could get you in serious trouble with the law.

With Secure Shell a passwordless login can happen, but it is done with an exchange of secure keys taking the place of the password. Authorization happens, but without the need to verify the authorization with the user. The secure keys are called “public keys”.

Using SSH for remote commands

Most people use SSH to login to servers or boxes remotely. However, you can also use SSH to issue commands on remote servers without logging in if you have prepared the environment using the above described passwordless login technique.

The following example shows you how to view a list of files in a directory of a Windows computer.

  • ssh username@winapp /usr/contrib/win32/bin/dir