| Author |
Message
|
| smdavies99 |
 Posted: Sat Sep 20, 2014 11:45 pm Post subject: V7.0.1.8 to V8.0.0.0 upgrade |
 |
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I'm preparing an upgrade for one of our customers going from 7.1.0.8 to (hopefully) V8.0.0.1.
The current system is a Windows MSCS Cluster with MQ in an active/passive configuration.
Because this is V7, I use saveqmgr and amqoamd to create a backup of the current configuration. I'm using amqoamd to get a script that I can use the output script to load the defs into the new QMGRS when we build the new system on new hardware. When is is all commissioned we will switch over to the new H/Q and decommission the old servers. (the new H/W is the same PVU rating before anyone asks)
The problem I see is in that the output from amqoamd differes depending upon which node the QMGR is running on when the commands are run.
For example.
| Code: |
setmqaut -m PRODQM -n BILLING.IN -t queue -p Administrator@XXX-SYS-DEMO +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m PRODQM -n BILLING.IN -t queue -g mqm +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m PRODQM -n BILLING.IN -t queue -p wmuser@XXX-SYS-DEMO +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
|
Then on the other server I get (for the same base queue)
| Code: |
setmqaut -m PRODQM -n BILLING.IN -t queue -p Administrator@XXX-SYS-DEMO +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m PRODQM -n BILLING.IN -t queue FAIL : unresolved account +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
setmqaut -m PRODQM -n BILLING.IN -t queue -p wmuser@XXX-SYS-DEMO +browse +get +inq +passall +passid +put +set +setall +setid +chg +clr +dlt +dsp
|
It seems that the 'mqm' group is the thing causing the 'FAIL'. Obviously the group exists on both machines so I would have to be very careful when taking the backups and probably do it on both just to be safe, so that I end up with a complete set of definitions.
The customer has added some queues of their own since the system was delivered so the versions othe object definiitons we have are not going to be accurate but I want to be totally sure that the new QMGR is identical to the current one.
So my question is,
Do I need to worry about the 'FAIL' records if they apply to 'mqm'?
I think I don't need to worry because 'mqm' is added by default.
_________________
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: Sun Sep 21, 2014 12:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
mqm group is local to each machine... so this is going to puzzle you some.
Instead you should probably be using "domain mqm".
Anyways I'd just exclude from the definitions to port over anything that is -g mqm. You really don't need to define those...
Just make sure the local mqm and administrator groups contains the same actors in both machines.
Have fun. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Sep 21, 2014 1:18 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
AFAIK, the 'mqm' group is added automatically when the object is created so using 'domain mqm' isn't really an option.
All the groups and users that are needed are defined at the domain level and there are no local ones to that point you raised is taken care of.
_________________
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: Sun Sep 21, 2014 2:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smdavies99 wrote: |
AFAIK, the 'mqm' group is added automatically when the object is created so using 'domain mqm' isn't really an option.
All the groups and users that are needed are defined at the domain level and there are no local ones to that point you raised is taken care of. |
What account is the MQService running under ? (Windows services)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Sep 21, 2014 3:27 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The account that MQ is running under is called 'mqservice'. It is a member of 'Domain mqm' and is properly authorized to do things like Read Group Membership etc. All the connections to the domain for defining Auths etc work perfectly as does the failover. As I said, this is an existing system and has been running since April 2012.
The account is also a member of the local 'mqm' group.
_________________
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: Sun Sep 21, 2014 8:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
you're fine...
when running amqoamd use:
| Code: |
| amqoamd -s -m <qmgr> | find /V "-g mqm " |
This will filter out group mqm for your script...
When running on the new qmgr you will see that any object created will have -g mqm authorities. Now if you check the authorities the corresponding mqm group of the other side will show as an unknown gid.
you can and may specifically set group mqm on both sides if you want to..., just be aware that it will show as unknown gid on the other side...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
