PLINK on OpenVMS

[cdan]

I have the following setup of servers: several Itaniums with OpenVMS 8.3-1H1 with no connection between them, so no possibility of using SYSMAN.
This can't be modified as it is a requirement from customer to have the servers separated.
I can only ssh (no telnet) to each server.

I am using PLINK as a replacement for SYSMAN but I have the following annoyances:
-I cannot use input file with commands (-m). The error is always
%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
\TIME
SHO\
IF I add a "$" is the same error:

%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\$\

The only way I can run commands is as an argument to the plink command, between double quotes.
Example:
C:\Putty>plink -l myuser -pw mypass server "show time"
-If I need to use doublequotes inside doublequotes it's more complicated as I have to escape them:
C:\Putty>plink -l myuser -pw mypass server "write sys$output f$getsyi("""boottime""")"

-If I want to run multiple commands, it can be very long piped commands

Anyone is using PLINK with VMS and found a solution for these issues?
Or any other software able to run multiple commands from windows to VMS server via SSH?

The purpose is just automation of some administrative tasks, from basic commands to more complex (installation of patches, for example).

[Steven Schweda]

I know nothing, but ...

Why not use a plain-old interactive SSH
session?

> -I cannot use input file with commands (-m).

With my weak psychic powers, I can't see
what's in your file. Plink apparently has a
"-v" ("show verbose messages") option, which
might offer some clues about what the program
is doing.

> -If I need to use doublequotes inside
> doublequotes it's more complicated [...]

As I recall, _you_'re the one who dragged the
Windows shell into this task.

> The purpose is just automation of some
> administrative tasks, from basic commands
> to more complex (installation of patches,
> for example).

That description is a bit too vague to reveal
why Plink instead of SSH. A DCL procedure on
the remote VMS system might be easier to
manage than a DCL procedure on the local
Windows system.

I don't run it (or much else) on Windows, but
you might find Kermit scripting useful in a
case like this.

[RBrown_1]

I know nothing either, but openVMS Management Station (http://h71000.www7.hp.com/openvms/products/argus/index.html) is supposed to be good for something. Is it this?

[cdan]

Steven, thank you for your answer.
Here are the details you asked:
> Why not use a plain-old interactive SSH
session?
Because I'd like to avoid connecting many times and doing the same think all over again. I also looked into the possibility to automate the SSH login without password using public hostkey, but unfortunately this is not acceptable by my client's security.
Sometimes I need to generate the output from all servers in one file then import data in excel (for example CSV formatted data like free space on disks, output from monitoring of CPU and other capacity planning data).

>A DCL procedure on
the remote VMS system might be easier to
manage than a DCL procedure on the local
Windows system.

You're right and that's how I do most of the repeating stuff, like capacity reports.
The -m option will be useful for various commands which I might need one day or another. It's easier to modify one file on windows than copy the same file on x servers. And anyway, it's strange that -m option is working on a linux box (I tried it), but not on VMS. Right now I am more interested about the theoretical possibility of using the -m and not about some specific script.

With -v, the output is not much more helpful.
Example with file commands.txt containing:
show time
show system/noprocess


Looking up host "10.10.10.2"
Connecting to 10.10.10.2 port 22
Server version: SSH-2.0-3.2.0 SSH Secure Shell OpenVMS V5.6 VMS_sftp_version 2
We claim version: SSH-2.0-PuTTY_Release_0.60
Using SSH protocol version 2
Using Diffie-Hellman with standard group "group1"
Doing Diffie-Hellman key exchange with hash SHA-1
Host key fingerprint is:
ssh-dss 2048 d0:ed:5b:8b:35:f2:6c:5e:df:4b:08:29:31:48:bd:34
Initialised AES-256 CBC client->server encryption
Initialised HMAC-SHA1 client->server MAC algorithm
Initialised AES-256 CBC server->client encryption
Initialised HMAC-SHA1 server->client MAC algorithm
Using username "system".
Sent password
Access granted
Opened channel for session
Started a shell/command

%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
\TIME
Server sent command exit status 0
Disconnected: All channels closed

As far as I experimented, the spaces and the CR/LF from the commands.txt are not parsed correctly.

Another example: a file containing only the following line, will have the expected output:
mc authorize show system
But if the file contains following 2 rows:
mc authorize show system
tcpip show services

This will fail with the error:
Started a shell/command

%CLI-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
\BR
Server sent command exit status 0

About Kermit I don't know, I will have to search.

[cdan]

RBrown, thank you, I downloaded the Alpha version and I will test it.

[John Gillings]

I'm not familiar with "plink", but the issue you describe sounds like your command string is being unquoted somewhere along the path, possibly multiple times. Similar things happen with plain old RSH commands.

You may be able to simplify things by writing a DCL jacket around "plink" which can build the appropriately quoted string to pass to plink. It could also hide the username, password and node list. Something like:

$ MYPLINK YOUR COMMAND HERE

Within the constraints of the DCL 8 parameter limit (16 on V8.4), you might not need to put quotes around the whole command. Concatenate the parameters delimited with spaces, then walk along the resulting string doubling up double quotes as needed, then quote the whole string and feed it to plink.

Note there may be a 256 character limit to the whole command string, as there is with RSH (it's actually something weird like 253). If your very long piped commands are longer than the limit, you may have to generate a temporary command procedure, ship it across to the other node and have it executed.

[Jeremy Begg]

You said you have "several Itaniums with OpenVMS 8.3-1H1 with no connection between them, so no possibility of using SYSMAN."

Does this mean that these servers have no network connectivity between them at all, i.e. you can't use FTP or any other TCP/IP service between servers?

If they *do* have TCP/IP connectivity between them you should be able to configure DECnet-Plus on each server, which will allow DECnet applications (such as SYSMAN) to be sued. They will use TCP port 399.

Regards,
Jeremy Begg

[cdan]

@Jeremy
No TCPIP, no Decnet, no eth frames, nada.
Don't ask me to argue with the architect, already did that with no result.

BTW, for those unfamiliar with PLINK, it is part of the Putty open source project.
http://www.chiark.greenend.org.uk/~sgtatham/putty/

[cdan]

@John I'm not sure what you mean by "writing a DCL jacket around "plink" ".
I'm, already using a CMD script SYSM.BAT around PLINK to cycle through all servers from file servers.txt
Content of SYSM.BAT:
FOR /F "eol=!" %%i in (servers.txt) do plink %%i -ssh -2 -t -l myuser -pw mypass %1

Usage of SYSM.BAT:
C:\Putty\SYSM "show time"

I'm not good enough in CMD to make this script automatically escape every double-quote.

[Joseph Huber_1]

Well the problem of quoting and CMD handling of quotes aside (I don't want get into ) ...

The main problem seems to be the way the VMS SSH side sees the records coming from an "-m" file: all lines there seem to come to VMS as one single record:
see this test (TCPIP 5.4 in my case, Linux client):
tmp.txt:
@[.com]test par1
show time

(test.com is a DCL command file showing the parameters)

plink -ssh -2 -l huber -m tmp.cmd mynode

result:
13:45:38.00: $ show symbol p1
P1 = "PAR1.SHOW"
13:45:38.00: $ show symbol p2
P2 = "TIME."
13:45:38.00: $ show symbol p3
P3 = ""

(The dots display the linefeeds)

I have tried to explicitely insert characters at the end of lines without a change in behaviour.

So this seems to be a problem with the VMS side, Linux to Linux doesn't have the problem.

So with a support contract You should report to HP.