0

I have a IBM MQ server in a Windows machine, MQ client and a Redistributable file transfer client installed a Linux machine.

I have successfully run the fteSetupCoordination, fteSetupCommands and fteCreateAgent commands and the object creating file is generated the required BFG_DATA folder. Issue is when I try to run the below command from Linux machine to create the agent (client, where MQ client is installed)

runmqsc -c MFTU < RDSAGTLIN_create.mqsc

the below command message popsup.

5724-H72 (C) Copyright IBM Corp. 1994, 2016. Starting MQSC for queue manager MFTU. AMQ8135: Not authorized. 0 command responses received.

RDSAGTLIN is my file transfer agent name in the client.

I can telnet the server queue manager port (from Linux to Windows).

What can be the issue and what am I missing here?

EDIT

I have created a channel in the server and have exported the MQSERVER

export MQSERVER=TEST.SVR/TCP/'192.168.90.185(1656)'

in the client machine.

EDIT 2

Just as Josh instructed I ran the file in the MQ server (Windows) itself. Now when I start the agent in the Linux the below error is in the agent log file.

[29/01/2020 16:11:30:053 IST] 00000001 AgentRuntime I BFGAG0058I: The agent has successfully initialized. [29/01/2020 16:11:30:085 IST] 00000015 AgentRecovery E BFGAG0052E: The agent received MQI reason code 2035 when establishing a client transport mode connection to the queue manager 'MFTU' with connection name '192.168.90.185(1656)' and using channel 'MQMFT.MFTU.SVRCONN'. The agent cannot continue and will end.

EDIT 3

I checked in the Queue manager (Windows machine) for the authentication and it's disabled. Not sure why a 2035, unauthorized is coming up.

DIS QMGR CHLAUTH 1 : DIS QMGR CHLAUTH AMQ8408I: Display Queue Manager details. QMNAME(MFTU) CHLAUTH(DISABLED)

Any guidance is very much appreciated on what I'm doing wrong here.

Yasothar
  • 435
  • 1
  • 7
  • 24
  • 1
    You need to have admin access to `MFTU` to run commands to create objects. If you are a MQ admin, you should just run the command local on the server where `MFTU` is running. – JoshMc Jan 29 '20 at 08:41
  • Hi Josh, apologies I'm pretty noob to this, MFTU is my queue manager and I need to associate an agent (RDSAGTLIN) running in with a IBM MQ client in a Linux machine. In the MQ client there is no queue manager. (MFTU is running in the server/ WIndows machine). So I will not be able to run the `runmqsc` locally. – Yasothar Jan 29 '20 at 08:50
  • If you can't run `runmqsc` locally on the queue manager machine, and must run it as a client, you need to ensure that the user ID the client is associated with over on the queue manager is one that has the authority to run the commands. If you are unable to run the `runmqsc` locally on the queue manager, you will need to get whomever owns the queue manager to grant you said authority, or set up your SVRCONN to have said authority. Given that, it would likely be easier just to get them to run the setup script for you. – Morag Hughson Jan 29 '20 at 09:22
  • Hi Morag, by "has the authority to run the commands" you are meaning the user need to be in the `mqm` group. I'm running as `root` and root belongs to `mqm` group. – Yasothar Jan 29 '20 at 09:40
  • How did you "created a channel in the server" if you do not have access to the windows server? – JoshMc Jan 29 '20 at 10:03
  • This is a UAT setup and I have access to every machine and all the users. By your question (pls correct me if I'm wrong), can I assume I can just copy the RDSAGTLIN_create.mqsc (the generated RDSAGTLIN agent object creation file by the `fteCreateAgent`) and directly run it in the MQ server (Windows machine)? – Yasothar Jan 29 '20 at 10:17
  • That is correct. This was suggested in the answer provided by @MoragHughson to the earlier question you asked. – JoshMc Jan 29 '20 at 10:22
  • Thanks Josh, one small clarification, will it suffice my requirement to pick files from Linux machine and transfer to Windows machine, after creating the agent in Windows (where the MQ server is running), can I start the agent in Linux (where the client is running) transfer files. Apologies if my questions are not making sens, I'm just learning by trial and error. – Yasothar Jan 29 '20 at 10:28
  • Transfer the MQSC file as ASCII and it should run fine with the windows `runmqsc`. You should be able to configure the linux agent to connect to the windows queue manager. Can you provide the `SVRCONN` channel `DEFINE` statement and any associated `CHLAUTH` rules. – JoshMc Jan 29 '20 at 13:53
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/206895/discussion-between-yasothar-and-joshmc). – Yasothar Jan 30 '20 at 06:38
  • Hi @Yasothar - no I just mean that your user has the authority required. One way to achieve that is to, as you say, be in the mqm group, but alternatively, and perhaps more securely, granting a user or the non-mqm group that user is in, only the authorities they need, is a safer and less wide open solution. – Morag Hughson Jan 30 '20 at 07:16

1 Answers1

0

After some rigorous reading and testing I was able to connect the redistributable client and MQ by the following means. Thanks to Morag and Josh's guidance.

By a runmqsc checked the authentication enabled for the queue manager.

dis qmgr connauth
 1 : dis qmgr connauth
AMQ8408I: Display Queue Manager details.
   QMNAME(MFTU)
   CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) chcklocl chckclnt
 2 : dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) chcklocl chckclnt
AMQ8566I: Display authentication information details.
   AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
   AUTHTYPE(IDPWOS)                        CHCKCLNT(OPTIONAL)
   CHCKLOCL(OPTIONAL)

SYSTEM.DEFAULT.AUTHINFO.IDPWOS implies the default authentication mechanism is enabled.

My MQ was running in the Windows under administrator user. What I did was I created a administrator user in the Linux (client) and the transfer worked like a charm. (Which exactly what Morag has commented, to create a user and give the capability).

Yasothar
  • 435
  • 1
  • 7
  • 24
  • Note if you are not sending a password the connection is wide open for anyone to connect the same way and administer your MQ and windows machine. – JoshMc Jan 31 '20 at 09:35