Stdio problem when moving non-i5 user to native processes via ssh

3 09 2009

We needed to move non-i5 internal users to native i5 processes. For this to work effectively I set links to processes under the QShell because it provides direct native execution and then set up PASE scripts to run via ssh. A number of IBM documents describe setting up ssh so that users need never see a native i5 screen.

Example application – SSH

OpenSSH: How to Stop SSH from Creating Thousands of Job Logs

IBM Redbook
Securing Communications with OpenSSH on IBM i5/OS, July 2006

‘Qshell and OpenSSH for IBM System i’ by Bob Bittner dated 15-May-2007
http://www.omniuser.org/Downloads/Qshell-OpenSSH-OMNI.pdf
Note: This paper is an excellent introduction to the QShell.

The problem is that QP2SHELL does not properly handle stdio for the QShell and QP2TERM cannot be used because the job running under the SSH subsystem is not interactive. Using QSH CMD(‘usr/sbin/sshd’) as described in Bob Bittner’s document in place of ‘CALL PGM(QP2SHELL) PARM(”/QOpenSys/usr/sbin/sshd”)’ – note that ” is two single quotes – , does correctly handle QShell stdio. So, changing the follwing

CRTJOBD JOBD(SSHLIB/SSHJOBD) JOBQ(SSHLIB/SSHJOBQ)
TEXT(‘Job description for SSHD autostart’) USER(SSHDUSR)
RQSDTA(‘CALL PGM(QP2SHELL) PARM(”/QOpenSys/usr/sbin/sshd”)’)

to

CRTJOBD JOBD(SSHLIB/SSHJOBD) JOBQ(SSHLIB/SSHJOBQ)
TEXT(‘Job description for SSHD autostart’) USER(SSHDUSR)
RQSDTA(‘QSH CMD(”/QOpenSys/usr/sbin/sshd”)’)

resolves the problem. The command ‘QSH CMD(”/usr/sbin/sshd”)’ may also be used as both /QOpenSys/usr/sbin/sshd and /usr/sbin/sshd link to the same executable.

One additional problem remains; how to get the stdio from the various environments, native, QSHELL and PASE to all display in the ssh terminal window. This is accomplished via either the .env or .profile file. See http://www.uic.edu/depts/accc/software/unixgeneral/unixcust.html and http://publib.boulder.ibm.co/infocenter/systems/scope/aix/index.jsp for additional information regarding these files. To obtain the needed environmental variables and their settings, invoke PASE using CALL QP2TERM from a native command line and enter env. Use the output from the env command for the .profile file since the installed ssh client uses the BSH shell. Do not include variables that will result in conflicts with the shell such as the SHELL, LOGNAME, LANG or HOME.

I have implemented and tested this on both V5R3 and V5R4 systems.

It should be noted that there are many instances where the system command from PASE should be used to execute native processes rather than using QShell. In fact, I used both methods in the PASE shells implemented for this project.

Some may also find the following IBM Software Technical document, OpenSSH: Configuring Server / Client, helpful.

Advertisements




The Real Problem with Enterprise Job Scheduling

18 08 2009

As a brand new product manager, I recently learned in product management 101 that if you identify the problem, the problem is pervasive, and enough companies are willing to pay to solve the problem you are on the right track for success. It seems so simple.

Market + Problem + Solution = SUCCESS

This brings me to my first product management challenge: What if the problem is not correctly identified?

What I have learned in my 20+ years in the enterprise job scheduling market is that sometimes the true problem is misunderstood. Time after time I have seen companies try to fix the wrong problem with the wrong solution only to find out after they fail. This is a very costly step and one that should be avoided.

In the past I have witnessed this from the technical side and often wandered why anyone would put themselves and their companies through a painful costly implementation of a solution that fails to solve the problem. Now, when I see the same behavior from the view of the product manager, I am even more perplexed!

The problem that companies have with enterprise job scheduling is not the need for enterprise scheduling. The real problem is the complexity and cost of the traditional solutions. Since the market thinks the problem stops at the need for enterprise scheduling, it is only logical to try to solve this need from one of the big traditional job scheduling vendors. This too often leads to failure because the real problem of cost and complexity associated with their solutions is not addressed.

So first, the challenge is to educate the market of the true problem: the cost and complexity of traditional solutions for enterprise job scheduling.

If you had a way to solve the problem of complexity and cost associated with traditional enterprise scheduling solutions wouldn’t you give it a try? I hear a resounding yes; it only makes sense!

I came to work at Stonebranch 8 years ago because I saw that they provide a solution to the real problem. The solution is simple, makes sense, and is easy to implement and deploy which can be seen by the long list of enterprise customers. However, we don’t always meet our customers in time to help them avoid the long and arduous step of trying to implement traditional enterprise scheduling but are often at the end helping to pick up the pieces. This pains me to no end!

So how do you educate the market that the real problem is the cost and complexity associated with traditional enterprise job scheduling products and there is a proven solution available?

a) More Customer testimonials
b) Educate the analyst to redefine the definition of enterprise scheduling
c) Keep plugging away at the market, one customer at a time
d) Schmooze the analysts
e) Forget it and get out while you can. It’s just too painful to watch companies go down the long, hard, costly, wrong path!

Other options?

Stonebranch Agents reduce maintenace and costs over native agents from your scheduling and workload management application provider