Author |
Message
|
smdavies99 |
Posted: Tue Apr 22, 2014 11:48 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Quote: |
Do i now have to physically give permission to the MQSI program files folder for local mqbrkrs group (or mqm group) ?
|
No. If you look at the permissions you may find that they are already set.
But... you have to give the directories used on the shared drive FULL access to the account that broker will run under. _________________ 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 |
|
|
pintrader |
Posted: Wed Apr 23, 2014 12:10 am Post subject: |
|
|
Disciple
Joined: 22 Jan 2014 Posts: 164
|
smdavies99 wrote: |
No. If you look at the permissions you may find that they are already set.
|
actually i did not see any mqm or mqbrkrs permission on the MQSI program folders. eg c:\program files\ibm\MQSI\9.0.0.1. I can see only Administrators, SYSTEM, CREATOR OWNER, <Computer name>\Users. My test setup have 2 others , "ALL APPLICATION PACKAGES" and "TRUSTED INSTALLER". But i don't think they are an issue on production.
Even if I add the service account to the MQSI program folder with R,W,X permissions, it should not have any impact right?
smdavies99 wrote: |
But... you have to give the directories used on the shared drive FULL access to the account that broker will run under. |
ok. I can give local mqbrkrs group to this folder or just give the service account FULL access. will try. |
|
Back to top |
|
|
smdavies99 |
Posted: Wed Apr 23, 2014 4:57 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
pintrader wrote: |
smdavies99 wrote: |
No. If you look at the permissions you may find that they are already set.
|
actually i did not see any mqm or mqbrkrs permission on the MQSI program folders. eg c:\program files\ibm\MQSI\9.0.0.1. I can see only Administrators, SYSTEM, CREATOR OWNER, <Computer name>\Users. My test setup have 2 others , "ALL APPLICATION PACKAGES" and "TRUSTED INSTALLER". But i don't think they are an issue on production.
. |
You don't need anymore than this. 'Users' have 'Read and Execute' priv. That is all that is needed for example to the binary mqsichangebroker.
Remember that on windows all the broker data files are stored elsewhere. If you don't use the -e or -w options when creating a broker (for example in a non clustered setup) the files go in a hidden directory. On Server 2008 this is c:\ProgramData\... (no access to a server 2012 system at the moment)
I normally make the root of this tree unhidden when on a non clustered system. (attrib -s -h c:\programdata )
These broker specific directories will have 'mqbrkrs' permitted.
This is not the root cause of your problem IMHO. _________________ 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 |
|
|
fjb_saper |
Posted: Wed Apr 23, 2014 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003 Posts: 20696 Location: LI,NY
|
You need to set full permissions for the Domain groups referenced in the
Code: |
crtmqm -a "mydomain\Domain mqm" and
mqsicreatebroker -B "mydomain\Domain mqbrkrs" |
domain groups.
It is just good practice to have the Domain service id to be part of its domain group. It is also good practice to have those domain groups as members of the corresponding local group...
Have fun _________________ MQ & Broker admin |
|
Back to top |
|
|
smdavies99 |
Posted: Wed Apr 23, 2014 8:02 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
fjb_saper wrote: |
You need to set full permissions for the Domain groups referenced in the
Code: |
crtmqm -a "mydomain\Domain mqm" and
mqsicreatebroker -B "mydomain\Domain mqbrkrs" |
domain groups.
It is just good practice to have the Domain service id to be part of its domain group. It is also good practice to have those domain groups as members of the corresponding local group...
Have fun |
But the OP does not want to use the -B option, I wonder why? _________________ 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 |
|
|
pintrader |
Posted: Wed Apr 23, 2014 3:13 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2014 Posts: 164
|
smdavies99 wrote: |
But the OP does not want to use the -B option, I wonder why? |
thanks actually, i will try it as a last resort. This is because i can get it to work by putting the service account inside local admin group. Hence, -B is not really the cause? Further, i used mqsiaddbrokerinstance on both nodes in turn. The problem persists on the node i used this command on. Hence i don't think its a shared drive permission issue.
Also, i am confused on the creating of security groups. What is the difference if you put a user inside a group and assigning this group permission to folders/files versus assigning just the user to the folders/files? aren't they the same? So if i assign the service id to those broker directories, it should work right? Why the need to create security groups?
Last edited by pintrader on Wed Apr 23, 2014 11:30 pm; edited 1 time in total |
|
Back to top |
|
|
pintrader |
Posted: Wed Apr 23, 2014 3:17 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2014 Posts: 164
|
smdavies99 wrote: |
Remember that on windows all the broker data files are stored elsewhere. If you don't use the -e or -w options when creating a broker (for example in a non clustered setup) the files go in a hidden directory. On Server 2008 this is c:\ProgramData\... (no access to a server 2012 system at the moment)
|
actually the path shows c:\programData\... when the node is on Passive standby. When its active, this path would change to the shared drive. I have checked this using mqsireportbroker. (and i had used -e and -w) |
|
Back to top |
|
|
fjb_saper |
Posted: Thu Apr 24, 2014 4:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003 Posts: 20696 Location: LI,NY
|
pintrader wrote: |
This is because i can get it to work by putting the service account inside local admin group. Hence, -B is not really the cause? Further, i used mqsiaddbrokerinstance on both nodes in turn. The problem persists on the node i used this command on. Hence i don't think its a shared drive permission issue. |
Actually you can't get it to work because the broker does not start on the stand by instance. It has to do with the fact that the os is using uid and gid and not the corresponding names. Also to have the right permissions on the file system and allow correct access from both hosts you need to use the -B option. Just have the service user be a member of the domain group used in the -B option...
pintrader wrote: |
Also, i am confused on the creating of security groups. What is the difference if you put a user inside a group and assigning this group permission to folders/files versus assigning just the user to the folders/files? aren't they the same? So if i assign the service id to those broker directories, it should work right? Why the need to create security groups? |
Security groups are meant to grant access to resources. They also make life a lot easier: individuals change roles over time. It is easier to change group membership for the individuals then it is to set up their individual permissions.
Anyways in the Unix world a lot of things go by the primary group of the user and very little to nothing is gained by setting permissions at the principal level. Windows is more like the odd man out by allowing you to set permissions at the principal level...
Have fun _________________ MQ & Broker admin |
|
Back to top |
|
|
pintrader |
Posted: Sun Apr 27, 2014 11:42 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2014 Posts: 164
|
thanks fjb and smdavies.
I manage to get the thing going using your suggestions. -a for Qmgr and -B when creating the broker.
Few things I learned from this
1) trust only 50% of what an IBM engineer says. :)
2) Documentation can be wrong or inadequate too
3) take heed from people who have done it before.
4) Production env take precedence over test env. No matter how good your test env is, its always different in production.
5) There is no need to assign any Domain group to the shared drive. I have "Domain mqm" assigned to shared drive and "hamvmqm" will give me error when copying. Removed the assignment and everything works fine.
lol.
Last edited by pintrader on Mon Apr 28, 2014 12:02 am; edited 1 time in total |
|
Back to top |
|
|
pintrader |
Posted: Sun Apr 27, 2014 11:57 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2014 Posts: 164
|
Wondering how is the industry practice like for changes to the password of the service account every few months in a cluster environment?
can it be something like this?
1) Change password of service id at Node (P)assive
2) Failover from Node (A)ctive to P
3) Change password of service id at Node A (which is now on passive mode)
All this to be done when there are less traffic , eg at night or evening.
Is that how its done normally?
Or can I just change the password and leave it be without failovers?
thanks |
|
Back to top |
|
|
smdavies99 |
Posted: Mon Apr 28, 2014 12:10 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
pintrader wrote: |
thanks fjb and smdavies.
I manage to get the thing going using your suggestions. -a for Qmgr and -B when creating the broker.
|
Well done!.
Quote: |
Few things I learned from this
1) trust only 50% of what an IBM engineer says.
|
Very True, sad to say some of the Level 2 support don't know about the -B option.
Quote: |
2) Documentation can be wrong or inadequate too
|
Indeed. submit a response stating what is wrong and in my experience it does get changed. without adequate feedback it won't get changed.
Quote: |
3) take heed from people who have done it before.
|
Yes but with a pinch of salt. Until you try it for yourself remain suspicious.
Quote: |
4) Production env take precedence over test env. No matter how good your test env is, its always different in production.
|
you can minimize the differences if you plan properly. I try to use the same build scripts for all environments with the differences incorporated into the scripts.
Quote: |
5) There is no need to assign any Domain group to the shared drive. I have "Domain mqm" assigned to shared drive and "hamvmqm" will give me error when copying. Removed the assignment and everything works fine.
|
good to know that. _________________ 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 |
|
|
smdavies99 |
Posted: Mon Apr 28, 2014 12:16 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
pintrader wrote: |
Wondering how is the industry practice like for changes to the password of the service account every few months in a cluster environment?
can it be something like this?
1) Change password of service id at Node (P)assive
2) Failover from Node (A)ctive to P
3) Change password of service id at Node A (which is now on passive mode)
All this to be done when there are less traffic , eg at night or evening.
Is that how its done normally?
Or can I just change the password and leave it be without failovers?
thanks |
If your site allows non expiring passwords then you are good to go but this is not be the norm.
At one financial institution where I worked (about 10 years ago) we managed to get security to sign off on a non expiring password only because we proved to them that it met all the requirements. This was a Unix Environment so we could set the account up so that no one could login to it. We accessed the account via a secondary account what was one-time password controlled and did an 'su' to it.
Sadly Windows is not yet mature enough to allow things that have been in Unix/Linux for decades. I am sure there are some AD tricks but these are not for the masses. _________________ 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 |
|
|
fjb_saper |
Posted: Mon Apr 28, 2014 7:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003 Posts: 20696 Location: LI,NY
|
I believe you can set up the service account so as not to allow interactive login... _________________ MQ & Broker admin |
|
Back to top |
|
|
pintrader |
Posted: Mon Apr 28, 2014 5:24 pm Post subject: |
|
|
Disciple
Joined: 22 Jan 2014 Posts: 164
|
fjb_saper wrote: |
I believe you can set up the service account so as not to allow interactive login... :innocent: |
hi fjb (and smdavies) , yes , i think its the deny log on locally user rights assignment. but deciding to do it or not is not my call. But i can still make the suggestion
(But if this can't be done, are the steps i highlighted correct , in your experience? )
thanks. |
|
Back to top |
|
|
smdavies99 |
Posted: Mon Apr 28, 2014 9:53 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
pintrader wrote: |
fjb_saper wrote: |
I believe you can set up the service account so as not to allow interactive login... |
hi fjb (and smdavies) , yes , i think its the deny log on locally user rights assignment. but deciding to do it or not is not my call. But i can still make the suggestion
(But if this can't be done, are the steps i highlighted correct , in your experience? )
thanks. |
My best bet would be to test it for yourself. Then you can document the exact steps that are needed to be done and in what order. (for when you are on vacation...) _________________ 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 |
|
|
|