I try to install WebSphere MQ v8 on Centos 7... I did have no problem instaling the server and test it. When I try to configure client every is OK until I try to put a message at queue with the following command: ./amqsputc queue manager. Here part of the log file.
-------------------------------------------------------------------------------
08/01/15 13:16:17 - Process(37991.4) User(mqm) Program(amqrmppa)
Host(localhost.localdomain) Installation(Installation1)
VRMF(8.0.0.0) QMgr(my.manager)
AMQ9776: Channel was blocked by userid
EXPLANATION: The inbound channel 'CANAL1' was blocked from address
'127.0.0.1' because the active values of the channel were mapped to a
userid which should be blocked. The active values of the channel were
'MCAUSER(mqm) CLNTUSER(mqm) ADDRESS(localhost)'. ACTION: Contact the
systems administrator, who should examine the channel authentication
records to ensure that the correct settings have been configured. The
ALTER QMGR CHLAUTH switch is used to control whether channel
authentication records are used. The command DISPLAY CHLAUTH can be
used to query the channel authentication records.
----- cmqxrmsa.c : 1257 -------------------------------------------------------
08/01/15 13:16:17 - Process(37991.4) User(mqm) Program(amqrmppa)
Host(localhost.localdomain) Installation(Installation1)
VRMF(8.0.0.0) QMgr(my.manager)
AMQ9999: Channel 'CANAL1' to host '127.0.0.1' ended abnormally.
EXPLANATION: The channel program running under process ID 37991 for
channel 'CANAL1' ended abnormally. The host name is '127.0.0.1'; in
some cases the host name cannot be determined and so is shown as
'????'. ACTION: Look at previous error messages for the channel
program in the error logs to determine the cause of the failure. Note
that this message can be excluded completely or suppressed by tuning
the "ExcludeMessage" or "SuppressMessage" attributes under the
"QMErrorLog" stanza in qm.ini. Further information can be found in the
System Administration Guide.
----- amqrmrsa.c : 925 --------------------------------------------------------
I appreciate all the help you can give me, thanks in advance.
It is very easy to troubleshoot the reasons why you have been blocked by a CHLAUTH rule. There is a blog post on it, I'm being blocked by CHLAUTH - how can I work out why?
However, I can tell you from here exactly which rule is blocking you, it is the default rule which bans remote privileged access, i.e. mqm access from client connections. If you want to have access without being privileged, read A non-privileged MQ administrator, and alternatively if you do want to allow the risky remote access from privileged users, read CHLAUTH - Allow some privileged admins
It's worth noting MQ v8 doesn't support CentOS at all, and hasn't declared support for RHEL 7 either.
http://www-969.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProduct?deliverableId=1350550241693&osPlatform=Linux
At time of writing MQ v8 supports the following Linux distros:
Asianux 3.0
RHEL 6
SLES 11
Ubuntu 12.04
That said, the error 'AMQ9776: Channel was blocked by userid' you pasted above show that your client is failing the channel authentication checks.
You can check this by disabling channel authentication via the following MQSC command:
'ALTER QMGR CHLAUTH(DISABLED)'
There's a good article on developerworks that explains how to work out why your connection attempt was blocked you can look at here:
https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/blocked_by_chlauth_why?lang=en
Related
I trying to connect RFHUTIL from my laptop to remote MQ server but its show error
09.43.47 Open for temporary reply queue failed rc=2035
Error getting queue names
Below are from Queue Manager Error Log:
2/26/2021 02:43:44 - Process(2716.35) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(MCP-50-50-1-5) Installation(Installation1)
VRMF(9.1.0.7) QMgr(mq)
Time(2021-02-26T01:43:44.367Z)
RemoteHost(50.50.1.2)
CommentInsert1(g525097#mcp-50-50-1-5)
CommentInsert2(SYSTEM.DEFAULT.MODEL.QUEUE)
CommentInsert3(get)
AMQ8077W: Entity 'g525097#mcp-50-50-1-5' has insufficient authority to access
object 'SYSTEM.DEFAULT.MODEL.QUEUE'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: get
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
Are you using any SYSTEM.*.SVRCONN channels? Because CHLAUTH rules (on the queue manager) can be blocking you.
RFHUTILC uses your Windows UserId for authentication (MQ v8.0 or higher) and authorization for MQ objects (i.e. queue manager, channels, queues, etc.)
Did your MQAdmin give your UserId, or group which your UserId is in, permission to access the queue manager and the queues?
From the error message you have provided in your question, you need to run the following MQSC command (that is a command issued using the runmqsc tool). If you don't have full authority over this queue manager then I suggest you ask your MQ administrator to run this command. If you do have full authority over this queue manager then make sure you are running the runmqsc tool with the same user id that your started the queue manager with, and that you are running it on the machine where the queue manager resides.
SET AUTHREC PROFILE('SYSTEM.DEFAULT.MODEL.QUEUE') OBJTYPE(QUEUE) GROUP(the-group-that-user-id-g525097-is-in) AUTHADD(GET)
If it still fails after you do this, please post the new error message because it will likely need other permissions and the error message, while similar, will be different.
Try to run this command on queue manager and then try to access
ALTER QMGR CHLAUTH(DISABLED)
We've tryed to test connection to the remote queue manager after installing MQ client v7.5 on Windows Server 2019. We've used Rfhutilc for this and got 'Host not available' inspite of the fact that telnet connection to the corresponding address was succecfully established. Also we tryed to connect using MQ client v9.0 with the same result.
AMQERR01.LOG (client v.7.5) reported following details:
29.09.2020 15:36:10 - Process(10828.2) User(Администратор) Program(rfhutilc.exe)
Host(-) Installation(Installation1)
VRMF(7.5.0.6)
AMQ9208: Error on receive from host 'X.X.X.X'.
EXPLANATION: An error occurred receiving data from 'X.X.X.X' over TCP/IP. This may be due to a communications failure.
ACTION: The return code from the TCP/IP recv() call was 10054 (X'2746'). Record these values and tell the systems administrator.
----- amqccita.c : 4065 -------------------------------------------------------
29.09.2020 15:37:56 - Process(10828.1) User(Администратор) Program(rfhutilc.exe)
Host(-) Installation(Installation1)
VRMF(7.5.0.6)
AMQ9202: Remote host 'X.X.X.X' not available, retry later.
EXPLANATION: The attempt to allocate a conversation using TCP/IP to host 'X.X.X.X' was not successful. However the error may be a transitory one and it may be possible to successfully allocate a TCP/IP conversation later.
ACTION: Try the connection again later. If the failure persists, record the error values and contact your systems administrator. The return code from TCP/IP is 10060 (X'274C'). The reason for the failure may be that this host cannot reach the destination host. It may also be possible that the listening program at host 'X.X.X.X' was not running. If this is the case, perform the relevant operations to start the TCP/IP listening program, and try again.
Here is an example of how traffic data looks like when Rfhutilc refuses to connect to the queue.
As soon as according to the picture there was some code page issue we've tryed to set MQCCSID environment variable with the value 1208 and it helpled.
Also connection attempt via Rfhutilc was succeful while running under another user with login "admin" even though without setting MQCCSID variable.
But I failed to find explanation for this. Did the CCSID of the MQ client differ from system code page of what? And how could I find out default CCSID of MQ client then?
MQ client v7.5 worked just fine on the Windows Server 2012 R2 right after installing. Rfhutilc v7.5 was used both on Server 2012 and Server 2019 for testing.
Alter channel page https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q085170_.htm shows that I can use Disconnect interval (DISCINT) in server connection channel alter command, however I get error message which claims that it can only be used for server or sender channel types, but not for server connection channel types.
Maybe MQ command level is too low for DISCINT attribute? How can I check that?
Operating System is Linux for that particular workgroup server...
This knowledge center page for MQ v 7.0.1 indicates that alter chl DISCINT is only valid on zOS.
Also, this page says: This attribute is valid for channel types Server connection (z/OS® only)
Maybe you are using an older version of MQ? There are many different ways to check your MQ version - from the command line try dspmqver.
I am trying to put a message into Websphere MQ queue from an Orchestration which is deployed on Cast Iron Live. I have used secure connector since the orchestation is deployed on Cast Iron. When I am trying to execute the flow, it fails and the message is not placed in MQ queue. The below are the errors:
Error while trying to call remote operation execute on Secure Connector for activity
com.approuter.module.mq.activity.MqPut and Secure Connector LocalSecureConnector,
error is Unable to put message on queue null. MQ returned error code 2538.
Unable to put message on queue null. MQ returned error code 2538.
Fault Name : Mq.Put.OperationActivityId : 163
Message: Unable to put message on queue null. MQ returned error code 2538.
Activity Name:Put MessageFault Time: 2015-07-15T05:40:29.711Z
Can someone please help me resolve this. Please let me know if any further details are required.
Here are the details:
Cast Iron flow is deployed on Cast Iron Cloud i.e Cast Iron Live
MQ is running on-premise
The port I am trying to connect is 1414.
Have a secure connector running on the machine where MQ is installed.
MQ version is 8.
In Cast Iron flow, I am using an MQ connector, by giving the hostname where MQ is running, port: 1414, Channel Name : SYSTEM.DEF.SVRCONN and username as mqm. Tired using my log on username, by adding it to mqm group. But this also dosent seem to work.
The return code is instructive:
2538 0x000009ea MQRC_HOST_NOT_AVAILABLE
This indicates that Cast Iron is attempting to contact MQ using a client connection and not finding a listener at the host/port that it is using.
There are a couple of possibilities here but not enough info to say which it might be. I'll explain and provide some diagnostics you can try.
The 2538 indicates an attempt to contact the QMgr has failed. This might be that, for example, the QMgr isn't listening on the configured port (1414) or that the MQ listener is not running.
The error code says the queue name is "null". The question doesn't specify which queue name the connector is configured with but presumably it's been configured with some queue name. This error code suggests the Secure Connector on the MQ server side doesn't have its configuration installed.
The Cast Iron docs advise connecting with an ID in the mqm group but do not mention that on any MQ version 7.1 or higher this is guaranteed to fail unless special provisions are made to allow the admin connection. It may be that it's actually failing for an authorization error and the connector not reporting the correct error.
If it is as simple as the listener not running, that's easy enough to fix. Just start it and make sure it's on 1414 as expected.
Next, ensure that the Secure Connector has the configuration that was created using the Cast Iron admin panel. You need to understand why the error code says the queue name is null.
Now enable Authorization Events and Channel Events in the QMgr and try to connect again. The connector on the MQ server should connect when started and if successful you can see this by looking at the MQ channel status. However, if unsuccessful, you can tell by looking at the event messages or the MQ error logs. Both of these will show authorization failures and connection attempts, if the connection has made it that far.
The reason I'm expecting 2035 Authorization Error failures is that any QMgr from v7.1 and up will by default allow an administrative connection on any channel. This is configured in the default set of CHLAUTH rules. The intent is that the MQ admin would have to explicitly provision admin access by adding one or more new CHLAUTH rules.
For reasons of security SYSTEM.DEF.* and SYSTEM.AUTO.* channels should never be used for legitimate connections. The Best Practice is to define a new SVRCONN, for example one named CAST.IRON.SVRCONN and then define a CHLAUTH rule to allow the administrative connection.
For example:
DEFINE CHL(CAST.IRON.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(ADDRESSMAP) +
ADDRESS('127.0.0.1') +
USERSRC(MAP) MCAUSER('mqm') +
ACTION(REPLACE)
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(BLOCKUSER) +
USERLIST('*NOBODY') +
WARN(NO) ACTION(REPLACE)
The first statement defines the new channel.
The next one allows the connections from 127.0.0.1 which is where the Secure Connector lives. (Presumably you installed the internal Secure Connection on the same server as MQ, yes?) Ideally the connector would use TLS on the channel and instead of IP filtering the CHLAUTH rule would filter based on the certificate Distinguished Name. This rule is not nearly so slective and allows anyone on the local host to be an MQ administrator by using this channel.
The last statement overrides the default CHLAUTH rule which blocks *MQADMIN with a new rule that blocks *NOBODY but just for that channel.
I am trying to connect to Websphere MQ 7.1 with Hermes JMS but I am not able to. I have followed their giude, loaded all the jars without problems, set the plugin, set all the variables (hostname, port, transportType, queuemanager), checked the box at the bottom that says user and typed the username and password and after confirming I tried to discover however I get the following message back:
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'.
at
com.ibm.mq.MQManagedConnectionJ11.(MQManagedConnectionJ11.java:233)
at
com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553) at
com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at
com.ibm.mq.StoredManagedConnection.(StoredManagedConnection.java:95)
at
com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at
com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:882)
at
com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:770)
at
com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:719)
at
com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:175)
at com.ibm.mq.MQQueueManager.(MQQueueManager.java:647) at
hermes.ext.mq.MQSeriesAdmin.getQueueManager(MQSeriesAdmin.java:107)
at
hermes.ext.mq.MQSeriesAdmin.discoverDestinationConfigs(MQSeriesAdmin.java:280)
at
hermes.impl.HermesAdminAdapter.discoverDestinationConfigs(HermesAdminAdapter.java:82)
at
hermes.impl.DefaultHermesImpl.discoverDestinationConfigs(DefaultHermesImpl.java:1126)
at
hermes.browser.tasks.DiscoverDestinationsTask.invoke(DiscoverDestinationsTask.java:77)
at hermes.browser.tasks.TaskSupport.run(TaskSupport.java:175) at
hermes.browser.tasks.ThreadPool.run(ThreadPool.java:170) at
java.lang.Thread.run(Thread.java:662)
After a few hours of trial and error and research on the net, it seems that the issue is that it cannot connect due to bad authorization however I am able to connect using Java code (Using same lib MQQueueConnectionFactory) and I am also able to connect using QueueZee with the exact same libraries, get a list of all queues and browse them so I know user authorization issues should not be the problem.
I am running Hermes JMS 1.14 and I tried using both Java 1.6.0_33 and 1.7.0_5. Websphere MQ is running on version 7.1.0.0 and the libraries were gotten from this installation on a remote server.
I tried setting the channel variable to SYSTEM.DEF.SVRCONN which is what I used in QueueZee to get it to work but still the same issue.
Has anybody seen this issue before and hopefully can shed some light in the situation?
At V7.1 the new CHLAUTH rules shut off access to all SYSTEM.* channels except SYSTEM.ADMIN.SVRCONN by default and do not allow any administrative access on any SVRCONN channel by default. In order to diagnose this it would be necessary to know what channel was used, the CHLAUTH rules that are set, the channel definition (in particular, the MCAUSER value) and whether the ID used is in the mqm group.
You didn't mention whether the QueueZee setup was also to a V7.1 QMgr or this one in particular. Taking a wild guess, I'd say that CHLAUTH rules are enabled and that the SYSTEM.DEF.SVRCONN channel is disabled at this point. Recommended steps are to define a new channel whose name doesn't start with SYSTEM. and make sure the ID used is not in the mqm group but is authorized as a non-admin ID.
Alternatively, an ID in the mqm group can be used but you'd have to define a CHLAUTH rule to allow it to work. For example, the default CHLAUTH rule uses CHANNEL(*) BLOCKUSER(*MQADMIN) and you could change that to CHANNEL(THE.NEW.CHL.NAME) BLOCKUSER('nobody'). The new rule would be more specific than the old rule and thus take precedence on your channel. It tells the QMgr to block the user ID 'nobody' but omits any mention of *MQADMIN. Since 'nobody' doesn't have access anyway but since *MQADMIN is not mentioned (and thus not blocked by thei rule) the effect of the rule is to allow admins on this channel.
As a quick, dirty and temporary measure, you can also ALTER QMGR CHLAUTH(DISABLED) to get the same behavior as in v7.0 and earlier QMgrs. Be aware though that this allows anonymous remote admin and remote code execution using the mqm user ID. That's why the default settings were changed. Now you must explicitly provision remote admin access if you need it.
For more on this topic, I recommend the Securing Your QMgr presentation from the IMPACT conference.
Note that the password the app sends in is not checked by the QMgr. The field exists so that channel exits can validate the password against AD, LDAP, etc. Without such an exit, the password is ignored. The user ID passed in by the client is either accepted at face value or modified by the channel's MCAUSER or by CHLAUTH rules.
Finally, when having authorization problems the easiest way to diagnose is to ALTER QMGR AUTHOREV(ENABLED) and then use SupportPac MS0P to decode the PCF messages in WMQ Explorer. The auths errors end up in the QMgr Event queue. Each message tells you the object that failed auths, the API call made against that object, the options of the call and the ID that made the call. Often we find the ID making the call isn't the one we wanted or that the program is using options it isn't authorized for so this can be extremely helpful.
Not really an answer, just a little research on the problem.
I have faced the same problem about hour ago. I am passing the username like domain\sortoflongusername and what i see in systemlog on WSMQ server is that my username is being truncated to 12 symbols.
I'm not really familiar with hermesJMS and soapui at all (just wanted to offer it to our testers to check it out as testing platform), so maybe anyone here does know about roots of this problem.