| Author |
Message
|
| lancelotlinc |
 Posted: Fri Sep 09, 2011 9:51 am Post subject: |
 |
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Very good Joe.
There are five steps to manual deployment independence:
1. Create the bar.
2. Override the bar.
3. Package the bar (into tar or zip).
4. Move package to remote machine.
5. Deploy the package (bars & jars) locally.
Each of these steps is a separate Ant task.
Using a Continuous Integration server, like Hudson, CruiseControl, BuildForge, these Ant tasks can be run in parallel.
Avoid deploying the bar remotely through mqsideploy. Only deploy the bar locally after moving the package (tar or zip file) to the target machine.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Sep 09, 2011 10:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| 3. Package the bar (into tar or zip). |
That's a bit odd.
BAR == JAR == ZIP...
whaddya need to package it twice for? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Sep 09, 2011 10:30 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| lancelotlinc wrote: |
| 3. Package the bar (into tar or zip). |
That's a bit odd.
BAR == JAR == ZIP...
whaddya need to package it twice for? |
Because the deployment package has several artifacts: readme file, jars, properties files, ant scripts for use in deployment of all artifacts, bar files, SSL certificates, shell scripts, mqsc scripts for queue creation.
Basically every thing necessary to stand up a service from ground zero.
You have to approach the deployment package with the philosophy "if I were not here tomorrow, a regular sys-admin with only knowledge on Ant could successfully stand up this service." In essence, program the Ant scripts to make yourself obsolete.
The readme file currently contains about 24 steps. Each of the steps is an Ant invocation. The output of the Ant invocation is captured in a text file. The readme shows the human how to invoke Ant and the expected output contained in the text file. We're at the point now where humans don't invoke the Ant commands. Our BuildForge server does it. Our Ant script emails a mail group when it is complete and attaches the text files.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Sep 09, 2011 11:55 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Here is an example of an Ant command:
| Code: |
# On Windows:
"C:\Program Files\apache-ant-1.8.2\bin\ant" -f someprojectname_deploy.xml deployCommonJars > deployCommonJars.txt
# On AIX:
/usr/local/ant/apache-ant-1.8.2/bin/ant -f someprojectname_deploy.xml deployCommonJars > deployCommonJars.txt |
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 26, 2016 7:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
I'm playing around with Ant Hill Pro and deploying to WMB (Hi, yes, the 21st century looks great!)
Based on the advice in this thread, we are going push the bar file up to the WMB server and execute the mqsideploy command.
But, the user ID executing the command needs to be a member of the mqbrkrs group, and the WMB Admins told us to take a hike - no one is being added to the mqbrks group. OK, that's understandable.
So, how to give the service account that will be used by Ant Hill Pro enough access to issue mqsideploy, without adding it to the mqbrkrs group?
Am I missing something obvious, or is this going to end up being a sudo solution?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 26, 2016 7:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| So, how to give the service account that will be used by Ant Hill Pro enough access to issue mqsideploy, without adding it to the mqbrkrs group? |
See here - "Required authority for developers"
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 26, 2016 7:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
and something about reopening old threads...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 26, 2016 7:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| and something about reopening old threads... |
Yes, yes, but it's Friday ...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 26, 2016 8:42 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| mqjeff wrote: |
| and something about reopening old threads... |
A thread older than 1 week, 1 month, 1 year is too old to use? What's the rule again?
Maybe next time I'll just rehash the entire situation in a new thread. After first not using search.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 26, 2016 8:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| Vitor wrote: |
| PeterPotkay wrote: |
| So, how to give the service account that will be used by Ant Hill Pro enough access to issue mqsideploy, without adding it to the mqbrkrs group? |
See here - "Required authority for developers" |
It doesn't talk about the mqsideploy command. We have it working correctly and securely thru the MQ Client Channel via the ToolKit. The users have the MQ Authorities they need to the Queue Manager and SYSTEM.BROKER.* queues. But that's not enough when trying to kick off mqsideploy locally.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 26, 2016 9:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| But that's not enough when trying to kick off mqsideploy locally. |
So what happens when you try and kick it off locally? In the error message sense of the question?
Does the shell the process is using have mqsiprofile sourced in it?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 26, 2016 10:10 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
| PeterPotkay wrote: |
It doesn't talk about the mqsideploy command. We have it working correctly and securely thru the MQ Client Channel via the ToolKit. The users have the MQ Authorities they need to the Queue Manager and SYSTEM.BROKER.* queues. But that's not enough when trying to kick off mqsideploy locally. |
It should be enough to kick off mqsideploy locally -- in client mode.
To kick it off in server mode you may have to be a member of the mqbrkrs group... and have the right authorities on the qmgr.
I would expect this activity to be done by a type of service user ... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 26, 2016 10:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| mqjeff wrote: |
| and something about reopening old threads... |
A thread older than 1 week, 1 month, 1 year is too old to use? What's the rule again? |
Well, I don't know. I just know when it's done by other people, it seems to be frowned on. General recommendation seems to be start a new thread and refer back to the old one.
Not for me to say either way.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 26, 2016 11:19 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Yes, we are sourcing mqsiprofile.
| Code: |
mqsideploy
Failed to open file /var/mqsi/registry/utility/HASharedWorkPath with error Permission denied
BIP2113E: Message broker internal error: diagnostic information ''Permission denied'', '13', ''/var/mqsi/registry/utility/HASharedWorkPath''.
|
WMB 8.0.0.6 on RHEL x86-64
This link seems rather explicit that the account needs to be a member of mqbrkrs to issue mqsideploy
http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/ap08682_.htm?lang=en
Have you guys got a local mqsideploy to work with an ID that is not a member of mqbrkrs?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 26, 2016 12:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| Have you guys got a local mqsideploy to work with an ID that is not a member of mqbrkrs? |
Ours works with a service id that owns the automated deployment process (we don't use Ant but another vendor's product) and does all the deploys, no matter what user requests it (and has ACLs and so forth to control that).
I observe that my /var/mqsi/registry and it's child directories are owned by mqbrkrs and have rwxrwxr-s permissions. I wonder if the "Permission Denied" is as simple as bad permissions at the OS level.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
