| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Why mqm should not be the Broker Service Id. |
« View previous topic :: View next topic » |
| Author |
Message
|
| AndreasMartens |
 Posted: Fri Mar 08, 2013 9:21 am Post subject: Not quite right. |
 |
|
Acolyte
Joined: 30 Jan 2006
Posts: 65
Location: Hursley, UK
|
OK, I'm resurrecting this thread.
Having mqbrkrs as primary group ID is not necessary whatsoever.
not entirely sure where this came from. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Mar 08, 2013 4:04 pm Post subject: Re: Not quite right. |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| AndreasMartens wrote: |
OK, I'm resurrecting this thread.
Having mqbrkrs as primary group ID is not necessary whatsoever.
not entirely sure where this came from. |
So what you mean to say is: It it not necessary to start the broker as a user with primary membership in mqbrkrs, but the broker service_Id should still have a primary membership in mqbrkrs, yes? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| longng |
| Posted: Sat Mar 09, 2013 9:50 am Post subject: Re: Not quite right. |
|
|
Apprentice
Joined: 22 Feb 2013
Posts: 42
|
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sat Mar 09, 2013 7:42 pm Post subject: Re: Not quite right. |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
Where exactly is the error in the given link that leads users to create WMB service Ids as 'mqm'? It states that users must be members of the mqm group in order to create a broker, or to enable/disable broker administration security, but need not be members of the mqm group in order to start/stop a broker.
The only documented constraint relating to primary groups and semaphores for UNIX/Linux is that:- either "all user IDs used to start WebSphere Message Broker have the same primary group",
- or "all user IDs are members of primary groups of all other user IDs."
But there's no indication that the primary group must be mqbrkrs.
Where do the given links make that claim? They describe how to grant broker access for users of the toolkit, CMP and other APIs, and certain mqsi commands, when broker administration security is enabled. They only mention primary groups to describe how the setmqaut command works on UNIX/Linux systems:
| Quote: |
| If you use the setmqaut command to grant an authority to a principal, the authority is actually granted to the primary user group of the principal. |
The only documented scenario where a user requires a primary group of mqbrkrs is when running mqsicreatebroker on the AIX platform. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Mar 11, 2013 4:37 am Post subject: Re: Not quite right. |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| AndreasMartens wrote: |
OK, I'm resurrecting this thread.
Having mqbrkrs as primary group ID is not necessary whatsoever.
not entirely sure where this came from. |
On Linux platforms, due to the IPC internals of Linux builds based on System V, when the Broker service Id does not have mqbrkrs as its primary group, the locking mechanisms for Broker semaphores do not behave correctly.
If you'd like a demonstration, one can be arranged.
As rekarm points out, it doesn't have to be mqbrkrs group, just the same group for all access Ids. Which is why sudo is a great way to solve this problem.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Fri Sep 20, 2013 6:31 am Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Lot of good discussion here but Im still trying to figure if there is an official recommendation from IBM somewhere that mqm must not be used as a broker's serviceId ? Should it be an issue if mqm (alone) thats running all broker's processes has the primary group set to 'mqm' (obviously) and is also part of mqbrkrs group.
In my situation, OS is Linux & wmb is v8 |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Sep 20, 2013 6:43 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| sunny_30 wrote: |
Lot of good discussion here but Im still trying to figure if there is an official recommendation from IBM somewhere that mqm must not be used as a broker's serviceId ? Should it be an issue if mqm (alone) thats running all broker's processes has the primary group set to 'mqm' (obviously) and is also part of mqbrkrs group.
In my situation, OS is Linux & wmb is v8 |
V8 & V9 do not seem to behave the same as V7.
Symptoms you should look for that indicate a problem :
- zombie DataFlowEngine processes
- mqsistarts that hang
- mqsistops that hang
- message flows that stop processing Input
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Fri Sep 20, 2013 8:36 am Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
| lancelotlinc wrote: |
Symptoms you should look for that indicate a problem :
- zombie DataFlowEngine processes
- mqsistarts that hang
- mqsistops that hang
- message flows that stop processing Input |
Thanks for info !
So- you are saying all these issues might occur if mqm is used as a Broker serviceId on Unix.
And if its proven, thats a big deal. Then, why isnt there an official recommendation from IBM that mqm must not be allowed as a Broker serviceId ? If there is one, could someone point me to that source/link please |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Sep 20, 2013 9:15 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The lack of such guidance is one reason for LancelotLin's crusade on the matter anf hence this thread.
Now you know the best practice.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Sep 20, 2013 9:29 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| sunny_30 wrote: |
| lancelotlinc wrote: |
Symptoms you should look for that indicate a problem :
- zombie DataFlowEngine processes
- mqsistarts that hang
- mqsistops that hang
- message flows that stop processing Input |
Thanks for info !
So- you are saying all these issues might occur if mqm is used as a Broker serviceId on Unix.
And if its proven, thats a big deal. Then, why isnt there an official recommendation from IBM that mqm must not be allowed as a Broker serviceId ? If there is one, could someone point me to that source/link please |
On Linux, at least for WMB V7, the WMB runtime uses System V IPC semaphores for Interprocess Communication among the EGs that belong to a particular broker.
As discussed above, if PGID 40325 (mqm) gets ownership of the semaphore then PGID 73403 (mqbrkrs) tries to take it over, the result is a deadlock. Examples of such deadlocking are mqsistart, mqsistop, mqsideploy. Click this link for a discussion on System V IPC primitive deadlocking possibility.
| Quote: |
| Avoiding deadlock situations is another difficult problem when constructing applications from various combinations of queued IPC, shared memory, and miscellaneous synchronization primitives. For example, suppose thread A doesn't release mutex 1 until thread B releases mutex 2. Unfortunately, if thread B is in the state of not releasing mutex 2 until thread A releases mutex 1, a standoff results. Simulation tools are often invoked in order to ensure that deadlock won't occur as the system runs. |
It is unfortunate that (even when IBM acknowledged the shortcomings of the documentation two years ago) they have yet to correct the documentation to clearly identify this, although there are places that call this problem out.
Its a simple solution, if you run your WMB runtime on any Linux variant, just make sure that your service Id has Primary Group mqbrkrs and anyone that runs any administrative commands to sudo to that Id.
I have yet to hear of any deadlocking in WMB V8 or WMB V9, so this problem may have been addressed within the code. I no longer anticipate running into it myself since I use a service Id which has primary membership in mqbrkrs and I sudo to that Id whenever I run any mqsi command.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 20, 2013 9:48 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Sep 20, 2013 10:15 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Sep 23, 2013 3:09 am Post subject: Re: Why shouldn't mqm be the Broker Service Id? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
For the UNIX and Linux systems that use UNIX System V IPC primitives, IBM recommends that all user IDs used to start brokers have the same primary group, but only requires that all such user IDs are members of the primary groups of all the other such user IDs. So far, nobody has offered any evidence that this requirement is insufficient.
To correct some of the misstatements throughout this thread:- The example given in the initial post doesn't meet the above requirement, as user myuserid does not belong to user mqm's primary group.
- IBM's "Thank you very much for your feedback..." does not count as an acknowledgement that the documentation is incorrect.
- There is nothing in the referenced documentation that "lead users to create" broker service ids with primary group mqm.
- Whatever (undocumented) semaphores are used among the EGs that belong to a particular broker are probably unrelated to any semaphores used between different brokers.
- Whatever example involving PGID 40325 (mqm) and PGID 73403 (mqbrkrs) was never "discussed above".
- "PGID" refers to the id for a Unix process group, not to any group ids for a process.
- "deadlock" is a different problem, not caused by group permission-related issues.
- The referenced troubleshooting pdf contains the identical (word-for-word) recommendations for setting group ids to work with UNIX semaphores; it does not "call out" any sort of problem with uncorrected documentation.
There are unrelated requirements for user IDs used to create brokers, (not to be confused with user IDs used to start brokers). For WMB v6.x on AIX, user IDs used to create brokers must have a primary group of mqm, and have mqbrkrs as one of the group set. For WMB v7 and later on AIX, user IDs used to create brokers must have a primary group of mqbrkrs. But this has to do with file permissions, not semaphore permissions.
There are also unrelated requirements for user IDs accessing the broker through various GUIs, APIs, or other mqsi commands, either with or without broker adminstration security, about which groups they must belong to. But in this case, it makes no difference whether the required group is primary or not, and it also has nothing to do with semaphore permissions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Sep 23, 2013 3:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
All of that said, a Broker should not run under the mqm service id unless you are running that Broker as a trusted application.
There aren't any specific technical reqiurements that prevent doing so, but there are several good reasons why you shouldn't do so.
As an example, if Broker is running as mqm, then any local or mounted file systems that Broker needs to read from using FileInput nodes are now visible to every single application that can connect to the queue manager - at least potentially.
As an example, if Broker is running as the mqm user, then a random broker developer can build a message flow that sends PCF messages, giving random broker developers full administrative access to the queue manager.
As an example, if Broker is running as the mqm user, then a random broker developer can send messages to ANY queue on the larger MQ network.
It's a door that just doesn't need to be open, and even if it doesn't necessarily open very wide in a given installation, that doesn't mean it shouldn't be locked anyway.
Don't put mqm in the mcauser of unsecured channels, and don't run broker as mqm unless you HAVE to. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Sep 23, 2013 3:27 am Post subject: Re: Why shouldn't mqm be the Broker Service Id? |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| rekarm01 wrote: |
For the UNIX and Linux systems that use UNIX System V IPC primitives, IBM recommends that all user IDs used to start brokers have the same primary group, but only requires that all such user IDs are members of the primary groups of all the other such user IDs. So far, nobody has offered any evidence that this requirement is insufficient.
To correct some of the misstatements throughout this thread:- The example given in the initial post doesn't meet the above requirement, as user myuserid does not belong to user mqm's primary group.
- IBM's "Thank you very much for your feedback..." does not count as an acknowledgement that the documentation is incorrect.
- There is nothing in the referenced documentation that "lead users to create" broker service ids with primary group mqm.
- Whatever (undocumented) semaphores are used among the EGs that belong to a particular broker are probably unrelated to any semaphores used between different brokers.
- Whatever example involving PGID 40325 (mqm) and PGID 73403 (mqbrkrs) was never "discussed above".
- "PGID" refers to the id for a Unix process group, not to any group ids for a process.
- "deadlock" is a different problem, not caused by group permission-related issues.
- The referenced troubleshooting pdf contains the identical (word-for-word) recommendations for setting group ids to work with UNIX semaphores; it does not "call out" any sort of problem with uncorrected documentation.
There are unrelated requirements for user IDs used to create brokers, (not to be confused with user IDs used to start brokers). For WMB v6.x on AIX, user IDs used to create brokers must have a primary group of mqm, and have mqbrkrs as one of the group set. For WMB v7 and later on AIX, user IDs used to create brokers must have a primary group of mqbrkrs. But this has to do with file permissions, not semaphore permissions.
There are also unrelated requirements for user IDs accessing the broker through various GUIs, APIs, or other mqsi commands, either with or without broker adminstration security, about which groups they must belong to. But in this case, it makes no difference whether the required group is primary or not, and it also has nothing to do with semaphore permissions. |
Why is it so difficult then to clearly state such requirements in the documentation ?
[A] Reviewing the many posts here (and presumably many PMRs) that relate to zombie DataFlowEngine processes ; [B] the many feedbacks sent on incorrect or ambiguous documentation ; [C] this thread, which has so many views and so much interest : should prompt IBM to take positive action.
Its one thing to say that this thread has so many misstatements. Its another thing entirely to set the record straight in product documentation.
All we want is to properly configure our IBM product. Why is it so diffcult to get an official IBM straight answer that tells us what the right thing to do is? We have clearly identified a real problem that impacts the product's ability to function. What more do you need ?
It seems that this particular issue is needing some cover for some reason. We're not angry about this problem. We just want to know what to do. In the vacuum of official IBM statements, yes, there may be some user statements that may not be fully accurate.
So what's the plan, rekarm, to correct this situation within the official IBM documentation of the product so we no longer have to deal with zombies and deadlocks ?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| 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
|
|
|
|
