| Author |
Message
|
| lancelotlinc |
 Posted: Tue Jun 26, 2012 12:02 pm Post subject: Why mqm should not be the Broker Service Id. |
 |
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Code: |
$ id mqm
uid=1022(mqm) gid=1022(mqm) groups=1(staff),1021(mbbrowse),1023(mqbrkrs),1024(mqmlogs),1093(mqmiles)
|
| Code: |
$ id brksvcid
uid=123456789(brksvcid) gid=1023(mqbrkrs)
groups=1020(mqbrowse),1021(mbbrowse),1024(mqmlogs,1071(mqmuser),1093(mqmfiles),1022(mqm)
|
| Code: |
$ id myuserid
uid=132456789(myuserid) gid=1034(stduser) groups=1020(mqbrowse),1021(mbbrowse),1023(mqbrkrs),1024(mqmlogs),1071(mqmuser),1093(mqmfiles) |
A global mutex (semaphore) is used to control access to the broker's configuration repository, and it is created by the broker started task at Broker start time.
When the broker starts, it allocates a semaphore and explicitly marks the semaphore's ownership to anyone whose primary group = mqbrkrs. When the semaphore is created by the broker on startup, the Broker runtime tries to set the owning group of the semaphore to "mqbrkrs" by making a getgrnam() system call to get the GID for the "mqbrkrs" group name.
If I (myuserid) tries to lock the semaphore, my attempt will fail since my primary group for my user Id is stduser. If I sudo to the Broker service Id first (brksvcid), then my primary group now does equal the mqbrkrs group, and I am able to lock the semaphore.
Some mqsi commands require access to the repository, as well as the broker and execution group tasks, and therefore the user id that is running the command jobs must have sufficient access permissions (ie. primary user group of mqbrkrs not mqm) to use the semaphore. If the user id does not have sufficient access, the command job abends or timesout when issuing a semctl() system call to gain ownership of the semaphore.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Jun 26, 2012 12:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Does that mean that if I stop the broker and clear the associated IPC memory and semaphores, then start the broker with the mqm id, it would use the mqm group (primary group) and all would be good, or does that mean that regardless of the primary group of the userid starting the broker, the userid trying anything afterwards needs to have primary group mqbrkrs?
Does that mean that to have a multi-instance broker run as a service on top of MQ I need to set the mqm user up with primary group mqbrkrs and secondary group mqm ??
Furthermore could this mean that a permission change to the broker's executable (sticky bit) could fix that?
Can you please clarify? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 26, 2012 12:51 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
According to IBM, a startup task performed by the Broker is to "set the owning group of the semaphore to "mqbrkrs" by making a getgrnam() system call."
If this statement holds true, then any use of mqm would not be recommended.
Some mqsi commands need no coordination with the semaphore (and by implication the repository) and therefore will work regardless. Some mqsi commands need shared access to the repository and would likely not work. A few mqsi commands need exclusive access to the repository and will never work if not sudo to the mqbrkr primary group service Id.
A permission change to the sticky bit would not affect this since the semaphore ownership is explicitly set by the startup process to mqbrkrs.
Google for the source code to semtool and semstat. Use them (maybe with some additional enhancement) to discover what is really happening.
Long story short, [A] never ever use mqm as your service Id for Broker; [B] create a separate account to be the service Id that Broker runs under; [C] enable and create sudo policy for your site; [D] grant access to Broker mqsi commands through sudo.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 26, 2012 7:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
So how do you run the broker as an MQ service in this case? (Multi instance broker and qmgr)?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 26, 2012 11:21 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| fjb_saper wrote: |
| So how do you run the broker as an MQ service in this case? (Multi instance broker and qmgr)? |
Something needs to be done, I'm not sure what. You have a great question. I work around this problem since any redundancy I design is active-active (two separate and distinct Broker instances running with a proper mqbrkrs service Id) rather than active-passive (two mqm instances).
I think that is the quandary that may be solved in future release. One way to solve it would be put a flag at start up allowing the primary group Id started and owning the semaphore to be owned by mqm not mqbrkrs. A simple solution that would be easy to implement.
I don't know what other implications would exist by changing the semaphore ownership in that way. We are currently in a catch twenty-two.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 27, 2012 4:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| So how do you run the broker as an MQ service in this case? (Multi instance broker and qmgr)? |
You configure the service to run a batch file that runs su that runs broker.
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 27, 2012 2:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| fjb_saper wrote: |
| So how do you run the broker as an MQ service in this case? (Multi instance broker and qmgr)? |
You configure the service to run a batch file that runs su that runs broker.
|
Thought about that. But the service not having root authority (under mqm) needs a password for running su right? How do you obfuscate that? Any insight?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 27, 2012 2:32 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| mqjeff wrote: |
| fjb_saper wrote: |
| So how do you run the broker as an MQ service in this case? (Multi instance broker and qmgr)? |
You configure the service to run a batch file that runs su that runs broker.
|
Thought about that. But the service not having root authority (under mqm) needs a password for running su right? How do you obfuscate that? Any insight? |
Well, I really meant "sudo", not "su". |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 27, 2012 2:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| fjb_saper wrote: |
| mqjeff wrote: |
| fjb_saper wrote: |
| So how do you run the broker as an MQ service in this case? (Multi instance broker and qmgr)? |
You configure the service to run a batch file that runs su that runs broker.
|
Thought about that. But the service not having root authority (under mqm) needs a password for running su right? How do you obfuscate that? Any insight? |
Well, I really meant "sudo", not "su". |
Doesn't matter. In unattended mode, even sudo requires a password...
At least the first time in the session... and after a certain time of inactivity...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jun 28, 2012 4:58 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| fjb_saper wrote: |
| mqjeff wrote: |
| fjb_saper wrote: |
| mqjeff wrote: |
| fjb_saper wrote: |
| So how do you run the broker as an MQ service in this case? (Multi instance broker and qmgr)? |
You configure the service to run a batch file that runs su that runs broker.
|
Thought about that. But the service not having root authority (under mqm) needs a password for running su right? How do you obfuscate that? Any insight? |
Well, I really meant "sudo", not "su". |
Doesn't matter. In unattended mode, even sudo requires a password...
At least the first time in the session... and after a certain time of inactivity... |
sudo accepts the following command line options:
-A
Normally, if sudo requires a password, it will read it from the user's terminal. If the -A (askpass) option is specified, a helper program is executed to read the user's password and output the password to the standard output. If the SUDO_ASKPASS environment variable is set, it specifies the path to the helper program. Otherwise, if /etc/sudo.conf contains a line specifying the askpass program, that value will be used.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 28, 2012 1:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
google says -a ... got it! Thanks ... learning something new every day...
Didn't check yet. Hope this flag is also available on AIX
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jun 28, 2012 1:08 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| fjb_saper wrote: |
google says -a ... got it! Thanks ... learning something new every day...
Didn't check yet. Hope this flag is also available on AIX |
sudo is a public domain program, with source code. If it's not loaded in your default service package, you can d/l it and compile the code yourself. Modern AIX versions have it by default (6.1).
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 29, 2012 1:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Also, I don't think -a is strictly necessary in all cases. It's been a while since I've done this, but I thought some of the options in /etc/sudoers had some control over when/where a password was asked for as well.
But that's unreliable memory, so ....   |
|
| Back to top |
|
|
| Infraguy |
| Posted: Tue Sep 25, 2012 5:23 am Post subject: |
|
|
Newbie
Joined: 23 May 2012
Posts: 4
|
Depending on the level of access you have to the host running MQ, there is the NOPASSWD option you can explicitly set to either a group, group alias, or user/user alias.
The executions allowed would need careful review, including the command grouping.
This would allow an ID to execute specific commands without being prompted for a password. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Oct 18, 2012 8:35 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Just received an email from IBM which acknowledges the documentation is incorrect.
IBM has acknowledged the error in the IBM documentation that leads users to create WMB service Ids as 'mqm'. IBM states the documentation will be corrected in a future release. WMB service Id's primary group membership must be mqbrkrs not mqm.
"Thank you very much for your feedback. This topic will be updated for a future release."
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.doc/bp43600_.htm
The instructions in this article lead to three specific problems on AIX and Red Hat Linux operating systems.
1. When deploying bar files, the deployment sometimes hangs and does not complete.
2. When starting and stopping the brokers, some DFEs do not terminate and become zombies owned by root, whereas they were started under mqm Id.
3. Sometimes, when issuing an mqsistop command, a DFE will terminate and unexpectedly restart.
To resolve this, the service Id that runs Broker runtime needs to have primary group membership in mqbrkrs not mqm. This document leads users to create a Broker configuration where the Broker runtime service Id is primary group membership of mqm which is not correct. In order for Broker runtime to operate without the above three anomalies, the Broker service Id must have primary group membership of mqbrkrs and any user executing Administrative commands must sudo into the Broker Service Id first.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
