Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

GUARDIAN FTP client command line args

565 views
Skip to first unread message

Henrik Paludan-Mørk

unread,
Mar 3, 2016, 9:18:41 AM3/3/16
to
I am trying to 'remote-control' the guardian FTP program from a command line TACL macro. Apparently i can build a TACL variable level and use it as INV for the ftp client like so:

#frame
#push myvar
#set myvar open 10.10.10.10
#append myvar USER myuser
#append myvar PASS mypass

run FTP /inv myvar, out $s.#some/
#unframe

well. it does not work. the remote site is opened, but the user/pass dialog is not successul. Without the PASS-symbol, the command file works in principle on the pc with the ftp -s:file command method. Not so on Guardian.

I do not in my library, have access to a manual that describes operation of the FTP program on guardian. does any one of you?

//Henrik

JShepherd

unread,
Mar 3, 2016, 11:28:54 AM3/3/16
to
In article <a58bd611-3f44-4f4d...@googlegroups.com>,
kilg...@gmail.com says...
#set #inlineprefix +
ftp /inline, name / [_FTP_SERVER]
+ [_FTP_USER]
+ [_FTP_PASSWORD]
+ prompt
== ftp get,put etc commands go here
#inlineeof

Rich S.

unread,
Mar 3, 2016, 2:01:36 PM3/3/16
to
you can store the user name and password in a separate file called FTPCSTM which can be referenced by the FTP client to automatically log you in.

Look in the "HP Nonstop TCP/IP Applications and Utilities User Guide" in Section 6 on FTP-Transferring Files.

11i

unread,
Mar 4, 2016, 4:54:48 AM3/4/16
to
Hendrik,

There is of cause a more elegant way to do this than using TACL. There is a FTP API (and a SFTP api) available for C/C++ from HPE that really allows you to take full control. Here you can also easily code error reporting and retry mechanisms.

Randall

unread,
Mar 4, 2016, 3:50:44 PM3/4/16
to
On Friday, March 4, 2016 at 4:54:48 AM UTC-5, 11i wrote:
> Hendrik,
>
> There is of cause a more elegant way to do this than using TACL. There is a FTP API (and a SFTP api) available for C/C++ from HPE that really allows you to take full control. Here you can also easily code error reporting and retry mechanisms.

Another elegant way is to use JSch from Java, which is an OpenSource SSH API. This will allow you to use public-private keypairs so that passwords are not stored in scripts. The API for using JSch is used throughout ECLIPSE products for SSH communications and AFAIK supports *current* SSH security patch levels and key encodings.

11i

unread,
Mar 5, 2016, 5:28:30 PM3/5/16
to
The question is about FTP therefore FTPapi from HPE is an option beyond TACL macros.

---------------------------------------

If SFTP is required, SFTPapi from HPE is another. If SSH client api is required, then HPE is now making SSHLIB available with regex pattern matching (Tcl Expect like) build into it. All native to Guardian and all in C/C++.


Yes PKC is std to SSH and worth considering. HPE's SFTP/SSH clients stores remote pwds encrypted and therefore no fear of pwds in scripts/macros or anywhere else.

(There are also excellent Python and Ruby SSH libs/apis as alternative to Java.)

Henrik Paludan-Mørk

unread,
Mar 8, 2016, 11:00:41 AM3/8/16
to
For general interest the solution was:

#frame
#push myvar
#set myvar open 10.10.10.10
#append myvar USER myuser
#append myvar mypass

run FTP /inv myvar, out $s.#some/ -n
#unframe

you will notice:
1. no PASS instruction
2. the -n option in the command line for FTP which suppresses the user/pass dialog upon connection.

In my macro i will also SINK the FTP process once i know it works and remove the OUT $s.# guardian parameter.

thanks for the tip about FTPCSTM - i might make use of that. this is a multi-user ROUTINE so it needs to be safe.

//Henrik

11i

unread,
Mar 9, 2016, 3:40:15 PM3/9/16
to
Hendrik, all I can say from using FTP; your data in flight are not safe and the pwds you store are not safe on various levels, whether this is a problem after a few beers I can not say ;-)

Henrik Paludan-Mørk

unread,
Mar 10, 2016, 5:20:15 AM3/10/16
to
This is known and considered. We are sending on our internal datacenter net only, and this user/pass is not used anywhere else. also, what is sent, is far from sensitive.
Otherwise we would have selected a different method :)

thanks for thinking about my solution.
0 new messages