Do developers have WMQ admin privileges at your shop? |
No! |
|
58% |
[ 10 ] |
Yes, in test, qa and prod - everywhere |
|
11% |
[ 2 ] |
Yes, in test and qa; but NOT prod |
|
11% |
[ 2 ] |
Yes, in test only |
|
17% |
[ 3 ] |
|
Total Votes : 17 |
|
Author |
Message
|
bruce2359 |
Posted: Fri Jan 07, 2011 8:47 am Post subject: Do developers have WMQ admin privileges at your shop? |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Do developers (or other non-administrators) have WMQ admin privileges at your shop? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Mon Jan 10, 2011 12:01 pm; edited 2 times in total |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Jan 07, 2011 12:22 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Generic no. Truth to tell sometimes yes...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Jan 07, 2011 12:33 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Might also want to be clear on Production vs. dev environments. |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Jan 07, 2011 12:39 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
I'm one of those purists who want admins to create and manage objects first in TEST, promote them directly to QA, then(ce) to PROD.
If object defs need to change, they go back to, and through TEST, QA, PROD. (With the exception of emergencies, of course.)
Most shops don't allow developers to fiddle with o/s settings, do they? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Jan 07, 2011 12:41 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
I don't disagree with that.
I'm just saying that it's not a blanket situation in all cases.
So it's possible that someone could answer "Yes", but mean "only in development". |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Jan 07, 2011 12:44 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Thanks, Jeff. Good call. Modified the poll accordingly. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
fatherjack |
Posted: Fri Jan 07, 2011 2:22 pm Post subject: |
|
|
 Knight
Joined: 14 Apr 2010 Posts: 522 Location: Craggy Island
|
bruce2359 wrote: |
Thanks, Jeff. Good call. Modified the poll accordingly. |
How do I modify my vote ???? _________________ Never let the facts get in the way of a good theory. |
|
Back to top |
|
 |
fatherjack |
Posted: Fri Jan 07, 2011 2:39 pm Post subject: |
|
|
 Knight
Joined: 14 Apr 2010 Posts: 522 Location: Craggy Island
|
What would be interesting for those respondents who reply yes would be to understand why it was felt necessary to grant them this authority or if it just happened accidentally/by default 'cos you didn't know any better at the time etc. _________________ Never let the facts get in the way of a good theory. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Jan 07, 2011 3:47 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
If you give one developer access to start / stop his one svrconn channel, but nothing else, do you answer yes to this poll?
Technically he has WMQ Admin privileges. So does the one that is (maybe incorrectly) in the mqm group or the Windows Administrator group, but there's a world of difference. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fatherjack |
Posted: Fri Jan 07, 2011 4:10 pm Post subject: |
|
|
 Knight
Joined: 14 Apr 2010 Posts: 522 Location: Craggy Island
|
PeterPotkay wrote: |
If you give one developer access to start / stop his one svrconn channel, but nothing else, do you answer yes to this poll?
Technically he has WMQ Admin privileges. So does the one that is (maybe incorrectly) in the mqm group or the Windows Administrator group, but there's a world of difference. |
Absolutely. Hence my question about why it was deemed necessary to grant admin access. 'Cos if it was just so he could start his own channel then fine. But if he could delete the QMGR then maybe not.
Maybe the poll should have been .... What do you allow you developers to do? And then a zillion options. Or maybe not. Maybe just a normal discussion thread? _________________ Never let the facts get in the way of a good theory. |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Jan 07, 2011 4:22 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
The topic of non-admins having admin privilege comes up in lots of posts. It is the source of many problems for admins.
The discussion is what I'm seeking; with the inevitable goal of getting non-admins out of the mqm group.
There are 1000 ways to skin a cat. There are somewhat less ways to start a channel or qmgr. One could create an automated task (via Tivoli, for example) that a developer could initiate without the developer having mqm authority. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Jan 10, 2011 5:08 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Lest I get banned by Vitor for bringing up the Build Engineering role again, I shall only touch on it briefly.
You would want four environments: Sandbox, Dev, Test/Perf Test, Prod. Developers would have complete reign in Sandbox. Any MQ objects that need to be created should be done using a Developer-created MQSI script run from a command line. This script would be coded and tested by Developers in the Sandbox environment.
To get those MQ objects created in any other environment after Sandbox, the Build Engineer would run the script or the automated build tool would run the script. Therefore, there is no need for Developers to have elevated authority in any environments aside from Sandbox.
People want to take short cuts and give Developers admin access to all environments, that's their bad luck. Bustard-izing the Prod environment by giving Developers admin access is a root cause for failure. If your company uses HIPAA data, the Feds will fine your company for failing to protect HIPAA data:
http://www.google.com/search?hl=en&source=hp&q=hipaa+fine+data+access&aq=f&aqi=&aql=&oq=&gs_rfai=
If your company processes credit card payments, the major card networks will turn off your access to the network until you remedy the situation. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
exerk |
Posted: Mon Jan 10, 2011 7:02 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
lancelotlinc wrote: |
...Developers would have complete reign in Sandbox. Any MQ objects that need to be created should be done using a Developer-created MQSI script run from a command line. This script would be coded and tested by Developers in the Sandbox environment... |
I worked in an environment like that once and all went well until they (they being the developers) wanted stuff promoted beyond sand-box - it failed. You see, we'd built the environments properly, i.e. security etc., and they just had a sand-box where they didn't want any niff-naff-and-trivia such as security settings holding them up.
When told what they needed to do they looked rather nonplussed, vacant, shuffled their feet, and went to management an spake thus "...we'll have to redevelop everything around the security requirements and we don't have the time to do it and make the dead-line...", and want to guess what management came and said to us? Thankfully I no longer work for that organisation.
Developers should work within the confines of the infrastructure that their applications will be deployed on, and for me that means early engagement with them to hammer out just what they need (note the use of the word need, as opposed to want) in the sand-box and what 'support' will be given. Do that early enough and they don't go off-track and cause later issues and problems, 'support' requirements etc. are actually minimised, and usually a good working relationship ensues. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon Jan 10, 2011 7:20 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
@exerk
I'm sympathetic with your experience; however, there is no MQSI code any developer could write in the mainstream of WMB development that would break any proper security arrangements.
Bruce's question is directed at MQ objects. An MQSI script is an MQSI script. Proper commands in an MQSI script will be successful in all 4 environments.
The point being that human intervention in any environment above Sandbox is not permitted. With the skilled Build Engineer and a good Hudson implementation, human intervention is unneeded. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Jan 10, 2011 7:21 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
The security issue is where I brought the internal audit group into the foray.
In exchange for a few audit-items they could ding IT for, they brought to management the concept that the test/development environment should (must) include not only applications, but also security testing and development. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
|