I'm trying to setup a Client connection to IBM MQ and test this using the samples application wmqjava.
I am able to connect in binding mode but I'm getting a 2035 unauthorised error when using client mode.
The steps I've taken to set this up are:
Create / run a queue manager
Create a listener
Create a SVRConn channel (multiple attempts)
I think I'm missing something with authorisation?
DEF CHL('TEST2.CHANNEL') CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER(' ')
I'm trying to connect to this on the same machine that the MQ server is running on.
Depending on the version of IBM MQ you are using, you could be being blocked by the default CHLAUTH rule which bans client connections which assert privileged user ids, or the default CONNAUTH rule which demands a password is provided for such a client connection.
Read Getting going without turning off MQ Security for instructions on how to turn both off, or use both correctly.
FYI: Your queue manager error log will tell you the reason you were blocked from accessing it.
You can put the user "mqm" in MCAUSER Field to bypass all the authorisation.
DEF CHL('TEST2.CHANNEL') CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('mqm')
This will use all the authorities of mqm user (Default MQ admin user) to connect to Queue Manager.
Alternatively you can authorize the user to allow to connect, put, get messages.
setmqauth or getmqauth commands can help you.
Related
When I try to access IBM MQ remotely, I get the errors below in my log file. Could someone give me some tip about what could I do to solve this?
AMQ5534E: the authentication user id usermq failed.
AMQ5542I: The authentication verification with fail was caused by configuration CONNAUTH CHCKCLNT (RECDADMIN) of queue manager.
I asked my network administrator to create another user for me to make the access, but didn't solve.
I'm working on a "pilot" installation of a webapp that runs in Tomcat, in a GCE instance, that talks to a Second Generation MySQL server. As I get closer to making it operational, I'm now running into something I'm having trouble making sense of.
Given:
The application is in Java, a webapp context running in a Tomcat server, on what is intended to be a load-balanced cluster of GCE instances.
And all of these instances share several common storage buckets, and a common Second Generation MySQL instance for their database.
Now, the developer who's in charge of the webapp ran an experimental cluster in his own private Google Cloud project, in which he just opened up the SQL server to the world, and didn't bother with any SSL. But obviously that's not going to fly as we get closer to the real thing.
I'm trying to get closer to the real thing. But how am I supposed to set up the database connections, when I don't know what IP addresses the GCE instances will have?
Looking at the "Authorization" tab for my MySQL instance, I see:
App Engine authorization
All apps in this project are authorized by default. To authorize apps in other projects,
follow the steps below.
Apps in this project: All authorized.
But that's "App Engine." Not Google Compute Engine.
And I see something called "JDBC Socket Factory," but it's on a page about connecting from applications running outside of Google Cloud.
And I see a page about connecting the MySQL Client on a Google Compute instance (which begs the question, "why would I want to do that, when I can connect from my desktop, via something a bit more user-friendly?"). Not connecting a Tomcat webapp context running on a dynamically created instance.
What am I missing here?
I've been experimenting with the Proxy now, and I find that I can connect if the proxy is running under my account, but not if it's running under either of two service accounts that should also be able to connect.
In all three cases, the proxy starts, and is waiting for connections. If I'm running the proxy as myself, I can connect just fine, whether from the default MySQL client, or from Sequel Pro, or from Squirrel. But if I'm running the proxy from either the default service account, or a service account I created specifically for this, the client gets:
MySQL said: Lost connection to MySQL server at 'reading initial
communication packet', system error: 0
and the proxy shows:
2018/03/22 09:38:23 New connection for "<REDACTED>"
2018/03/22 09:38:24 couldn't connect to "<REDACTED>": ensure that the
account has access to "<REDACTED>" (and make sure there's no typo in
that name). Error during createEphemeral for <REDACTED>: googleapi:
Error 403: Access Not Configured. Cloud SQL Administration API has
not been used in project 773874261491 before or it is disabled.
Enable it by visiting
https://console.developers.google.com/apis/api/sqladmin.googleapis.com
/o erview?project=<REDACTED> then retry. If you enabled this API
recently, wait a few minutes for the action to propagate to our
systems and retry., accessNotConfigured
I have:
Cloud SQL Admin
Cloud SQL Client
Compute Instance Admin (v1)
Compute Network Admin
Compute Security Admin
Deployment Manager Editor
Service Account Actor
Service Account Admin
Service Account Key Admin
Project IAM Admin
Storage Admin
The default service account has:
Cloud SQL Client Editor
The service account I created has:
Cloud SQL Client
At a suggestion to try re-enabling the Cloud SQL API, I had it disabled and re-enabled. No change. Still:
Jamess-Mac-mini:~ jamesl$ ./cloud_sql_proxy -instances=<REDACTED>=tcp:3306
2018/03/22 09:37:42 Listening on 127.0.0.1:3306 for <REDACTED>
2018/03/22 09:37:42 Ready for new connections
{Sequel Pro connected just fine}
2018/03/22 09:37:50 New connection for "<REDACTED>"
2018/03/22 09:37:52 New connection for "<REDACTED>"
2018/03/22 09:38:01 Client closed local connection on 127.0.0.1:3306
2018/03/22 09:38:01 Client closed local connection on 127.0.0.1:3306
^C
Jamess-Mac-mini:~ jamesl$ ./cloud_sql_proxy -instances=<REDACTED>=tcp:3306 -credential_file=<REDACTED my new service account>.json
2018/03/22 09:38:19 using credential file for authentication; email=<REDACTED my new service account>
2018/03/22 09:38:19 Listening on 127.0.0.1:3306 for <REDACTED>
2018/03/22 09:38:19 Ready for new connections
{Sequel Pro failed to connect}
2018/03/22 09:38:23 New connection for "<REDACTED>"
2018/03/22 09:38:24 couldn't connect to "<REDACTED>": ensure that the
account has access to "<REDACTED>" (and make sure there's no typo in
that name). Error during createEphemeral for <REDACTED>: googleapi:
Error 403: Access Not Configured. Cloud SQL Administration API has
not been used in project 773874261491 before or it is disabled.
Enable it by visiting https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?project=<REDACTED>
then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry., accessNotConfigured
^C
Jamess-Mac-mini:~ jamesl$ ./cloud_sql_proxy -instances=<REDACTED>=tcp:3306 -credential_file=<REDACTED default service account>.json
2018/03/22 09:46:41 using credential file for authentication; email=<REDACTED default service account>
2018/03/22 09:46:41 Listening on 127.0.0.1:3306 for <REDACTED>
2018/03/22 09:46:41 Ready for new connections
{Sequel Pro failed to connect}
2018/03/22 09:46:45 New connection for "<REDACTED>"
2018/03/22 09:46:46 couldn't connect to "<REDACTED>": ensure that the account has access to "<REDACTED>" (and make sure there's no typo in that name). Error during createEphemeral for <REDACTED>: googleapi: Error 403: Access Not Configured. Cloud SQL Administration API has not been used in project <REDACTED> before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?project=<REDACTED> then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry., accessNotConfigured
^C
You might consider using the Cloud SQL Proxy when the source IP of the Compute Engine instance might be changing. Step 8 of the guide explains how to start the proxy and you can use the mysql client (step 9) to test the connection from the GCE instance.
Once the proxy is setup, in the connection URL, use 'localhost' as it will be the proxy that will do the connection on 127.0.0.1. This in case you use a TCP socket connection, it's different if you use Unix sockets.
I am unable to connect IBM websphere MQ
Can anyone tell me what are the initial setting need to be done in MQ to acces it from remote machine using simple java code?
Besides the MQ samples shipped with the product, there is also a long list of Java & Java/JMS samples here.
The recommended practice for MQ Java (non-JMS) is:
Hashtable mqht = new Hashtable();
mqht.put(CMQC.CHANNEL_PROPERTY, channelName);
mqht.put(CMQC.HOST_NAME_PROPERTY, hostName);
mqht.put(CMQC.PORT_PROPERTY, new Integer(portNumber));
try
{
MQQueueManager qMgr = new MQQueueManager(qMgrName, mqht);
System.out.println("Successfully connected to "+ qMgrName);
}
catch (com.ibm.mq.MQException mqex)
{
System.out.println("MQException cc=" +mqex.completionCode + " : rc=" + mqex.reasonCode);
}
A few points to make sure you are able to connect to Websphere MQ using Java code :
Have you validated your MQ server deployment using these steps "Verifying Installation" in following deployment instructions http://sadockobeth.blogspot.in/2014/03/how-to-install-ibm-websphere-mq-75-on.html
Have you started a listener for a Queue Manager that is configured on your MQ server. You can find command to start Listener here http://bencane.com/2013/04/22/websphere-mq-cheat-sheet-for-system-administrators/
With default installation the connection from a Java application over TCP will fail because of channel authentication enforced by default. You can confirm this is the case by looking at Queue manager error logs. Would suggest you to look at appropriate ways to configure channel authentication to allow the Java application to connect. One method ok for Non-Production or test set up is to disable channel (Please use this with caution).
If all of the above are taken care and still you are not able to connect than you will need to look at your Java client code and get more information from error codes that your code is seeing. If there are any genuine network connectivity issues or some thing else like firewall preventing connection etc.
I've installed the Websphere MQ 7.5 and written a Java-client to connect to the queue. To perform the task, I'ev created a custom connect-to-server channel that is based on the SYSTEM.DEF.SVRCONN channel.
Firstly, to block all users with administrator privileges and all anauthorized users for all channels I've types such a command (runmqsc TEST_MANAGER): SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST('nobody', *MQADMIN) . Now I see this restriction in the MQ Explorer (TEST_MANAGER -> Channels -> Channel Identification Records).
After that, to provide my test user (Java-client) with an access, I've typed such a command:
SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS('*') MCAUSER('TestUser') .
Lastly, I've set the username/password pair in the Spring's UserCredentialsConnectionFactoryAdapter where the username is TestUser.
The problem is I can't connect with the 2035 MQRC_NOT_AUTHORIZED exception. If I remove the 'nobody'/*MQADMIN blocking rule, everything works fine (only the rule for the TestUser client rule presents).
SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS('*')
MCAUSER('TestUser')
I do not think you understand this command. This command says that ALL applications connecting on channel 'TEST_CHANNEL' will use UserID of 'TestUser'.
I've set the username/password pair in the Spring's
UserCredentialsConnectionFactoryAdapter where the username is
TestUser.
Setting a Password is pointless, as MQ does NOT perform authentication. You need to purchase a 3rd party product (i.e. MQAUSX) to handle the authentication. Also, your CHLAUTH command is actually overriding whatever UserID you set in your Spring application.
The problem is I can't connect with the 2035 MQRC_NOT_AUTHORIZED exception. If I remove the 'nobody'/*MQADMIN blocking rule, everything works fine (only the rule for the TestUser client rule presents).
Did you use the setmqaut command to give the UserID 'TestUser' the appropriate access to the queue manager and queue?
Turn on the queue manager's Authority Event and to see exactly why MQ is returning 2035.
I am using MQexplorer to handle queue manager, and when I connect to MQ using JMS with JNDI lookup, using qcf.createQueueConnection(); I am getting JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager error. All posts/blogs mention about this error, but they say to remove CHAUTH for queuemanager and so on... How do I work this out using MQExplorer? Please help me on this!
I am using MQ client(with JNDI on LDAP) connection which can connect remote machine(not bindings).
Actually disabling CHLAUTH is NOT advised as doing so opens up your queue manager to the world. It's OK if this is a test queue manager. Using runmqsc you can disable channel authentication. In runmqsc issue "ALTER QMGR CHLAUTH(DISABLED)" command to disable channel authentication.
Please read WMQ InfoCenter or Chapter 20 of this redbook or just search for T.Rob's posts in this forum on CHLAUTH. Few links here, this one