| Author |
Message
|
| rknox |
 Posted: Wed Jan 16, 2008 1:11 pm Post subject: RAC and broker 6.1 |
 |
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
We just upgraded from broker 6006 to 6101. We would prefer to use RAC for debugging rather than the native java debugger included in 6.1. Is this feasable?
The components my company uses for authentication do not work well with MQ so we have to give full admin access to the channel between the toolkit and the cfgmgr and we do not want to give developers full admin access to the MQ environment.
Our way around this is to use RAC. From my initial tests, I can't get it to work with the toolkit the way it did with 6006.
Does RAC even work with 6.1? Is there doc out there that I am missing? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jan 16, 2008 1:15 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
RAC can't be used with v6.1, as far as I know (Huzzah!).
I would be surprised to learn that the Java debugger in v6.1 requires you to have any particular MQ access. This doesn't mean a lot, as I haven't yet managed to work with v6.1 in any depth.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Wed Jan 16, 2008 1:28 pm Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
The MQ permissions issues are a result of some of the products we use for UNIX authorization company wide. We're going to have a problem figuring that out, but I just wanted to be sure that RAC doesn't run with 6.1.
thanks |
|
| Back to top |
|
|
| jharringa |
| Posted: Wed Jan 16, 2008 1:35 pm Post subject: |
|
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
| Has anyone really had much experience with development in 6.1? I'm curious how some of the new nodes are working out. Particularly the EmailOutput node and the File nodes. |
|
| Back to top |
|
|
| mqmatt |
| Posted: Thu Jan 17, 2008 3:06 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
RAC cannot be used with v6.1. Instead, the v6.1 toolkit talks directly with the broker using Java Debug Protocol.
I've used the Email and File nodes a fair bit; I think they're great but I am slightly biased.  |
|
| Back to top |
|
|
| rknox |
| Posted: Thu Jan 17, 2008 7:09 am Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
| So now that I need to use the Java debugger, we have an environment where we don't want our developers to have full deploy rights to the configmgr, rather only use the debugger. Finding doc specific to this is difficult as well. I suppose this is a relatively unique architecture. So I see generic doc on how to use ACL's, but is there anything specific out there giving me an idea of how to block deployments, but allow debugging? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 17, 2008 7:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I don't think debugging is at all related to broker ACLs... ?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Thu Jan 17, 2008 7:40 am Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
| There has to be permissions that allow the user to access the Broker to do debugging. I want to disallow deployments to the broker while allowing broker debugging. There have to be permissions involved at the broker level, I would think. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 17, 2008 7:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Giving a developer access to the Java Debugger port for a given Execution Group does not give the user any access to the ConfigMgr for deployment or configuration changes.
There are no Broker ACLS, even in v6.1, that affect the Java Debugger port.
If you want to restrict a user from having deployment access through the ConfigMgr, then you need to set ACLs as appropriate.
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ap12520_.htm
Again, though, this is entirely separate from Debugging, and hasn't changed from v6 with the removal of RAC.
The removal of RAC has, from what I can tell, removed the ability to secure access to the Java Debug Port using anything other than network level controls. But almost nobody that I know of used those features of RAC anyway.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Thu Jan 17, 2008 8:53 am Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
This presents another problem. In 6.0 we installed RAC, set the debug port and the developers were able to use the debug options in the toolkit. Now we are using 6.1 and have made no other changes. The debug port is set and when the developer tries to use the debugger, it says the EG's are not enabled for debugging. It appears that something has to have changed from 6.0 to 6.1.
Also the toolkit does not show available EG's for debugging unless you are directly connected to a domain. Previously RAC showed the developers the EG's without being directly connected to the domain. If they now need connectivity to a domain, they then need ACL's defined at the broker level. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 17, 2008 9:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay.
This: http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ag11186_.htm
says "The execution groups are defined in the Deployment Location panel of the Test Client".
So the Select Execution Button is trying to use the Test Client to connect to the domain and look up the names of the EGs.
I think you don't need to use that button... I think if you just put in the JVM Debug port (which is tied to the EG) and other necessary info on the connect panel, and then hit Debug... you should be okay. I'm just guessing here, though.
I've never advocated using a debugger (only trace) in production environments, and I've never seen a need to restrict developers from being able to deploy to development environments... So I'm not sure I understand what the problem actually is with giving the developers access to the ConfigMgr.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rknox |
| Posted: Thu Jan 17, 2008 11:04 am Post subject: |
|
|
Apprentice
Joined: 28 Aug 2007
Posts: 34
|
| Quote: |
I've never seen a need to restrict developers from being able to deploy to development environments... So I'm not sure I understand what the problem actually is with giving the developers access to the ConfigMgr.
|
Jeff, I agree with you here, but these decisions are not made by me. I think it is just a matter of wanting to control the environment.
Let me look into your last suggestion.
thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 17, 2008 11:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The value arising from controlling development environments that tightly is significantly outweighed by the cost of slowing down development that much.
If developers have proven themselves completely ungoverned to the extent that they break everything for everyone, and it takes substantial expense to keep development mostly functional.. then it's reasonable to limit what developers can actually touch. But even then, I'd give each developer their own EG and allow them to deploy as they like to that.
QA/Perf/Test/Integration/Prod/etc./etc.. on the other hand, are hands-off and admin installs only.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mqmatt |
| Posted: Thu Jan 17, 2008 7:29 pm Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
| Remember as well, that the Unit Test license in Message Broker V6.1 allows each developer to have a broker alongside the toolkit on their own machines. |
|
| Back to top |
|
|
|
|
