| Author |
Message
|
| gmmqnet |
 Posted: Thu Jul 31, 2008 4:59 am Post subject: FileOutput node FTP to UNIX doesn't seem to work |
 |
|
Novice
Joined: 12 Feb 2004
Posts: 18
|
First the background MB 6.1.0.2 in windows 2003.
Flow is FileInput -> FileOutput
The FileInput node picks the message from a windows local directory to the broker and tries to FTP to a AIX machine. The flow runs well without any error but the file is not written to the target AIX server in the directory.
Apart from the configuration mentioned for FileOutput node do I need to do anything specific? |
|
| Back to top |
|
 |
| AkankshA |
| Posted: Thu Jul 31, 2008 7:56 pm Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
if not at the taerget destination then where are the files moving ??
did u try using trace or debugger to verify no exception is thrown ??
_________________
Cheers |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 31, 2008 8:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Did you make sure the broker/MQ user has authority to write a file to the target directory? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gmmqnet |
| Posted: Thu Jul 31, 2008 8:59 pm Post subject: |
|
|
Novice
Joined: 12 Feb 2004
Posts: 18
|
| Quote: |
| Did you make sure the broker/MQ user has authority to write a file to the target directory? |
For FTP ,we specify the user details in the mqsisetdbparms command and create a identity.This identity is then used in the FileOutput node.So the question of broker authority does come into picture at all and the user used in the identity is able to write the file from FTP client so the authority issues goes out of window.
| Quote: |
| if not at the taerget destination then where are the files moving ?? |
If I had known then I would have not posted a question in here...
| Quote: |
| did u try using trace or debugger to verify no exception is thrown ?? |
There are no errors on the trace...no exception....
I hope this is not the first instance where we say messages are being lost from WMB.... |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Thu Jul 31, 2008 9:11 pm Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
Did you first try to write file to local windows directory and have verified that the message is really propagated to the FileOutput -node and file is produced?
Marko |
|
| Back to top |
|
|
| chrisc |
| Posted: Thu Jul 31, 2008 9:21 pm Post subject: |
|
|
Voyager
Joined: 19 Mar 2006
Posts: 77
|
Have you followed all of the instructions here about sending to a remote machine?
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac55410_.htm
You need to make sure you've set up your security identity for the FTP transfer, which will require you to shut down the broker, run mqsisetdbparms and then start it up again...
If you've done all that, I guess it's down to checking credentials are correct, manually FTPing to the target (and source, I guess), trying an FTP from and to the Windows box (Windows is often more slack with security!), etc. |
|
| Back to top |
|
|
| mqpaul |
| Posted: Fri Aug 01, 2008 10:05 am Post subject: Are you using Whole file transfer, or Record creation? |
|
|
Acolyte
Joined: 14 Jan 2008
Posts: 66
Location: Hursley, UK
|
If you create your output file record by record (that is, you have the FileOuput node's Record creation property set to something other than "Record is Whole File") you build the output in the local mqsitransit directory. The file does not get FTP'd until you send a message on the FileOutput node's Finish File terminal.
** updated - I read the start of this thread: you have 6.1.0.2, so you have the fix for IC55034 discussed below. **
If that does not answer your problem, it may be you need to apply a fix. APAR IC55034 addresses a problem where communications issues during FTP from a FileOutput node produced error messages in the event log, but did not cause an exception. Check your broker event log (the system Event Log on Windows, or /var/log/messages or whatever you have configured on UNIX) for messages BIP338x. If you find them, they mean there's a communications problem between the broker and the FTP server. It the messages appear, but the FileOutput node doesn't throw an exception, you need this fix. It's in broker fix pack 6.1.0.2.
_________________
Paul |
|
| Back to top |
|
|
| gmmqnet |
| Posted: Tue Aug 05, 2008 1:32 am Post subject: |
|
|
Novice
Joined: 12 Feb 2004
Posts: 18
|
Thanks all for your help..I had connected the terminal to finish file instead of the in terminal and now it is working.But a new problem has cropped up.I am not able to secure FTP using the port 22.Not sure on the reason why.The error in the eventviewer is as follows -
The description for Event ID ( 0 ) in Source ( sshd ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: sshd : PID 6304 : fatal: Timeout before authentication for 127.0.0.1. |
|
| Back to top |
|
|
| mqpaul |
| Posted: Tue Aug 05, 2008 2:55 am Post subject: Broker file nodes do not support SFTP |
|
|
Acolyte
Joined: 14 Jan 2008
Posts: 66
Location: Hursley, UK
|
| gmmqnet wrote: |
...
I am not able to secure FTP using the port 22.Not sure on the reason why.The error in the eventviewer is as follows
...
sshd : PID 6304 : fatal: Timeout before authentication for 127.0.0.1. |
"Vanilla" FTP (defined in RFC 959) uses port 21 for the control connexion and a random port for the data connexion. The broker V6.1 file nodes use vanilla FTP
Port 22 is used by SFTP (FTP using SSH - it doesn't have a definitive RFC, as far as I know), and uses a different protocol (both control and data connections use the same port). The file nodes do not support SFTP.
If you are trying to configure an SSH tunnel for the FTP connexions to run inside, there's no easy way to do this.
It's easy to set up an SSH tunnel for the FTP control connexion by forwarding port 21. That is very useful, as it encrypts your logon credentials. But FTP uses a random port number for the data connexion, so you can't set up an SSH tunnel for it in advance. Also, you tend to get firewall problems. Most firewalls understand the FTP control messages, so they know the random port number to open. When you use an SSH tunnel for the control connexion, the firewall can't read the port number, so it does not know which port to open.
IMHO, the easy way to arrange secure connexions for vanilla FTP is to use a VPN between the two hosts; then all connexions (FTP, whatever) are protected against access from outside those two systems. (Note that they are not not protected against access from users within the two systems.)
_________________
Paul |
|
| Back to top |
|
|
|
|
