ssh return codes in dcl script

[Thomas A. Williams]

I've got a DCL procedure that creates .COM files, pushes them over via scp, then executest them via SSH. Part of the .COM file grabs the return code and sticks in in a file, to SCP back, because that's the only way I could figure out how to get the status of the remote command. This works MOST of the time, but every now and then, either the file is empty, or never makes it back to the originating node. Has anybody seen this behavior? I'm running VMS 7.3-2 with TCP V5.4 ECO-7. and the SSH ECO 7E patch.

[James R. Ferguson]

Hi Thomas:

Since this is on a *VMS* operating system, you should post in the *OpenVMS* forum. This is HP-UX.

Ask a moderator to move this post by making a request here:

http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1236703

Regards!

...JRF...

[Thomas A. Williams]

I thought I was in the VMS networking list, sorry.

[Matti_Kurkela]

In any Unix-like environment, the return code of the SSH process will be the same as the return code of the remote process, or 255 if a connection error occurred.

I would expect it to work about the same in the VMS environment, unless VMS explicitly requires different behaviour.

MK

[Thomas A. Williams]

You would expect that. I wish it did. If it worked the way it does in Unix, I wouldn't have to do all this rigamarole.

[Jan van den Ende]

Thomas,

Matti wrote
>>>
or 255 if a connection error occurred.
<<<
and you reacted
>>>
You would expect that. I wish it did.
<<<

Well, THAT would upset ANY VMS status questioning.

In VMS, ANY numeric _ODD_ status is (maybe qualified) _SUCCESS_, and any EVEN status is (maybe severe) ERROR.

So, evaluating a status of value '255' would be considered _successfull_ , for which a call which
>>>
either the file is empty, or never makes it back to the originating node
<<<
does not really qualify.

So, the returm code NEEDS to be translated, or REALLY weird things will happen.

(unlike Unixes, where it is up to the programmer to choose which codes mean what to which program, VMS is (and has always been) much more structured in defining such things).

But, obviously, somewhere some things do not go as expected, meaning either the documentation is not respected, or you have found some documenting or programming bug. (And I do not have the facilities to investigate which one applies here)

Proost.

Have one on me.

jpe

[Richard Whalen]

The SSH protocol actually defines the ability for the remote server to return a status code, but does not document any particular interpretation of the status codes. Of course Unix people want the status codes to be like Unix status codes.

The protocol also specifies the ability to return signal values, which are well defined.

[Steven Schweda]

> This works MOST of the time [...]

I haven't seen anything like this, but that
proves little.

I've seen no evidence that the people who
wrote the SSH standards thought about any
non-UNIX-like OS, but I may have missed
something.

Depending on exactly what your requirements
are, you might be able to adapt something
like this:

alp $ define /user_mode sys$command nl:
alp $ ssh -o "batchmode yes" alp-l "pipe show defa ; write sys$output $status"
Authentication successful.


%X00030001:[SMS]

alp $ define /user_mode sys$command nl:
alp $ ssh -o "batchmode yes" alp-l "pipe show fred ; write sys$output $status"
Authentication successful.


\FRED\IVKEYW, unrecognized keyword - check validity and spelling
%X00038060

alp $

alp $ write sys$output f$message( %X00030001)
%CLI-S-NORMAL, normal successful completion

alp $ write sys$output f$message( %X00038060)
%CLI-W-IVKEYW, unrecognized keyword - check validity and spelling

(Your software is a bit newer than mine, so
you may not need all the quirk work-arounds.)

The terminal carriage control is pretty bad,
as usual, but it may easier to parse than to
look at. Or, write more to SYS$OUTPUT before
the important final status.

[Thomas A. Williams]

I'm doing something similar, except I write the status to a file, then scp that file back, so I can read it and determine what to do next. The procedure will run for a bunch of iterations, passing status back-and-forth fine, and then it'll randomly either not generate a status, or push back an empty file.

[Steven Schweda]

> I'm doing something similar, except [...]

Except it's different.

Knowing nothing, I'd guess that your status
file may not have been written and closed by
the time you try to fetch it. Feeding a
status value back through stdout should
avoid/evade a problem of that type.

There was a lot to be said for DECnet
task-to-task communication.

[Thomas A. Williams]

Thanks for the pointers. I just can't figure out how to read the output from the remote command into a local symbol. Can you give me an example?

[Jim_McKinney · Accepted solution]

How about extending Steve Schweda's prior example?

$ pipe ssh nodex "pipe show fred ; write sys$output $status" | -
search sys$pipe "%X" | ( Read Sys$Pipe x ; Define/Job x &x )
$ status := %'f$extract(0,8,f$element(1,"%",f$trnlnm("x","lnm$job")))'
$ deassign/job x
$ show symbol status

[Thomas A. Williams]

I figured out I could define SYS$OUTPUT to a file before the SSH, then go massage that, but this is MUCH better! Thanks! I'm still a novice to PIPE, but this example will go a long way.

[Jim_McKinney]

> $ status := %'f$extract(0,8,f$element(1,"%",f$trnlnm("x","lnm$job")))'

Correction - this command line should specify that the f$extract lexical take the 8 character string beginning at position 1 and not 0.

$ status := %'f$extract(1,8,f$element(1,"%",f$trnlnm("x","lnm$job")))'

[Thomas A. Williams]

It needs an "X" after the "%" too, but I didn't want to nitpick.

$ status := %X'f$extract(1,8,f$element(1,"%",f$trnlnm("x","lnm$job")))'

(Now if I could get an exit status from a remote command procedure, I'd be in heaven!)

[Thomas A. Williams]

got that working too!

[Thomas A. Williams]

I'm back about this problem again. My code works great when I create a command file to ship over and execute, but I'm trying to just do a one-line command, like change a password in AUTHORIZE, but for obvious reasons, I don't want to create a command file containing a password to ship over. When I try to get the return status of a DCL command, the procedure developed in this thread (reading the status in sys$pipe and putting it in a logical) doesn't seem to work. Has anyone done this before? Thanks for all the help!

[Hoff]

Trump the problem?

Have the procedure self-determine and set a pre-expired random password, and have the procedure communicate that value with the user. This could well apply a second-level trumping (assuming a web server is around, either Apache or a lighter-weight option), and run this whole password reset sequence as a CGI script, using https and email. (Here, you could conceivably use personally-issued certificates.)

Or go to certificates entirely, and get rid of passwords?

Or go to kerberos, and reset the password everywhere?

Or provide a generic and captive login on the host that performs the reset for the user. How you authenticate that user is an open (and local) question; these sorts of sequences can be secure, or can potentially be quite insecure.

As for the sequence itself, DCL can provide basic client-server; it's not great, but you can prompt for the sequence or the password over the link and then use symbol substitution directly. Here's an analogous (though DECnet-based) client-server sequence:

h71000.www7.hp.com/wizard/wiz_0159.html

[Thomas A. Williams]

Thanks for the suggestions, but I know how to do this with DECnet. It's SSH that's the problem. It would also be nice to have this ability to get the return code for remote commands in other cases, not just for setting passwords.

[Hoff]

I don't know of a way where this can be directly implemented in a reliable fashion; I'd use some sort of a variant or alternative. (Yes, that you're seeking ssh is obvious.)

One ssh-based approach might involve writing your own solution on top of the ssh transport; a so-called ssh subsystem. (fish is a variation on this.) Another approach would involve port forwarding. That's real work.

The generic difficulty here is the OpenVMS ssh daemon doesn't seem to be intended for this sort of thing; the sftp and scp pieces are present, but I don't know that HP supports other or user-written subsystems. (That written, the daemon does have port forwarding.) And that the OpenVMS ssh client is fairly weird and weak; it's definitely not what Unix users are accustomed to.

A solution akin to ssh -Y and its port forwarding (where the remote process does its thing, aiming its communications back over the link) would allow you to launch this stuff remotely, but you're still left to script part of this under bash or under DCL; on the client end.

As for a sign-up based approach, I've a fairly extensive and extensible user registration environment that's used on one of the public-access clusters; it's how you sign up for a username. Extending that to provide password reset wouldn't be a big effort. Full source code is available for download:

http://64.223.189.234/labsnotes/newuser102.zip

Cited alternative approaches are likely easier, and more reliable. DCL integration with TCP and with common IP applications is, well, lacking. As you've found.