| Author |
Message
|
| zpat |
 Posted: Wed Oct 07, 2015 6:36 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What's to stop a developer not using these MQ services and just connecting to a queue manager by configuring node properties?
What's to stop this being promoted into production in this state, accidentally or otherwise?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Oct 07, 2015 6:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
What's to stop a developer not using these MQ services and just connecting to a queue manager by configuring node properties?
What's to stop this being promoted into production in this state, accidentally or otherwise? |
Are these properties not overrideable?
I know you don't like to use mqsiapplybaroverrides, but it is excellent for this kind of situation.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 07, 2015 6:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
What's to stop a developer not using these MQ services and just connecting to a queue manager by configuring node properties?
What's to stop this being promoted into production in this state, accidentally or otherwise? |
What's to stop a developer promoting a flow that has an MQGet node in a loop, or goes through a big list with an index not a reference, or any other poor / undesirable practice?
The same mechanism prevents this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Oct 07, 2015 7:12 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
There is a difference between poor code within that environment and the ability to consume messages from anywhere.
Code logic errors generally get sorted out during development. They don't suddenly come back when the code is promoted.
However I can see nothing that would prevent a message flow in production from accidentally connecting to the same queue but on the wrong QM.
OK, maybe it's an additional issue, but it's a big one if (like most long-time users) your message broker is primarily consuming messages from MQ.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 07, 2015 7:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| However I can see nothing that would prevent a message flow in production from accidentally connecting to the same queue but on the wrong QM. |
How do you prevent a flow in production from accidentally connecting to a QA database? Or a flow in QA connecting to Prod?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Oct 07, 2015 7:20 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| zpat wrote: |
However I can see nothing that would prevent a message flow in production from accidentally connecting to the same queue but on the wrong QM.
|
A case of what can go wrong will go wrong...
This example is a good case for making every QMGR use a different Listener port AND locking down the list of IP's that can connect to each and every QMGR.
As the Scoust say, 'Be Prepared'.
My rules for IIB10 and Remote Queue Access are Yes for Dev and Level 1 test but only for flows used in testing. None of the Flows that would be used in Production will use this feature.
_________________
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 |
|
|
| murdeep |
| Posted: Wed Oct 07, 2015 8:10 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| zpat wrote: |
| However I can see nothing that would prevent a message flow in production from accidentally connecting to the same queue but on the wrong QM. |
Really? for clients how about deploying SSL and using the SSLPEER channel attribute to restrict who can connect. For server how about using a different userid for the Prod IIB and restricting Prod qmgr/queue access to only that userid. |
|
| Back to top |
|
|
| murdeep |
| Posted: Wed Oct 07, 2015 8:32 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| Vitor wrote: |
As an admin, I don't want a web of SVRCONN channels. I want some control over message flow, message priority, the ability to use pub/sub and the decoupled joy that only an XMITQ can bring. I don't want every single application (especially every single application all running under mqbrkrs) authorized to every single queue manager. I want my controlled topology, where it's easy to see when some application is being a jackass, where sanction is available and multiple routes can be defined for those 25Mb Java-Classes-Serialized-As-XML messages can lumber between queue managers and not spook the herd of tiny SOAP-over-JMS messages trying to meet their sub second SLA. |
Ok let me play devil's advocate here, but it seems to me that using client channels we can address most of the issues you have listed. For example by using a client you wouldn't have to concerned about a 25M message impacting the delivery of a smaller message on your MQ network since they would traverse unique client connections so this eliminates the scenario where many small messages enqueue behind a large message on the SCTQ or DQM xmitq. If an application is being a jackass then I suspect that would be mitigated by using client channels since it would only impact the enqueue or dequeue of messages to that specific application's queues and I don't have to be concerned with said jackass flooding my MQ network. As far as not wanting to authorize the IIB userid to every qmgr and it's queues I don't see how is any different than allowing access to any other application or user. An MQAdmin would still have to manage the security so not using client channels would not eliminate the need to perform this function.
I tend to agree with the SMEs here that I wouldn't want to start using clients but if an architect comes to me and proposes it the only real technical reason I see to not do it is the global UOW issue. The other reasons listed seem more like "I wouldn't do that because, well, I don't particularly like it". |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Oct 07, 2015 8:48 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| murdeep wrote: |
| zpat wrote: |
| However I can see nothing that would prevent a message flow in production from accidentally connecting to the same queue but on the wrong QM. |
Really? for clients how about deploying SSL and using the SSLPEER channel attribute to restrict who can connect. For server how about using a different userid for the Prod IIB and restricting Prod qmgr/queue access to only that userid. |
Yes, this is all possible but IMHO, you are really complicating matters with no good reason.
KISS rules IMHO.
Do you want even more certificates expiring?
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Oct 07, 2015 8:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Your production environment needs to be secure. both from outside and inside.
This means, among other things, that apps not deployed in production can not talk to production queue managers.
The preprod/staging envirnoment needs to mirror production. That means that apps not deployed in staging can't talk to staging queue managers.
If you aren't doing those things, you probably aren't in compliance with industry regulations/standards and your own change management protocols.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| murdeep |
| Posted: Wed Oct 07, 2015 9:38 am Post subject: |
|
|
Master
Joined: 03 Nov 2004
Posts: 211
|
| smdavies99 wrote: |
| murdeep wrote: |
| zpat wrote: |
| However I can see nothing that would prevent a message flow in production from accidentally connecting to the same queue but on the wrong QM. |
Really? for clients how about deploying SSL and using the SSLPEER channel attribute to restrict who can connect. For server how about using a different userid for the Prod IIB and restricting Prod qmgr/queue access to only that userid. |
Yes, this is all possible but IMHO, you are really complicating matters with no good reason.
KISS rules IMHO.
Do you want even more certificates expiring? |
T.Rob's head would explode in this thread. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 07, 2015 9:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Do you want even more certificates expiring? |
Yes. Certificate management is as hard as you make it.
You can't avoid SSL (and as has been pointed out, make T.Rob's life's work irrelevant) just because "it's too complex".
We're moving to a much greater use of SSL because it simplifies things compared to our previous model. And yes, we've had to put some thought and effort into certificate management. It's still a net win.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Oct 07, 2015 11:10 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Vitor wrote: |
| zpat wrote: |
| However I can see nothing that would prevent a message flow in production from accidentally connecting to the same queue but on the wrong QM. |
How do you prevent a flow in production from accidentally connecting to a QA database? Or a flow in QA connecting to Prod? |
Simple. I control the ODBC.ini file - so it can't connect to a database that I have not defined. No bar file can override that. So it is out of their hands and into mine. The database nodes do not define where the database is.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 07, 2015 11:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| I can see the IIB v10 MQ client connection being a bit of a nightmare to control. |
So should we push for a "compatibility mode", where IIB doesn't allow client connections and forces the existing bindings behavior?
Or push for the removal of the ability for individual programmers to set connections and only use a CCDT? This would be analogous (IMHO) to the control offered by the use of the ODBC.ini file you describe.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 07, 2015 11:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| Vitor wrote: |
| zpat wrote: |
| However I can see nothing that would prevent a message flow in production from accidentally connecting to the same queue but on the wrong QM. |
How do you prevent a flow in production from accidentally connecting to a QA database? Or a flow in QA connecting to Prod? |
Simple. I control the ODBC.ini file - so it can't connect to a database that I have not defined. No bar file can override that. So it is out of their hands and into mine. The database nodes do not define where the database is. |
How do you enforce that all db access is done from ESQL, and not Java?
How do you enforce that any Java DB access is done using the broker JDBC functions, rather than hand-coded JDBC functions?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
