| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Help on MQ-JMS architectures |
« View previous topic :: View next topic » |
| Author |
Message
|
| SilentWind |
 Posted: Tue Jan 24, 2006 12:57 am Post subject: Security issue now... |
 |
|
Acolyte
Joined: 11 Jan 2006
Posts: 58
|
Great thanks to fjb_saper and others for your patience. My configuration works perfectly now.
However using the same pyramid configuration, I now have a client D connecting to B. If B logs in as the user TEST, will all queue managers A, B and C require TEST to authenticated for access?
Also, besides using the Windows method to add a new user, how do I add a brand new user (new to the network)? I know of the setmqaut commands but it only works after the user exists else the AMQ7096 error comes out. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Jan 24, 2006 5:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
Remember it is always a bad scheme to distribute authorizations by user.
You should really be distributing authorizations by groups.
When a new user comes along just stick him into the right group and your work is done.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| SilentWind |
| Posted: Sun Feb 12, 2006 6:15 pm Post subject: Problems |
|
|
Acolyte
Joined: 11 Jan 2006
Posts: 58
|
| As per the architecture, if I have an ip conflict at one of the servers e.g. B, and clients connecting to B can connect, but there is no response from the broker (i.e. not receiving messages) what can be done to resolve the situation? Is there any checks that can be run? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Feb 12, 2006 7:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
I had a few surprises with clustering. Especially with full repositories.
Changing the conname property on the channel did not stick. The only way to check it was through plain old runmqsc. (Did not display in MQExplorer V6).
Symptom:
After changing the conname and recycling the channel the channel is still in retrying mode... Runmqsc (dis chs(to.*)) shows that the old conname is still in effect. The qmgr is a full repository.
Cure:
Make the qmgr a partial repository. Run refresh cluster repos(yes).
Change the channel's conname definition again (alter chl...)
Recycle the channel again. Check that it runs with the right definition (dis chs(to.*) )
Make the qmgr a full repository again.
And remember for a "healthy" cluster the definition of the conname in the cluster receiver channel should be reachable from any part in the cluster.
Particularly important when you have managers on both sides of a firewall + NAT.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| SilentWind |
| Posted: Sun Feb 12, 2006 11:28 pm Post subject: TCP/IP |
|
|
Acolyte
Joined: 11 Jan 2006
Posts: 58
|
Hi F.J,
Thanks for your reply but sorry I was not specific enough with my question. My apologies.
Also here is my detailed problem. I left my broker topology on over the weekend, with messages being published on B's clients to be received over C's clients and vice versa (C publish to B). I had about 20 clients in total. Everything worked fine until one day over the weekend, A and B (A the core, B the sub-server) both had an IP conflict (one of my users accidentally configured A/B's ip for another on the network).
There were several results and logs.
1) A had orphaned connections in my defined broker queue streams. Question: Does this affect anything (i.e. network congestion, queue conflict etc), and also it does not seem to auto-remove these connections. Any way to work around this? (api, config within WMQ?)
2) The broker in B writes to the DLQ constantly due to the conflict, and this piles up very fast.
Question: Is there a way to set up a round-robin or a method to configure to auto-dispose of these useless messages? (again api or within WMQ?)
3) The main (and big) problem is that my clients can connect to B, it shows up in the SVRCONN status, but it does not receive the messages published from B. A local client on B can receive the messages though, which shows the broker still works. Also a client connecting to C, can receive the messages published from B
The logs on B now shows the standard TCP 10054 code. I have browsed through this forum but came up with no solution to help myself.
Some pointers to note (solutions from the 10054 search):
I have no firewall, net sniffers and other security programs running within the network. My MCA id is set correctly (same for A/B/C). I do not wish to manually edit the HOST files in windows. There has been no change to any TCP/IP properties on any of the computers nor the network. Also all the ip addresses are not assigned by DHCP for my case, all static IPs.
Sorry for the long post, but I feel there was a need to explain my situation as I spent countless hours figuring it out myself and searching for answers elsewhere before resolting to this avenue.
[/b] |
|
| Back to top |
|
|
| SilentWind |
| Posted: Mon Feb 13, 2006 12:44 am Post subject: Updates |
|
|
Acolyte
Joined: 11 Jan 2006
Posts: 58
|
| Quote: |
3) The main (and big) problem is that my clients can connect to B, it shows up in the SVRCONN status, but it does not receive the messages published from B. A local client on B can receive the messages though, which shows the broker still works. Also a client connecting to C, can receive the messages published from B
|
Apparently, I did the ultimum, restart all A, B and C. (This was very unadvisable in a production environment as we all know). Everything is back to normal except I still receive the tcp 10054 error logs in A and B despite still receiving messages in B's clients.
Is something wrong? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 13, 2006 4:10 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
One of my reasons for never using the IP in the conname is that an ip can change at the whim of the network group. However they take care of redirecting traffic the correct way by keeping the DNS name linked to the right computer. It works fine as well when the IP is not the same depending on which side of the NAT you are on.
You will need to work with the network group to make sure everything works fine and may have to use some of the tricks I described in my last post if the qmgrs are in a cluster.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
