| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Problems removing queue from cluster. |
« View previous topic :: View next topic » |
| Author |
Message
|
| gs |
 Posted: Wed Feb 13, 2008 2:10 am Post subject: Problems removing queue from cluster. |
 |
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
When a custom user alters the local queue to be in the cluster, this works fine and the queue is visible from all other queue managers. ALTER QL(Q1) CLUSNL(NL1)
However, when the user tries to remove it from the cluster, the queue is still visible on all the other queue managers. ALTER QL(Q1) CLUSNL('')
This is probably an authorities related problem since the mqm user can do the change without problem. Any clues on what object authorities to review?
Version is MQ 6.0.1.1 on Windows Server 2003. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Feb 13, 2008 2:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
What kind of non-mqm user is doing administration? On clusters yet? 
It's more likely that (as the queue's being propagated via a namelist) not all the other queue managers are up to date with the change. What happens when another queue manager tries to put to that instance of the queue? What happens when you view the queue from an FR rather than a PR?
And WHY is a non-administrator changing cluster definitions????
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gs |
| Posted: Wed Feb 13, 2008 6:56 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
This is a development environment and naturally we don't want developers to have full access to the system (via mqm). However, they can and should set up queues as they like.
I'll check what happens while trying to do a MQPUT on the queue from the PR/FR. Aswell as what the FR says about the queue.
But wouldn't PR/FR inconsistency indicate a cluster problem (channels/etc) rather than an authority problem? As I noted, propagation worked well while doing the change as user mqm.
Thanks for your input |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 13, 2008 7:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gs wrote: |
| This is a development environment and naturally we don't want developers to have full access to the system (via mqm). However, they can and should set up queues as they like. |
I've met a number of admins who'd disagree with that statement; I meet one of them every morning in the mirror when I shave! IMHO the use of queues is best determined by a trained MQ person who understands the abilities of WMQ and how to leverage it, not a developer who just defines a queue because he thinks he needs it. At a more simplistic level, who supports the infrastructure in production - the developer who "designed" it, or the MQ admin? If the former, get them to fix this problem - it'll be good practice!
| gs wrote: |
| But wouldn't PR/FR inconsistency indicate a cluster problem (channels/etc) rather than an authority problem? As I noted, propagation worked well while doing the change as user mqm. |
It might well do, which is another good reason not to allow untrained people access to administrative commands. I'd assumed you'd already checked the health of the cluster, and that no-one had tried to "fix" it because they wanted a cluster queue in a place that didn't seem to work.
(If you'd retained administrative control of the cluster, you'd know if there was a cluster problem)
Another possibility if you're determined to give developers this level of control is to have a baseline cluster you can easily rebuild from scripts, so when this happens you can quickly reset the cluster to a known, working configuration.
Just a suggestion. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gs |
| Posted: Thu Feb 14, 2008 1:57 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
| Vitor wrote: |
| gs wrote: |
| This is a development environment and naturally we don't want developers to have full access to the system (via mqm). However, they can and should set up queues as they like. |
I've met a number of admins who'd disagree with that statement; I meet one of them every morning in the mirror when I shave! IMHO the use of queues is best determined by a trained MQ person who understands the abilities of WMQ and how to leverage it, not a developer who just defines a queue because he thinks he needs it. At a more simplistic level, who supports the infrastructure in production - the developer who "designed" it, or the MQ admin? If the former, get them to fix this problem - it'll be good practice! |
With developlers I mean integration developers and not application developers. These are people with very good skills in MQ and it's a relatively small consequent group of people.
Since it's a development environment I think it's ok that they're locked down to only managing queues. All other infrastructure changes such as channels, certificates etc are handled by the MQ admins.
Thus, development environment support is very limited.
All production change proposals/designs has to be reviewed & approved by the mq admins before ANY deployment will be done in production.
Handling EVERY development queue addition/removal/change seems like an administrative nightmare.
| Vitor wrote: |
| gs wrote: |
| But wouldn't PR/FR inconsistency indicate a cluster problem (channels/etc) rather than an authority problem? As I noted, propagation worked well while doing the change as user mqm. |
It might well do, which is another good reason not to allow untrained people access to administrative commands. I'd assumed you'd already checked the health of the cluster, and that no-one had tried to "fix" it because they wanted a cluster queue in a place that didn't seem to work.
(If you'd retained administrative control of the cluster, you'd know if there was a cluster problem)
Another possibility if you're determined to give developers this level of control is to have a baseline cluster you can easily rebuild from scripts, so when this happens you can quickly reset the cluster to a known, working configuration. |
How big a damage can a person with fairly/very good skills in MQ unintentionally do to a cluster with queue-only access (no system objects except default ones)? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 14, 2008 2:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gs wrote: |
| With developlers I mean integration developers and not application developers. These are people with very good skills in MQ and it's a relatively small consequent group of people. |
If they're that good, allow them access to mqm.
| gs wrote: |
Since it's a development environment I think it's ok that they're locked down to only managing queues. All other infrastructure changes such as channels, certificates etc are handled by the MQ admins.
|
If they can issue an ALTER QLOCAL command, they can issue DEFINE CHANNEL.
| gs wrote: |
| All production change proposals/designs has to be reviewed & approved by the mq admins before ANY deployment will be done in production. |
But if they've been adding new queues, developing applications based on how they think they'd like the queues to work, potentially heading off in a direction the MQ admin team don't approve off then any review is likely to occur after the horse has not only bolted but is well over the horizon.
| gs wrote: |
| Handling EVERY development queue addition/removal/change seems like an administrative nightmare. |
I call it control. It also enables me to guide the development of the MQ infrastructure, and introduce helpful suggestions at the development stage. Ideally, the developers tell me what they're trying to achieve and I tell THEM what queues they're getting rather than just sticking in any old queue because a developer thinks they need it.
| gs wrote: |
| How big a damage can a person with fairly/very good skills in MQ unintentionally do to a cluster with queue-only access (no system objects except default ones)? |
See my comment above. If they've got ALTER access they can achieve anything. Which is potentially why you've had to start this post.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gs |
| Posted: Wed Feb 20, 2008 4:56 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
| Vitor wrote: |
| gs wrote: |
| With developlers I mean integration developers and not application developers. These are people with very good skills in MQ and it's a relatively small consequent group of people. |
If they're that good, allow them access to mqm. |
IMHO, you should ALWAYS differ between admin and user. Just the same as you don't consequently log in and administrate a *nix system as root
| Vitor wrote: |
| gs wrote: |
Since it's a development environment I think it's ok that they're locked down to only managing queues. All other infrastructure changes such as channels, certificates etc are handled by the MQ admins.
|
If they can issue an ALTER QLOCAL command, they can issue DEFINE CHANNEL. |
No, they don't have access to the default channel objects.
| Vitor wrote: |
| gs wrote: |
| Handling EVERY development queue addition/removal/change seems like an administrative nightmare. |
I call it control. It also enables me to guide the development of the MQ infrastructure, and introduce helpful suggestions at the development stage. Ideally, the developers tell me what they're trying to achieve and I tell THEM what queues they're getting rather than just sticking in any old queue because a developer thinks they need it. |
Basic infrastructure's (channels, clusters etc) one thing and integration specific queues another. Instead of playing an active role in every change there's guidelines, standard items etc. Follow them or the proposal is rejected.
Also, how you handle this depends on the organization & environment size. For us, this method is both well working and a lot more effective.
| gs wrote: |
| How big a damage can a person with fairly/very good skills in MQ unintentionally do to a cluster with queue-only access (no system objects except default ones)? |
See my comment above. If they've got ALTER access they can achieve anything. Which is potentially why you've had to start this post.....[/quote]
As I said, default object access is VERY restrictive. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 20, 2008 5:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gs wrote: |
| Vitor wrote: |
| If they're that good, allow them access to mqm. |
IMHO, you should ALWAYS differ between admin and user. Just the same as you don't consequently log in and administrate a *nix system as root |
I meant if they've got the skills claimed, allow them proper administrative access.
| gs wrote: |
| Vitor wrote: |
| If they can issue an ALTER QLOCAL command, they can issue DEFINE CHANNEL. |
No, they don't have access to the default channel objects. |
Really? Not if they've got MQ skills.
| gs wrote: |
| Basic infrastructure's (channels, clusters etc) one thing and integration specific queues another. Instead of playing an active role in every change there's guidelines, standard items etc. Follow them or the proposal is rejected. |
How do you reject a "proposal" who's already been mostly designed & coded before you hear of it?
| gs wrote: |
| Also, how you handle this depends on the organization & environment size. For us, this method is both well working and a lot more effective. |
Until you get problems like the one that prompted this thread.
But hey, it's your system. I wish you well with it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gs |
| Posted: Fri Feb 22, 2008 3:27 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
| Vitor wrote: |
| gs wrote: |
| Vitor wrote: |
| If they're that good, allow them access to mqm. |
IMHO, you should ALWAYS differ between admin and user. Just the same as you don't consequently log in and administrate a *nix system as root |
I meant if they've got the skills claimed, allow them proper administrative access. |
May I ask you, would you reason the same way regarding an operating system or any other authorities controlled environment?
| Vitor wrote: |
| gs wrote: |
| Basic infrastructure's (channels, clusters etc) one thing and integration specific queues another. Instead of playing an active role in every change there's guidelines, standard items etc. Follow them or the proposal is rejected. |
How do you reject a "proposal" who's already been mostly designed & coded before you hear of it? |
If the guidelines hasn't been followed, then there's reason to reject it. Through the many many integrations reviewed, it's mostly minor comments that can be quickly fixed before approval.
| Vitor wrote: |
| gs wrote: |
| Also, how you handle this depends on the organization & environment size. For us, this method is both well working and a lot more effective. |
Until you get problems like the one that prompted this thread.
But hey, it's your system. I wish you well with it. |
Yes, but my question wasn't if I should change the authority model. Rather, what authorities to change to stay in line with the current setup. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 22, 2008 3:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gs wrote: |
| May I ask you, would you reason the same way regarding an operating system or any other authorities controlled environment? |
Yes I would. Appropriately skilled people can either be "deputised" into the admin group in the environments they use (with the "real" admins taking the precautions named above) or banned from making changes except by request to the admin group.
I've been on both sides of the fence on many technologies; having independent MQ admins on dev, making changes myself to DB2 databases or having to get the Unix admin to change the file system even though I can write down the commands they need to use, in order.
It's all about how you want to work your system.
| gs wrote: |
| If the guidelines hasn't been followed, then there's reason to reject it. Through the many many integrations reviewed, it's mostly minor comments that can be quickly fixed before approval. |
If the design in question has been in work for 6 months and already cost a lot of money, politically it can be hard to reject. Again, it all depends on your system.
| gs wrote: |
Yes, but my question wasn't if I should change the authority model. Rather, what authorities to change to stay in line with the current setup. |
The mqm group has non-grantable authorities to administer the system.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| thipe |
| Posted: Wed Feb 27, 2008 6:31 am Post subject: |
|
|
Novice
Joined: 24 Jun 2003
Posts: 19
Location: Brasil - São Paulo
|
Hi GS . . .
There are few things yon can check to confirm your queue change.
First one would be the own mq log files , there you will find something telling how many objects where changed ... almost the same when you do a refresh ( which I don't recommend ) .
Second is to use the "amqrfdm" command and check what sequence and status you have for that queue ... you may see it as "Deleted" .
Last option would be apply a refresh from the FR with "queue" YES parameter .
I did a small test here and it worked .
Regards,
_________________
Adriano Alves
São Paulo - Brasil
Websphere MQSeries v5.3 Adm Certified
Websphere MQSeries v 6 Adm Certified |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
